AI programme management
Human-in-the-loop workflows: design useful review
Design human-in-the-loop workflows with clear review tasks, source access and escalation. Measure quality and workload before scaling AI assistance.
Adding an approval button does not establish useful human review. A person can click “accept” without checking the source, understanding the consequence or having enough time to notice an error. A human-in-the-loop workflow needs a defined review task, the evidence to perform it and a workable way to refuse or escalate.
The design question is therefore practical: what judgement should remain with a person, at what point, with what information? This guide concentrates on operational review rather than training models from human feedback. It complements the AI programme management guide and the governance charter.
Specify the judgement before assigning the reviewer
Start by identifying the decision the output supports. A reviewer may need to check factual accuracy, assess relevance, approve tone, verify permissions or authorise an external action. These are different judgements. “Check the AI answer” leaves the reviewer to invent a standard each time.
State the consequence of acceptance. Approving a private draft and authorising a customer email are not interchangeable. The interface should communicate what happens next and let the reviewer inspect the parts that matter for that action. If acceptance changes a record, show the proposed change rather than only a conversational summary.
The NIST appendix on human–AI interaction describes human involvement across AI activities. That broader view is useful: oversight is a workflow relationship, rather than proof of safety supplied by one click.
List the knowledge required for the judgement. Someone who understands brand tone may not know whether a technical statement is true. A subject expert may lack the authority to approve a customer promise. Assign the review to people with both appropriate competence and a clear decision boundary.
Choose where the human enters the process
Review can happen before generation, before an action or after an action. A pre-generation step can establish approved inputs and scope. A pre-action step can stop an unsuitable output from leaving the organisation. A later audit can reveal recurring problems but cannot undo every consequence.
The right arrangement depends on the task and exposure. For a low-consequence internal suggestion, later sampling may support improvement. For a consequential external action, the team may require explicit approval and independent permission checks. This article proposes questions to support that design; it does not classify regulated uses or prescribe professional decisions.
Do not confuse this with reinforcement learning from human feedback. Operational feedback may inform a product backlog, source correction or evaluation set without training the model at all. Tell users what their feedback actually changes and avoid implying immediate learning if no such process exists.
Google's People + AI guidance on feedback and control stresses the ability to adjust outputs and the importance of explaining feedback effects. In your workflow, make “edit”, “reject”, “ask for evidence” and “continue manually” meaningful actions, with clear results.
Give the reviewer the evidence needed to disagree
Put source material beside the output. For document-based answers, show the specific source passage, its date and any relevant scope. A link to a large folder makes the review expensive and encourages acceptance without inspection. Provenance should help someone verify a statement, rather than decorate it.
Show uncertainty through observable gaps. “No approved source found for this claim” is more actionable than a confident-looking score whose meaning the reviewer does not understand. If you display model confidence, establish what it measures and whether it has been validated for the task. A self-reported certainty is not a calibrated probability.
Highlight changes when the task is an edit. The person needs to see modified facts, removed qualifications and added claims. Reading a fluent replacement from beginning to end makes those changes harder to locate. Preserve access to the original so the reviewer can compare without reconstructing it from memory.
Make refusal straightforward. Do not hide rejection behind several clicks while making acceptance immediate. Explain where the rejected case goes and whether the person can finish the task manually. A review process that blocks work without a recovery route invites people to invent unofficial shortcuts.
Use a review contract that fits the task
A review contract is a short agreement about what the person checks, what the system provides and what happens when the check fails. It should be visible in the workflow, with detailed instructions available when needed.
Swipe or use the arrow keys to see every column.
| Review question | Information the system must provide | Reviewer action |
|---|---|---|
| Is the statement supported? | Relevant approved source passage | Confirm, correct or reject |
| Does it fit this case? | Task context and known exclusions | Accept scope or escalate |
| Does it add an unsupported promise? | Original input and changed claims | Remove or obtain approval |
| Is the proposed action permitted? | Target, fields, recipient and permissions | Authorise only the stated action |
| Can the task continue without AI? | Manual route and current work state | Switch without losing the case |
| What should improve? | A short reason field and case identifier | Report a specific failure |
Do not require every field for every output. A draft headline and a service-term answer need different evidence. Keep the contract narrow enough to perform and explicit enough to audit. The AI output evaluation guide can provide examples of what passes and fails each criterion.
Hypothetical example: a product-content review queue
Imagine a hypothetical retailer using AI to draft product descriptions from approved data. The scenario is illustrative, with no claimed outcome. The intended benefit is reduced drafting effort, while factual product attributes must remain correct.
A first design asks editors to approve the finished paragraph. It does not show which attributes came from the source or which were generated. The editor has to reopen several records to check a size, material or compatibility statement. Review becomes a second research task.
A revised design displays approved attributes, flags statements without a supporting field and shows the difference between the input and the draft. The editor can reject unsupported compatibility claims without discarding accurate sections. Uncertain records return to the source owner rather than circulating through the same queue.
The team measures complete handling time, correction types and factual errors in an independent sample. It does not assume that more accepted drafts mean better quality. If editor workload falls but unsupported claims increase, the workflow has not met its stated objective.
For a content-specific implementation, connect this design with the AI marketing guide. The principle remains the same: the person reviews a defined claim with accessible evidence.
Plan reviewer capacity and escalation
Estimate capacity from observed review work, including difficult cases. Average time alone can hide bursts, absences and cases that need a specialist. Track queue age as well as queue length: a short queue can still contain important cases waiting too long.
Define what happens when demand exceeds capacity. Possible responses include reducing the eligible scope, returning some work to a manual process or pausing new generation. Routing overflow to automatic acceptance defeats the purpose of the review contract unless the changed scope has been separately justified.
Escalation should name the question and the recipient. “Needs review” without a reason sends the next person back to the beginning. An effective escalation records the disputed claim, the available source, the uncertainty and the decision needed. Make clear who can accept the remaining risk.
Use the AI project risk register to identify cases that need different paths. Routing rules should rely on observable task characteristics and verified constraints. Do not let an unvalidated confidence score become the only gate for consequential work.
Evaluate the human and AI as one system
Test the workflow, rather than only the model output. Recruit people who resemble the intended reviewers and give them realistic tasks within the authorised scope. Observe whether they locate evidence, detect errors, correct the output and complete the task.
Use deliberate challenge cases to examine specific controls. An unsupported attribute can test whether provenance helps the editor reject it. Keep these challenge cases clearly separate from ordinary samples: their purpose is to assess detection, not estimate how frequently such errors occur.
For routine performance, compare comparable work with and without assistance where the setting allows it. Predefine quality criteria and how time is measured. Include corrections and handoffs. If the comparison is observational, record differences in case complexity and reviewer experience rather than attributing the entire change to AI.
Measure false acceptance and unnecessary rejection alongside effort. A workflow that rejects everything may prevent errors while providing little value. A workflow that accepts everything may be fast while providing little oversight. The useful operating range depends on the task and its consequences.
Watch for review that becomes automatic agreement
Repeatedly correct-looking outputs can make checking feel unnecessary. Time pressure, hidden sources and a target for fast approvals can reinforce that behaviour. Examine the conditions rather than assuming every reviewer will remain vigilant indefinitely.
Avoid measuring people solely on acceptance rate or queue clearance. Those incentives can conflict with the required judgement. Give reviewers examples of genuine failures, a route to challenge the system and time to perform the checks. Sample review quality independently of the person who generated the output.
Feedback also needs a destination. A list of rejection reasons that nobody analyses does not improve the workflow. Assign someone to group recurring failures, correct sources and decide whether evaluation or scope should change. Explain to reviewers when their feedback affects the process.
Human review has limits. It can miss errors, vary across people and introduce new mistakes. It does not replace access controls or specialist assurance for consequential uses. Start with one task, test the contract and measure the complete system before expanding. To design that review around your team's work, tell me about the workflow.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI governance: assign responsibility before release
Make AI governance operational with clear decision rights, release gates and incident ownership. Use a charter that your team can apply to real work.
AI project risk register: turn concerns into controls
Build an AI project risk register around failure scenarios, owners and tested controls. Use a worked example to review residual risk before release.
AI roadmap prioritisation: choose what to build first
Prioritise an AI roadmap around evidence, dependencies and measurable value. Use a practical decision sheet to choose the next project with confidence.