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

*Published 2026-06-24 · Dmitry Shirokov · shirokoff.ca/blog/ai-governance-frameworks · as of mid-2026*

A procurement questionnaire asked me to "describe compliance with applicable AI regulations." The honest answer — there is no single AI law in North America — loses the deal. What buyers actually want is evidence: which AI systems exist, what they can do to a person, who signed off, what happens when one misbehaves. **Frameworks give you the operating model, laws give you the deadlines, certification gives you the receipt.** One well-built program produces the evidence for all of them. (I'm an architect, not a lawyer — use this to know what to ask your counsel.)

## NIST AI RMF — the operating model

**AI RMF 1.0** (Jan 2023) is voluntary, sector-agnostic, and **not certifiable** — nobody is "NIST AI RMF certified." Four functions: **GOVERN** (policy, roles, risk tolerance — the one everyone skips), **MAP** (context + risk enumeration, i.e. impact assessment), **MEASURE** (metrics, evals, red-teaming), **MANAGE** (prioritization, incidents, retirement). For anything with an LLM in it you need **NIST AI 600-1, the Generative AI Profile** (July 2024) — confabulation, prompt data leakage, information integrity, capability uplift. A policy predating mid-2024 doesn't cover what you're shipping. The July 2025 *AI Action Plan* tasked NIST with revising the RMF; build against the four functions (stable), not subcategory numbering (in flux).

## ISO/IEC 42001 — the receipt

**42001:2023** is a certifiable AI management system (AIMS): PDCA, Annex A controls, internal audit, accredited external auditor. Two 2025 companions matter: **42005** (AI system impact assessment guidance — the most reusable artifact in the program) and **42006** (requirements for certification bodies, which is what made accredited certification real). Certify if you sell to enterprises — it pays for itself in shortened questionnaires. Internal platform team with no external buyers: mine Annex A as a checklist, skip the audit.

| Instrument | What | Binding? | Certifiable? |
|---|---|---|---|
| NIST AI RMF 1.0 + AI 600-1 | Voluntary framework, 4 functions | No | No |
| ISO/IEC 42001:2023 | AI management system | No | **Yes**, accredited |
| ISO/IEC 42005:2025 | Impact assessment guidance | No | Supports 42001 |
| EU AI Act | Product-safety regulation | **Yes** on EU market | Conformity assessment |
| OSFI E-23 (Canada) | Model risk supervision | **Yes** for FRFIs | Supervised |
| US state statutes | Consumer protection / transparency | **Yes**, per state | No |

## What binds you in the US (mid-2026)

No comprehensive federal statute. Since EO 14179 (Jan 2025, revoking EO 14110) the federal posture is deregulatory, formalized in *America's AI Action Plan* (July 23, 2025); OMB's 2025 memos flow down contractually to federal vendors. The binding layer is states + sectoral regulators + your contracts:

- **Texas TRAIGA** — effective Jan 1, 2026; intent-based, government-use disclosure, prohibited uses.
- **California SB 53** (Transparency in Frontier AI Act) — Jan 1, 2026; large frontier developers only (very high revenue + enormous training compute), published frontier framework + fast safety-incident reporting. Fine-tuning someone else's model almost certainly isn't in scope.
- **Colorado** — the cautionary tale: SB 24-205 pushed to June 30, 2026, then repealed and replaced (May 2026) by a narrower ADMT statute effective Jan 1, 2027. Programs shaped like one statute got built twice.
- **Employment/insurance regulators** (NYC AEDT bias audits, Illinois, state DOIs) never waited for AI law.

Federal preemption is a live push (Dec 2025 EO, March 2026 legislative framework) but **not enacted**.

## What binds you in Canada (mid-2026)

**AIDA is dead** — lapsed with Bill C-27 at prorogation, Jan 2025 — and the June 4, 2026 national strategy *AI for All* points to targeted privacy/online-safety bills, not an omnibus act. It's a strategy, not a rulebook. What has teeth:

- **Quebec Law 25 s.12.1** — the most under-appreciated obligation in the country: inform the individual of exclusively-automated decisions, disclose the personal information used and the reasons, and provide human re-examination plus the right to submit observations. The CAI also expects an algorithmic impact analysis pre-deployment.
- **OSFI Guideline E-23** — published Sept 11, 2025, effective **May 1, 2027**, deliberately extended to AI/ML models enterprise-wide: model inventory, tiering, independent validation, lifecycle controls, monitoring. Design decisions happen now.
- **TBS Directive on Automated Decision-Making** — binding on federal departments and flows down to their vendors. Its **Algorithmic Impact Assessment** scores impact levels I–IV with escalating peer review, notice, human intervention, explanation, recourse. Good enough that I reuse its tiering logic privately.
- **Ontario Bill 149** — from Jan 1, 2026, employers with 25+ staff must disclose AI screening in public job ads. Trivial to comply with, embarrassing to miss.
- **PIPEDA / provincial privacy / PHIPA** underneath everything. Most Canadian "AI incidents" are privacy incidents with a model attached.

Selling into the EU: GPAI obligations have applied since Aug 2, 2025; the Digital Omnibus (Parliament endorsed June 16, 2026) defers stand-alone high-risk to Dec 2, 2027 and embedded to Aug 2028. Extra runway, not a reprieve — prohibited practices apply today.

## The trap

Treating "no applicable law" as "no obligation." Two failure modes: **wait-and-see** (then a Fortune-500 buyer's 90-question AI questionnaire arrives with revenue on the clock — enterprise procurement is the de facto AI regulator in North America), and **over-fitting to one law** (Colorado). Build the program; let the mapping change.

## The program: five artifacts and one gate

1. **AI system register** — one file per system in **git**, reviewed in PRs: owner (a person), purpose, tier + rationale, autonomy level, affected persons, personal data, jurisdictions, pinned model version, links to impact assessment / eval suite / monitoring / incident runbook, review dates. NIST calls it inventory, 42001 calls it AIMS scope, E-23 calls it the model inventory. Build it once.
2. **Impact assessment** in **ISO/IEC 42005** shape, with fields that also satisfy Canada's AIA, an EU high-risk file, and US state duties — one document, different cover sheets. Per-jurisdiction formats produce inconsistent descriptions of the same system, and inconsistency is what auditors pull on.
3. **Evals as evidence** — the eval suite *is* the MEASURE function. "The assistant doesn't give financial advice" is unverifiable prose until a test set probes it and a score gates the deploy. Keep a named **policy evals** subset that can never be quietly disabled to unblock a release.
4. **Crosswalk** — one table mapping each control you run to every instrument that asks for it (register → GOVERN/MAP, AIMS scope, E-23 inventory; impact assessment → MAP, AIA, state duties; human review → Law 25 re-examination, AIA human intervention; incident runbook → nonconformity, breach reporting, SB 53). Turns a two-week questionnaire fire drill into an afternoon.
5. **Release gate in CI** — a job that validates the register entry, checks tier-appropriate evidence exists and isn't stale, runs policy evals at threshold, and uploads results as durable audit artifacts keyed by system + commit. Engineers respect a failing build; they route around a committee.

Tier **by consequence to a person**, before choosing controls — not by how sophisticated the technology is, which absurdly gives a meeting-notes summarizer more scrutiny than a rules engine denying loans.

## Best practices

Put the register in git, not a GRC tool engineers can't reach. Write vendor clauses early — training-data provenance, prompt/output handling, **model-version pinning** and deprecation notice (a silent provider-side upgrade is an unassessed change to a registered system), incident notification speed, evaluation access. Make human oversight real or don't claim it: 400 recommendations a shift at a 90% accept rate with no explanation is a rubber stamp with legal exposure. Start small — twelve honest register rows, a tiering rule, one assessment template, and a CI gate on your two riskiest systems is a functioning program; a 60-page policy with no register isn't.

## Carry-away

Frameworks = operating model, laws = deadlines, certification = receipt; build one program for all three because the artifacts overlap almost completely. NIST's four functions for vocabulary, AI 600-1 for LLM risks, 42001 + 42005 for the management system and the reusable assessment. US: states + sectoral regulators + contracts, and it moves. Canada: Law 25, OSFI E-23 (May 2027, design now), the TBS Directive and its AIA, Ontario's job-ad disclosure, privacy law underneath. Then the part that decides whether it works — register in git, tier by consequence, evals as evidence, enforced as a failing build.

*Related: [Regulated AI in finance](https://shirokoff.ca/blog/regulated-ai-finance) · [Regulated AI in healthcare](https://shirokoff.ca/blog/regulated-ai-healthcare) · [LLM evaluation frameworks](https://shirokoff.ca/blog/llm-evaluation-frameworks) · [Evaluating LLM and agent systems](https://shirokoff.ca/blog/evaluating-llm-agent-systems) · [AI-native readiness](https://shirokoff.ca/blog/ai-native-readiness) · [Authoring ADDs and ADRs](https://shirokoff.ca/blog/architecture-definition-documents)*