Human-in-the-Loop AI: Designing Approval and Escalation Systems
Adding an approval step does not automatically make AI safe. Effective human oversight requires the right reviewer, at the right decision point, with the evidence and authority to intervene.

Teams often respond to AI risk with a universal instruction: “a human will review it.” That sounds prudent, but it leaves critical questions unanswered. Which human? Reviewing what evidence? Against which criteria? Can the reviewer reject or reverse the action? What happens when the queue grows faster than the team can inspect it?
Human-in-the-loop (HITL) should be designed as a control architecture. It allocates decisions between automation and people according to impact, uncertainty, reversibility and policy. Done well, it protects outcomes and creates learning. Done poorly, it becomes approval theatre or a hidden bottleneck.
Separate four human roles
Approver: authorises a proposed high-impact action before execution.
Reviewer: samples completed or proposed work to assess quality.
Exception handler: resolves cases the system cannot safely complete.
Supervisor: monitors aggregate behaviour, thresholds and incidents.
These roles require different interfaces and response times. An approver needs concise evidence and a clear decision. An exception handler needs the full trace and repair tools. A supervisor needs trends, drift and policy-level controls.
Tier decisions by risk
Create a decision inventory and classify each action using:
- potential impact on customers, employees, finance or legal obligations;
- reversibility and time to reverse;
- sensitivity of the data involved;
- novelty of the case;
- quality and completeness of available evidence;
- degree of model discretion;
- policy or regulatory requirements.
Then define an operating mode. Low-risk, reversible and well-observed actions may execute automatically with sampling. Medium-risk actions may execute only when deterministic checks pass. High-impact actions should pause for approval. Unknown or out-of-policy cases should fail safely and escalate.
The threshold should be based on business risk, not a generic model confidence score. A model can be highly confident and wrong; a low-confidence case may still be harmless if the action is only to create a draft.
Give reviewers decision-grade evidence
An approval request should show:
- the proposed action and affected record;
- the business reason;
- authoritative source data used;
- relevant policy or rule;
- uncertainty or missing information;
- previous related actions;
- options to approve, edit, reject or escalate;
- the consequence and reversibility of each option.
Avoid forcing reviewers to open multiple systems. Context switching increases latency and encourages reflex approval. Equally, do not bury the decision in a model’s chain-of-thought. Provide concise, auditable rationale and source references that the organisation is permitted to retain.
Engineer the pause-and-resume lifecycle
A robust HITL workflow has an explicit state machine. When review is required, execution pauses and stores a durable checkpoint. The request is assigned according to role and service level. The reviewer’s identity, decision, edit and timestamp are recorded. The workflow resumes from a controlled state, not by rerunning all prior steps.
Set expiration and reassignment rules. Define what happens when no reviewer responds, when the underlying record changes during review, or when two people act concurrently. Require revalidation before execution if material context has changed.
Microsoft’s workflow guidance describes HITL as pausing at key decision points, gathering human input and then resuming execution. The architectural implication is important: human participation is not an informal message outside the system; it is a managed workflow state.
Prevent the human bottleneck
Measure review demand by reason and outcome. If reviewers approve nearly every case, investigate whether the gate can become sampling or rule-based validation. If rejection is common, improve the upstream data, prompt, policy or candidate scope. If one exception type dominates, fix it at the source.
Use structured reason codes plus optional notes. Track:
- review volume and queue age;
- approval, edit, rejection and escalation rates;
- agreement between reviewers;
- incidents caught and incidents missed;
- time from request to decision;
- automation performance by risk tier and case type.
Do not optimise review time at the expense of decision quality. Instead, reduce unnecessary review and improve evidence presentation.
Turn review into controlled learning
Reviewer edits are valuable signals, but they should not flow directly into production behaviour. Aggregate feedback, examine representativeness and privacy constraints, and evaluate candidate changes in a controlled test set. Version prompts, models, rules and policies so behaviour can be traced to a release.
NIST’s AI RMF emphasises continuous governance, measurement and management across the AI lifecycle. A HITL programme supports that goal when human decisions produce observable evidence and accountable improvement—not when “human review” is merely a sentence in a risk register.
The best human-in-the-loop systems are selective. They preserve human judgement for consequential ambiguity while allowing bounded, reversible work to move without unnecessary delay.
Test the control, not just the model
Before launch, test whether the human layer works under realistic pressure. Present reviewers with incomplete, contradictory and adversarial cases. Confirm that they can identify the risk, locate source evidence, reject the proposal and trigger escalation. Test queue spikes, absent approvers, expired requests and changed records. Run permission tests to ensure a reviewer cannot approve actions outside their remit. Periodically insert known control cases to detect inattentive approval, while respecting employee policy and transparency. Finally, rehearse rollback: suspend automation, identify affected records and restore a safe state. These exercises distinguish a documented approval step from an operational control. They also reveal whether the interface, staffing and service levels are proportionate before a real incident forces the discovery.