AI System Register: What Canadian Companies Should Record About Every Model

An AI system register lists every model you run, who owns it, what data it touches and when it was reviewed. What to record and how to start.

By Krikor Tengerian · Co-founder, SecuritAI Technologies Ltd. · September 2026

Your customer’s security questionnaire just asked you to list every AI system in use, and the honest answer is that nobody knows. Marketing has a writing assistant. Support turned on a chatbot inside the help desk tool. An engineer wired a model API into the product last spring, on a key tied to a personal account.

That is how most Canadian companies meet this document. It arrives as a line in a procurement form, not as a line in a policy, and it is not a sign you are behind. It is a sign you are selling to buyers who have started asking.

Here is the part people get wrong

People treat the register as a spreadsheet of tool names. It is a governance record. The list itself is the easy part. What matters is that every row has one person who answers for it and a date that proves someone looked. A list of product names with no owner fails the first follow up question, which is always some version of “who approved this?”

The second thing people get wrong is waiting for a law to tell them what to record. There is no AI specific federal law in force in Canada. What applies today is the privacy law you already have, and we cover that in our guide to AI governance in Canada. So nobody hands you a mandatory field list. You borrow one from the frameworks buyers already trust, and three of them are worth reading closely.

Where the field list comes from

NIST’s AI Risk Management Framework. The NIST AI RMF Playbook addresses this under GOVERN 1.6, which describes an AI system inventory as an organized database of artifacts relating to an AI system or model. Its suggested actions are practical. Define which attributes get recorded. Name a specific individual or team responsible for keeping the inventory. Define which systems are in scope, with a stated preference for inventorying all of them. If you have already started with the framework, our NIST AI RMF practical guide for Canada shows where GOVERN sits in the wider program.

OSFI Guideline E-23. For Canadian banks, insurers and other federally regulated financial institutions, OSFI’s Guideline E-23 on model risk management takes effect May 1, 2027. Its definition of a model explicitly includes AI and machine learning methods, and it expects an inventory of models kept at the enterprise level and updated in a timely manner when a model is modified or its use, risk rating or performance status changes. Appendix 1 lists what to track: a model ID, name and description, risk rating, owner, developer and origin for every model, and for models with more than negligible risk, the version, deployment date, reviewer, approver, dependencies, data sources, approved uses, limitations, most recent review date, monitoring status and next review date. You may never be regulated by OSFI. It is still the most detailed Canadian field list we have found, and it works well as a template outside banking.

The federal Algorithmic Impact Assessment. Federal departments assess automated decision systems with the Treasury Board’s Algorithmic Impact Assessment tool. The Directive on Automated Decision-Making requires completing, approving and publishing the final results of an algorithmic impact assessment in an accessible format on the Open Government Portal prior to the production of any automated decision system, and reviewing, approving and updating it on a scheduled basis, including when the functionality or scope of the system changes. That makes it a useful reference for what a documented system looks like when it faces the public, and for the risk questions worth asking before a system makes decisions about people.

What to record for every AI system

Put these columns in your register. Each one exists because someone will eventually ask for it.

ID and name. A stable identifier, so the row survives a product rename.

What it does and who uses it. One plain sentence. “Drafts replies to support tickets for the customer care team” is useful. “AI assistant” is not.

Origin. Built in house, bought as a product, or embedded as a feature inside a tool you already pay for. The third category is the one that gets missed.

Owner. One named person, not a team alias. This is the person who approves changes and answers the buyer.

Vendor and model version. Which provider, which model, which version. A model upgrade is a change to your system even when nobody on your side touched the code.

Data it touches. Whether personal information goes in, what kind, and where prompts and outputs are stored. For Canadian buyers, where that data is processed is often the question that decides the deal.

Approved uses and known limits. What it is allowed to do, and what it must not be used for. Writing down the limits is what stops a drafting tool quietly becoming a decision tool.

Risk rating. A simple scale is enough to start. Does it touch personal information? Does it make or shape decisions about people? Does a customer see its output directly? More yes answers means a higher rating and a shorter review cycle.

Testing before launch. Who tested it, when, and against what. For anything customer facing, that should include testing for prompt injection and data leakage, not only accuracy.

Guardrails and monitoring. What is in place to block misuse, and whether anyone is watching the output after launch.

Dependencies. Other systems it relies on, or that rely on it.

Last review and next review. Two dates. The first proves the row is alive. The second makes sure it stays that way.

The systems people forget

The register is only as good as the discovery behind it, and the gaps follow a pattern. Features a vendor switched on inside software you already use. Browser extensions staff installed themselves. Model API keys created on a personal card during a proof of concept that quietly became production. Transcription and meeting summary tools that record customer calls. Any of these can process personal information you are accountable for, whether or not anyone approved them.

Asking IT alone will not find them, because most were never routed through IT.

How to build the first version in two weeks

1. Ask every team lead, not only IT, one question in writing: which tools do you use that generate text, images, code, summaries or decisions?

2. Check expense reports and card statements for AI vendors. Paid tools leave a trail even when nobody mentions them.

3. Check your single sign on application list and your browser extension policy.

4. Search your code repositories for model API calls and keys. Engineering knows where to look.

5. Create one row per system and assign an owner before the row is considered finished.

6. Rate each row with the simple scale above, and schedule the review date from the rating.

7. Agree a rule with procurement: nothing with a model in it gets bought or switched on without a row.

The first version will be incomplete. That is fine. A register with a known gap and an owner chasing it is worth far more to a reviewer than no register at all.

Keeping it alive

A register decays the week after it is built unless something forces updates. Tie reviews to events as well as dates: a new model version, a new data source, a new use, a new customer segment, or an incident. OSFI’s guideline makes the same point for banks, expecting the inventory to be updated when a model changes or its use changes, and that discipline carries to any company.

This is where the register earns its place. When a buyer’s questionnaire asks which AI systems touch their data and who tested them, the answer comes out of a record with owners and dates, not out of a round of messages asking who set up the chatbot. The gap is almost never the policy. It is being able to produce the evidence on the day someone asks.

Being straight about our role

We are not an auditor and we do not certify anyone. What we do is test AI systems for the risks that belong in your risk rating and testing columns, the kind of testing a buyer expects to see recorded before launch. If you want to see where your AI program stands today, start with our AI security readiness check.

If the register also needs to sit alongside your ISO 27001 or SOC 2 evidence, SecuritComply’s AI Governance Readiness Checklist is on the SecuritComply resources page.

References

1. National Institute of Standards and Technology, AI RMF Playbook, GOVERN function (GOVERN 1.6)
2. Office of the Superintendent of Financial Institutions, Guideline E-23: Model Risk Management (2027)
3. Treasury Board of Canada Secretariat, Directive on Automated Decision-Making
4. Government of Canada, Algorithmic Impact Assessment tool
5. SecuritAI, AI governance in Canada
6. SecuritAI, NIST AI RMF practical guide for Canada

← Back to the blog