AI Governance: NIST AI RMF vs ISO 42001, US vs Canada

The question came in a procurement questionnaire, three weeks before a contract was supposed to close: "Describe your organization's compliance with applicable AI regulations." One line, one text box. The client's legal team wanted me to fill it in, because the system in question was one I'd architected. And the honest answer — that there is no single AI law in North America to be compliant with — is exactly the answer that loses you the deal.

So I wrote something better, and that exercise is what this article is about. Because the thing procurement actually wants isn't a citation to a statute. It wants evidence that somebody inside your company knows which AI systems exist, what they can do to a person, who signed off, and what happens when one misbehaves. That evidence is buildable. And the useful surprise is that one well-built program produces the evidence for all of the frameworks and most of the laws at once — if you design the program around evidence instead of around any single framework's table of contents.

Here's the mental model I keep coming back to, and everything below is a consequence of it: frameworks give you the operating model, laws give you the deadlines, certification gives you the receipt. Three different layers with three different jobs. Teams get stuck because they try to make one layer do all three — treating NIST AI RMF like a compliance checklist, or waiting for a law to tell them what a framework already tells them. Everything here is as of mid-2026, and I'll flag what's still moving.

The three layers, and why conflating them wastes a year

A framework is a voluntary operating model for managing AI risk; a law is a binding obligation with a jurisdiction and a date; a certification is a third party attesting that your management system exists and works. They compose, and none of them substitutes for another.

graph TD
  subgraph L1["Layer 1 — Frameworks (voluntary)"]
    NIST["NIST AI RMF 1.0
+ Generative AI Profile"]
    ISO23894["ISO/IEC 23894
AI risk guidance"]
  end
  subgraph L2["Layer 2 — Management system (certifiable)"]
    ISO42001["ISO/IEC 42001 AIMS
+ 42005 impact assessment"]
  end
  subgraph L3["Layer 3 — Law + supervision (binding)"]
    US["US: state statutes
+ sectoral regulators"]
    CA["Canada: privacy law
+ OSFI E-23 + TBS Directive"]
    EU["EU AI Act
if you sell into the EU"]
  end
  NIST -->|"shapes"| PROG["Your one AI governance program
register · tiering · gates · evidence"]
  ISO23894 -->|"shapes"| PROG
  PROG -->|"audited as"| ISO42001
  PROG -->|"produces evidence for"| US
  PROG -->|"produces evidence for"| CA
  PROG -->|"produces evidence for"| EU

What NIST AI RMF actually gives you

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023) is a voluntary, non-certifiable framework that organizes AI risk work into four functions: GOVERN, MAP, MEASURE, and MANAGE. It's American in origin, sector-agnostic, and free. There is no such thing as being "NIST AI RMF certified" — anyone who tells you otherwise is selling something.

What makes it worth using anyway is the shape of those four functions, which happens to be the right shape:

• GOVERN — the cross-cutting one. Policies, accountable roles, risk tolerance, workforce competency. This is the function everyone skips and then rebuilds under pressure.
• MAP — establish context and enumerate risks for a specific system. Who is affected, what's the intended use, what happens when it's wrong. This is where an impact assessment lives.
• MEASURE — analyze and track. Metrics, evaluations, red-teaming, monitoring. For LLM systems this is your eval harness, which is why I treat eval tooling as governance infrastructure and not just an engineering nicety.
• MANAGE — allocate resources to the risks that matter, respond to incidents, decide what gets deprecated.

The companion document you actually need for anything with an LLM in it is NIST AI 600-1, the Generative AI Profile (July 2024), which enumerates the risks that are specific to generative systems — confabulation, data leakage through prompts, harmful outputs, information integrity, dangerous capability uplift — and maps concrete actions against each of the four functions. If your governance policy predates mid-2024 and doesn't reference it, your policy doesn't cover the systems you're currently shipping.

One thing to track: the July 2025 America's AI Action Plan tasked NIST with revising the AI RMF, explicitly to remove references to misinformation, DEI, and climate change. A revision hasn't landed as a "2.0" as of this writing, and the surrounding work — profiles, the Cyber AI Profile, control overlays for AI mapped onto SP 800-53 — is what's actually shipping. So build against the four functions, which are stable, and don't hard-wire your policy language to specific subcategory numbering that's in flux.

What ISO/IEC 42001 gives you that NIST can't

ISO/IEC 42001:2023 is a certifiable management system standard for AI — an AIMS, structurally the same idea as ISO 27001 for information security: a Plan-Do-Check-Act management system, a set of Annex A controls, mandatory internal audit and management review, and an accredited external auditor who can issue a certificate. That last part is the whole point. It's the only widely recognized way to hand someone a piece of paper instead of a slide deck.

Two companion standards matter more than people realize, and both landed in 2025:

• ISO/IEC 42005 — guidance for AI system impact assessment. This is the one I lean on hardest in practice, because it gives you a defensible structure for the single most reusable artifact in the whole program (more on that below).
• ISO/IEC 42006 — requirements for the bodies that audit and certify AIMS. Unglamorous, and the reason accredited 42001 certification became real rather than theoretical: it's what certification bodies get accredited against.

My honest read on whether to certify: if you sell software or services to enterprises, especially into financial services, healthcare, or the public sector, 42001 certification pays for itself in shortened security questionnaires and procurement cycles. If you're an internal platform team with no external buyers, use 42001's Annex A as a control checklist and skip the audit — you'll get most of the discipline without the cost.

What actually binds you in the United States, mid-2026

There is no comprehensive federal AI statute. The binding obligations come from states, from sectoral regulators, and from your own contracts. The federal posture since Executive Order 14179 in January 2025 — which revoked the prior administration's EO 14110 — has been deregulatory and innovation-first, formalized in America's AI Action Plan (July 23, 2025). For federal agencies and the vendors who sell to them, OMB's 2025 memoranda on federal AI use and federal AI procurement are the operative documents, and they flow down to you contractually whether or not any law applies to your company directly.

The state layer is where the real compliance work is, and it has been genuinely volatile:

• Texas — TRAIGA (Responsible AI Governance Act), effective January 1, 2026. Intent-based rather than impact-based, with disclosure requirements around government AI use and prohibitions on specific harmful uses.
• California — SB 53, the Transparency in Frontier Artificial Intelligence Act, main provisions effective January 1, 2026. It targets large frontier developers — very large revenue plus enormous training compute — requiring a published frontier AI framework and safety-incident reporting on a tight clock. If you're fine-tuning someone else's model, you are almost certainly not in scope; read it before you assume you are.
• Colorado — the cautionary tale. SB 24-205, the algorithmic-discrimination law that everyone built compliance plans against, had its effective date pushed to June 30, 2026, and was then repealed and replaced in May 2026 by a narrower automated-decision-technology statute taking effect January 1, 2027. Teams that built a Colorado-shaped compliance program rather than a program-shaped one did the work twice.
• Employment and insurance regulators — NYC's automated employment decision tool bias-audit rule, Illinois, and several state insurance departments have been enforcing AI-adjacent rules for years under existing authority. Sector regulators didn't wait for AI law and don't need it.

Federal preemption of state AI law is a live political push — a December 2025 executive order singled out state regulation, and a legislative framework followed in March 2026 — but as of this writing preemption is not enacted. Planning on it is planning on a bill that hasn't passed.

What actually binds you in Canada, mid-2026

AIDA is dead, and Canada is not getting an omnibus AI act. What binds you today is privacy law, sector supervision, and employment rules — all of which already reach AI systems. The Artificial Intelligence and Data Act lapsed with Bill C-27 when Parliament was prorogued in January 2025. On June 4, 2026 the federal government released a refreshed national strategy, AI for All, which points at targeted, incremental legislation — privacy modernization and online safety bills — rather than reviving the AIDA model. It's a strategy, not a rulebook. Anyone waiting for the Canadian EU-AI-Act-equivalent to start governing should stop waiting.

Meanwhile, here's what has teeth right now:

• Quebec's Law 25 — the most under-appreciated AI obligation in the country. Section 12.1 covers decisions based exclusively on automated processing: you must inform the individual, disclose the personal information used and the reasons for the decision, and give them the right to have a human re-examine it and to submit observations. The Commission d'accès à l'information's guidance also pushes an algorithmic impact analysis before deployment. If your product makes automated decisions about Quebec residents, this is your binding baseline.
• OSFI Guideline E-23, Model Risk Management — published September 11, 2025, effective May 1, 2027, and it deliberately extends beyond traditional credit and capital models to cover AI/ML models across the enterprise. If you build models for a federally regulated financial institution, the E-23 shape — model inventory, risk tiering, independent validation, lifecycle controls, ongoing monitoring — is the shape your governance has to take. Two-plus years of runway means the design decisions are happening now. I've written about how this plays out in delivery in regulated AI in finance.
• Treasury Board's Directive on Automated Decision-Making — binding on federal departments, and by flow-down on anyone selling automated decision systems into the Government of Canada. The core artifact is the Algorithmic Impact Assessment, which scores a system into impact levels I–IV, with escalating requirements for peer review, notice, human intervention, explanation, and recourse. It's genuinely well designed, and I use its tiering logic even for private-sector clients.
• Ontario's Bill 149 (Working for Workers Four Act) — effective January 1, 2026, employers with 25+ employees must disclose in publicly posted job ads whether AI is used to screen, assess, or select applicants. Small obligation, trivially auditable, embarrassing to miss.
• PIPEDA and provincial privacy law, plus health privacy statutes like Ontario's PHIPA, still govern the data your models train on and infer from. Most "AI incidents" I've seen in Canada were privacy incidents with a model attached — the theme of regulated AI in healthcare.

And if you sell into the EU, the EU AI Act is the strictest instrument you're subject to, so it tends to set your ceiling. Worth knowing that the timeline moved: the general-purpose-AI obligations have applied since August 2, 2025, but the Digital Omnibus simplification package pushed the high-risk obligations out — Parliament endorsed it on June 16, 2026 with the Council's final sign-off imminent, deferring stand-alone high-risk systems to December 2, 2027 and embedded ones to August 2028. Extra runway, not a reprieve; the prohibited-practices list still applies today.

How to actually build the program

Five artifacts and one gate. That's the whole program. Everything else — the policy PDF, the committee, the training deck — is scaffolding around these, and if you build the scaffolding first you get a governance theatre production with no evidence in it.

graph TD
  IDEA["New AI use case
or model change"] --> INTAKE["1. Intake
register entry created"]
  INTAKE --> TIER{"2. Tier by impact
on people + business"}
  TIER -->|"Tier 3 — low
internal, no personal data"| LIGHT["Lightweight controls
owner + eval + monitoring"]
  TIER -->|"Tier 2 — moderate"| STD["Standard controls
impact assessment + eval suite
+ human review path"]
  TIER -->|"Tier 1 — high
affects rights, money, health"| HEAVY["Full controls
independent validation
+ recourse + sign-off"]
  LIGHT --> GATE{"3. Release gate
evidence complete?"}
  STD --> GATE
  HEAVY --> GATE
  GATE -->|"no"| BACK["Back to the team
with the missing evidence named"]
  GATE -->|"yes"| PROD["4. Production
monitoring + drift + incident hooks"]
  PROD --> REVIEW["5. Periodic review
re-tier on material change"]
  REVIEW --> TIER

Artifact 1: the AI system register

One row per AI system, and the first honest count is always higher than leadership expects — somebody's team is running a customer-facing summarizer nobody logged. The register is also the artifact almost every instrument demands under a different name: NIST calls it inventory under MAP, 42001 wants it as part of the AIMS scope, OSFI E-23 calls it the model inventory, and a state statute will ask you to enumerate consequential-decision systems. Build it once.

# ai-register/claims-triage-assistant.yaml
# One file per AI system, in git, reviewed like code. This is the row that
# every framework, auditor, and questionnaire ends up asking for.
id: AI-0041
name: Claims triage assistant
owner: dana.okonkwo@example.com          # a person, not a team alias
business_sponsor: VP Claims
status: production
first_deployed: 2026-03-02
purpose: >
  Ranks inbound claims by likely complexity to route them to the right
  adjuster queue. Advisory only — never auto-approves or auto-denies.
tier: 2                                   # see tiering rules; drives controls
tier_rationale: >
  Affects service speed and adjuster workload, not entitlement decisions.
  No automated decision within the meaning of Quebec Law 25 s.12.1 because
  a human adjuster makes every claim determination.
autonomy: advisory                        # advisory | human-in-the-loop | autonomous
affected_persons: [policyholders]
personal_data: [claim_text, policy_id]    # no health data; PII minimized at ingest
jurisdictions: [CA-ON, CA-QC, US-TX]
model:
  provider: azure-openai
  family: gpt-4o
  version_pinned: "2026-02"
  fine_tuned: false
controls:
  impact_assessment: docs/aia/AI-0041-v2.md      # ISO/IEC 42005 shape
  eval_suite: evals/claims_triage/               # gates the deploy, see CI
  human_review: "adjuster reviews 100% of routed claims"
  monitoring: dashboards/ai-0041                  # drift + refusal + latency
  incident_runbook: runbooks/ai-0041-incident.md
last_review: 2026-06-01
next_review: 2026-12-01                    # re-tier on material change, too

Artifact 2: the impact assessment you write once and reuse

This is the highest-leverage decision in the whole program. Write your impact assessment template to the ISO/IEC 42005 structure, and make sure it captures the fields that Canada's Algorithmic Impact Assessment, an EU AI Act high-risk conformity file, and a US state impact-assessment requirement each want. Then one document per system satisfies all of them with a different cover sheet. Teams that let each jurisdiction generate its own assessment format end up with three inconsistent descriptions of the same system, which is worse than having one imperfect description — inconsistency is what auditors pull on.

Artifact 3: evals as the evidence, not as a nicety

Here's the part engineering teams like, because it's the part where governance stops being paperwork: your evaluation suite is the MEASURE function. A governance claim like "the assistant does not give financial advice" is unverifiable prose until there's a test set that probes for it and a score that gates the deploy. Run the suite in CI, store the results as artifacts, and your release gate becomes a check on a number instead of a meeting. I go deep on the harness in evaluating LLM and agent systems and on choosing the tooling in the eval framework comparison. For governance specifically, keep a named subset of the suite as your policy evals — the cases that exist because a policy commitment exists — and never let them be quietly disabled to unblock a release.

Artifact 4: the crosswalk

One table, maintained by whoever owns governance, mapping each control you actually run to every instrument that asks for it. This is the document that turns a 90-question buyer questionnaire from a two-week fire drill into an afternoon. It's also how you notice you're running two controls that do the same job.

Artifact 5: the gate, in CI

The gate is where a governance program either becomes real or becomes a wiki page. Make it a job that reads the register entry, checks that the required evidence for that tier exists and is current, and fails the pipeline when it isn't. Engineers respect a failing build; they route around a committee.

# .github/workflows/ai-release-gate.yml — governance as a failing build
name: AI release gate
on:
  pull_request:
    paths: ["services/claims-triage/**", "ai-register/**"]
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. The register entry must exist, parse, and name a human owner.
      - name: Validate register entry
        run: python tools/ai_gate.py validate --id AI-0041

      # 2. Tier-appropriate evidence must be present and not stale.
      #    Tier 1 also requires an independent-validation sign-off record.
      - name: Check required evidence
        run: python tools/ai_gate.py evidence --id AI-0041 --max-age-days 180

      # 3. Policy evals must pass at threshold. These are the eval cases that
      #    exist because a governance commitment exists — no quiet disabling.
      - name: Policy evals
        run: |
          pytest evals/claims_triage/policy \
            --junitxml=evidence/AI-0041-policy-evals.xml

      # 4. Store the results as durable audit evidence, keyed by system + commit.
      - name: Upload evidence
        uses: actions/upload-artifact@v4
        with:
          name: AI-0041-evidence-${{ github.sha }}
          path: evidence/

Best practices I'd argue for

Tier honestly, and tier on consequence to a person. The temptation is to tier on how sophisticated the technology is, which produces the absurd result that a fine-tuned model summarizing internal meeting notes gets more scrutiny than a simple rules engine deciding who gets a loan. Consequence to the affected person is the axis that both regulators and reasonable people care about.

Put the register in git. Not in a GRC tool the engineers can't reach, and not in a spreadsheet that gets emailed. In the repo, reviewed in pull requests, next to the code. You get version history, diffs, and the ability to fail a build — which is the only enforcement mechanism that has ever survived contact with a delivery deadline. This is the same argument I make about architecture artifacts generally in authoring ADDs, ADRs, and runbooks: an artifact that lives away from the work rots.

Write the vendor clauses before you need them. Most of your AI risk is in models and tools you didn't build. The questions that matter in a vendor assessment: what are the training-data provenance representations, what happens to your prompts and outputs, is there a model-version pinning commitment and a deprecation notice period, who tells you about a safety incident and how fast, and can you get evaluation access to test the thing yourself. Unpinned model versions are an under-rated governance failure — a silent provider-side upgrade is a change to a system in your register that nobody assessed.

Make human oversight real or don't claim it. "A human reviews the output" is the single most common control in every AI register I've read, and the most commonly fictional. If the human sees 400 recommendations a shift with a 90%+ accept rate and no ability to see why the model said what it said, that's not oversight; that's a rubber stamp with legal exposure. Either give the reviewer time, context, and a genuine ability to override — the design work in human-in-the-loop approval — or reclassify the system as autonomous and control it accordingly.

Start the program before you need it, and start small. A register with twelve honest rows, a tiering rule, one impact-assessment template, and a CI gate on your two riskiest systems is a functioning governance program. You can build that in a quarter. A 60-page policy with no register is not a governance program regardless of how many committees approved it. If you're earlier than that and wondering whether your organization is even ready to operate AI systems, that's the AI-native readiness assessment.

What to carry away

Frameworks give you the operating model, laws give you the deadlines, certification gives you the receipt — build for all three at once with one program, because the artifacts overlap almost completely. Use NIST AI RMF's four functions as your vocabulary and its Generative AI Profile as your risk catalogue for anything with an LLM in it. Use ISO/IEC 42001 as the management system, with 42005 shaping the impact assessment you write once and reuse everywhere; certify if you sell to enterprises, otherwise mine Annex A and skip the audit.

On jurisdiction: in the US, the binding layer is states plus sectoral regulators plus your contracts, and it moves — Colorado repealed and replaced its own law before it took effect, so never build a program shaped like one statute. In Canada, AIDA is gone and isn't coming back in that form; what binds you is Quebec's Law 25 on automated decisions, OSFI E-23 if you're in financial services (effective May 2027, designed now), the Treasury Board Directive and its Algorithmic Impact Assessment if you sell to the federal government, Ontario's job-ad disclosure, and privacy law underneath all of it.

And the part that actually determines whether any of this works: put the register in git, tier by consequence to a person, make your eval suite the evidence, and enforce it as a failing build. The organizations that handle their next AI questionnaire — or their next incident — calmly are the ones that can answer "which systems, who owns them, what did you test, what happened when it was wrong" in an afternoon. That capability is what you're building. The certificate is just the receipt for it.