AIDA, OSFI E-23, and the agent-action problem.
If you sell AI agents into a Canadian bank, fintech, insurer, or crown corporation in 2026, you are about to walk into a procurement conversation with three regulators in the room behind the buyer. None of them have agreed to a final position on autonomous agents yet. All of them have published enough that the question they are going to ask is already legible.
The three documents that matter
Three documents are doing most of the work shaping enterprise procurement in Canada right now.
AIDA — the Artificial Intelligence and Data Act, embedded in Bill C-27. It has been in committee for a long time and the text continues to shift, but the obligations it gestures at are mostly stable: identification of operators, record-keeping for "high-impact" systems, risk mitigation, and notification requirements. Even though AIDA is not yet in force, procurement teams treat its expected obligations as already binding, because no enterprise wants to deploy a system today that fails to meet a regulation that ships next year.
OSFI E-23 — the Office of the Superintendent of Financial Institutions' guideline on Model Risk Management, refreshed in 2024. Every federally regulated financial institution in Canada (the banks, the major insurers, certain pension funds) operates under it. It has been in force for over a decade in earlier forms and has the legal weight of a binding regulator's expectation. AI agents that take financial actions are squarely in scope.
The Directive on Automated Decision-Making — Treasury Board's directive for federal government use of AI. It applies to every federal department and to vendors selling into them. The directive's risk-tiered impact assessment is now imitated by provincial governments and crown corporations.
There are others — FINTRAC for AML, OSFI's third-party risk guideline B-10, the Office of the Privacy Commissioner's positions on automated processing — but the three above are the ones that consistently show up first in procurement questionnaires.
The convergent question
Read the three documents end-to-end and you will notice something. They use different language, address different regulated populations, and have different teeth. But they all converge on the same operational question, and most agent vendors are not yet built to answer it:
"For each consequential action this agent took, identify the natural person who, through a documented chain of authority, is accountable for that action — and produce evidence sufficient for a third party to verify the chain."
AIDA calls this "identification of the responsible person." OSFI E-23 calls it "ownership and accountability of model use." The Treasury Board directive calls it "authority to operate." The vocabulary differs; the ask doesn't.
Why this is harder than it sounds
The naive answer is "well, the developer is responsible." That answer fails in three places.
It fails when the agent makes an action that the developer did not specifically intend — which is the entire point of an autonomous agent. Sending money is the developer's doing only in the sense that they wrote the code; the specific decision to send this amount to this merchant at this time was the agent's. Accountability follows authority, and the developer didn't authorize this particular action.
It fails when the agent is operated by a different person than the one who built it. In a typical enterprise deployment, the agent is deployed by an engineering team but operated by a business unit. The business unit configured it, set its budget, decided which workflows it owns. Accountability tracks that operational reality, not the build.
It fails when the chain has multiple humans. A board approves an AI program. A CFO approves an agent class. A department head approves a specific deployment. An operator runs a session. Pretending one of these is the one accountable is the kind of thing that gets a regulator to send a follow-up letter.
The honest answer maps cleanly onto an authorization chain: the action was authorized by the operator, who was authorized by the department head, who was authorized by the CFO, under policies traceable to a specific board approval. The chain is the answer.
What an actual procurement conversation sounds like
Imagine the procurement officer at a Canadian schedule-I bank. They have an RFP for an agent that handles low-value vendor invoice processing. The questions on the questionnaire — and these are real, paraphrased from public RFPs — include:
- "Provide a description of the chain of accountability from the agent's actions to a human officer of the bank."
- "Describe how operations of the agent are logged and how those logs are made available to the bank's internal audit function for a period of seven years."
- "Describe the controls that prevent the agent from exceeding its delegated authority, and how those controls are tested."
- "Describe the kill-switch capabilities available to a bank operator, including the maximum time from kill-switch invocation to action cessation."
- "Describe how AIDA Section X obligations [the section number changes — it's the high-impact systems section] are addressed."
Most agent vendors today have no good answer for at least three of these. The vendors that do answer well are the ones who treated authorization, audit, and revocation as architectural primitives from the beginning, not as last-mile features to bolt on for the bank.
What OSFI E-23 specifically wants
OSFI E-23 is the most concrete of the three documents because it is in force today. The expectations relevant to agent systems map onto a small number of practical controls.
Inventory. Every model in use must be identified, tracked, and assigned an owner. For agents, this means every agent identity — including transient agents spawned for a task — must be inventoried and owned. The inventory must survive personnel changes; the owner field is a role, not a name.
Tiered governance. Models are tiered by risk, with stricter controls at higher tiers. Agent tiers in practice line up with the size of the action: an agent that drafts emails is a different tier from one that signs purchase orders. The control surface (policies, budgets, kill switches) must be specific enough to enforce different rules at different tiers.
Independent challenge. The model must be reviewable by someone who is not the model's owner or developer. For agents, this means the audit log, policy artifacts, and budget records must be queryable by an independent reviewer in a form that does not require trusting the operator's word about what happened.
Periodic review. Model behavior must be reviewed on a defined cadence. For agents, this is decision review — sampling decisions, examining policy fires, looking for pattern shifts.
None of this is exotic. All of it requires the system to have been designed with the review in mind.
What AIDA is going to want, when it lands
AIDA's text has been moving and may move further. The shape, though, has been stable across drafts.
"High-impact systems" — a category we should expect to include autonomous agents that take consequential actions — will require a documented risk assessment, mitigation plan, ongoing monitoring, and notification of material harm. Operators will be required to identify themselves, retain records, and make those records available to a regulator on request.
The interesting part is the notification obligation. AIDA contemplates that material harm caused by a high-impact system must be reported to the responsible regulator. For an agent system, "material harm" includes financial harm — a series of unauthorized transactions, for example. To meet the notification timeline, the operator must know material harm has occurred. That requires monitoring of denied actions, anomalies in patterns, and chain-integrity breaks. Not after the fact, in real time.
This is not a "post a privacy policy" obligation. It is a control-and-detection obligation, and it requires architecture choices that most current agent products have not made.
The federal directive's quiet influence
The Directive on Automated Decision-Making applies, strictly, only to federal departments. But two things make it more important than its surface scope suggests.
First, every Canadian crown corporation, agency, and many provincial governments use it as a template for their own AI procurement. If you sell to Canada Post, the CRA, Hydro One, OPG, the Ontario government — your buyer's questionnaire will include the directive's algorithmic impact assessment.
Second, the directive is the only one of the three that has actually been operationalized for years. Federal departments have run the algorithmic impact assessment hundreds of times. The questions are tested. The procurement language is mature. The directive's score-band logic is a workable proxy for what AIDA's risk-tiering will likely look like in practice.
If you can answer the directive's algorithmic impact assessment cleanly, you can probably answer 80% of what the bank's questionnaire asks. The directive is, effectively, a free dress rehearsal.
What to put in front of a Canadian buyer
Not slides. Slides explain. Buyers in this segment want artifacts.
An architecture document showing the identity hierarchy, the policy layer, the budget layer, and the audit log. One page, no marketing.
A compliance mapping showing how each control surface answers a specific obligation in AIDA, OSFI E-23, and the directive. The buyer's procurement officer will paste this into their internal questionnaire.
A threat model stating, plainly, what the system defends against and what it does not. Procurement teams have read enough vendor materials to discount any document that doesn't have an "out of scope" section.
A working demo that shows a denial in real time. Not a screenshot. A buyer who watches an action get denied, see the reason, and verify the chain integrity has just had the audit question answered without saying a word.
The shape of the next twelve months
AIDA will land, in some form. OSFI's expectations on AI use will tighten further. Provincial governments will continue to follow the federal directive's pattern. The three documents will continue to converge.
The vendors who win in this segment over the next year are not the ones with the best models. They are the ones whose architecture answers the convergent question without pivoting and reframing it. The chain is the artifact. Build the chain.