Treadstone Associates
Guide

How to decide what a human must approve

No Canadian statute tells a private business where to put the human. The closest real templates — a federal directive, a provincial privacy law, a voluntary code — each answer a narrower question than “is a human involved.” This guide works through them in order and turns them into a checkpoint you can actually run.

Treadstone Associates · Updated 2026

Key takeaways

  • • Québec’s Law 25 is the one hard Canadian rule on point: where a decision about a person is based exclusively on automated processing, the organisation must tell them and let them take it to a staff member who can review it.
  • • The federal Treasury Board’s Directive on Automated Decision-Making binds government departments, not businesses — but it is still the most detailed Canadian description of what a real approval checkpoint looks like, and it is worth borrowing on purpose.
  • • The OPC’s generative-AI principles ask for an “effective challenge mechanism” after a decision, which is a different design question from requiring pre-approval before one.
  • • The useful question is never “is a human in the loop” — it is which step, on which class of case, checking what, with what happens if they are wrong.

STEP 01 OF 10

Start from Québec’s actual rule, because it is the only hard one

Most of what circulates about “AI needs human oversight” in Canada is voluntary. Québec’s privacy regulator, the CAI, is the exception. Its guidance on Law 25 states, in the original French: “Les organisations doivent notamment informer la personne concernée lorsqu’elle fait l’objet d’une décision fondée exclusivement sur un traitement automatisé de ses renseignements personnels, et ce, au plus tard au moment où elles l’informent de cette décision.” In plain English: where a decision about someone rests exclusively on automated processing of their personal information, tell them, no later than when you tell them the decision — see the CAI’s summary of the Law 25 changes.

The same page adds the review right: “Les organisations doivent également donner l’occasion à la personne concernée de présenter ses observations à un membre de leur personnel en mesure de réviser cette décision.” — the person must be able to put their case to a staff member who can actually revisit the decision. Note the word exclusively: the rule targets decisions with no human step at all, not every decision an AI tool merely assists with. If a person reviews the output before it takes effect, this specific trigger does not apply — which is itself the argument for building a review step deliberately, rather than by accident.

STEP 02 OF 10

Separate a draft from a decision

Before deciding who approves anything, decide whether the AI is producing a draft or a decision. A draft reply, a flagged anomaly, a summarised document changes nothing on its own — a person has to act on it first. A decision that fires by itself — approving a refund, adjusting a price, sending a notice, submitting a filing — is a different category, because the harm (if the output is wrong) happens before anyone looks at it.

This split does most of the practical work. Plenty of AI use in a small business never needs a formal checkpoint because nothing happens automatically. The checkpoint only matters once the system is wired to act — and that wiring, not the model itself, is the design decision worth scrutinising.

STEP 03 OF 10

Borrow the federal government’s own trigger question

Ottawa’s Directive on Automated Decision-Making binds federal departments, not private businesses — say that plainly, because it is a common source of confusion. But its scope test is a genuinely useful filter to borrow: it applies to “any automated decision system in production used to make an administrative decision or a related assessment about a client” (Directive on Automated Decision-Making, s.5.1).

Translate “client” to “customer, applicant, employee, or anyone else affected” and the test becomes: does the system’s output change a real person’s status, price, eligibility, or standing? If yes, treat that case the way the Directive treats an administrative decision, even though nothing legally compels you to.

STEP 04 OF 10

Decide between pre-approval and post-review — they are not the same control

Two different safeguards get conflated under “human oversight.” Pre-approval means nothing happens until a person signs off; the AI proposes, a person disposes. Post-review means the system already acted, and a person is checking or could still reverse it. ISED’s Voluntary Code commits signatories to “Human Oversight and Monitoring”, defined on the page this way: “System use is monitored after deployment, and updates are implemented as needed to address any risks that materialize” — see the Voluntary Code of Conduct. That is a monitoring commitment, not a gate.

Pick pre-approval for anything hard to reverse or high in consequence; post-review is defensible for anything cheap to undo. Naming which one you are actually running — out loud, in writing — is what most informal “a human checks it” setups skip.

STEP 05 OF 10

Write the notice before you write the checkpoint

The Directive’s transparency requirement is two-sided and both halves are worth copying regardless of who it legally binds: “Providing notice through all service delivery channels in use that the decision will be made or assisted by an automated decision system” before the decision (s.6.2.1), and “Providing a meaningful explanation to clients of how and why the decision was made” after it (s.6.2.3) — both from the Directive.

A business that tells an affected person, in plain language, that AI assisted the decision — and can explain afterward why it went the way it did — has done the cheap, high-value part of this whole exercise, independent of any approval mechanics.

STEP 06 OF 10

Build the challenge path, not just the checkpoint

A checkpoint stops a bad output before it goes out. A challenge mechanism is what happens after, when the person on the receiving end disagrees. The OPC’s generative-AI principles state it directly: “Ensure that impacted individuals are provided with an effective challenge mechanism for any administrative or otherwise significant decision made about them,” including “the opportunity to request human review” — from the Principles for responsible, trustworthy and privacy-protective generative AI (dated 2025-05-06).

A route to a named person who can actually reopen the file satisfies this. A support chatbot that repeats the original answer does not, whatever it is branded as.

STEP 07 OF 10

Match the checkpoint to the stakes, case by case

A single approval rule applied to every case is usually either too heavy for the routine ones or too light for the rare, damaging ones. Sort cases informally into three bands: low-stakes and reversible (a draft reply, an internal summary) needs no pre-approval at all; moderate (a price change, a scheduling decision) can run with fast post-review and a clear reversal path; high-stakes or hard-to-reverse (denying a claim, closing an account, a legal filing) needs a named person’s sign-off before it happens.

This is an informal echo of the structure behind the Directive’s own Impact Assessment Levels, which scale requirements to “the reversibility and duration of impact” of the decision (Appendix B). You do not need the government’s paperwork to use its logic.

STEP 08 OF 10

Name the role, not “a human”

“A person reviews it” without naming who becomes, in practice, nobody — the step gets clicked through by whoever is nearest the queue. Assign the checkpoint to a specific role, record who approved what and when, and treat that record as the raw material for the “meaningful explanation” a customer might later ask for.

This is also what makes the challenge mechanism in Step 6 workable: a second reviewer needs to know who made the first call and on what basis before they can meaningfully revisit it.

STEP 09 OF 10

Tell the approver what to actually check

Skimming an AI-drafted summary and clicking approve is not the same discipline as verifying the underlying answer. Canada’s Cyber Centre is blunt about this: generative AI output “can be incorrect”, “might not make sense”, “can be biased”, and, in the Centre’s own words, “You should always be aware of and validate your sources to verify whether the content being presented is accurate” — from ITSAP.00.041, Generative artificial intelligence.

Give the approver a short, specific list of what to verify for that particular case type — the number, the citation, the eligibility rule — rather than a general instruction to “review before sending.” A vague instruction gets a vague check.

STEP 10 OF 10

Revisit the rule on a schedule, not by accident

A checkpoint written once and left alone drifts out of date as the system, the data, or the stakes change. The Directive requires reviewing and updating the algorithmic impact assessment “on a scheduled basis, including when the functionality or scope of the automated decision system changes” (s.6.1.3). Put a real date on your own review, tied to any change in what the system is allowed to touch — see what an AI can reach once it’s connected for how that access tends to expand quietly over time.

If the checkpoint has not been revisited since the system started doing more than it did on day one, that is the first thing to fix — not the checkpoint’s wording.

Common mistakes

Treating “a human is somewhere in the loop”. as sufficient without saying which step, on which cases, checking what. That sentence describes almost any process and guarantees almost none of it.

Approving the AI’s confidence instead of its output. A fluent, well-formatted answer passes a distracted reviewer regardless of whether it is correct — the Cyber Centre’s own caution that output “can be biased” and “might not make sense” applies precisely at this point.

Building the checkpoint but skipping the challenge path. A customer who disagrees with an AI-assisted decision needs somewhere real to go. Without it, the checkpoint only protects the business, not the person the decision was about.

Copying a government-style sign-off wholesale. Importing the Directive’s full documentation burden for a low-stakes internal draft is how these processes get abandoned within a month. Scale the paperwork to the stakes, as in Step 7, not to the source you borrowed the idea from.

A simple way to sort cases into three bands

This is a structuring tool, not a Canadian standard — use it to organise your own case types, not as a rule anyone else recognises.

  • • Band 1 — draft only. Nothing happens until a person acts on the output. No approval step needed; spot-check quality periodically.
  • • Band 2 — acts, then reviewed. The system executes and a named person is notified and can reverse it within a defined window. Fits reversible, moderate-consequence actions.
  • • Band 3 — approval required first. Nothing executes until a named role signs off. Reserved for hard-to-reverse or high-consequence actions — denying someone something, closing an account, anything that would trigger Québec’s Law 25 notice-and-review duty if it ran with no human step at all.

Assign every recurring AI-assisted action in the business to one band on purpose, rather than discovering which band it was in after something goes wrong.

Frequently asked

Does Canadian law require a human to approve every AI decision?

No general rule does. The one hard Canadian requirement on point is Québec’s Law 25, and it is narrower than “every decision”: it applies where a decision about a person rests exclusively on automated processing, and it requires notice plus a route to human review — not pre-approval before the decision is made.

Is the federal Directive on Automated Decision-Making a law businesses have to follow?

No. It binds federal government departments and agencies, not private businesses — unless you are selling a system into government, in which case your customer will hold you to it. For everyone else it is a well-documented model to borrow from, not an obligation.

What is the difference between human oversight and a human approval gate?

Oversight, in the sense ISED’s Voluntary Code uses it, means monitoring a system after it is deployed and fixing problems as they surface. An approval gate stops a specific output before it takes effect. Both are legitimate controls; they answer different questions, and a process can need one, the other, or both depending on the stakes of the case.

See how approval steps hold up once a system is actually connected to your tools.

Deciding who signs off is easier before the AI can reach a live system than after.