Human review of AI work has to be able to say no.

“A person reviews everything before it goes out.” Agencies say this to clients about AI-assisted work all the time, and it is the right instinct. It protects the client only when the review is real. That takes a reviewer who can see what the AI was working from and who is free to send the draft back.

What makes a human review real?

Think of a parcel at the door. You can sign the courier’s screen without opening the box, and your signature looks the same whether the box holds four mugs or three. Or you can open it on the step, check it against the order and hand it back when a mug is missing. Only the second is a review. It needs the order to compare with, a minute to look, and the freedom to hand the box back.

Researchers have a name for the slide from opening the box to signing for it unopened: overreliance. A Microsoft Research review of about 60 papers defines it as users who start accepting incorrect AI outputs¹. It adds that calls for human oversight make users the last line of defense against AI failures¹. That is a lot to hang on one person with an inbox.

A reasonable fix would be to have the AI explain itself. It helps less than you would hope. In a preprint of user studies on three datasets, explanations increased the chance that humans will accept the AI’s recommendation, regardless of its correctness². The authors also found that the improvements from pairing people with AI were not increased by explanations. A tidy rationale can make agreeing feel safer than it is.

What does a real review need?

Four things, and none of them is exotic. They are design choices made before the first draft arrives, which is why they are easy to skip.

The European Union’s AI Act describes much the same thing for high-risk systems. Article 14 says the people given oversight must be able to stay aware of the tendency of automatically relying or over-relying³ on the output, to decide not to use the system, to override or reverse its output, and to intervene or stop it. That category is defined narrowly, so check whether a client’s use falls inside it. As a description of what a reviewer needs, it travels well.

What's Real?

• •Overreliance is a documented problem. Microsoft Research’s review covers how to measure overreliance¹ and what its consequences are, which makes it something a team can check for rather than a vague worry.
• •More explanation is not the cure. The Bansal preprint found explanations made people more likely to accept the recommendation² whether or not it was right. Show the reviewer the source, and keep the AI’s own reasoning as a side note.
• •Authority matters as much as attention. Article 14 lists the power to decide not to use³ the system and to stop it. A reviewer who cannot reject the work is only watching it.
• •Approval belongs on actions with consequences. The Open Worldwide Application Security Project (OWASP) advises using human-in-the-loop control to require a human to approve high-impact actions⁴ before they are taken. The same logic is at work in prompt injection⁵.
• •Still early: none of these sources says how much review is enough. That depends on the stakes and the error rate, so treat any fixed sampling number from a vendor as theirs.

The “so what” — for anyone serving tech clients

• •Put the reviewer in the scope. Write down who checks, what they see and that they can reject. A client reads that as quality control, and it keeps the review from turning into ceremony.
• •Put the source next to the draft. A reviewer who can compare a claim with its source can find an error. One asked whether it looks right can only judge the tone.
• •Spend review where mistakes cost most. Publishing, sending, paying and anything carrying a client’s name get a person. Internal brainstorms can skip it. That is the layered thinking behind guardrails⁶.
• •Test the reviewer too. Slip a known error into a small sample and see whether it is caught. Evals⁷ do this for the AI, and the same habit works on the process.