Who approves the AI's work? A practical operating guide

Begin with actions, not a blanket label such as “AI-assisted.” Reading an authorized document, preparing a draft, changing a client record, sending an external message, and committing a financial transaction have different consequences.

I would list each action and assign a policy: permitted automatically within a defined boundary, requires review, or prohibited. The business owner should approve that policy. A developer should not infer permission to send messages merely because the workflow can draft them.

Keep the first release narrow. A system can provide useful assistance while stopping before external communication or record changes. Expand authority only after the relevant behavior has been tested and someone accepts responsibility for the new action boundary.

A queue assigned to “the team” can leave every person assuming somebody else is watching it. Assign a primary role, a backup, and an escalation path. Define which cases each role can approve and which need a specialist.

For example, an account manager might approve a routine onboarding record while a nonstandard contract term goes to the responsible commercial owner. In an engineering workflow, a coordinator might check completeness while an authorized engineer decides the technical question. These are illustrative divisions, not universal job descriptions.

NIST's AI RMF calls for defined roles and responsibilities in human-AI configurations and oversight. My operational recommendation is to translate that into named queue ownership and explicit decision authority. NIST AI RMF Core

The review screen should display the target, proposed change, source evidence, and important uncertainty. If an email will be sent, show the recipient, subject, body, and attachments. If a record will change, show the relevant before and after values.

A model-generated explanation can help the reviewer, but it should not replace the underlying evidence. Let the reviewer open the source document or authoritative record. Highlight missing information and conflicting values so that approval is an informed decision rather than a trust exercise.

I would avoid hiding consequential details behind a generic “looks good” summary. The person approving should be able to describe what will happen without reading internal prompts or implementation code. Test the interface with an actual intended reviewer.

Approval should refer to a defined action and the relevant version of its inputs. If the recipient, attachment, amount, or source record changes after review, the system should determine whether a new approval is required before execution.

A practical design records an approval identifier, reviewer, time, target, proposed payload, source version, and policy version. The execution service checks those conditions before acting. The exact storage design depends on the application, but the principle is that approval must not become an open-ended permission for the agent to improvise.

Include a stale-review test. Prepare an action, change the underlying record, and attempt execution using the earlier approval. The expected result should be specified before the test. For a consequential changed field, I would normally require another review.

A rejected item needs a clear next state. The reviewer should be able to explain whether the problem is missing information, an incorrect extraction, an unauthorized action, or a business decision not to proceed. Those reasons help the operator resolve the case and help the team improve the workflow.

Do not automatically send every rejection back to a model until it produces a more persuasive answer. Some rejections mean stop. Others mean request a specific missing document. Define which transitions are allowed and keep repeated attempts visible.

If the reviewer edits the proposed action, treat the edited version as the object being approved. Preserve enough history to distinguish the model's proposal from the human's final decision. That distinction matters when investigating why an action occurred.

Decide how long an item can wait and what happens when that period ends. A timeout should not quietly become approval. Route it to the backup, escalate it, or leave it stopped according to the agreed business policy.

Time-sensitive work may need a separate path. If a deadline cannot wait for the normal queue, define an authorized manual procedure. The AI workflow should not invent urgency exceptions from the wording of an email.

Measure the age of pending items and the number of items without an owner. Those signals help distinguish a model-quality problem from a staffing or process problem. Adding another prompt will not resolve a queue that nobody has time to review.

An approved action can still fail. The target service may reject it, become unavailable, or complete the write while the response is lost. Record approval and execution as separate states so that the interface does not tell the reviewer a task is finished too early.

I would require an execution receipt from the destination where available, plus a reconciliation path for uncertain outcomes. If an email provider accepted a message, retain its provider identifier. If a record changed, retain the resulting record reference and the relevant response.

Retries need a duplicate-prevention strategy. A reviewer should not accidentally trigger two external actions by refreshing a page or pressing a button twice. Test interrupted execution and repeated approval requests, not only the smooth path.

A queue that asks people to approve trivial items all day can make the important item harder to notice. I would group work by consequence and uncertainty, while keeping the actual policy boundary intact. Routine checks that can be validated deterministically should not require a person simply because the workflow uses AI elsewhere.

Do not use the model's confidence statement as the sole reason to bypass review. Decide which evidence or validation results are required for automatic handling and test that rule. Keep a route for ambiguous cases rather than forcing every input into an approved category.

Measure correction rate, rejection reasons, review time, stale items, and actions that required reconciliation. These are proposed operating metrics, not promised performance improvements. Use a defined observation window and avoid treating a small sample as proof that oversight can be removed.

Ask the intended reviewers to process normal, ambiguous, malicious, stale, and duplicate cases in a safe environment. Observe whether they can find the evidence and understand the consequence. Update the interface or policy where the decision is unclear.

Then rehearse the unavailable-reviewer case and the uncertain-execution case. The system should leave an understandable record and a named next action. That is the point at which a review queue becomes an operating process rather than a decorative approval button.