NIST AI Risk Management Framework

The AI RMF is not a control catalogue and it is not a certification scheme. It is a structure for having a specific set of arguments: about what a system is for, what could go wrong, whether you can measure that, and what you will do about it. It is also a structure for leaving a documented trail behind each argument. Read it as a framework for producing evidence, not as a list of requirements to satisfy.

That distinction matters because the framework states no thresholds. It never tells you that a false positive rate above some number is unacceptable, or that a model card must contain particular fields. It tells you that the outcome “risks or trustworthiness characteristics that will not - or cannot - be measured are properly documented” should hold, and leaves the substance to you. Teams that expect a checklist find this frustrating; teams that already have review processes find it a usable spine to hang them on.

The AI RMF is voluntary. NIST describes it as “intended for voluntary use”. There is no conformity assessment, no accreditation, no certificate and no penalty for ignoring it. For a private-sector organisation, adopting it creates no legal safe harbour anywhere. Its practical weight comes from being cited in contracts, procurement questionnaires and internal policy, and from being the reference point that other regimes crosswalk against. If you need something certifiable, see ISO/IEC 42001; if you need something legally binding in the EU, see the EU AI Act.

Provenance and current status

AI RMF 1.0 was released on 26 January 2023, developed over roughly 18 months with input from more than 240 contributing organisations through a Request for Information, two public drafts and a series of workshops. NIST publishes it alongside the Playbook, a Roadmap, a set of crosswalks and several profiles.

Two later documents matter if your work touches generative models or critical infrastructure:

NIST states on both the framework landing page and the Resource Center that AI RMF 1.0 is being revised as part of the White House AI Action Plan, and that the Playbook will be updated after the framework is. Treat subcategory numbering as stable for now but not permanently: anything you build that hard-codes GOVERN 1.1 as an identifier will need remapping when 2.0 lands.

Trustworthiness characteristics

Before the four functions, the framework defines what it is trying to produce. Trustworthy AI systems are characterised as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

The framework is explicit that these trade off against each other, and refuses to rank them: it notes tensions between interpretability and privacy, and between predictive accuracy and interpretability, and says that under data sparsity privacy-enhancing techniques can cost accuracy in ways that then affect fairness. Its position is that the trade-off must be resolved in context, transparently and with justification, not that some ordering exists. Validity and reliability is treated as the base condition; accountability and transparency cut across all the others.

This is the part most often skipped, and skipping it is what produces governance documents that assert a system is “fair and explainable” without saying what was given up to make it so.

The Core: four functions, categories, subcategories

The Core decomposes into four functions (govern, map, measure, manage), each broken into categories, each category into subcategories. Subcategories are written as outcomes (“legal and regulatory requirements involving AI are understood, managed, and documented”), not as instructions. NIST is explicit that the actions under them “do not constitute a checklist, nor are they necessarily an ordered set of steps”.

Govern is deliberately not the first of four sequential steps. NIST describes it as “a cross-cutting function that is infused throughout AI risk management”, and says aspects of govern (particularly compliance and evaluation) should be integrated into each of the other three. The suggested sequence for a user is: establish govern, then start at map, then measure or manage, iterating and cross-referencing instead of proceeding linearly.

GOVERN

Six categories covering: policies and procedures for mapping, measuring and managing risk (GOVERN 1); accountability structures (GOVERN 2); workforce diversity, equity, inclusion and accessibility (GOVERN 3); team culture and safe reporting (GOVERN 4); processes for engaging relevant AI actors including affected communities (GOVERN 5); and policies for third-party software, data and models (GOVERN 6).

The hook that connects this framework to actual law is GOVERN 1.1: legal and regulatory requirements are understood, managed and documented. GOVERN 1.3 is the one people underestimate: processes must exist to determine the needed level of risk management activity based on the organisation’s risk tolerance. Without it you either review everything at the same depth, which stalls, or you review ad hoc, which is not a process.

GOVERN 6 is where engineering organisations most often have a real gap. The majority of AI risk in a typical product now arrives through a third-party model API or a pretrained checkpoint, and the existing vendor-risk process was written for SaaS.

MAP

Map establishes the context in which risk means anything. NIST’s stated reason is that the AI lifecycle involves many interdependent activities and actors, and “AI actors in charge of one part of the process often do not have full visibility or control over other parts and their associated contexts”. Early framing decisions therefore silently constrain what later stages can fix.

The concrete output NIST expects is a decision: “sufficient contextual knowledge about AI system impacts to inform an initial go/no-go decision about whether to design, develop, or deploy an AI system.” Map is the only function with a documented stopping point of “do not build this.”

Categories cover establishing context (MAP 1), categorising the system and its capabilities (MAP 2 and 3), mapping risks and benefits including for third-party components (MAP 4), and characterising impacts to individuals, groups, communities and society (MAP 5).

MEASURE

Measure applies “quantitative, qualitative, or mixed-method tools, techniques, and methodologies” to analyse, benchmark and monitor risk. NIST asks for testing before deployment and regularly while in operation, rigorous software testing and performance assessment with associated measures of uncertainty, comparison to benchmarks, and formalised reporting. It also recommends independent review to mitigate internal bias and conflicts of interest.

The subcategory to read carefully is MEASURE 1.1: metrics are selected starting with the most significant risks identified in map, and the risks or trustworthiness characteristics that will not - or cannot - be measured are properly documented. That second clause is the honest part of the framework. It concedes that some of what matters is not measurable with current methods. You must then say which parts those are instead of quietly dropping them.

Measure 2 covers evaluation of the system for the trustworthiness characteristics; Measure 3 covers mechanisms for tracking identified and emergent risks; Measure 4 covers feedback about efficacy of measurement, including from domain experts and affected users.

MANAGE

Manage allocates resources against risks that map and measure have established, “on a regular basis and as defined by the govern function”. MANAGE 1.1 restates the go/no-go decision as a continuing one: whether the system achieves its intended purposes, and whether development or deployment should proceed. MANAGE 1.3 enumerates the response options as mitigating, transferring, avoiding or accepting: the standard four, which means “accept and record” is an available answer.

Manage 2 covers strategies to maximise benefits and minimise negative impacts, Manage 3 covers third-party risks and benefits, Manage 4 covers risk treatments including response, recovery and communication plans for incidents.

The Playbook

The Playbook is the companion resource that supplies suggested actions for each subcategory, along with references and documentation prompts. It is online at the AI Resource Center and downloadable as PDF, CSV, XLSX and JSON.

The JSON and CSV forms are the useful ones. They let you treat the subcategory set as data: import it, mark each subcategory as applicable or not applicable with a reason, attach evidence links, and diff it between releases. That converts governance from a document that is rewritten annually into a record that is updated per change.

NIST is clear about the Playbook’s status: suggestions are voluntary, it is “neither a checklist nor set of steps to be followed in its entirety”, and organisations may borrow as many or as few suggestions as apply. Updates are released approximately twice per year.

Operationalising it without producing shelfware

The framework’s abstraction is its main practical problem. A workable reduction for an engineering team looks like this.

Pick the unit of assessment first. The framework is written per AI system, and “system” is ambiguous when one fine-tuned model serves six features. Choose either the deployed feature (more assessments, each meaningfully scoped) or the model plus a register of approved uses (fewer assessments, but each must enumerate use restrictions). Deciding this later means re-doing the work.

Make GOVERN a small number of durable artefacts, not a policy document. An AI system register, a named accountable owner per entry, a documented risk-tolerance tier scheme (GOVERN 1.3), and a third-party model intake checklist (GOVERN 6). Four things that exist and are maintained beat a thirty-page policy nobody reads.

Run MAP as a template on the design document. Intended purpose; who is affected and who is not the user; what happens if the output is wrong in each direction; what the fallback is when the model is unavailable; which Annex-III-like consequential decisions are involved if you also operate in the EU. Finish with an explicit go/no-go signed by the owner.

Attach MEASURE to CI, not to a review meeting. Whatever metrics MAP identified become a stored evaluation suite that runs on model change, with results retained per version. NIST’s requirement for “measures of uncertainty” means confidence intervals on those numbers, which for small evaluation sets is frequently the finding: the set is too small to detect the regression you care about. Disaggregate by the data segments MAP said mattered. Record explicitly, in the same file, the risks you decided not to measure.

Make MANAGE a queue with owners and dates. Prioritised risks, chosen treatment from the four options, owner, review date. Incident response for AI failures should extend the existing incident process instead of starting a new one. The escalation path, on-call and postmortem format already exist.

Instrument the feedback loop. Measure 3 and Measure 4 require tracking emergent risks and gathering feedback on whether your measurements mean anything. In practice this is production monitoring of input drift and output distribution, plus a route by which support tickets and user complaints about model behaviour reach the team that owns the evaluation suite. If those two things do not exist, the measure function is a point-in-time test masquerading as monitoring.

Failure modes

The last one is the common terminal state. The framework says risk management “should be continuous, timely, and performed throughout the AI system lifecycle”. The operational reading is that a change to the model, the prompt, the retrieval corpus or the intended use must re-open the assessment, and that the deployment pipeline, not intent, must enforce this.

Crosswalks, and their limits

NIST hosts community-submitted crosswalks mapping the AI RMF to other resources, including ISO/IEC 23894 (AI risk management guidance), ISO/IEC 42005, ISO/IEC 5338 and 5339, Singapore’s IMDA AI Verify, Japan’s AI Guidelines for Business, Korea’s TTA guidebook, and a Microsoft-provided crosswalk to ISO/IEC 42001. NIST also published its own illustration relating the trustworthiness characteristics to the OECD Recommendation on AI and the then-proposed EU AI Act.

NIST attaches an explicit caveat to that page: inclusion “does not imply NIST endorsement of the resource the AI RMF is mapped to, nor does it imply that either resource comprehensively covers the contents of the other”. A crosswalk shows where vocabulary corresponds. It does not show that satisfying one satisfies the other, and it is not evidence of compliance with anything. Using an AI RMF implementation as the internal machinery that produces EU AI Act documentation is reasonable; claiming the AI RMF work is conformity is not.

Related

• EU AI Act - binding obligations, risk tiers and phased application dates
• ISO/IEC 42001 - certifiable AI management system standard
• AI governance - index