NIST AI RMF in Practice: What Govern, Map, Measure and Manage Actually Ask For

The NIST AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1) is a voluntary framework with four functions. It asks an organisation to govern AI risk as an ongoing management duty, map each AI system's context and impacts, measure the risks it found, and manage them with documented responses. Its Generative AI Profile (NIST AI 600-1) adds 12 risks specific to generative models and more than 200 suggested actions. Nobody certifies you against either document, and NIST is revising the core framework right now.

Verified as of 30 October 2026. Every statement below about what the framework says is sourced to the NIST documents themselves. The minimum viable version at the end is my own proposal, and I label it that way.

What the AI RMF is, and what it is not

NIST describes the framework as "intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic" in the AI RMF 1.0 document. Its FAQ answers the obvious question directly. Will organisations be required to use it? "No. NIST has produced the AI RMF as a voluntary Framework."

It was released on 26 January 2023, according to the NIST AI RMF page. The document has two parts. Part 1 frames AI risk and defines seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST treats valid and reliable as the base the others rest on. Part 2 is the Core, which is where the work is.

The sentence I quote most often to teams starting out is this one from section 5: "Actions do not constitute a checklist, nor are they necessarily an ordered set of steps." The Core is a set of outcomes. NIST also says organisations "may choose to select from among the categories and subcategories" rather than apply all of them. That flexibility is the framework's strength. It is also why "we follow the NIST AI RMF" means almost nothing in a security questionnaire until you say which outcomes you implemented.

The four functions, in plain English

The Core has four functions, broken into categories and subcategories. By my count of Tables 1 to 4 in the document, that is 19 categories and 72 subcategories. NIST calls Govern "a cross-cutting function" that informs the other three. It also says that after putting Govern in place, most users start with Map and then move to Measure or Manage.

Govern: make AI risk somebody's job

Govern is the management-system layer: six categories and 19 subcategories covering policy, accountability, culture, stakeholder feedback and third parties. The subcategories that matter most in practice are concrete. GOVERN 1.1 asks that legal and regulatory requirements involving AI are "understood, managed, and documented." GOVERN 1.6 asks that "mechanisms are in place to inventory AI systems." GOVERN 1.7 covers decommissioning AI systems safely. GOVERN 2.3 says executive leadership "takes responsibility for decisions about risks" in AI development and deployment. GOVERN 6.1 and 6.2 cover third-party AI risk, including intellectual property, and contingency plans for failures in third-party data or AI systems deemed high-risk.

If you only implement one subcategory this quarter, make it the inventory. You cannot map, measure or manage a system nobody has written down.

Map: write down what the system is for and who it can hurt

Map establishes context for one AI system at a time. MAP 1.1 asks you to document intended purposes, the deployment setting, the users and the potential positive and negative impacts. MAP 1.5 asks that "organizational risk tolerances are determined and documented." MAP 2.2 asks you to document the system's knowledge limits and how humans oversee its output. MAP 4.1 covers legal risks of components, including third-party data, software and IP. MAP 5.1 asks for the likelihood and magnitude of each identified impact.

NIST is explicit about what Map is for. After completing it, you should have enough context "to inform an initial go/no-go decision about whether to design, develop, or deploy an AI system." That is the most useful framing in the whole document. Map is a decision gate, not paperwork.

Measure: test it, and admit what you cannot test

Measure is the largest function: four categories and 22 subcategories. It covers test, evaluation, verification and validation, which NIST abbreviates TEVV. MEASURE 2.1 asks that test sets, metrics and tool details are documented. MEASURE 2.4 asks that the system is monitored in production. MEASURE 2.7, 2.10 and 2.11 cover security and resilience, privacy risk, and fairness and bias. MEASURE 1.3 asks for assessors who were not front-line developers of the system, or independent assessors. MEASURE 3.3 asks for ways end users can report problems and appeal outcomes.

The subcategory I would point every team at is MEASURE 1.1. Alongside selecting metrics for the most significant risks, it asks you to document the risks and trustworthiness characteristics that will not, or cannot, be measured. Writing down "we have no reliable test for this" is an outcome the framework asks for. It is also the honest answer most teams currently hide.

Manage: decide, respond, and keep an off switch

Manage turns findings into decisions. MANAGE 1.1 asks for a determination of whether development or deployment should proceed. MANAGE 1.3 lists the response options: "mitigating, transferring, avoiding, or accepting." MANAGE 1.4 asks you to document negative residual risk for downstream acquirers and end users. MANAGE 2.4 asks for mechanisms "to supersede, disengage, or deactivate AI systems" that behave inconsistently with intended use. MANAGE 3.2 says pre-trained models used for development are monitored. MANAGE 4.1 and 4.3 cover post-deployment monitoring, incident response and communicating incidents.

For a company building on a third-party model API, MANAGE 3 is where most of your real exposure sits. You did not train the model, but you shipped it to your customers.

What the Generative AI Profile adds

NIST AI 600-1, released on 26 July 2024, is "a cross-sectoral profile of and companion resource for" the AI RMF, for generative AI. A profile, in NIST's own definition, is an implementation of the AI RMF functions, categories and subcategories for a specific setting or technology. It does not replace the AI RMF. It sits on top of it.

It defines 12 risks "unique to or exacerbated by" generative AI. The count is NIST's own numbered list in section 2:

1. CBRN information or capabilities: eased access to information about chemical, biological, radiological or nuclear weapons.
2. Confabulation: confidently stated but false content, colloquially "hallucinations."
3. Dangerous, violent, or hateful content.
4. Data privacy: leakage, unauthorised use or de-anonymisation of personal or sensitive data.
5. Environmental impacts from compute-heavy training and operation.
6. Harmful bias or homogenization.
7. Human-AI configuration: automation bias, over-reliance, anthropomorphising, emotional entanglement.
8. Information integrity: content that blurs fact and fiction, or fuels large-scale disinformation.
9. Information security: lowered barriers to offensive cyber capability, and a larger attack surface on the AI system itself.
10. Intellectual property: replication of copyrighted, trademarked or licensed content, and exposure of trade secrets.
11. Obscene, degrading, and/or abusive content.
12. Value chain and component integration: untraceable third-party components, improperly obtained data, and weak supplier vetting.

NIST scoped the list deliberately. It covers risks "for which there is an existing empirical evidence base," and states that speculative risks of more advanced future systems are not considered.

The second half of the profile is a set of suggested actions keyed to AI RMF subcategories, with IDs like GV-1.6-001 (Govern 1.6, first action). I extracted more than 200 of them from the document. Two caveats from the profile itself matter. Not every AI RMF subcategory is covered, and actions relevant to developers "may not be relevant to GAI deployers." A SaaS company calling a hosted model is a deployer for most of them.

The actions are where the profile gets specific. GV-1.6-001 asks you to add generative AI systems to your AI inventory. GV-1.6-002 asks you to define, in policy, any inventory exemptions for generative AI embedded in application software. That one catches the AI feature that arrived inside a vendor tool nobody reviewed. GV-1.6-003 lists inventory fields: data provenance, known issues, human oversight roles, the underlying foundation model, its version and the access mode. MS-2.7-001 names threats to assess, including compromised dependencies, model theft or exposure of model weights, and extraction. MG-3.1-005 asks you to review system cards and model cards for third-party models.

The profile's public working group focused on four primary considerations, described in Appendix A: governance, content provenance, pre-deployment testing and incident disclosure.

Where it stands on 30 October 2026

The NIST AI RMF page now says the framework is being revised "as part of the White House AI Action Plan". The AI Action Plan of July 2025 directs NIST to "revise the NIST AI Risk Management Framework to eliminate references to misinformation, Diversity, Equity, and Inclusion, and climate change". The AI RMF Playbook page adds that the Playbook "will be updated after the AI RMF is revised."

I found no published draft of the revision, no version number and no release date on any NIST page. AI RMF 1.0 remains the current version. If someone tells you there is an "AI RMF 2.0," ask them for the NIST link.

Two newer NIST items are worth knowing about. On 7 April 2026 NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. It is a concept note with an ongoing project, not a finished profile. Separately, the Cyber AI Profile (NIST IR 8596) was published as a preliminary draft on 16 December 2025, with comments closed on 30 January 2026. That one is a Cybersecurity Framework profile, not an AI RMF profile, and it is still a draft.

My practical read: build on 1.0 now. The revision's stated direction removes topics. Nothing published so far suggests the Govern, Map, Measure, Manage structure is going away. An inventory and an impact assessment will still be the starting point after it lands.

How it relates to ISO/IEC 42001 and the EU AI Act

The three are different kinds of thing. The AI RMF is voluntary US guidance. ISO/IEC 42001 is a certifiable management-system standard. The EU AI Act is law. I covered what a 42001 certificate actually attests to in ISO 42001: What It Actually Certifies, and what a company calling a model API owes under EU law in the EU AI Act for the downstream provider.

ISO/IEC 42001: the crosswalk is not NIST's

NIST's crosswalk page on the AI Resource Center lists community crosswalks. The AI RMF to ISO/IEC 42001 crosswalk there is provided by Microsoft, not by NIST. It maps to ISO/IEC FDIS 42001, the final draft rather than the published standard. NIST states that a listing "does not imply NIST endorsement," nor that either resource "comprehensively covers the contents of the other."

With that caveat, the crosswalk is useful because the overlap is real. It maps GOVERN 6.1 to 42001's supplier controls (B.10.2 and B.10.3). It maps MAP 5.1 to clause 6.1.2, AI risk assessment, and MEASURE 2.11 to the impact assessment controls B.5.4 and B.5.5. It maps MANAGE 4.3 to management review inputs and external reporting.

The practical consequence: if you are heading toward 42001 certification, AI RMF artefacts are reusable evidence. The AI RMF gives you the vocabulary for AI risk work. 42001 gives you an auditor and a certificate.

EU AI Act: no current NIST crosswalk

The only NIST-authored crosswalk touching the EU AI Act is a January 2023 draft for comment. It maps the seven trustworthiness characteristics to vocabulary in the OECD AI Recommendation, the proposed EU AI Act, and two US federal documents. It maps characteristics to terms, not subcategories to articles, and it predates the final Regulation. I would not use it as compliance evidence.

The functional overlap is clearest in Article 9. It requires a risk management system for high-risk AI systems, run as "a continuous iterative process" across the lifecycle. Map, Measure and Manage describe that kind of loop. The legal gap is Article 40. Presumption of conformity comes from harmonised standards whose references are published in the Official Journal of the EU. The NIST AI RMF is not one of them. My reading is that following it can help you build an Article 9 system, but does not on its own demonstrate conformity. That is my interpretation of the text, not a statement from NIST or the Commission.

A minimum viable AI RMF for a mid-size SaaS company

This is my proposal, not NIST's. It assumes a SaaS company of a few hundred people that ships AI features on third-party model APIs and fine-tunes nothing. Each row is one artefact you can hand to a buyer, tied to the subcategories it satisfies.

Function	Artefact	What it contains	AI RMF subcategories
Govern	AI use policy, one page	Approved uses, prohibited uses, who approves a new AI feature, the risk tolerance statement	GOVERN 1.1, 1.2, 1.3; MAP 1.5
Govern	AI system inventory	Every AI feature and internal tool, owner, underlying model and version, access mode, data it touches, AI embedded in vendor tools	GOVERN 1.6; GV-1.6-001 to 003 in the GenAI Profile
Govern	Named accountable owner and RACI	One executive who signs off on AI risk, plus a per-system owner	GOVERN 2.1, 2.3
Govern	AI vendor review addendum	Questions on data retention, training on customer data, model and system cards, incident notice terms	GOVERN 6.1, 6.2; MANAGE 3.1; MG-3.1-005
Map	Per-feature impact assessment	Intended purpose, users, knowledge limits, who is harmed if it is wrong, likelihood and magnitude, human oversight, go/no-go decision	MAP 1.1, 2.2, 3.5, 5.1
Map	Component and legal risk note	Third-party models, datasets and licences in each feature, and the IP position	MAP 4.1, 4.2
Measure	Evaluation plan and results	Test sets, metrics, pass thresholds, and an explicit list of what you cannot measure yet	MEASURE 1.1, 2.1, 2.3
Measure	Security test record	Prompt injection and data exfiltration testing, run by someone other than the feature team	MEASURE 1.3, 2.7; MS-2.7-001
Measure	Production monitoring dashboard	Error and complaint rates, drift signals, user feedback and appeal channel	MEASURE 2.4, 3.1, 3.3
Manage	Risk register entries	Each mapped risk with a response (mitigate, transfer, avoid, accept), an owner, and documented residual risk	MANAGE 1.2, 1.3, 1.4
Manage	Kill switch runbook	How to disable each AI feature or swap its model, who can do it, how fast	MANAGE 2.4; GOVERN 1.7
Manage	AI incident playbook	AI-specific additions to your existing incident process: customer notice, model provider escalation, after-action review	MANAGE 4.1, 4.3; MG-4.3-001

Twelve artefacts, and most of them extend things a SOC 2 or ISO 27001 programme already has. The inventory, the impact assessment and the evaluation plan are the genuinely new work.

Use the framework's own gap tool to sequence it. Section 6 defines a Current Profile and a Target Profile. Comparing the two "likely reveals gaps to be addressed." Score each row above as absent, partial or done, and that is your current profile.

Checklist: the first 90 days

• Build the inventory. Include AI features inside SaaS tools your teams already use, not just the ones you ship.
• Name one accountable executive. GOVERN 2.3 asks for leadership to own the decision, not a committee.
• Write the risk tolerance down. One paragraph on what error rate or harm you will not ship.
• Run an impact assessment on your highest-exposure feature. Make the go/no-go decision explicit and record it.
• Document what you cannot measure. MEASURE 1.1 asks for it, and buyers trust it.
• Test security with someone outside the feature team. Prompt injection and data leakage first.
• Write the kill switch runbook and rehearse it once.
• Add AI questions to vendor review. Ask for system or model cards and incident notice terms.
• Check the GenAI Profile's 12 risks against each feature. Most SaaS teams will find confabulation, data privacy, information security, IP and value chain risk apply. Record why the rest do not.
• Put a review date on everything. GOVERN 1.5 asks for periodic review, and the framework itself is mid-revision.

Frequently Asked Questions

Is the NIST AI RMF mandatory?

No. NIST states that it produced the AI RMF as a voluntary framework, and the document calls itself voluntary, non-sector-specific and use-case agnostic. Customers can still require it contractually, which is how most SaaS companies first meet it.

Can a company be certified against the NIST AI RMF?

No NIST page describes a certification scheme for the AI RMF, and NIST says its Core actions do not constitute a checklist. If you need a certificate, ISO/IEC 42001 is the certifiable management-system standard. AI RMF artefacts can be reused as evidence for it.

How many risks are in the NIST Generative AI Profile?

Twelve. NIST AI 600-1 lists CBRN information, confabulation, dangerous or hateful content, data privacy, environmental impacts, harmful bias, human-AI configuration, information integrity, information security, intellectual property, obscene or abusive content, and value chain and component integration.

Is there a NIST AI RMF 2.0?

No, as of 30 October 2026. NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, but no draft, version number or release date has been published. The Playbook will be updated after the revision.

Does following the NIST AI RMF mean I comply with the EU AI Act?

Not on its own. Under Article 40, presumption of conformity comes from EU harmonised standards published in the Official Journal, and the AI RMF is not one. Its Map, Measure and Manage loop resembles the risk management system Article 9 requires for high-risk systems.

What is the difference between Govern and the other three functions?

Govern applies across the whole organisation: policy, accountability, culture and third-party risk. Map, Measure and Manage apply to a specific AI system at a specific lifecycle stage. NIST suggests putting Govern in place first, then starting each system with Map.