When does an AI assistant trigger an Algorithmic Impact Assessment?

By Sherif AbdElGawad, Chief AI Officer · Published 15 August 2026

The Treasury Board Directive on Automated Decision-Making applies to production systems that make or support administrative decisions or related assessments about clients. It excludes test and research systems. So an AI assistant triggers an Algorithmic Impact Assessment when two things hold at once. It has moved into production, and an officer relies on its output in an administrative decision or assessment about a person or entity the institution serves. A retrieval assistant that returns passages to an analyst who then reasons independently can fall outside that scope. The institution must make that judgement and record it.

The detail follows: where the boundary sits, and what the assessment asks. Then how the resulting impact level drives peer review, and a screening list you can apply to your own workflow this week.

A system supports a decision when its output is an input the decision-maker relies on as such. That covers a score, a ranking, a recommendation, an eligibility signal, a risk flag, a draft determination, or a summary that in practice becomes the basis of the decision. The system does not have to be automatic, and it does not have to be right. What matters is the role its output plays in the administrative process.

A system retrieves information when it finds and presents source material that a human then independently reasons from. The officer reads the cited passages, applies their own judgement and legislative authority, and could reach the same conclusion without the tool, more slowly. The tool is a faster index, not a participant in the reasoning.

The honest position is that this boundary is a judgement your institution makes, in context, for a specific system. The Algorithmic Impact Assessment is the instrument used to work through and document that judgement. That is why we advise completing the assessment when the answer is unclear. Do not debate applicability in a meeting. The questionnaire is the structured way to find out, and a completed assessment showing a low impact level is a documented result an auditor can review.

The questionnaire is in two parts. Risk questions describe the system, the business process, the data and the people affected, and produce a raw impact score. Mitigation questions describe the controls in place (consultation, data governance, testing, explainability, human oversight, monitoring) and produce a mitigation score that can reduce the raw result. The combination yields an Impact Level from I to IV, and the level determines the requirements that attach to the system.

Read the areas the assessment probes before you build, because they cover architectural decisions as well as paperwork:

Project authority

The legal and program authority for the activity, and whether the automated component is within it.

System capability

What the system does, what it outputs, how autonomous it is, and where a human sits in the process.

Algorithmic explainability

Whether the reasoning can be explained to an affected person in terms they can act on, rather than whether an engineer can describe the model.

Data quality and provenance

Where the data came from, whether it is fit for the purpose, how it is maintained, and what happens when it is wrong.

Protected characteristics and proxies

Whether the system uses characteristics protected under human rights law, or proxies for them, and whether that could compound existing barriers for vulnerable groups.

The last one deserves particular attention in retrieval systems, where bias hides in the corpus and the ranking rather than in an explicit variable. A system that surfaces certain precedents more readily than others is making a substantive choice, even though no protected characteristic appears anywhere in its configuration.

Impact Levels II to IV require peer review. Qualified reviewers may come from government, academia, civil society, a contracted specialist, or a board specified by the Treasury Board Secretariat. The common assumption that a department must hire an external firm is not accurate. A qualified reviewer inside government or in an academic institution can satisfy the requirement, and that is often the faster and cheaper route.

Reviewers examine whether the assessment accurately describes the system, and whether the data is of adequate quality and appropriately sourced. They also examine whether the process is procedurally fair to the people affected, whether the explanation offered is meaningful, and whether privacy obligations have been properly addressed. Give them what they need to do that work. That means the completed assessment, the data description, the evaluation method and results, the human oversight design, and an honest list of known limitations.

1. Is this going to production, or is it research or testing? Test and research systems are excluded from the Directive. Record the date production begins, since that change of status is easy to miss.
2. Who is affected by the output? A client of the institution (a person or entity receiving a service, benefit, decision or enforcement action), or only internal staff producing internal work.
3. Is the output used in an administrative decision or a related assessment? Follow the output through to where it lands. If it reaches a decision record, a case file or a recommendation, say so.
4. Does the system produce a score, ranking, recommendation, eligibility signal or draft determination? Any of these points toward support of a decision rather than retrieval.
5. Would a reviewer, in practice, adopt the output without independent reasoning? Ask the people who will use it rather than the people who will govern it.
6. Does the system use protected characteristics or plausible proxies for them? Postal code, name form, language of correspondence and institutional history are all proxies in the right context.
7. Could the output affect rights, entitlements, health, safety, economic interests or access to a service? If yes, treat the screen as pointing toward the assessment regardless of how the tool is described.
8. What happens when it is wrong? Who notices, how quickly, what is the recourse for the affected person, and is the effect reversible?

If questions 3, 4, 5 or 7 return a yes, complete the Algorithmic Impact Assessment. If they all return a clear no, record the screen, the date, the reasoning and the person accountable. Then put re-screening into change control. A low-impact assistant can quietly acquire a recommendation feature in release four and cross the boundary without being re-screened. We help your institution run this screen as part of the Governance Sprint. We then design the resulting boundary into the six-week pilot.

The Government of Canada AI Register is a useful map of what federal institutions are doing with AI. It is not a list of systems requiring an Algorithmic Impact Assessment, and you should not cite it as one. The register covers systems from early exploration through deployment. A listing says nothing in itself about whether the Directive applies to a given entry.

It is also explicitly a minimum viable product with incomplete fields. It held 412 entries from 43 institutions when we read it on 5 September 2026, against a file last updated on 28 April 2026. That count should not be quoted as the number of federal systems subject to the Directive. The register carries no impact level field at all, so it cannot answer that question either way. Treat it as a directory for finding comparable work and the people doing it, which is valuable, and not as a compliance denominator. We read the whole file in what the federal AI register shows.