In most organisations, nobody. Verification is the one stage of AI-assisted work that everybody assumes is happening and almost nobody has assigned. It is not in a job description, not in a budget line, not on an org chart, and not usually in the process document. It is assumed to be a property of the workflow rather than the responsibility of a person, and assumed responsibilities are the ones that fail quietly.
This is now a live legal question as well as a management one. Since 2 August 2026, Article 14 of the EU AI Act requires that people assigned to oversee a high-risk system are enabled to detect anomalies, interpret output correctly, and disregard or override it. That presupposes there is somebody assigned. Many organisations will discover, under audit, that there is not.
Why it disappears
It was never a job, it was a by-product. When a person wrote the report, checking was part of writing it. Separate the generation from the person, and the checking becomes a distinct task nobody was hired to do and nobody has time allocated for. It falls into the gap between the person who prompted and the person who signed.
It is priced as administration. Producing is visible, senior and rewarded. Checking is invisible until it fails, and the person who catches an error gets less credit than the person who produced the output that contained it. That mispricing is what I call the verifier's discount, and it reliably produces less verification than an organisation thinks it has bought.
Sign-off gets mistaken for verification. They are different acts. Sign-off is accepting accountability for an outcome. Verification is establishing whether the content is correct. A senior person can perform the first without being able to perform the second, and in AI-assisted work that combination is now common.
The people best placed to do it are the ones being removed. The junior work that produced the pattern recognition needed to spot a wrong answer is the work most easily automated. See the missing rungs.
The test that settles it
The capability test
Could the person verifying this have produced it themselves, well enough to notice if it were wrong?
If no, the verification is decorative. It should be recorded as absent rather than as satisfied, because recording it as satisfied is what turns a capability gap into a governance failure. This is the only test on this page that cannot be gamed, and it is the one almost nobody applies.
The reason it is decisive is that fluency carries no signal. A language model's confidence is a property of its writing style rather than of its knowledge, so a plausible wrong answer and a correct one look identical to anyone who cannot independently evaluate the content. Reviewing without competence is not a weaker form of verification. It is a different activity that produces a similar-looking record.
Four ownership models, and what each actually costs
The producer verifies. Whoever prompted checks their own output. Cheapest, and it fails on exactly the errors that matter, because someone who accepted a framing is poorly placed to notice the framing was wrong. Workable for low-consequence work, not for anything else.
A named peer verifies. Someone with equivalent domain competence, not in the production chain. This is the model that passes the capability test most often. It costs real time and it is the first thing cut when throughput matters.
A specialist function verifies. A dedicated group, as model risk management works in banking, which is the most mature precedent available and worth studying rather than reinventing. Strong for high-consequence, repeated decisions. Expensive, and it can turn into a rubber stamp if the function lacks authority to stop work.
Nobody verifies, declared. For genuinely low-stakes output, this is a legitimate and honest choice, and it is far better than pretending. The failure mode is not choosing this; it is choosing it by default and describing it as one of the other three.
Where this is uncertain
No study has compared these four models for accuracy or cost. The recommendation to prefer a named peer rests on the capability test and on the Vaccaro meta-analysis finding that human-AI combinations underperform the better party when the human is judging rather than producing, not on a trial of ownership structures. It is a reasoned position, not a demonstrated one, and it is worth saying so.
There is also a real objection. Where a system genuinely outperforms every available human verifier, insisting on human verification buys accountability at the price of accuracy. That may be the right trade for legitimacy and for the ability to explain a decision, but it is a trade, and organisations should make it deliberately rather than assume they are getting both.
The SuperSkills view
Verification is not a separate activity from expertise. It is expertise, applied. That single reframing changes what an organisation does about it.
If verification is administration, you buy more of it cheaply and treat it as overhead. If verification is expertise applied, then verification capacity is a stock that has to be maintained, and it depreciates precisely when you automate the work that built it. An organisation that automates production while assuming verification will look after itself is spending down an asset it never put on the balance sheet. That is capability debt in its most operational form.
Which produces an uncomfortable rule: you cannot automate a task and retain the ability to verify it unless you deliberately fund the practice that keeps someone competent at it. That looks like paying people to do work a machine does faster, which is why almost nobody does it. It is actually paying for the ability to notice when the machine is wrong, and after 2 August 2026 in the EU it is also paying for the ability to pass an audit.
What to do this quarter
- Name a person per stage, in writing, before the work starts. Not a team, not a function. The Delegation Boundary Map has a column for exactly this, and the gaps become visible as soon as you try to fill it in.
- Apply the capability test to each name, privately. Ask them whether they could detect the error. The answer is often no, and it is almost never recorded.
- Count overrides. If nobody has disregarded the system this quarter, the right to refuse is untested rather than unnecessary.
- Put time in the plan. Verification with no allocated time is verification that will not happen under pressure, which is when it matters.
- Pay for it as skilled work. While it is priced as administration you will keep getting the amount of it that administration buys.
- Declare the gaps. Where nobody can verify, say so and set the consequence tier accordingly. An honest gap can be managed; an assumed control cannot.
Related SuperSkills research
On the mispricing, the verifier's discount. On the legal duty, meaningful human oversight. On the practical framework, the Delegation Boundary Map. On detecting error at all, how do I know when AI is wrong and automation bias. On the underlying erosion, capability debt.
Key sources
- Article 14, Human Oversight, Regulation (EU) 2024/1689. In force 2 August 2026.
- Vaccaro, M., Almaatouq, A. and Malone, T. (2024). When combinations of humans and AI are useful. Nature Human Behaviour, 8.
- Parasuraman, R. and Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. Human Factors, 52(3).
- Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6).
- Mavundla v MEC: COGTA KwaZulu-Natal [2025] ZAKZPHC 2. High Court of South Africa, on verifying machine output with another machine.
About this research
Rahim Hirji is the author of SuperSkills: The Seven Human Skills for the Age of AI (Kogan Page, 2026) and founder of The SuperSkills Intelligence Company. The regulatory position is quoted from the primary text and dated; the interpretation is the author's and kept separate. Not legal advice. Reviewed quarterly.
Cite this
Hirji, R. (2026). Who owns verification when AI does the work? The SuperSkills Intelligence Company. Last reviewed 26 August 2026. thesuperskills.com/research/who-owns-verification-when-ai-does-the-work