“A human will review it” is one of the most common safeguards in AI projects. It is also one of the least designed. The phrase appears in a proposal, reassures everyone in the room, and then arrives in operation as a queue that nobody sized, owned, or measured.
Within weeks, one of two things happens. Either the queue grows until the system is slower than the manual process it replaced, or reviewers start approving items without really looking. In both cases, the safeguard has stopped doing its job.
Human review works when it is treated as part of the product: a step with a purpose, a defined scope, and a person who can actually complete it well.
Decide what review is for
Review can serve different purposes, and each needs a different design:
- Preventing harm before an action reaches a customer or a record;
- Applying judgment the system is not permitted to exercise;
- Checking quality on a sample to detect drift; and
- Building evidence that a category of work can be trusted with more autonomy.
When a team cannot say which purpose a review step serves, it usually tries to serve all of them by reviewing everything. That is the design most likely to fail.
Review the cases that carry consequence
Not every output needs a person. Route to review based on what could go wrong, not on a blanket rule. Useful triggers include:
- the action is irreversible or reaches a customer directly;
- the amount, value, or risk crosses a defined threshold;
- the system is missing required information or found conflicting sources;
- the request falls outside an approved category; and
- the person on the other side asks for someone accountable.
Everything else can proceed, with a sample reviewed for quality. This keeps attention on the work where a person changes the outcome.
Give the reviewer a decision, not a document
A reviewer who receives a full transcript and a vague prompt to “check this” will either spend too long or skim. A good review step presents:
- the proposed action, stated plainly;
- the reason it was routed for review;
- the sources the system used, with the relevant part visible; and
- the specific question the reviewer is answering.
Offer clear choices—approve, edit, reject, or escalate—and capture a short reason when the reviewer changes something. That reason is what turns review from a cost into a source of improvement.
Review is only as good as the decision it asks a person to make.
Size the queue before launch
Review is real work, and it competes with everything else on a person’s day. Before launch, estimate how many items will be routed, how long each should take, and who will handle them at busy times.
If the numbers do not fit the team’s capacity, change the design before go-live: narrow the scope, tighten the routing rules, or add reviewers. Discovering the gap in production usually means a backlog, a frustrated team, and pressure to remove the safeguard entirely.
Set an expected response time as well. A review that takes two days may be acceptable for a contract clause and unacceptable for a customer waiting on a booking.
Watch for rubber-stamping
A very high approval rate can mean the system is reliable. It can also mean reviewers have stopped engaging. The difference shows up in the details: time spent per item, edits made, and whether seeded test cases are caught.
Periodically include known errors in the review queue and see whether they are stopped. Rotate reviewers where the work allows. If a category is approved without change for a long period, that is evidence to reduce its review rate—through a deliberate decision, not quiet drift.
Let review evidence move the boundary
Every review produces a record: what was routed, what was changed, and why. Over time that record shows which categories of work are consistently correct and which still need judgment.
Use it in the same regular review that tracks what to measure after launch. When the evidence supports it, reduce review for a category and record who approved the change. When corrections rise, increase it. Review that works the same way as a well-designed escalation becomes the mechanism through which autonomy is earned.
Design the reviewer’s day, not just the system
The best test of a review step is simple: could a capable person do it well, all day, without cutting corners? If the answer is no, the safeguard is on paper only.
Designing for the reviewer—fewer, better-routed cases, with context and a clear question—protects the people the system serves and the people who oversee it. That is what makes human review a working control rather than a line in a proposal.