The easiest way to make an AI agent look safe is to require a person to approve everything. It also gives you a fast way to ruin the business case.
Every draft waits. Every account change waits. Every exception joins the same queue. Reviewers open items without enough context, approve them quickly to catch up, or become the new capacity limit for a workflow that was supposed to remove manual work.
Human approval is a control. It is not a substitute for workflow design. The decision is not whether humans stay involved. The decision is where human judgment changes the outcome enough to justify the delay and labor.
Stop treating approval as one setting
"Human in the loop" sounds precise, but it can describe several very different controls. A reviewer might approve every transaction, approve only exceptions, approve a policy that governs many low-risk actions, review a sample after completion, or receive an alert when a limit is crossed.
Those controls do different jobs. Per-item approval blocks an action until a person decides. Exception review handles cases outside a defined boundary. Policy approval lets the agent act inside a narrow rule. Sampling checks whether the system remains healthy without delaying every item. Limits stop volume, value, permission, or risk from exceeding an approved range.
If your design document says only "a human reviews it," the operating model is unfinished.
Price the queue before you approve the agent
Review work is part of the implementation cost. Count it.
Estimate eligible transactions, the percentage routed for review, average review time, coverage hours, peak arrival rate, rework, and escalation time. Then identify the people qualified to make each decision. A queue that needs two hours of legal, security, or finance attention every afternoon is not free because those employees already work for you.
Use observed numbers during the pilot. If 30 percent of cases require three minutes of review, put that labor and wait time into the AI agent integration cost model. Do not keep the expected automation savings while pretending the approval queue has no cost.
Also model the peak, not only the average. A queue can look manageable over a week and still fail during month-end processing, a service outage, a promotion, or a backlog after an integration recovers.
Reserve per-item approval for consequential actions
Some actions deserve a hard stop. Money movement, contract commitments, access changes, regulated decisions, customer promises, destructive writes, and sensitive disclosures may require a person to approve the individual action.
Even then, do not send the reviewer a vague request to "approve the AI." Show the proposed action, source records, policy used, confidence or exception reason, expected downstream effect, alternatives, prior related actions, and what happens if the reviewer rejects it. The reviewer should be deciding, not rebuilding the case from five systems.
Low-risk and reversible work usually needs a different control. A draft saved for later review is not the same as a refund issued to a customer. A CRM enrichment suggestion is not the same as deleting an account. Treating them the same wastes attention that should be reserved for the action that can hurt the business.
Use a control ladder
Start with the consequence of a wrong action, then choose the least expensive control that keeps the risk inside the approved boundary.
| Action profile | Useful control | Evidence to keep |
|---|---|---|
| High consequence or hard to reverse | Per-item approval by a qualified owner | Proposal, source context, approver, decision, time, and resulting write |
| Known exception outside policy | Exception queue with reason-specific routing | Failed rule, supporting context, queue owner, age, and disposition |
| Low consequence inside a stable rule | Pre-approved policy, limits, and alerts | Policy version, transaction log, limits checked, and outcome |
| Reversible action with measurable quality | Post-action sampling and trend review | Sample method, defect rate, correction, and threshold breaches |
| New or materially changed behavior | Temporary approval gate during staged release | Release version, review results, expansion criteria, and stop conditions |
Route by reason, not to one giant inbox
A security exception should not wait behind a copy edit. A pricing exception should not go to the person who owns customer identity. Build separate routes for separate decisions, with a named owner, backup owner, service target, escalation path, and maximum queue depth.
The agent should attach a reason code. "Low confidence" is usually too broad. Name the actual problem: conflicting customer records, missing approval evidence, value above limit, sensitive data detected, requested action outside policy, or downstream system unavailable.
Reason codes let you improve the workflow. If most exceptions come from one missing CRM field, fix the source or change the intake process. Do not hire more reviewers to repeatedly solve a data-quality problem.
Measure whether the review is real
An approval count does not prove human oversight worked. A reviewer can approve 200 items and add no judgment.
Track queue age, time to decision, rejection and modification rates, overrides by reason, items returned for missing context, agreement between reviewers, downstream defects after approval, and business delays caused by the queue. Compare those numbers by risk class and reviewer role.
A near-zero rejection rate can mean the agent is excellent. It can also mean the approval step is ceremonial. Sample approved items independently and ask reviewers what evidence changed their decision. If the answer is usually "I clicked approve because it looked fine," remove the theater or redesign the evidence.
Add queue measures to your AI agent production scorecard. The workflow has not created capacity if work merely moved from the person doing the task to the person approving it.
Give reviewers a safe rejection path
Approval interfaces often make "approve" easy and every other outcome awkward. That pushes reviewers toward the fastest button.
Let a reviewer reject, edit, request missing information, reroute, pause similar actions, or escalate a policy issue. Record the reason without forcing an essay. If rejection sends the item into a dead-end inbox, people will approve questionable work just to keep the process moving.
Define what happens after each decision. Does the agent retry with new information? Does a human complete the transaction? Does the proposed write disappear? Does the team inspect similar queued items? Connect the approval decision to the failure recovery plan so rejected and timed-out work reaches a known state.
Use approval to earn authority, then reassess it
Per-item approval can be useful during a pilot or staged release. It gives the team evidence about error patterns, reviewer effort, policy gaps, and consequences before the agent receives broader authority.
Set the graduation rule before launch. For example, a class of reversible actions may move from per-item approval to sampling after a minimum case volume, acceptable defect rate, stable exception mix, and no serious unauthorized action. High-consequence work may keep its hard gate.
The NIST Generative AI Profile recommends documenting human oversight roles and responsibilities in the system inventory. It also recommends sharing pre-deployment test results with people who have system release approval authority. That supports a practical distinction: the person approving a production release and the person reviewing an individual transaction do not have to be the same person.
Review the control after model, prompt, connector, policy, data, or workflow changes. The AI agent release test helps decide when a temporary approval gate should return.
Ask vendors to demonstrate the queue
Do not accept a checkbox labeled human approval as proof. Ask the vendor to run a realistic volume through the review process.
Inspect routing rules, reviewer permissions, context shown, mobile and desktop experience, delegation, timeouts, alerts, audit records, edits, rejections, rerouting, bulk actions, queue reporting, and export. Test what happens when the reviewer is unavailable or the queue exceeds its limit.
Ask how pricing treats approval steps, retries, stored context, and reviewer seats. Ask who can change a policy from per-item approval to automatic action. Ask whether the system records which policy and workflow version produced each proposal.
Your vendor pilot acceptance test should include the review queue under expected and peak volume. A beautiful agent demo followed by a miserable approval screen is still a bad workflow.
Keep the human where judgment pays
More approval is not automatically more control. A flooded queue creates delay, weak review, and false confidence. It can hide a poorly defined policy behind a wall of busy people.
Classify the action. Match the control to the consequence. Give the reviewer the evidence needed to decide. Measure the queue as part of the operating cost. Then remove approval steps that do not change outcomes and strengthen the ones that protect something important.
That is how human oversight helps an AI workflow instead of becoming the next manual process you need to automate.