A Human in the Loop Needs a Job

One of the most reassuring phrases in AI is also one of the least useful: “there is a human in the loop.” It sounds like a control. Often it just means that, when something goes wrong, there will be a person somewhere near the process who can be asked why they did not stop it. The question that matters is: what job has the human actually been given?

If an AI system produces a recommendation and a person is expected to approve it, then that person needs a defined decision, usable evidence, authority to intervene, and a route for what they learn to change the system. Without those things, “human in the loop” can become a polite description of responsibility being passed downstream.

Review is not the same as control

The most common version of human oversight is a review step at the end of an automated process. A human can check a small number of high-consequence outputs, approve a payment, decide whether a drafted response should be sent, or stop an action that crosses an authority boundary.

However review becomes a weak control when the person arrives too late, receives too much material, or cannot see how the system reached its result. A reviewer who is asked to clear hundreds of plausible-looking recommendations in a short period is doing a different job from a decision-maker. They may be carrying the formal responsibility, but they do not have meaningful control over the process.

This is one reason that generative AI can feel productive locally while making work harder overall. A human-factors synthesis describes how automation can move people from producing work to evaluating it, disrupting concentration and leaving them to reconstruct context after the system has already done something. The issue is not simply that people dislike reviewing AI output, it is that supervision can demand scarce expertise and attention at exactly the point where the process is least transparent.

The human role changes with the work

There is no single right place for a human to sit in an AI-enabled process. The right arrangement depends on the consequence of being wrong, how easily the result can be checked, whether an action can be reversed, and who carries the cost when it cannot.

Bounded work with clear checks may not need a human checkpoint before every action. Running a test suite, drafting a first version of a document, or classifying a straightforward record may be better controlled through the environment: permissions, checks, logs, and the ability to undo a mistake.

Other work benefits from AI preparation but still needs a human decision at the point where judgement, authority, or external consequence becomes real. The system might assemble the evidence, suggest an option, or do the administrative work around a decision, but the checkpoint sits where the recommendation becomes an accountable choice.

Decisions that affect somebody’s rights, safety, access to a service, or ability to challenge an outcome need a stronger human role again. The person should be able to understand the basis for the recommendation, recognise when the case does not fit the pattern, and take a different course without fighting the system’s workflow to do it.

This is consistent with NIST’s AI Risk Management Framework, which treats human-AI interaction as a context-dependent design choice rather than a universal checkbox. That moves the autonomy question away from whether we are “in” or “out” of the loop and toward a more practical design problem: which decisions are delegated, which remain human, and what evidence supports each handover.

Give the person a real operating role

When trying to work out whether human oversight is genuine, I look for four practical conditions:

• The person needs a defined decision. “Review the output” is not a decision. “Approve this action if the evidence meets these conditions, otherwise return it for investigation” is closer to one.
• They need usable evidence. A confident-looking answer is not evidence, and neither is a long activity log that nobody can reasonably read. The system should show the source information, important assumptions, uncertainty, and any checks it has already performed in a form that fits the decision at hand.
• They need authority. If the human can only agree with the system, or has to navigate several layers of exception handling to disagree, they are not providing oversight so much as they are validating the appearance of oversight.
• What they learn must travel back into the system. If the same error, edge case, or harmful effect appears repeatedly, it should be possible to change the data, workflow, decision rules, guidance, or permissions that produced it. Otherwise each reviewer is left to rediscover the same failure one case at a time.

The UK government’s Data and AI Ethics Framework connects accountability with clear roles, monitoring, feedback, challenge, and redress. A named reviewer is only one part of an accountable system; the organisation also needs a way for those reviewers and affected people to surface problems and see whether anything changes.

Do not make people the last line of defence by default

One lazy design move in AI projects is to automate as much as possible, then put a person at the end to catch anything that went wrong. It looks prudent because a human remains involved. In practice, it can be a way of avoiding the harder work of deciding what should be automated, what checks belong in the system, and what volume of review a person can genuinely perform.

Good controls begin earlier: they constrain what the system can access and do, make important actions traceable, use checkpoints where the cost of a wrong action is high and keep the route to escalation clear. They also accept that some work should remain recommendation-only because the difficult part is not producing an answer, but judging whether it is fair, proportionate, and defensible.

That does not mean treating every AI-assisted task as if it were a high-stakes decision. Over-control can be its own form of failure: a weekly governance meeting to approve low-risk draft summaries, for example, may slow the work without adding any evidence that a reviewer could not check directly in the document. The point is to match the control to the work. A person reviewing ten well-evidenced exceptions may add real value; the same person rubber-stamping a thousand opaque outputs does not.

The phrase “human in the loop” is worth keeping only when it describes a job that somebody can actually do. Before relying on it, ask what would happen when that person spots a problem. If the honest answer is that they can only approve, apologise, or work around the system one case at a time, then the loop is not yet a safeguard.