Put human review where a workflow interprets uncertain information, changes a commitment or takes an action that is difficult to reverse. Define what the reviewer must check and how the decision returns to the workflow. Routine, bounded work can proceed automatically when its inputs, permissions, result and exception route are understood.
- Bounded internal taskProceed under understood inputs and exception route.
- Uncertain interpretationReview source information or proposed output.
- Permission changeCheck recipient and appropriate access before action.
- Hard-to-reverse actionRequire authorized review before proceeding.
Choose review points from the action, not whether a model is used.
Choose review points from the action
Start with what the workflow will do, not whether it uses an AI model. A simple rule can still send the wrong client message or modify an important record. An AI-assisted summary can be low consequence when it remains an internal draft for review.
Identify who is affected, what can change and how easily an error can be corrected. Use those answers to decide whether a person needs to review the input, the proposed output or both.
Build a review decision table
| Workflow action | Useful review question | Possible review point |
|---|---|---|
| Internal reminder | Is the owner and record current? | Exception review when unclear |
| Client message | Is it accurate, relevant and authorized? | Before sending |
| Scope or proposal change | Does it alter an agreed commitment? | Authorized owner decision |
| Access change | Is the recipient and permission appropriate? | Before granting or expanding access |
| Public content | Are facts, claims and approvals complete? | Before publication |
| Data deletion | Is the target correct and action permitted? | Explicit action review |
The table is a starting assessment. Your agency should set review rules for its own systems, commitments and data practices.
- Internal reminderReview only when record or owner is unclear.
- Client messageCheck accuracy, relevance and authorization before sending.
- Access changeCheck recipient and permission before granting access.
- Public contentCheck facts, claims and approvals before publication.
The agency should set rules for its own systems, commitments and data practices.
Give the reviewer enough context
Show the source record, proposed action, relevant constraints and unresolved questions. A button labeled “approve” is not useful when the reviewer cannot see what will happen.
For an illustrative client update, the reviewer needs the current project facts and the draft message. They should be able to check whether the draft presents planned work as completed or includes information from another account. Editing tone alone does not resolve those questions.
Avoid making the reviewer navigate several systems just to understand one decision. Link to the sources and highlight the affected fields without hiding the original information.
Define approval, rejection and expiry
Record the reviewer's decision against the specific proposed action or version. A changed input can make an earlier approval stale. Decide when the workflow must return for review.
- Proposed actionShow the specific version or action for review.
- Recorded decisionCapture approval, rejection or a correction request.
- Changed inputsCheck whether an earlier approval still applies.
- No decision yetUse the agreed waiting or escalation route.
Silence should not become approval merely because a timer expired.
Give the reviewer a route to reject or request a correction, and name who receives that work. If no decision arrives, the workflow should follow an agreed waiting or escalation state. Silence should not become approval simply because a timer expired.
Keep routine work bounded
Review every action only if its consequence requires that effort. For a predictable internal task, you may be able to define reliable inputs, a narrow action and a visible exception route. That reduces unnecessary review while keeping important uncertainty visible.
Test the boundary cases. What happens if a contact changes, a field is missing or the output violates a required format? Those cases should either be handled under a clear rule or routed to a person.
Measure the review process itself
Track items rejected, approved after correction and waiting without an owner. Repeated corrections can show that the upstream instruction or data is inadequate. A review step should improve the result, not merely create an approval log.
- Rejected itemsIdentify decisions that did not proceed.
- Corrected approvalsFind recurring upstream data or instruction gaps.
- Waiting itemsShow reviews without an owner.
- Bypassed checksInvestigate volume, context or unclear responsibility.
An approval log alone does not show that the expected check occurred.
Also watch for approvals given without the expected check. If reviewers routinely bypass the process, investigate missing context, excessive volume or unclear responsibility. The permission model guide helps define who can authorize different types of action.
Questions and answers
Does every AI-generated output need the same review?
Assess the action and consequence. An internal draft differs from a client message, access change or public claim. Define what may proceed under a bounded rule and what requires a person to verify the source, output and authority before the action.
Can a missing response count as approval?
Only use that behavior where a specific, appropriate agreement establishes it. For ordinary consequential workflow decisions, a waiting state or escalation is clearer. Do not let an arbitrary timeout silently authorize an action the reviewer never assessed.
What should an approval record contain?
Identify the proposed action or version, reviewer, decision and relevant conditions. If the underlying input changes, determine whether the approval remains valid. A generic approval flag can lose the connection between what was reviewed and what the workflow actually does.