An AI workflow should require human review when an incorrect output could create a meaningful consequence and the error cannot be reliably detected or reversed by the system. Review should also increase when the input is unusual, the model is uncertain or the action falls outside an approved boundary.
The goal is proportionate control. Reviewing every output can remove the capacity benefit. Reviewing none can transfer hidden uncertainty into customer, financial or operational decisions.
This control decision sits within the broader question of where to start with AI and automation, after the business has identified a worthwhile and sufficiently contained opportunity.
Place review before the consequence becomes difficult to reverse, and send the reviewer the evidence needed to decide.
Separate generation from action
AI can classify a request, extract fields, summarise material, draft a response or recommend a next action. The risk changes when that output triggers another step.
A draft saved for an employee to edit has a different consequence from a message sent to a customer. An extracted invoice number displayed beside the source has a different consequence from one posted directly into accounting software.
Map the chain from model output to business action. Review belongs at the point where uncertainty meets consequence, which may be after several technical steps rather than immediately after generation.
Assess four factors
Use uncertainty, reversibility, consequence and exception patterns to set the review requirement.
Uncertainty
How variable are the inputs and how dependable is the task? AI confidence scores can help route cases, but they are not proof that an answer is correct. Evaluate performance on representative examples and known difficult cases.
Uncertainty rises with poor scans, missing context, ambiguous language, conflicting sources, unfamiliar formats and tasks requiring unstated business knowledge.
Reversibility
How easily can the action be undone? A draft can be edited. An internal label can often be corrected. A payment, customer promise, deletion or external filing may be difficult or costly to reverse.
Place review before irreversible or expensive actions. If reversal is easy and detection is strong, post-action sampling may be sufficient.
Consequence
Consider customer, financial, privacy, contractual, safety and operational effects. Avoid reducing consequence to a generic high, medium or low label without describing what could happen.
This guide supports operational design and does not replace legal, regulatory or professional advice. Work in regulated or safety-sensitive contexts may require controls beyond this framework.
Exception patterns
Look at which cases fail or need judgement. Repeated exceptions should become routing rules, input improvements or explicit exclusions. Novel exceptions still need an accountable person.
An exception path should state who reviews, what context they receive, the response deadline and how the workflow resumes.
Choose a review pattern
Several patterns can be combined within one workflow.
Review every output when consequences are high, the task is new or evidence is insufficient. This is also useful during an initial validation period.
Review selected outputs when rules can identify higher-risk cases, such as large values, sensitive customers, missing fields or material contractual language.
Review based on uncertainty signals when tested indicators can separate routine and ambiguous cases. Use more than a model-generated confidence score where possible. Input completeness and agreement with source rules can provide stronger signals.
Sample completed outputs when actions are reversible, consequences are limited and monitoring can detect drift. Sampling supports quality control rather than case approval.
Review by exception only when the normal path is well tested and deterministic controls catch unsuitable cases before action.
Give the reviewer a real decision
Human review creates value when the person can approve, correct, reject or redirect the output using relevant evidence. A vague “check this” task encourages quick acceptance and creates delay without control.
The review item should include:
- the proposed output or action;
- the source material used;
- the reason review was triggered;
- the fields or claims that need attention;
- available actions;
- the owner and deadline;
- a route for cases the reviewer cannot resolve.
Capture corrections in a structured form. They can reveal recurring input problems, weak instructions or categories that should leave the AI path.
Design a review matrix
Create a small matrix for each AI step. Record the action, possible error, consequence, reversibility, detection method and review rule.
For example, an AI-assisted customer enquiry workflow might use these controls:
- classify topic: automatic for known categories, route low-quality inputs for review;
- identify customer: require an exact system match, otherwise send to a person;
- draft reply: always reviewed during the pilot, then selected review for approved low-risk topics;
- send reply: blocked when the message contains pricing, commitments or sensitive account changes;
- update CRM: automatic only for validated fields, with an audit record.
This separates one broad “AI assistant” into actions with different risk profiles.
Test with representative and difficult cases
Build an evaluation set from the workflow rather than a demonstration sample. Include normal cases, incomplete inputs, rare formats, contradictory information and examples that previously caused mistakes.
For each case, record whether the output was acceptable, whether routing worked and whether a reviewer could decide efficiently. Measure false acceptance as well as unnecessary review. A system that sends every case to a person may appear safe while producing no useful capacity.
Keep the evaluation set and rerun it when prompts, models, source material or workflow rules change.
Monitor the operating workflow
Review design continues after launch. Track:
- share of cases reviewed;
- reason each review was triggered;
- approval, correction and rejection rates;
- time spent reviewing;
- errors found after approval or automatic action;
- recurring exception categories;
- changes in input or model performance.
Set thresholds that cause the workflow to narrow, pause or return to full review. Assign an owner who can make that decision.
A practical example
Consider a workflow that extracts details from supplier invoices and prepares records for finance.
Supplier name and invoice number can proceed when they match expected formats and the source remains visible. Bank-detail changes, tax uncertainty, duplicate indicators and values above an internal threshold require review. Posting remains a finance action during the initial period. After measured performance is stable, validated low-risk records may proceed automatically while exceptions retain review.
The design preserves human responsibility around financial consequence without asking finance to retype every routine field.
When AI is the wrong intervention
Do not add AI when fixed rules can perform the task reliably, when source information is too poor to support a decision, or when the required review would cost more than the manual process it replaces. Clarify ownership and improve inputs first if those are the real constraints.
The diagnostic guide helps classify the problem. The workflow mapping method provides the inputs needed to design review and exception paths.
Set the minimum safe review rule
For every AI action, write one sentence: “A person must review this output when…” Complete it using observable conditions. Then define who reviews, what evidence they see, what they can do and how the case returns to the workflow.
Start with more review while evidence is limited. Reduce it only when measured performance, reliable routing and the consequence of errors support that decision. Human review is part of the workflow design, with a cost and an owner, rather than a general reassurance added at the end.