The NIST AI Risk Management Framework: A Canadian Company's Field Guide

The NIST AI Risk Management Framework is a voluntary structure for identifying and managing risk in AI systems, organised around four functions: Govern, Map, Measure, and Manage. There is no certification, no auditor, and no legal obligation attached to it anywhere in Canada. It matters anyway, for one reason: it has become the shared vocabulary that large buyers and their security teams use when they ask how you handle AI risk.

If a customer questionnaire asks whether you have "mapped the context of your AI systems", that phrasing came from here.

What are the four functions asking for?

Govern is the layer that makes the other three real. It asks who is accountable, what policies exist, how risk decisions get made, and how that gets reviewed. This is the function organizations skip, because it produces no visible artefact about any particular system. It is also the one that determines whether the rest survives a staff change.

Map asks you to establish context before assessing anything. What is the system for, who does it affect, what assumptions is it built on, what are the known limits, and what happens downstream of its output. Mapping is where most of the useful thinking happens, and it is impossible without an AI system inventory.

Measure asks how you will know whether the system is behaving. Accuracy on what data, tested how often, with what thresholds, and what monitoring exists once it is live. This function exposes uncomfortable truths quickly, because most deployed AI systems in small companies are not measured at all after go-live.

Manage asks what you do about what you found. Prioritise, treat, accept with rationale, or retire. It also covers incident response for AI-specific failures, which look different from security incidents.

How does this differ from ISO 42001?

They answer different questions, and running both is less work than it sounds.

The practical relationship: NIST gives you the analysis, ISO gives you the evidence that the analysis happens consistently. Teams that adopt the RMF first usually find ISO 42001 easier later, because Map and Measure produce most of what an impact assessment needs.

Is it relevant if you never sell to the United States?

More than you would expect, for three reasons.

Enterprise procurement is converging on it. Canadian banks, insurers, and health networks buying software increasingly borrow their AI questions from American vendor questionnaires, because that is where the templates come from. Answering in the framework's own language shortens those conversations.

It is also the most complete free thinking available on the subject. Whatever you believe about its origins, the profile documents are the clearest public writing on how to reason about AI failure modes, and there is no Canadian equivalent of comparable depth.

Finally, it maps cleanly onto obligations you do have. Mapping context is the same work as scoping a privacy impact assessment. Measuring is what lets you claim meaningful human oversight. Managing is what your incident process needs anyway.

What does adopting it actually look like for a 40-person company?

Considerably lighter than the document length suggests. A realistic first pass:

1. Govern. Name one accountable owner for AI risk, write a one-page policy, and put AI risk on an existing management meeting agenda quarterly. That is the entire function at this size.
2. Map. Take your system inventory and add four fields per system: purpose, affected people, known limitations, and what happens if the output is wrong. An afternoon per ten systems.
3. Measure. For each system that influences a decision about a person, define one quality signal and one failure signal, and decide who looks at them and how often. Systems that only draft text can be measured informally.
4. Manage. Route anything material into the incident log you already use, with an AI category, and record acceptances with a rationale.

That is a few weeks of part-time work, not a programme. The failure mode is treating it as a documentation exercise and producing a beautiful map of systems nobody measures afterwards.

Where teams get it wrong

Two mistakes recur. The first is starting with Measure because it feels concrete, then discovering there is no agreement on what the system is even supposed to do. Map comes first for a reason.

The second is mapping only the AI systems you built. Most Canadian companies do not build models; they buy tools with models inside. Those are in scope, and the mapping questions are harder for them, because the answers live with a vendor. Ask your vendors the Map questions directly and record what they will not answer, since a refusal is itself a risk finding worth writing down.

For where this fits in the wider regulatory picture, AIDA and the AI law Canadian business owners ignore covers what is actually coming domestically.

This is general information, not legal advice.

Valdra structures AI risk work along the same lines, so the mapping you do for a buyer questionnaire is the same record that feeds your assessments and your AI governance reporting.