ai:review
Human-in-the-loop AI workflows: running the review step in production.
By Loan Laux · November 13, 2026 · 9 min read
Human-in-the-loop AI workflows are workflows where a person approves, corrects or rejects a model's output before it takes effect: before the email goes out, the record changes or the decision reaches the person it is about. Deciding that a person reviews is the easy part. The work is running that step in production, every day the workflow runs.
This post is for the engineering, operations and risk leads who own review in a live workflow, and covers what three public texts on human oversight say.
What human-in-the-loop AI workflows are.
A human-in-the-loop AI workflow has a step where a person sits between the model's output and its effect. The model drafts the reply, classifies the claim or proposes the change; a person approves, corrects or rejects it; only then does anything leave the workflow.
Two neighbouring designs get confused with it. Human on the loop: outputs take effect at once, and a person monitors and can step in afterwards. Decision support: the model only advises, and a person makes every decision. All three are legitimate; trouble starts when a team runs one and its documents describe another.
Review also has a cost: every output a person reads is time the workflow was meant to save, and a reviewer who reads too many stops reading. The decisions below keep review worth that cost.
Which outputs go to a person?
Route by three triggers, built into the workflow as rules rather than written in a wiki.
- Consequence of an error. Some outputs always go to a person because a wrong one is expensive or hard to reverse: a payment, a message to a customer or a citizen, a decision about a person, a change to a record other systems trust. The workflow owner lists these types and agrees the list with risk.
- The model's own uncertainty. Outputs the system flags as unsure: a low confidence score where the model exposes one, a second check that disagrees, a missing field, a refusal, an input unlike anything in the test set. Test these signals against past outputs before trusting them.
- A sample of the rest. Outputs that pass the first two triggers still reach a person now and then, picked at random. The sample finds the errors nobody predicted, and shows whether the other triggers still work.
Who reviews, and how fast?
The reviewer is a role with a name on it: the person who did the work by hand, or who signs it off today. Reviewers need the authority to reject an output and enough knowledge of the work to know when. A reviewer who cannot say no is a delay; one who does not know the work approves whatever reads well.
Then the queue. Decide where items land (the tool the reviewer already uses beats a new dashboard), who covers it when the usual reviewer is away, and how long an item may wait before someone is alerted.
Last, decide what happens to the work while it waits: it waits too (the safe choice for the consequence list), goes ahead on the manual path, or takes effect and is reviewed afterwards, which puts that output type on the loop. Pick one per output type and have the system enforce it.
What the reviewer sees and records.
The reviewer sees the input, the output and the context the model was given: the retrieved documents, the record it read, the instructions in force. Without the input, a reviewer can only judge whether an output sounds right. Show the passages the model relied on next to its output.
Design the screen against rubber-stamping: nothing pre-selected, rejecting as easy as approving, small corrections made in place.
Each decision is recorded: approved, corrected or rejected, by whom, when, and against which model and prompt version. A correction also records its reason, from a short list the team agrees (wrong fact, wrong tone, missing information, wrong action, against policy) plus free text. The list makes corrections countable; the free text makes them useful. Together the records are the workflow's audit trail.
Turning corrections into test cases.
A correction is a labelled example the workflow produced on its own: a real input, the model's output, and the output a person with authority accepted. Store them where the engineers can query them, grouped by reason.
Feed them into the test set. Before any model or prompt change, the test set is re-run, and corrected cases are the ones a change must not break again. That regression rule is part of our AI production readiness checklist; review keeps the test set current after go-live.
Read the reasons as well as the cases. A cluster with one reason points at one fix: a document missing from retrieval, an instruction the prompt states badly, an input type the workflow was never built for. Decide who reads the corrections and when.
When review can be reduced, and when it comes back.
Reduce review on evidence. When the sample keeps coming back clean and corrections for an output type have stopped, that type can move from always reviewed to sampled. Agree the evidence before you look at it: which output type, which measure, over what period, and who signs the change. The consequence list stays reviewed whatever its record.
Write down in advance what brings review back:
- A model change. A new version, a new provider, or an automatic upgrade on the platform. Review returns to its starting level until the test set and the next sample pass.
- A prompt, tool or retrieval change. These count as a model change here.
- A new data source or input type. A channel, language or document type the test set does not cover.
- A rise in corrections. The sample finds more errors than the agreed level, or a new correction reason appears.
Where policy sets the floor.
Your organisation's policy decides which workflows need a person at all; our enterprise AI governance framework covers that layer. Three public texts also describe human oversight. Below is what each says; whether one applies to a given system is a question for your counsel.
- EU AI Act, Regulation (EU) 2024/1689, Article 14, Human oversight. It provides that high-risk AI systems are designed and developed so that natural persons can effectively oversee them while in use, with oversight measures commensurate with the risks, level of autonomy and context of use. The people assigned oversight are to be enabled, as appropriate and proportionate, among other things to monitor the system's operation, to remain aware of automation bias (automatically relying or over-relying on the output), to disregard, override or reverse an output, and to interrupt the system through a stop button or a similar procedure.
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. A voluntary framework. Its core lists outcomes that include: processes for human oversight are defined, assessed and documented (MAP 3.5); policies and procedures define roles and responsibilities for human-AI configurations and oversight (GOVERN 3.2); and mechanisms are in place to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use (MANAGE 2.4).
- OWASP Top 10 for LLM Applications 2025, LLM06:2025 Excessive Agency. One of its mitigations is to require user approval: human-in-the-loop control under which a human approves high-impact actions before they are taken.
Do it yourself, or bring us in.
A team that owns its workflow can run all of this in house. The routing rules, the queue and the decision record are ordinary engineering; the rest is upkeep: reading corrections, keeping the test set current, restoring review when the model moves. Outside help fits when that upkeep keeps losing to roadmap work after launch, or when the builders have moved on.
Managed AI operations is the half that starts after go-live. The same engineers who built your AI agents keep them alive in production: watching for failures, swapping models when a better or cheaper one ships, and fixing prompts before a broken run reaches your team or your users.
Frequently asked questions.
Does every AI workflow need human review?
No. Review earns its cost where a wrong output is expensive, hard to reverse or about a person. A workflow whose errors are cheap and caught downstream can run on sampling alone, if its owner writes that decision down. The NIST AI RMF notes that some AI systems may not require human oversight while others specifically do.
Doesn't human review cancel out the time saved?
It can, when every output goes to a person and checking takes as long as doing. Route only the consequence list, the uncertain outputs and a sample, put the evidence beside the output, and reduce review as the record allows. If review still costs more than it saves, a narrower scope may be the honest answer.
Who is accountable for a reviewed output?
Split it the way the work is split. The reviewer answers for the decision they recorded. The workflow owner answers for the rules: what was routed to a person, what was not, and why. Write both roles down before go-live; accountability under a contract or a regulation is a question for counsel.
How does review change after a model update?
It goes back up. Re-run the test set, including every case built from past corrections, return review to its starting level, and lower it again only on the new model's own record.
What if reviewers approve everything?
Find out whether the outputs are that good or the review has become a stamp. Put known-bad outputs into the queue now and then and see whether they are caught. The fixes sit in the screen (nothing pre-selected, evidence beside the output) and in how much each reviewer is asked to read.