Human approval patterns for government AI agents

The question sounds like a policy problem. It is a design problem, and once you treat it as one it becomes tractable.

The Treasury Board of Canada Secretariat published its Guide on the Use of Agentic Artificial Intelligence on 22 May 2026. Its operative sentence on approval reads:

“When an AI agent’s action alters a system’s state (send, publish, approve, spend, update records), include a review/confirmation step in the design.” The exception follows: “unless the expected impact is demonstrably low and the action is trivially reversible.”

Two things in that sentence are easy to misread.

The first is the trigger. The gate attaches to a state altering action, not to a judgment about how important the task feels. An agent that drafts a briefing note and an agent that sends one are governed differently, even though the underlying model and the underlying content are identical. The guide enumerates the altering side: sending, publishing, approving, spending, updating records. It does not enumerate the complement, so draw that line yourself and write it down. Remember that a retrieval call writing to a cache or an audit trail has altered something too.

The second is the exemption. It is conjunctive. Skipping the review step requires that the expected impact be demonstrably low and that the action be trivially reversible. Reversibility alone does not buy you out of the gate. The sentence is not permission to automate anything you can undo.

Approval is a family of controls, and a sound design combines three or four of them.

Approval before the action. The agent proposes, a person confirms, the action executes. The strongest control and the most expensive in human attention.

Human involvement inside the decision. The agent produces an assessment and a person makes the determination. This is the shape the Directive on Automated Decision Making imposes at its two highest impact levels.

Monitoring after the fact. Sampling, spot checks and periodic review. The guide asks institutions to “occasionally have the agentic AI tasks performed manually by human experts for comparison with the agent’s performance.”

Interrupting a running process. The ability to halt mid execution rather than only at the boundaries.

Overriding an output. A person disregards or reverses what the system produced.

Named accountability. The guide is unambiguous. It wants a named role accountable for the AI agent’s outcomes and monitoring, with a documented escalation path and a designated delegate during absences or transitions. A delegate is not a nicety. An agent that runs while its accountable owner is on leave has no owner.

Notice to the affected person. Telling someone that an automated system was involved.

Explanation after the fact. Being able to say why, afterwards, on request.

Independent peer review. A second party examining the system before it goes live.

Logging sits underneath all nine, and none of them works without it. The guide asks institutions to “keep logs of tools used, actions taken, approvals given and key inputs/outputs.” For tool calls, it adds the tool name, the time, the outcome of the call and the type of parameters passed. Every one of those fields is cheap to capture at build time. Reconstructing them later is impossible.

The Directive on Automated Decision Making came into force 1 April 2019 and applies to systems developed or procured after 1 April 2020. Its most recent amendment that we can confirm from the Treasury Board of Canada Secretariat’s announcement record took effect 25 April 2023. It extended coverage to internal services including hiring, performance management and employee security screening.

Its Algorithmic Impact Assessment produces four impact levels: Level I, little to no impact; Level II, moderate; Level III, high; Level IV, highest. Its appendix on human involvement is binary, not graduated. At Levels I and II, an institution may render decisions without direct human involvement. At Levels III and IV, the process needs specific human intervention points, and a human must make the final decision.

The Directive requires the assessment before production. The Secretariat’s separate assessment tool guidance goes further. It recommends completing the assessment at the beginning of the design phase and again before production, to validate that the results reflect the system that was built. It also describes publication in both official languages on the Open Government Portal.

The trigger for all of this is the administrative decision test; whether a system faces inward or outward does not decide it. A system is in scope when it makes or assists an officer in making a decision that affects a person’s rights, privileges or interests.

The Secretariat’s own Guide on the Scope places outside that boundary “actions that do not impact the legal rights, privileges or interests of individuals or employees.”

Its examples include “research, program evaluation, brainstorming and drafting documents.”

Out of scope is not unregulated. The same guide notes that other requirements apply to systems used solely for research and experimentation, “such as those relating to privacy, security, information management, and values and ethics.” The same reasoning applies to any workflow you place outside scope.

The Guide on the Use of Agentic Artificial Intelligence asks institutions to “maintain a pause and disable mechanism (‘kill switch’) external to the AI agent or agentic system.” It also asks for “an appropriate recovery plan for unintended actions.” External is the operative word, and it is the Canadian guide’s own. A stop control implemented inside the agent is a request, not a guarantee.

The European Union reaches for the same control without requiring it to sit outside the system. Article 14(4) of Regulation (EU) 2024/1689 covers the people assigned to oversight. They must be enabled, “as appropriate and proportionate”, to decide in any particular situation not to use the system. They must also be able to “otherwise disregard, override or reverse the output”. They can intervene in its operation. They can also “interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state.”

One correction matters here for anyone planning against the old dates. The high risk obligations were originally to apply from 2 August 2026 for Annex III systems. For Annex I systems the date was 2 August 2027. Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026, moved them to 2 December 2027 and 2 August 2028 respectively. 2 August 2026 remains live for the rest of the Regulation, so the date has not disappeared. It no longer governs the high risk obligations.

Take the workflow you are planning. Write down every action the agent can take, and mark each one as state altering or not. That single column will resolve most of the argument, because it turns “how risky is this?” into “does this change something?”.

Then, for each state altering action, name the pattern, name the accountable role, name the delegate, and name the log fields that would let you prove afterwards what happened. Four columns. It fits on one page, and filled in before building, it gives a review board what it needs to see.

Do this early: retrofitting an approval model onto a working agent means rebuilding the agent.

Next in this series: five knowledge workflows Canadian public institutions can pilot safely.