AI governance, explained
What Canadian regulators expect from AI, and what to do about it this quarter
A field guide for the leader who has to answer three questions about AI: could it leak our data, can we prove we are in control, and do we know what is running?
By Daniel Zivkovic, founder of Magma Inc.
If you lead a business line, a technology team or a risk function at a Canadian bank, insurer, credit union or pension plan, someone has probably asked you three questions this year: could AI leak our data, can we prove to a regulator that we are in control, and do we even know what is running? All three start with the same record: one per AI use case. This guide maps what the regulators have published, puts the dates on one calendar, and shows how the same expectations read in the United States, the United Kingdom, the European Union and Singapore. It ends with what to do this quarter, and with the cases where you do not need any of this. It is written from the working side of the problem: I run an AI use-case intake with data classification, direction, model placement and autonomy limits inside a Fortune 500 financial-services company.
I got into AI governance by accident, trying to bring clarity so decisions could be made. In regulated industries I kept seeing the fear of AI grow bigger than the risk of the use case in front of it. The fear is understandable: financial institutions are right to be wary, and strict governance is a must. I learned how much when I ran my own work through the same questions and found what I had missed.
The short version. Canada's financial regulators have not issued a new AI rulebook. Instead, OSFI, Canada's banking regulator, extended its model risk guideline, E-23, to AI, and the AMF issued a new AI-specific guideline that supplements its model risk guideline. Both take effect on 1 May 2027, and OSFI's 2026 technology risk bulletins describe sound practices that institutions can consider now. The one artifact every one of those expectations points at is an inventory of what you run: each AI use case, who owns it, what data it touches, and how much it is allowed to do on its own.
Short on time? Jump to what to do this quarter.
Six areas, one inventory
OSFI's July 2026 bulletin on generative and agentic AI groups its sound practices in six areas, 33 by my count, and every area opens with the same words: "institutions can consider the following risk control and mitigation measures." Read them as a picture of good practice that a supervisor will recognize, not as a checklist. For each area, here is what it is about and one artifact an examiner might ask to see.
1. Governance and strategic accountability (6)
Senior management understands AI well enough to challenge it, AI sits inside the risk appetite and enterprise risk management, and someone owns each use case.
The artifact: per use case, a named owner, the limit on autonomy, and the approval checkpoint.
2. Information and decision integrity (6)
AI reads only trusted, classified data, sensitive data stays out of unapproved tools, and AI output informs a decision that a person makes and can explain.
The artifact: the data classification of what each AI system reads, and a decision log showing where a person decided.
3. Controlled software development and changes (8)
Models, data, tools and agents are treated as controlled technology assets, with secure development, change management and testing under normal and stressed conditions.
The artifact: the AI inventory itself, with change records for prompts, models and tools.
4. AI agent autonomy and access (3)
Every agent gets its own identity with least privilege and short-lived credentials, works through allow-listed tools, and leaves an activity log that someone reviews.
The artifact: the agent's identity, scopes and token lifetime, its tool allow-list, the review of its action log, and the spend and step ceiling that stops it.
5. AI in cyber security operations (5)
Prompt injection and other misuse belong in threat modelling and testing, AI telemetry flows into security operations, and AI incidents have a playbook.
The artifact: the threat model naming prompt injection, and an AI incident playbook with an exercise date.
6. Resilience and third-party risk (5)
Know which outside model and vendor sits under each critical operation, test what happens when it fails, and have third parties tell you if and how they use AI.
The artifact: a dependency map from critical operations to models and vendors, and each vendor's AI disclosure.
Count the practices and a pattern shows: eight of the 33 are about controlled software development and change, and only three about agent autonomy and access. My reading, not OSFI's, is that the bulletin treats agentic AI first as a change-management problem. Notice also that the six artifacts are fields of one record per use case: an owner, a data classification, an asset entry, an identity, a playbook, a dependency. In my reading, keep that record for every use case and you have the inventory.
What every regulator asks for, in different words
Read the instruments side by side and four expectations repeat, whatever the jurisdiction calls them. None of them is new as an idea. What changed is that each now names AI explicitly.
An inventory of what you run
NIST's AI Risk Management Framework makes it a category of its own, GOVERN 1.6, the AI system inventory. OSFI's E-23 lists the fields: model ID, name, risk rating, owner, developer and origin, plus version, deployment date, reviewer, approver, dependencies, data sources, approved uses, limitations, review dates and monitoring status, with vendor models in scope. NYDFS expects an inventory of systems that use or rely on AI. MAS observed banks recording purpose, scope, jurisdiction, risk materiality, approvals, use of personal data and owners, plus provider, version and endpoints for third-party AI.
Four sources, overlapping lists. E-23 and MAS describe model inventories, so the record I suggest is a use-case record that links to the model records E-23 asks for, rather than a separate list for each source.
An owner, and a person who decides
OSFI's bulletin asks institutions to consider defining ownership across the AI lifecycle and setting limits on autonomy, with human oversight and accountability for material decisions. MAS rates risk materiality partly on reliance, which it says "takes into account the autonomy granted to the AI". FSRA expects governance "commensurate with the scope and impact of the AI use cases".
The common thread: how much the system may do alone is a decision with a name next to it, not a default setting.
Disclosure of the AI inside what you buy
E-23 brings third-party models into scope. OSFI's bulletin lists an obligation on third parties to notify if and how they use AI. NYDFS recommends third-party AI diligence and notification. MAS states that institutions "remain accountable for AI used in the services they deliver, including AI developed, operated or provided by third parties", and its 2024 paper covers notification when AI is introduced into existing vendor solutions.
The case most often missed is the product you already license that quietly added AI. It reads data you gave the vendor years ago. Some vendors now ship AI features that ask you to bring your own model (BYOM), so a product you approved years ago becomes a new placement question overnight.
A plan for when it goes wrong
OSFI's bulletin lists AI incident response playbooks, developed and tested, and outage scenarios with manual fallbacks. FSRA expects notice of a material IT incident no later than 72 hours after determining it. MAS names throttling and kill switches for AI that exceeds risk tolerances.
Cost belongs here too. OWASP's agentic list describes a planner that "repeatedly calls costly APIs, causing DoS or bill spikes". Most cloud budget alerts act on billing data that lags 8 to 24 hours and do not stop consumption on their own; a limit in the request path is what stops a runaway loop.
The three overlays that decide the route
An inventory tells you what you have. The harder question is whether a new use case is allowed, and in practice three facts about it settle the route, meaning which reviews it must pass, long before anyone debates which model is best.
Going into an architecture or security review can feel like applying for a mortgage: you answer every question carefully and never know whether the last answer moved you closer to yes or further away. Banks solved that for borrowers with pre-approval. An intake record does the same for a project: before the review, the team knows which questions decide the route, and so do the reviewers.
Data: the tier and the overlays. A common scheme classifies data in tiers such as Public, Internal, Confidential and Restricted. Personal information and cardholder data are not tiers. They are overlays, extra labels recorded on top of the tier, and each opens its own review: privacy for personal information, and the card industry's security standard (PCI DSS) for cardholder data. For personal information, the federal and Quebec privacy laws apply, and the privacy commissioners' nine principles for generative AI are the clearest statement of what good practice looks like. Reviewers want the tier and the overlays recorded separately, because a Confidential document with no personal information and a Confidential document full of it take different paths.
Direction. Does the use case send company data out to a model, bring model output back into a system of record, or both? A tool that drafts into a folder a person reads carries a different risk from one that writes into a customer record, even with the same model behind both. In the public intake and inventory templates I checked (OSFI E-23, the EU AI Act registration annex, the US federal AI inventory), the questions are about the data a system uses, not which way it flows, so direction is usually left to the privacy review, which only starts when personal information is involved. Inbound is not automatically safe: a model that reads outside web pages can be steered by what it reads, which FINOS lists as indirect prompt injection.
Placement. Where the model runs: inside the corporate network, in a cloud account the company controls, or in a vendor's own software-as-a-service tenant outside the boundary. This is why the same model can be not permitted as a SaaS call and permitted on a connected, no-training cloud account. In the company's own account, with private connectivity and no-training and no-retention terms in the contract, Confidential data stays under contractual no-training and no-retention terms, reached over private connectivity. The model did not change. The route did.
The overlays also explain a puzzle every employee notices: why can everyone use the office assistant while a developer waits weeks for approval? Because there are three classes of AI user, and each reaches the boundary differently. Business users on a licensed assistant: the vendor contract sets placement and retention, the company's admin controls set what it can reach, and the review is mostly about that configuration. Developers on an approved platform: custom code, custom identity and custom logging, so the full record applies. Vendor products that added AI: the company did not build it and may not have noticed it, so the record exists to make sure someone does, and the third-party review runs again.
Write those three facts down for every use case and most routing arguments end before they start.
The same expectation across jurisdictions
| Canada (OSFI) | United States | United Kingdom | European Union | Singapore | |
|---|---|---|---|---|---|
| Inventory | E-23 names the model-inventory fields, vendor models included; the bulletin treats models, data, tools and agents as controlled assets | NYDFS expects an inventory of systems that use or rely on AI; NIST GOVERN 1.6 is the AI system inventory | PRA SS1/23 starts with model identification and classification, for banks that use their own models to set regulatory capital | Not stated here | Observed inventory attributes: purpose, scope, jurisdiction, risk materiality, approvals, personal data use, owners; provider, version and endpoints for third-party AI |
| Human oversight | Ownership across the lifecycle, limits on autonomy, human oversight with accountability for material decisions (sound practices) | SR 26-2 leaves generative and agentic AI out of its scope, so the bank's own governance carries it | Governance is one of the five SS1/23 principles; AI is covered by existing rules | Not stated here | Risk materiality weighs reliance, including "the autonomy granted to the AI" |
| Third-party AI | E-23 covers third-party models; the bulletin lists third-party notification of AI use | NYDFS recommends third-party AI diligence and notification | SS1/23 applies to all models regardless of technology, including third-party models | Not stated here | Institutions "remain accountable" for AI provided by third parties; notification when vendors add AI |
| Incident | AI incident playbooks, developed and tested; outage scenarios with manual fallbacks (FSRA: material IT incidents within 72 hours for Ontario credit unions) | NYDFS expects monitoring of AI, under the existing Part 500 obligations | Not stated here | Not stated here | Throttling and kill switches when AI exceeds risk tolerances |
| Change control | Eight of the 33 practices: secure development, change management, testing under stressed conditions | Not stated here | SS1/23 principles on development, implementation and use, and independent validation | Not stated here | Not stated here |
Each cell summarizes only what the sources behind this guide were read for. "Not stated here" means this guide does not characterize that instrument on that point, not that the instrument is silent. The EU AI Act's high-risk obligations (Articles 9 to 15) apply to Annex III systems from 2027-12-02; their article text is not summarized in this guide.
Where the open frameworks fit
None of the regulators above hands you a catalogue of AI risks to record against. The open frameworks do, and OSFI's own bulletin points at some of them: its related links name the NIST AI Risk Management Framework 1.0, NIST's Generative AI Profile, OWASP's Top 10 for LLM applications and its agentic guidance, and a July 2024 MAS paper on generative AI and cyber risk. They do not name ISO/IEC 42001 or the EU AI Act.
NIST AI RMF 1.0 (NIST AI 100-1, January 2023) organizes the work into four functions and 19 categories, and GOVERN 1.6 is the AI system inventory. The Generative AI Profile (NIST AI 600-1, 2024-07-26) extends it to generative systems. It is the most useful shared vocabulary between a risk team and a technology team, because both already know it.
OWASP's Top 10 for LLM Applications 2025 and its Top 10 for Agentic Applications, published in December 2025, are the security team's lists, and they are concrete where regulators stay general. LLM10, Unbounded Consumption, names the "denial of wallet" attack and answers it with rate limits, quotas and per-request caps. The agentic list adds usage ceilings on cost, rate or tokens, with automatic revocation or throttling when they are exceeded.
The FINOS AI Governance Framework is built by and for financial services. Version 2 is dated 2025-10-20 and published under the CC BY 4.0 licence, so you can reuse it with attribution. Its current catalogue holds 24 risks and 25 mitigations, each with a stable ID, and its maintainers come from Scott Logic, Morgan Stanley, Citi, NatWest and ControlPlane. Its references index maps the catalogue to 13 external frameworks, among them the EU AI Act, ISO 42001, NIST AI 600-1, the OWASP lists and Canadian regulation. One of those mappings is to SR 11-7, which SR 26-2 has since superseded, so read the US mapping as dated.
ISO/IEC 42001 is the management-system standard for AI. It describes how an organization runs AI governance as a system, rather than listing AI risks.
Why tag your records with a catalogue's risk IDs instead of writing your own taxonomy? A risk ID that someone else maintains survives reorganizations and staff turnover. An examiner, an auditor or a peer institution can read it without a glossary. And the mapping work to NIST, OWASP and the EU Act is already public, so your records inherit it. I have not seen a published intake template that joins AIGF risk IDs to OSFI E-23 and the July 2026 bulletin's measures. That join is work your own team can do once and reuse for every record.
What to do this quarter
The hard dates on the calendar below fall in 2027 and 2028. The work that meets them starts with one record per use case, and it fits inside a quarter if you keep it small.
One record per use case. Not one per model and not one per vendor: one for each thing the business does with AI. The same model can sit under five use cases with five different risks, and the examiner's questions are about the use.
Let the business owner fill in what they know. The purpose, the owner, who is affected, which data it touches and its classification, whether it sends data out or writes results back, which vendor product it lives in, and how much it may do without a person. A business owner can answer every one of those at the idea stage, in plain words, without a meeting.
Let the specialists add the evidence. Placement and data residency, the identity the system runs as and its permissions, logging, evaluation results, the threat model, the privacy assessment where personal information is involved, and the spend and step limits that stop a runaway agent. These come from evidence, not opinion, and they belong in the record before a pilot touches sensitive data or takes an action.
Keep a decision log. The early choices (which model, which provider, which platform, which cloud) are made over weeks by different people, and then revised. Record each one as a dated entry with who made it and why, and never edit an old entry: mark it superseded instead. The fields show the current state; the log shows how you got there, which is what an auditor reads.
Start where the risk is. Do not try to inventory everything at once. Start with the use cases that touch personal information and the ones that act on anything: write to a system, send a message, change a record, move money. That is where the bulletin's autonomy and decision-integrity practices apply most directly, and where a missing record is hardest to explain.
Do this and the inventory the examiner asks for falls out as a by-product. You did not run an inventory project. You built a front door, and the inventory is the set of records behind it. If you later buy a governance platform, it is the house behind that door: it stores and monitors what the front door lets in. Part two of this guide covers the intake record itself, with its fields and a worked example.
The calendar: every date in one place
| When | What was published | Why it matters to you |
|---|---|---|
| 2023-12-07 | Canada's privacy commissioners publish nine principles for generative AI. | The plainest privacy anchor: legal authority and consent, appropriate purposes, necessity and proportionality, openness, accountability, individual access, limiting collection, accuracy, and safeguards. |
| 2024-03-01 | FSRA's Operational Risk and Resilience guidance takes effect for Ontario credit unions. | Where a credit union uses advanced analytics such as AI, FSRA will assess its data governance and its controls on harm and bias in models. |
| 2024-04-01 | FSRA's Information Technology Risk Management guidance (GR0016INT) takes effect. | Data classification and access, third-party and cloud risk, change management, and notice of a material IT incident no later than 72 hours after determining it. |
| 2024-04-22 | The UK FCA and PRA publish their AI updates. | AI is covered by existing rules: "technology-agnostic does not mean technology-blind". |
| 2024-10-16 | NYDFS issues its industry letter on cybersecurity risks arising from AI. | No new rules beyond Part 500, and an expectation of an inventory of systems that use or rely on AI. |
| December 2024 | MAS publishes its information paper on AI model risk management. | Observed good practice from banks, including the attributes an AI inventory records. |
| 2025-02-02 | EU AI Act: the AI literacy article and the prohibited practices apply. | Relevant to any institution that operates in or serves the EU. |
| 2025-08-02 | EU AI Act: the rules for general-purpose AI models apply. | A question for your review of the models your vendors supply. |
| 2025-09-11 | OSFI publishes Guideline E-23, Model Risk Management. | All models at federally regulated institutions, including AI and machine learning models and third-party models, with named inventory fields. Pension plans are excluded. |
| 2026-04-17 | The Fed, OCC and FDIC issue SR 26-2, superseding SR 11-7. | Generative and agentic AI models are stated to be outside its scope. |
| April 2026 | OSFI's technology risk bulletin on frontier AI. | It opens by naming a frontier model that can "identify, chain, and generate vulnerability exploits at machine speed". |
| April 2026 | The AMF publishes its Guideline for the Use of Artificial Intelligence. | Any use of AI by the institution, whether or not it involves client records, across five areas from governance to fair treatment of clients. |
| June 2026 | FSRA's credit union town hall. | No AI-specific guidance planned; AI governance "commensurate with the scope and impact of the AI use cases". |
| July 2026 | OSFI's technology risk bulletin on generative and agentic AI. | 33 measures in six areas that "institutions can consider". |
| 2026-10-07 | MAS issues its Guidelines on AI Risk Management for Financial Institutions. | All financial institutions and all forms of AI, with staged start dates below. |
| Deadline2027-05-01 | OSFI E-23 and the AMF AI guideline take effect. | The date most Canadian plans should count back from. |
| 2027-10-07 | MAS guidelines, first stage, apply. | Stage one of two in Singapore. |
| 2027-12-02 | EU AI Act: high-risk obligations for Annex III systems apply. | The date after the 2026 Digital Omnibus moved it. |
| 2028-08-02 | EU AI Act: the transition for Annex I products ends. | AI embedded in regulated products. |
| 2028-10-07 | MAS guidelines, second stage, apply. | Singapore's second stage. |
Dates come from the regulators' own pages. Some rows carry only a month because the source gives no day. The EU literacy and general-purpose AI dates are taken from a published implementation timeline rather than the regulation text.
When you do not need any of this
Plain code and classical models already have a home. A rules engine, a credit scoring model or a forecasting model goes through your existing model-risk process, and E-23 already covers all models. Adding a separate AI intake on top creates a second queue for the same thing. Route them where they already go.
A licensed office assistant with admin controls is a configuration review, not a project. The vendor contract sets where the data goes and whether it is retained; your admin settings set what the assistant can reach. Review the configuration, record the product and the data class, and let people use it. Reopen the review when the vendor changes its terms, or when someone builds something on top of it that takes actions.
Proportion is the point for smaller institutions. FSRA has said it is not considering AI-specific guidance for credit unions and expects governance in proportion to the scope and impact of the use cases. In my reading, five use cases recorded with care can be commensurate. A borrowed big-bank framework that nobody fills in is not.
Quick answers
Is OSFI's generative and agentic AI bulletin binding?+
It is written as sound practice. Each of its six areas opens with "institutions can consider the following risk control and mitigation measures", and it aligns those measures to Guidelines B-13, E-21 and B-10, with a pointer to E-23 for model risk. Treat it as the picture of good practice a supervisor will recognize. For the underlying expectations, read the guidelines it aligns to.
Does E-23 cover AI we buy from a vendor?+
Yes. E-23 applies to all models at federally regulated financial institutions, explicitly including AI and machine learning models and third-party models, with validation and monitoring commensurate to the model risk. It takes effect on 1 May 2027. Pension plans are excluded from its scope. The case most often missed is AI that a vendor added to a product you already license, and OSFI's July 2026 bulletin lists third-party notification of AI use among its sound practices.
What does FSRA expect of an Ontario credit union?+
Provincially regulated credit unions in Ontario answer to FSRA, not OSFI, so no OSFI date applies to them. FSRA's IT Risk Management guidance (effective 2024-04-01) covers data classification, third-party and cloud risk, change management, and notice of a material IT incident within 72 hours of determining it. Its Operational Risk and Resilience guidance says FSRA will assess data governance and bias controls where a credit union uses AI. At its June 2026 town hall FSRA said it is not considering AI-specific guidance and expects AI governance commensurate with the scope and impact of the use cases; its survey found about 60 percent of credit unions adopting or planning AI, 75 percent with AI policies, and 17 percent using tools such as Copilot. Reading OSFI's bulletin as a picture of commensurate practice is my inference, not FSRA's statement.
Do we need ISO/IEC 42001?+
Not to follow the Canadian expectations in this guide, and OSFI's bulletin does not reference it among its related links. ISO/IEC 42001 is the management-system standard: worth it if your customers or your board want an external standard for how you run AI governance. The practice it describes (owners, records, reviews) is what matters to a supervisor; adopting the standard is a separate business decision.
What is an AI inventory?+
A list of every AI use case the institution runs, one record each, with at least the owner, the purpose, the model and where it came from (built, bought, or embedded in a vendor product), the data it touches, its risk rating, and its approved uses and limitations. E-23 names the model-inventory fields, NIST calls it GOVERN 1.6, and NYDFS and MAS describe the same thing in their own words. A useful inventory is not a spreadsheet one person maintains; it is the set of intake records, kept current because every change goes through them.
Who should own the use-case intake?+
My view: one function with one front door, usually the team that already runs model risk or technology risk, because it owns the review paths and the examiner relationship. The business owner owns each record; security, privacy, cloud and model risk specialists add evidence; an approver signs. What fails is two processes, an inventory kept by one team and an intake run by another with a different form. Merge them and the inventory stays current on its own.
Part two is the intake record
This guide is part one. Part two walks through the intake record field by field, and what happened when I ran my own projects through it. Until then, send me one AI use case that is stuck, and I will tell you which questions decide its route. A message on LinkedIn is enough. No names or data needed: describe it the way you would to a peer at another bank.
Message me on LinkedInSources and lineage
This guide is grounded in the regulators' and standards bodies' own publications. Each was read for the specific points used here, and nothing is cited beyond them.
OSFI, "Generative and Agentic Artificial Intelligence: Implications for Technology, Cyber Security, and Operational Resilience" (Technology Risk Bulletin, July 2026): the 33 measures, the six areas and their counts, the "can consider" wording, and the related links.
OSFI, "Frontier Artificial Intelligence: Implications for Technology, Cyber Security, and Operational Resilience" (Technology Risk Bulletin, April 2026): the frontier-model quotation.
OSFI, Guideline E-23, Model Risk Management (Appendix 1: the inventory fields), its publication letter and its backgrounder: publication and effective dates, scope including AI and third-party models, and the pension plan exclusion.
Autorité des marchés financiers, Guideline for the Use of Artificial Intelligence: the effective date, the scope, and the five expectation areas.
Financial Services Regulatory Authority of Ontario, Information Technology Risk Management guidance (GR0016INT), the Operational Risk and Resilience guidance for credit unions, and the June 2026 credit union town hall: the 72-hour incident notice, the AI clause, the position on AI-specific guidance, and the survey figures.
Office of the Privacy Commissioner of Canada (priv.gc.ca), the privacy commissioners' principles for generative AI (2023-12-07): the nine principles.
NIST, AI Risk Management Framework 1.0 (NIST AI 100-1) and the Generative AI Profile (NIST AI 600-1): the functions, categories and GOVERN 1.6.
Federal Reserve, OCC and FDIC, SR 26-2, Revised Guidance on Model Risk Management (2026-04-17): the supersession of SR 11-7 and the generative and agentic AI scope exclusion.
New York State Department of Financial Services, Industry Letter "Cybersecurity Risks Arising from Artificial Intelligence" (2024-10-16): the inventory, third-party and monitoring expectations.
UK Financial Conduct Authority and Prudential Regulation Authority, the AI updates of 2024-04-22 and Supervisory Statement SS1/23 on model risk management: the technology-agnostic position and the five model risk principles.
European Commission, the AI Act regulatory framework page: the Annex III and Annex I dates after the 2026 Digital Omnibus. The literacy and general-purpose AI dates come from a published implementation timeline.
Monetary Authority of Singapore, the information paper on AI model risk management (December 2024) and the Guidelines on Artificial Intelligence Risk Management for Financial Institutions (issued 2026-10-07): the inventory attributes, risk materiality, third-party accountability and the staged dates.
OWASP GenAI Security Project, LLM10:2025 Unbounded Consumption and the Top 10 for Agentic Applications (December 2025): denial of wallet, loop amplification and usage ceilings.
Microsoft Learn, Create and manage budgets (Azure Cost Management): budget alerts do not stop consumption, and cost data arrives 8 to 24 hours after use.
FINOS, the AI Governance Framework repository: the version 2 date, the licence, the risk and mitigation catalogue, the maintainers and the references index.
By Daniel Zivkovic, founder of Magma Inc.