Human-in-the-Loop Is a Design Decision, Not a Checkbox

Photo: Chopshop23, via Wikimedia Commons · CC BY 4.0
Almost every AI proposal I read these days contains a line saying that "a human remains in the loop." It is meant to be reassuring. Quite often it describes a person at the end of the process with an Approve button, looking at a screen full of values they have no practical way of checking.
That person is not overseeing anything. They are providing a signature.
The rubber stamp problem
There is a well-documented tendency, usually called automation bias, for people to accept what a system suggests, especially when that system is right most of the time. If the AI gets 97 cases out of 100 right, the reviewer learns very quickly that clicking Approve is nearly always fine. By mid-afternoon, they are approving the other three as well.
This is not laziness. It is a perfectly reasonable response to a badly designed task. If you ask someone to find three errors hidden among ninety-seven correct items, with no hint of where they are, you have built a process that depends on them failing gracefully.
Put the person where the uncertainty is
The better approach is to let the system tell the reviewer where to look. If the extraction is unsure about a value, highlight that value and show the sentence it came from right next to it. If a price falls outside the normal range for that customer, say so. If a rule could not reach a decision, explain which rule and why.
The goal is for the reviewer to spend their attention on the three cases that need it, instead of having to rediscover them every single time.
- Show the source: the email line, the drawing note or the order row that produced each value.
- Show the reason: which rule fired, which threshold was crossed, what the model was unsure about.
- Separate the routine from the exceptional. Routine items can be approved in a batch. Exceptions deserve their own screen.
- Make rejecting as easy as approving. If correcting a value takes five clicks and approving takes one, you already know which will happen.
Decide what the person is actually allowed to do
A review step only means something if the reviewer can change the outcome. Can they edit the value? Send it back? Escalate it? Stop the process entirely? If the only realistic option is Approve, and Reject leads to a phone call and a manual workaround, the review is decoration.
It also helps to be explicit about who is accountable. Not "the planning team", but a named role that owns the decision. When something goes wrong, it should be obvious who looked at it and what they could see at the time.
A useful test
Take ten items from yesterday's review queue and ask the reviewer why they approved each one. If the honest answer for most of them is "it looked fine", the process needs another look. The person does not.
Audit the approvals, not just the AI
Once a system is running, sample the approved items regularly, including the boring ones, and check a few against the source by hand. You are testing two things at once: whether the AI still performs the way it did when you measured it, and whether the review step still catches what it should.
Log who approved what, when, and on which version of the model and the rules. This is not about blame. When a pattern of errors shows up three months from now, you want to be able to see where it started.
Less review can mean more oversight
It sounds backwards, but it holds up. A process where the AI handles the clearly routine cases, and routes a small number of genuinely uncertain ones to a person with the right context, gives you better oversight than one where every item passes through a tired reviewer. That person's attention is the scarce resource. Spend it where it changes something.
That is what "human in the loop" should mean. Not a person somewhere in the process, but a process designed around what that person can actually judge.