Deployment
Human in the loop: where approval should stay
Human-in-the-loop isn't a compromise, it's a design decision. Where to keep a person in the process, and how to stop approval degrading into rubber-stamping.
Talk about an AI project long enough and the question arrives: “so we won’t have to check it any more, right?”
The short answer: of course you will — but not everything, and not the way you do now.
Approval isn’t weakness
“Human in the loop” reads easily as a half-measure: as if the system weren’t good enough, so someone has to sit next to it. In practice it’s the reverse.
In most processes the work isn’t the decision. The work is assembling what the decision needs: finding the purchase order, checking the framework agreement, looking up the exchange rate, working out who owns it. That’s forty minutes. The decision itself is five seconds.
If the system does the forty minutes and leaves the five seconds to a person, the process got 98% faster — while accountability stayed exactly where it belongs.
Where a human should stay
Three questions decide it.
Is the error reversible? A misclassified email can be reclassified. An initiated payment cannot be pulled back. Where it isn’t reversible, a human stays — regardless of the measurement.
Will anyone notice? If the error surfaces at the next step, that’s manageable. If it only surfaces at year-end close, that’s a different category. The silent error is the expensive one.
Is there external accountability? Where a regulator, an auditor or a contractual counterparty can demand an explanation, you need a person who owns it. That isn’t a technical question.
How to stop it becoming rubber-stamping
The biggest risk isn’t that the human slows things down. It’s that they stop checking. If the system proposed correctly three hundred times in a row, nobody is going to look at the three hundred and first.
A few things that work against that:
Show the source, not just the proposal. The approval screen carries the invoice image with the field the total came from highlighted. Checking becomes a glance, not a separate search.
Say how confident it is. When the system is uncertain, it should say so — and those cases should sit in their own queue, in a different colour. Attention is finite; point it where it counts.
No bulk approve. A “select all → approve” button kills review. If a category has genuinely earned bulk treatment, automate it rather than dressing it up as human approval.
Measure back. Occasionally inject cases where you know the right answer and see whether they’re caught. If not, approval has become a formality and the process, not the people, needs changing.
The exception queue
What the system won’t carry through can’t disappear. It goes into its own queue, and every item carries three things: why it stopped, who owns it, and when it’s due.
That queue is the best single health metric for the system. If it’s growing, something broke — or reality changed and the system has to change with it.
The transition
In practice it usually goes like this:
- Shadow mode. The system runs and proposes, but the colleague works as before. We compare the two.
- Proposal. The colleague starts from the system’s proposal and corrects it where needed. Every correction feeds back into the evals.
- Approval. The system prepares, the human approves.
- Partial automation. High-confidence categories go on their own; the rest stay on approval.
Plenty of processes stop at step four, and that is entirely fine.
Related: exception handling and shadow mode.
Questions on this topic
Doesn't human approval slow everything down?
It depends what they're approving. If the system has already gathered the sources and justified its proposal, approval takes seconds — because the bulk of the work was never the decision, it was assembling what the decision needed.
When can the human come out of the loop?
Per category, on measurement. If a segment has held above 99% agreement for months and the error is reversible, it can go automatic. Elsewhere a human may stay for years — that isn't a failure.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.