Human in the loop is not a control unless the person can say no

Putting a person between an AI agent and its action only controls anything if that person can refuse. That takes three things: enough time to look properly, enough information to judge the case, and the authority to say no without being overruled or penalised. Remove any one and the human in the loop becomes a signature on someone else's decision.

Why is "a human approves it" so often an empty control?

Because it is easy to design an approval step and hard to design a refusal. Most approval screens are built around the expected case: the agent has drafted something, the reviewer checks it, the reviewer clicks approve. The flow is optimised for speed, the queue is measured on throughput, and approving is one click while refusing means writing a reason, choosing an alternative and handling the customer.

Under those conditions people approve. Not because they are careless, but because the system has made approval the default and refusal the exception that needs justifying. The control exists on the process map. In practice the agent decides and the person confirms. Our explainer on what human-in-the-loop means covers the basic definition; the problem is what happens when it is implemented without the conditions for refusal.

What does a reviewer need in order to say no?

Three conditions, each necessary on its own.

Time is the condition most often missing. If a reviewer has forty seconds per item and the agent's proposal needs three minutes to check, the reviewer will either rubber-stamp or fall behind. Neither produces control.

Information is the next. A reviewer shown a polished draft refund letter cannot judge whether the refund should happen. They need to see why the agent proposed it, which facts it relied on and where each came from, and which limit stopped the agent from acting alone. Without that, they are proofreading, not reviewing.

Authority is the hardest to see from outside. A reviewer may have a refuse button and still not use it, because their manager questions every refusal, or because refusals count against them, or because the last person who refused was overruled by someone more senior. Authority that is never exercised is not authority.

How can you tell whether reviewers are really able to refuse?

Look at what they do, not at what the process says. Four signals help.

1. The refusal and edit rate. If reviewers approve nearly everything unchanged over months, either the agent is unusually good or nobody is reading. Sample and check which.
2. Time per item. Very short, very consistent review times suggest clicking rather than reading.
3. What happens after a refusal. If refusals are routinely reversed by someone else, the original reviewer did not have the authority.
4. Planted cases. Put a few cases into the queue that should clearly be refused and see whether they are caught.

None of these is an accusation. They are tests of whether the control exists. A reviewer who approves a planted bad case under impossible time pressure has shown that the design failed, not that the person did.

Does every agent action need a person who can say no?

No, and pretending otherwise usually makes oversight worse. If every routine action needs approval, queues grow, review time per item falls and refusal becomes impossible in practice. Our piece on whether every agent should have a human in the loop makes the case for being selective.

The better design puts a person with real power to refuse on the actions that need judgement: those above a limit, those that are hard to undo, those relying on weak evidence. Routine actions within proven bounds can run, with people watching the pattern rather than each item. That is closer to what is often called human-on-the-loop: supervision of the whole, with the power to intervene, rather than approval of each step.

Concentrating review where it matters is what gives reviewers time. Fewer items, chosen because they need a decision, can each get the attention a refusal requires.

What do regulators mean by human oversight?

The EU AI Act, in Article 14, requires high-risk AI systems to be designed so that people can oversee them effectively, which includes being able to understand the system's output, decide not to use it and intervene. That is close to the three conditions above, written as a design duty. Deployers carry their own obligations to assign oversight to people with the competence and authority to exercise it. Our comparison of human-in-the-loop and human oversight under the EU AI Act explains how the two ideas relate.

Outside the EU, the principle is similar even where the words differ. Supervisors tend to ask whether oversight is meaningful, not whether a person's name appears in the workflow. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

What is the trade-off in designing for real refusal?

Real refusal is slower and more expensive. Reviewers need more time per item, better screens showing sources and bounds, and a culture where refusing is treated as part of the job. Throughput falls in the short run. Some refusals will be wrong, and customers will wait while someone checks.

The alternative is a control that looks like oversight and does nothing. When something goes wrong, the record will show a named person approved it, and that person will reasonably say they had neither the time nor the information to do anything else. The accountability you thought you had will not hold.

Design the approval step around the refusal, not the approval. Give reviewers the case, the sources, the deciding bound and enough time. Measure them on the quality of their decisions, not the speed. And put them only where a decision is needed, as part of the wider approach in our guide to agent governance as a bound, not a model.