Human-in-the-Loop AI

When Should AI Require Human Approval?

For process owners sorting automatic actions from review work: a consequence-and-reversibility test that identifies blocking gates, exception review and safe monitoring.

Uli PrantzBuilds and operates all-agents
Published
Key takeaways

Key takeaways

  • Require approval before an action when a plausible error has serious consequences and cannot be completely reversed. Either condition on its own may call for a lighter control.
  • Confidence is evidence, not authority. A high model score cannot authorize a payment, public commitment or decision about a person.
  • Gate the effect, not every step that prepares it. Research, extraction and drafting can usually continue while sending, changing or committing waits.
  • Use deterministic validation for rules a machine can check. Sending every missing field or threshold breach to a person wastes the judgment the gate exists to obtain.
  • Some actions should be prohibited rather than approved. A reviewer must never be used as a waiver for missing authority, illegal use or an unbounded blast radius.
AI should require human approval before a proposed action when a plausible error has material consequences and the effect is difficult to reverse. Add review for subjective decisions about people, access, money, public commitments or sensitive disclosure even when the model reports high confidence. Use deterministic checks for machine-readable rules, exception review for ambiguous boundary cases, sampling for recoverable low-impact actions, and prohibition where no reviewer has authority to permit the action.

Classify the action with five questions

Classify the effect, not the model. “Generate text” could mean an internal draft or a binding promise sent to a customer. The model behavior is similar; the operational consequence is not. Ask the questions against one exact verb, target and payload.

The first two questions decide whether a blocking gate is likely. The remaining three can make the control stricter.
QuestionLower-risk answerApproval signal
What happens if it is wrong?Small internal correction with no decision about a personMoney, access, rights, safety, public commitment or sensitive disclosure changes
Can it be completely reversed?Version restore or isolated field edit with no downstream effectThe recipient acts, data leaves, a deadline passes or other systems consume it
Is judgment genuinely needed?Schema, range, allowlist or exact policy ruleCompeting goals, incomplete evidence, precedent or contextual exception
Who or how many are affected?One internal record with bounded visibilityA customer, employee, supplier, public audience or large batch
Who carries accountability?The process owner has pre-authorized the bounded automatic pathA named person must own the exception or cannot delegate the decision

Combine consequence and reversibility before looking at confidence

Default control by effect. Internal policy and law can only make these defaults stricter.
Consequence / reversibilityFully reversiblePartly reversibleIrreversible
LowAutomatic with samplingDeterministic limits plus exception reviewBlocking approval or redesign for reversibility
ModerateAutomatic with alert and rollback windowException or threshold approvalBlocking approval
HighBlocking approval unless the rollback is proven and immediateBlocking approvalBlocking approval; consider two people or prohibition
CriticalQualified review and independent safeguardsTwo-person approval or prohibitionProhibit unless a competent authority and governing rule explicitly allow it

NIST's AI RMF maps needed controls to likelihood, magnitude, context and organizational risk tolerance. It separately calls for human-oversight processes to be defined and assessed. The matrix is a practical starting point for that discussion, not a universal risk standard.

Model confidence enters after this classification. It can route a low-consequence extraction to exception review or help prioritize a queue. It cannot make an irreversible, high-consequence effect low risk. Confidence describes the system's estimate under a calibration method; it does not carry institutional authority.

Three similar AI outputs can require three different controls

One generated paragraph, three effectsSimulated example data

Internal meeting summary: the paragraph is stored as a draft beside the transcript and can be corrected before anyone relies on it. Low consequence, fully reversible: run automatically and sample for omissions.

Customer status reply: the same sort of paragraph promises a recovery time to a named customer. The recipient may plan around it and the promise cannot be unsent. Moderate consequence, partly reversible: require approval before send.

Employment decision notice: the paragraph communicates a decision about a person. The risk comes from the decision and process, not its grammar. Treat this as heightened employment work with qualified review and applicable policy; a copy-approval button alone is not an adequate control.

Do not send machine-checkable failures to a reviewer

A person should resolve context, tradeoffs or accountability. Code should reject a missing identifier, invalid currency, duplicate request, forbidden domain, exceeded hard limit or malformed payload. When those cases enter an approval queue, reviewers become slow validation rules and begin clicking through the real exceptions.

The variance-budget method helps separate the two. A deterministic step either passes or fails a stated condition. A human gate answers a question whose correct resolution needs authorized judgment.

Route the condition to the cheapest control that can actually decide it.
ConditionWrong controlBetter control
Required account ID missingManager approvalReject input; request the ID
Amount above fixed automatic limitAsk AI whether it feels riskyCode routes to the named approver
Two credible sources disagreeChoose the higher confidence scoreShow both sources for exception judgment
Requested action violates policyLet a reviewer waive it casuallyBlock or use the formal exception authority

Some actions need a stop, not an approval

Do not create a gate when the proposed action is outside the organization's authority, prohibited by policy, unsupported by evidence or capable of an unbounded effect. A reviewer is not a universal exception mechanism. The safe branch may be to block the action, narrow its scope or require a separate governed process.

For high-risk AI systems within its scope, Article 14 of the EU AI Act requires oversight proportionate to risk, autonomy and context. It also calls out automation bias, the ability to interpret output, override it and halt safely. This page does not classify a system under that law. It does show why an approve button without competence, information and stopping power is not meaningful oversight.

Reassess the gate with evidence from real decisions

  1. Log which rule created the request and what exact effect was pending.
  2. Separate approve, edit, reject, expire and cancel in the event record.
  3. Review whether edits and rejections prevented a defined bad outcome.
  4. Sample the automatic path to detect cases the routing rule missed.
  5. Narrow, strengthen or remove the gate only after the evidence supports the change.

Limitations and when not to use this

  • The matrix is an operational heuristic, not a legal classification or substitute for sector, security, employment, financial or safety policy.
  • “Reversible” must include downstream effects. Restoring a database field is not complete reversal if a customer saw it or another system acted on it.
  • Human review introduces its own errors, bias and delay. Do not assume a gate reduces risk unless the reviewer has evidence, competence, authority and enough attention to decide.

Sources

  1. AI Risk Management Framework CoreNIST Accessed 30 July 2026
  2. AI RMF Appendix C: AI Risk Management and Human-AI InteractionNIST Accessed 30 July 2026
  3. Regulation (EU) 2024/1689, Article 14EUR-Lex Accessed 30 July 2026

Triage one proposed action

Score the consequence, reversibility, uncertainty and affected scope, then inspect the suggested control and its reasoning.

Triage one proposed action
About the author

Uli Prantz

Builds and operates all-agents

Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.

Bring one process. We will scope it in 30 minutes.

You leave the call knowing whether it is a fit, what can become code and what still needs a person.

Book a discovery call