AI Governance Frameworks: NIST, ISO/IEC 42001, OECD and Building a Program

Laws tell an organization what outcomes it must achieve with AI; governance frameworks tell it how to run the machinery that achieves them. If you build or buy AI in a company of any size, you will be asked questions like "Which of our systems are high-risk?", "Who approved this model?", and "Show me the evidence." This lesson teaches the frameworks professionals use to answer them and how to turn those frameworks into a working program.

The intuition: a safety management system, not a checklist

Think of commercial aviation. No single rule makes flying safe. Airlines run a safety management system: every aircraft is registered, every component has a maintenance record, risky changes need sign-off, incidents are reported and analyzed, and independent auditors check that all of this actually happens. Regulations set minimums; the management system is how the airline meets them every day.

AI governance works the same way. A framework is a reusable design for that management system. The inventory is the aircraft register, risk tiering decides which systems get the heavy maintenance regime, impact assessments and model cards are the maintenance records, approval gates are sign-offs, monitoring and incident response close the loop, and audits check that the whole thing is real rather than paperwork.

A useful mental split:

The frameworks

OECD AI Principles (2019, updated 2024)

The OECD Recommendation on Artificial Intelligence was adopted in May 2019 and was the first intergovernmental standard on AI; the G20 drew on it the same year. It has five values-based principles (inclusive growth and well-being; human rights and democratic values including fairness and privacy; transparency and explainability; robustness, security and safety; accountability) and five recommendations to governments (invest in R&D, foster an inclusive ecosystem, enable an interoperable governance environment, build human capacity, cooperate internationally). The OECD revised the text at its Ministerial Council Meeting in May 2024 to address general-purpose and generative AI more directly, including privacy, intellectual property, safety and information integrity. The principles also supply the definition of an "AI system" that the EU AI Act's definition was aligned with. They are not operational on their own, but they are the shared vocabulary that the other frameworks inherit.

NIST AI Risk Management Framework 1.0

NIST released the AI RMF 1.0 (NIST AI 100-1) on 26 January 2023. It is voluntary, sector-agnostic and use-case-agnostic. Two ideas anchor it.

First, trustworthiness characteristics: valid and reliable (the base on which the others rest); safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. These trade off against each other (for example, more interpretability may cost accuracy, and privacy techniques may hurt fairness measurement for small groups), and the framework asks you to make those trade-offs explicitly.

Second, four functions:

• Govern (cross-cutting): policies, roles, accountability, culture, workforce diversity, third-party risk. It has six categories (GOVERN 1 to 6).
• Map: establish context. What is the system for, who is affected, what are the assumptions and limits, which risks and benefits exist? Five categories.
• Measure: analyze, assess, benchmark and monitor the risks you mapped, with quantitative and qualitative methods, including tracking risks that are hard to measure. Four categories.
• Manage: prioritize and treat risks (mitigate, transfer, avoid, accept), plan responses and recovery, and monitor third-party components. Four categories.

Each category breaks into subcategories (for example MAP 1.1 on intended purpose and context of use), and a companion Playbook suggests actions for each. NIST deliberately does not prescribe a sequence; in practice Govern is set up once and Map-Measure-Manage repeat across the lifecycle. As of November 2026, NIST's AI RMF page states that the framework is being revised as part of the White House AI Action Plan; check the page for the current version before citing subcategory numbers in contracts or policy.

NIST AI 600-1: the Generative AI Profile

A profile applies the RMF to a specific setting. NIST AI 600-1, released 26 July 2024, covers generative AI. It names twelve risks that generative AI creates or makes worse: CBRN information or capabilities; confabulation; dangerous, violent or hateful content; data privacy; environmental impacts; harmful bias and homogenization; human-AI configuration (over-reliance, anthropomorphism); information integrity; information security; intellectual property; obscene, degrading or abusive content; and value chain and component integration. For each, it lists suggested actions keyed to RMF subcategories, such as pre-deployment red-teaming, content provenance, and incident disclosure. If your organization ships LLM features, this profile is the most directly usable NIST document. NIST also published, in April 2026, a concept note for a profile on trustworthy AI in critical infrastructure (not a finished profile as of November 2026).

ISO/IEC 42001:2023 — the AI management system standard

Published in December 2023, ISO/IEC 42001 specifies requirements for an AI management system (AIMS). It uses the same high-level structure as ISO/IEC 27001 (information security) and ISO 9001 (quality): context of the organization, leadership, planning, support, operation, performance evaluation and improvement, following a Plan-Do-Check-Act cycle. Its annexes provide reference control objectives and controls (covering AI policy, internal organization, resources, impact assessment, the AI system lifecycle, data, information for interested parties, use of AI systems and third-party relationships) plus implementation guidance.

The crucial difference from NIST: 42001 is certifiable. An accredited certification body can audit you against it, which is why procurement teams increasingly ask for it. Certification shows that you run a disciplined process, not that any particular model is safe or fair. Organizations that already hold ISO/IEC 27001 can extend their existing ISMS processes (document control, internal audit, management review) rather than building from scratch.

ISO/IEC 23894:2023 and ISO/IEC 42005:2025

ISO/IEC 23894 (February 2023) is guidance, not certifiable. It adapts the generic risk-management process of ISO 31000 (establish context; identify, analyze and evaluate risk; treat; monitor and review; communicate) to AI, with an annex mapping risk management onto the AI lifecycle. Use it as the method inside the 42001 "risk assessment" and "risk treatment" requirements.

ISO/IEC 42005, published in 2025, gives guidance on AI system impact assessment: assessing effects on individuals, groups and society, including foreseeable misuse, and defining when assessments happen, who owns them, thresholds, documentation and review. It is designed to sit alongside 42001 and 23894.

Mapping frameworks to EU AI Act obligations

The EU AI Act is law; the frameworks above are voluntary tools that help you comply. As covered in AI Law and Regulation, as of November 2026 the Digital Omnibus on AI (in force 27 July 2026) moved the application date for stand-alone high-risk uses (Annex III) to 2 December 2027 and for AI in regulated products (Annex I) to 2 August 2028. That leaves a window to build the program now. The table maps the main provider obligations for high-risk systems to framework activities.

The NIST and ISO columns are an indicative crosswalk to show the idea, not an official mapping; NIST's AI RMF resources include published crosswalks you should check before relying on specific subcategory references.

Deployers of high-risk systems have their own duties (Art. 26: use per instructions, assign competent human oversight, monitor, keep logs, inform affected workers), and certain deployers (public bodies and some private services such as credit scoring and life/health insurance pricing) must do a fundamental rights impact assessment (Art. 27). An ISO/IEC 42005-style impact assessment is a natural vehicle for it, and it should be coordinated with any GDPR data protection impact assessment (DPIA).

One caution: holding ISO/IEC 42001 certification does not by itself create a legal presumption of conformity with the AI Act. That presumption comes from harmonised standards cited in the EU's Official Journal, which European standards bodies (CEN-CENELEC JTC 21) have been developing. Check which have been cited before relying on any standard for conformity.

Building an AI governance program

1. Mandate and roles

Get a board- or executive-level policy that defines scope (what counts as "AI": include vendor features and employee use of public chatbots), risk appetite, and accountability. Typical roles: an accountable executive; an AI governance committee (legal, privacy, security, risk, engineering, product, HR); system owners (one named owner per system); and independent review (internal audit as the "third line"). Write a RACI so nobody has to guess who approves what.

2. Inventory

You cannot govern what you cannot see. For each system record: ID, name, owner, business purpose, lifecycle stage, build/buy/API, models and versions, vendors, data categories (personal? special category? children?), affected people, decision role (informational, decision support, automated decision), deployment geography, user count, legal classification (for example "EU AI Act Annex III, point 4: employment"), risk tier, and links to assessments and approvals. Discover systems through procurement records, cloud and API billing (look for model-provider API keys), code search, and a short self-declaration survey.

3. Risk tiering

Tiering keeps effort proportional. A transparent, scored rubric beats intuition because it can be audited and challenged. One workable design:

• Severity of potential harm $S \in \{1,\dots,5\}$ (1 = trivial inconvenience; 5 = threat to life, liberty, livelihood or fundamental rights).
• Autonomy $A \in \{1,2,3\}$ (1 = human reviews every output; 3 = fully automated action).
• Scale $N \in \{1,2,3\}$ (1 = fewer than 100 people affected; 3 = more than 10,000).
• Data sensitivity $D \in \{1,2,3\}$ (1 = no personal data; 3 = special-category or children's data).

Score $R = S \times (A + N + D)$, with range 3 to 45. Tiers: Low if $R < 15$, Medium if $15 \le R < 30$, High if $R \ge 30$. Then apply overrides: anything that is legally prohibited is rejected; anything legally classified high-risk (for example an EU Annex III use) is High regardless of score.

4. Worked example: tiering three systems

(a) Internal coding assistant used by 400 engineers, outputs reviewed in code review, no personal data. $S = 2$ (bugs reach review), $A = 1$, $N = 2$, $D = 1$. $R = 2 \times (1+2+1) = 8$. Low. Controls: acceptable-use policy, vendor security review, secrets scanning.

(b) Résumé-screening model that ranks 20,000 applicants a year; recruiters only see the top 10%. $S = 4$ (access to employment), $A = 2$ (the bottom 90% is effectively decided by the model), $N = 3$, $D = 2$. $R = 4 \times (2+3+2) = 28$, which is Medium by score. But employment screening is an EU AI Act Annex III use, so the override makes it High. This is exactly why overrides exist: scoring alone under-weights legal classification. Controls: impact assessment, bias testing across protected groups (see Bias and Fairness), human review of rejections, applicant notice, logging, committee approval, quarterly monitoring.

(c) Customer-support chatbot with retrieval over policy documents, answering 50,000 customers a month, able to issue refunds up to 50 units of currency automatically. $S = 3$, $A = 3$, $N = 3$, $D = 2$. $R = 3 \times (3+3+2) = 24$, Medium. Controls: transparency notice that users are talking to AI (an EU AI Act Art. 50 duty), prompt-injection testing (see AI Security Risks), refund caps and anomaly alerts, conversation sampling.

5. Impact assessments and documentation

Match the artifact to the question:

• AI impact assessment (ISO/IEC 42005 style; covers the EU FRIA where required): who is affected, how, severity, likelihood, mitigations, residual risk, who accepted it.
• DPIA under GDPR Art. 35 when processing is likely to result in high risk to individuals (see Privacy-Preserving AI).
• Model card (Mitchell et al., 2019): intended use, out-of-scope uses, training data summary, evaluation results disaggregated by relevant groups, limitations, ethical considerations.
• Datasheet for datasets (Gebru et al., 2018): motivation, composition, collection, preprocessing, uses, distribution, maintenance.
• System card: the deployed system as a whole (model plus prompts, tools, retrieval, guardrails, human process), since most real risk lives in the system, not the bare model.

6. Approval gates

Use stage gates proportional to tier: Intake (register in inventory, initial tier), Design review (impact assessment draft, data approval), Pre-deployment (evaluation and red-team results meet pre-agreed thresholds; sign-off by owner for Low, by risk and privacy for Medium, by committee for High), and Post-deployment review (30 to 90 days after launch). Every approval records who, when, which version, and which evidence. A material change (new model version, new population, new purpose, new data source) re-opens the gate.

7. Monitoring, incidents and audits

Define metrics and thresholds before launch: performance, drift, fairness gaps, complaint and override rates, safety-filter hits. Run an incident process (severity levels, response times, regulator notification where law requires it). Audit at three levels: the system owner self-attests, risk and compliance reviews samples, and internal audit (or an external certification body for ISO/IEC 42001) tests whether controls operated.

A minimal tiering tool in Python

from dataclasses import dataclass, field

@dataclass
class AISystem:
    name: str
    severity: int        # 1..5
    autonomy: int        # 1..3
    scale: int           # 1..3
    data_sensitivity: int  # 1..3
    legal_flags: set = field(default_factory=set)  # e.g. {"EU_ANNEX_III"}

def tier(s: AISystem) -> tuple[int, str]:
    for v, lo, hi in [(s.severity, 1, 5), (s.autonomy, 1, 3),
                      (s.scale, 1, 3), (s.data_sensitivity, 1, 3)]:
        if not lo <= v <= hi:
            raise ValueError(f"{s.name}: value {v} outside {lo}..{hi}")
    score = s.severity * (s.autonomy + s.scale + s.data_sensitivity)
    if "PROHIBITED" in s.legal_flags:
        return score, "Reject"
    if "EU_ANNEX_III" in s.legal_flags or score >= 30:
        return score, "High"
    return score, "Medium" if score >= 15 else "Low"

inventory = [
    AISystem("code-assistant", 2, 1, 2, 1),
    AISystem("resume-screener", 4, 2, 3, 2, {"EU_ANNEX_III"}),
    AISystem("support-chatbot", 3, 3, 3, 2),
]
for s in inventory:
    print(s.name, *tier(s))

This prints code-assistant 8 Low, resume-screener 28 High, support-chatbot 24 Medium, matching the worked example. In a real program this logic lives in a GRC tool or a database with an audit trail, but encoding the rubric as code has a real benefit: the rules are explicit, versioned and testable.

A practical template: AI system assessment record

Copy this structure into your intake form:

1. Identification: system ID, name, owner, version, lifecycle stage, build/buy/API, vendors.
2. Purpose and context: intended use, out-of-scope uses, users, affected people, decision role, geography.
3. Legal classification: AI Act category (prohibited, high-risk, transparency-only, minimal; GPAI provider or downstream), sector rules, data protection basis.
4. Data: sources, personal and special-category data, retention, consent or lawful basis, datasheet link.
5. Risk tiering: S, A, N, D scores, computed score, overrides, final tier, rationale.
6. Risk register: each risk mapped to NIST AI 600-1 category where relevant, likelihood, severity, mitigation, owner, residual risk.
7. Evaluation evidence: metrics and thresholds, disaggregated results, red-team findings, robustness and security tests.
8. Human oversight: who reviews, when, with what authority and training; how users can contest outcomes.
9. Transparency: notices to users and affected people; model or system card link.
10. Approval: approver(s), date, version approved, conditions.
11. Monitoring plan: metrics, thresholds, cadence, incident triggers, re-assessment date.

Common pitfalls

• Paper programs. Policies exist but nobody uses the intake form; the inventory is a stale spreadsheet. Tie governance to something engineers cannot skip, such as production deploy pipelines or procurement approval.
• Inventory blind spots. Teams register what they build but miss vendor features turned on in SaaS products and staff use of public chatbots.
• Model-only assessment. Evaluating the base model while the risk lives in the system prompt, retrieval corpus, tools and human process around it.
• Scores without overrides. A clean scoring formula that lets a legally high-risk use slip into a lower tier, as in example (b).
• One-time approval. Approving version 1 and never re-reviewing after the model, data or user population changes.
• Confusing certification with safety. ISO/IEC 42001 certification attests to process; it does not certify that a model is accurate, fair or legal.
• Framework sprawl. Running NIST, ISO and AI Act checklists separately. Build one control set and map it to each framework (a "crosswalk"); NIST publishes crosswalks to help.

In practice

Start small and real. In the first 90 days most organizations: adopt a short AI policy; appoint owners; build the inventory from procurement, billing and a survey; tier everything with a simple rubric; and run full assessments only for the High tier. Base the operating model on ISO/IEC 42001 if you need certification or already run ISO/IEC 27001; use the NIST AI RMF and AI 600-1 as the risk vocabulary and action library; use the OECD principles in your policy's values section; and keep a crosswalk to EU AI Act articles for systems touching the EU market. Measure the program itself: share of systems inventoried, share of High-tier systems with current assessments, time from intake to decision, and number of incidents caught by monitoring versus by customers. Governance that slows every project equally will be bypassed; governance that is fast for low-risk work and rigorous for high-risk work earns trust.