Short answer: Place human review where the consequence of an undetected error is high and where a person can realistically detect the error. Review that a human cannot meaningfully perform — approving fifty outputs a minute — is theatre, not a control. Design checkpoints around consequence, make them practical, and document what was reviewed and by whom.
What "human in the loop" actually means
It's often used loosely to mean a person is somewhere nearby. Usefully, it means something specific: a human makes or confirms a decision before it takes effect, with genuine ability to change the outcome.
Three distinct arrangements, frequently conflated:
- Human in the loop — the system pauses; a person decides; the process continues.
- Human on the loop — the system proceeds; a person monitors and can intervene.
- Human in command — the system runs autonomously; a person has oversight, audit and the ability to shut it down.
These offer very different levels of control. Choose deliberately and write down which you've chosen.
Where checkpoints belong
Score each AI-assisted step on two axes: consequence of an undetected error, and detectability by a reviewer.
- High consequence, high detectability — mandatory review. Client deliverables, published content, anything with figures. A person can genuinely catch problems here.
- High consequence, low detectability — don't use AI, or add a deterministic verification step. If a reviewer can't realistically tell whether the output is correct, human review provides comfort rather than control.
- Low consequence, high detectability — spot-check periodically. Internal summaries, draft notes.
- Low consequence, low detectability — monitor aggregate outcomes rather than individual outputs.
How to make review meaningful rather than performative
The failure mode is rubber-stamping — a reviewer who approves everything because the volume makes real scrutiny impossible, or because the output always looks plausible. Countermeasures:
- Give reviewers time proportionate to the task. If the throughput requires ten seconds per item, you don't have review.
- Show the reviewer the source. Reviewing a summary without access to the original is not review.
- Ask for a specific judgement rather than general approval. "Are these three figures correct?" produces better checking than "Approve?".
- Track the rejection rate. A reviewer who never rejects anything is either receiving perfect output or not reviewing. Investigate which.
- Rotate reviewers on repetitive checks to counter habituation.
Documenting it
For anything with regulatory or contractual weight, keep a record of what the system produced, what the reviewer saw, what they decided, and when. Not an elaborate audit system — a log with those fields covers most needs.
This matters for two reasons. It's evidence of the human oversight that regulation increasingly expects, and it lets you analyse where the AI actually goes wrong, which is how you improve the workflow rather than guessing at it.
When to remove a checkpoint
Checkpoints have a cost, and unnecessary ones train people to ignore all of them. Remove one when you have evidence — a documented period with a low rejection rate on a low-consequence step — rather than because it's slowing things down. Removing a checkpoint on a high-consequence step because it's inconvenient is how incidents happen.
Frequently asked questions
Does human review make an AI system compliant?
It's a component, not a complete answer. Where high-risk obligations apply, human oversight is one requirement among several. Where they don't, review is good practice and evidence of reasonable care.
How do I stop review becoming a bottleneck?
Reduce the volume needing review by improving the upstream process, rather than reducing the depth of review. Batching and clear acceptance criteria help.
Who should review?
Someone with the domain knowledge to detect errors and no incentive to approve quickly. Those two conditions rule out more candidates than expected.
Automate the predictable, keep judgement human — it's how we design every system. See our approach.
