Assurance
How do you implement human-in-the-loop AI governance?
By binding the approval to the action rather than to an alert queue. A policy scope determines which actions require human authority; those actions are held before they execute and routed to the specific person accountable for that scope; and the decision, the approver, the policy that fired, and the timestamps are recorded together. An alert that arrives after the invoice is paid is not human-in-the-loop.
The three parts of a working approval
Most implementations get one or two of these right and the missing part is where the control fails.
The trigger is a policy scope, not a hunch. An action requires approval because it falls into a class that was decided in advance: it crosses a Segregation of Duties boundary, exceeds a value or blast-radius threshold, or touches a system classified as regulated. The rule about when to escalate is deterministic and enumerable, which is what lets you state your control coverage rather than describe your alerting.
The route is a named person. The action goes to whoever is accountable for that scope, identified on the policy. Not a shared channel, not a rota, not a queue that several people can see and each assume another will handle. Accountability that is not assigned to a name is not accountability, and an auditor asking who approved something needs an answer with a person in it.
The action is held. This is the part most often missing. The tool call is suspended before it executes and resumes only on approval. If the action completes while the notification is in flight, the human is being informed rather than consulted, and the control is decorative.
Notification, ticket, or approval
The three are routinely described as human-in-the-loop and only one of them is.
| Notification | Ticket | Held approval | |
|---|---|---|---|
| When it fires | After the action. | After the action. | Before the action. |
| Action state | Completed. | Completed. | Suspended. |
| Human role | Informed. | Investigating. | Deciding. |
| If ignored | Nothing changes. | Backlog grows. | Action does not happen. |
| Satisfies human oversight? | No. | No. | Yes. |
The "if ignored" row is the honest test. A control whose failure mode is that nothing happens is a control; one whose failure mode is that the action proceeds unreviewed is a notification with governance vocabulary attached.
Designing triggers that people actually action
The practical risk is not that approvals are too weak but that there are too many of them. An approval queue that fills faster than it drains gets rubber-stamped, and a rubber-stamped approval is worse than none because it manufactures evidence of oversight that did not happen.
- Escalate on consequence, not on category. Every payment is not a risk event; a payment above a threshold, or to a vendor created this week, is. Thresholds keep volume proportional to exposure.
- Let SoD block rather than escalate. An agent approving its own invoice should not be a decision anyone is asked to make. Reserve human attention for cases where judgement genuinely applies.
- Route by accountability, not availability. The right approver is the person who would be answerable for the outcome, which is usually not whoever is fastest to respond.
- Give the approver the context. What the agent is trying to do, on whose behalf, which policy fired, and what happens either way. An approver deciding without that is guessing.
- Watch the approval rate. A scope approved 100% of the time is a threshold set too low, and it is training people to click yes.
Where the regulatory expectation comes from
Human oversight is not only good practice; for high-risk systems it is an obligation with specific requirements.
The EU AI Act requires under Article 14 that high-risk AI systems be designed so that natural persons can effectively oversee them, including the ability to intervene or interrupt operation. Interruption is the operative word: a design where actions complete and humans are notified afterwards does not provide the capability the article describes. Article 26 puts a matching obligation on deployers, who must assign oversight to people with the necessary competence, training and authority — which presumes that approvals resolve to identified individuals rather than to a queue.
AIUC-1's control D003 is more specific still, naming human approval workflows for high-risk operations among the evidence it expects, alongside per-agent tool authorization and logging of every tool call.
Common questions
What triggers a human approval request?
A policy scope attached to the action, evaluated deterministically before it executes. In LangGuard the common triggers are crossing a Segregation of Duties boundary, exceeding a configured value or blast-radius threshold, and touching a system of record classified as regulated. The important property is that the trigger is a rule rather than a judgement: the same action in the same circumstances always escalates, so you can enumerate which classes of action require human authority and demonstrate that coverage. What the human then decides is genuinely a judgement, but whether they are asked is not.
Who does the approval route to?
The named approver on the policy for that scope — the person accountable for that class of action, rather than whoever happens to be watching a channel. Approvals resolving to a shared inbox fail in two ways: nobody is individually responsible, so responses are slow and diffuse, and the audit record cannot show who held the authority. Routing to a name gives the approver a reason to respond and gives the record something an auditor can act on. Different scopes route to different people, which is how the model reflects an actual delegation of authority rather than a single bottleneck.
What happens to the agent while it waits for approval?
The action is suspended and the workflow waits on it rather than failing. If the call were allowed to proceed with the approval raised in parallel, the approver would be confirming something that already happened. If it simply errored, the agent would typically retry or route around the control. Holding it keeps the workflow coherent: on approval, execution resumes from where it paused; on denial, the agent receives a definitive refusal it can reason about and report. Timeouts are a policy decision, and the safe default is that an unanswered approval expires as a denial rather than aging into an allow.
How is the approval decision recorded?
As part of the same record as the action it gated, not as a separate audit event to be correlated later. The record ties together the agent that attempted the action, the person it was acting for, the operation and its parameters, the policy that triggered the escalation, the named approver, their decision, and the timestamps for both the request and the response. Because it is written at the moment of the decision rather than assembled from logs afterwards, an auditor asking who authorized a specific action gets a direct answer instead of a reconstruction across systems.
Does human-in-the-loop mean approving every agent action?
No, and a design that did would not survive contact with production. The overwhelming majority of agent actions are routine and clear automatically with no added latency; approval is reserved for the classes of action where a person should be accountable. That selectivity is what makes the control credible — an approver who sees a handful of consequential decisions reads them, while one facing hundreds of routine confirmations stops reading and the oversight becomes fictional. Getting the thresholds right matters more than setting them strictly.
See a high-risk action routed to a named approver.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.