When a customer questionnaire or a procurement team asks whether your AI system "aligns with the NIST AI Risk Management Framework", the honest answer depends on what the document actually requires. The short version: the NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary vocabulary and structure for managing AI risk. It is not a standard you pass, not a certification, and not a checklist. This guide reads the primary text, explains its four functions and its generative-AI companion, and ends with a practical way to use it without pretending to more than it offers.[1][2]
What the framework is, and what it says it is not
NIST published AI RMF 1.0 as NIST AI 100-1 in January 2023. It says its goal, "as directed by the National Artificial Intelligence Initiative Act of 2020", is to offer a resource to organisations designing, developing, deploying or using AI systems to manage AI risks and promote trustworthy and responsible use. It is "intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic."[1]
Three consequences follow from that wording, and they are our reading rather than NIST's:
- There is no pass or fail. A voluntary, outcome-focused document has no certification body in it. The text says the framework should be "outcome-focused and non-prescriptive", offering a catalogue of outcomes rather than a method.[1]
- Claims of "NIST compliant" are loose. What can be true is "we mapped our process to these subcategories and here is the evidence". That is a statement you can back up.
- It does not replace law. One of the framework's own governance outcomes is that legal and regulatory requirements involving AI are understood, managed and documented, which treats law as an input, not something the framework supplies.[1]
The document also describes itself as a living document, with a formal review expected no later than 2028. NIST's program page, retrieved the same day, adds that the framework "is being revised as part of the White House AI Action Plan". We did not find the outcome of that revision, so check the current version before citing a subcategory number.[1][4]
The four functions
The Core is organised into four functions, each broken into categories and subcategories. The framework says functions can be performed in any order across the AI lifecycle, but that after instituting the outcomes in Govern, most users would start with Map and continue to Measure or Manage, iterating and cross-referencing as needed.[1]
| Function | What the text says it does | Example subcategory (paraphrased) |
|---|---|---|
| Govern | Cross-cutting; "infused throughout AI risk management and enables the other functions". Policies, roles, culture, risk tolerance, third-party handling. | GOVERN 1.6: mechanisms to inventory AI systems; GOVERN 1.7: processes for decommissioning |
| Map | "Establishes the context to frame risks related to an AI system": purposes, tasks, benefits, costs and impacts. | MAP 1.1: intended purposes, beneficial uses and context are understood and documented |
| Measure | Uses quantitative, qualitative or mixed-method tools to analyse, assess, benchmark and monitor AI risk. | MEASURE 2.1: test sets, metrics and tool details used during evaluation are documented |
| Manage | Allocates resources to mapped and measured risks, with plans to respond, recover and communicate. | MANAGE 4.1: post-deployment monitoring, including appeal, override, incident response and decommissioning |
Sources for the table: the function descriptions and subcategory texts in sections 5.1 to 5.4 and Tables 1 to 4 of AI 100-1.[1]
Govern is not a phase
The framework is explicit that Govern is not a first step you finish. It says governance is "a continual and intrinsic requirement for effective AI risk management over an AI system's lifespan", and that aspects related to compliance or evaluation should be integrated into each other function.[1] In practice, that means the inventory, ownership and decommissioning questions belong in the same meetings as the technical work.
Measure ties to evaluation
Measure asks for "rigorous software testing and performance assessment methodologies with associated measures of uncertainty, comparisons to performance benchmarks, and formalized reporting and documentation of results", and says independent review can improve testing and mitigate internal bias.[1] If you are building the testing side, see our guides to building LLM evals for your application and evals that survive production. For how to treat headline scores, see how to read an AI benchmark claim.
Seven characteristics of trustworthy AI
The framework lists seven characteristics: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed.[1] It states that tradeoffs among them are contextual: what counts as acceptable is "highly contextual and application and use-case specific".[1]
The useful reading is that the list is a prompt for explicit decisions. If you improve explainability by constraining the model and that costs accuracy, the framework wants that choice documented, not hidden.
Profiles: where the framework gets specific
The core is deliberately generic. NIST's answer to specificity is the profile: an implementation of the functions, categories and subcategories for a specific setting, such as a hiring profile. The text also describes a Current Profile (how AI is being managed now) and a Target Profile (the outcomes you want), and says comparing them reveals gaps to be addressed through action plans.[1] That gap analysis is the most directly usable idea in the document for a small team.
The Generative AI Profile: twelve risks
NIST AI 600-1, released in July 2024, is a cross-sectoral profile for generative AI. It defines twelve risks "unique to or exacerbated by" generative AI:[2]
- CBRN information or capabilities
- Confabulation
- Dangerous, violent or hateful content
- Data privacy
- Environmental impacts
- Harmful bias or homogenization
- Human-AI configuration
- Information integrity
- Information security
- Intellectual property
- Obscene, degrading and abusive content
- Value chain and component integration
Two entries are worth highlighting because they are easy to miss in a technical-only review. Confabulation is defined as generating and confidently presenting erroneous or false content; NIST notes it is colloquially called hallucination and describes it as a natural result of how generative models approximate the statistical distribution of their training data, which matches the mechanism in our piece on why models hallucinate.[2] Human-AI configuration covers interactions that can lead people to anthropomorphise a system or experience algorithmic aversion, automation bias, over-reliance or emotional entanglement, a risk that lives in your interface design as much as in the model.[2]
Value chain and component integration matters for anyone building on third-party models and datasets: NIST says GAI value chains involve many third-party components, and that it may be difficult to attribute issues in a system's behaviour to any one of them.[2]
The profile's suggested-action tables use IDs that map back to the core: GV for Govern, MP for Map, MS for Measure and MG for Manage, with tags linking each action to the relevant risks. The profile says the applicability of each action should be determined by organisational considerations and the organisation's own uses of generative AI.[2]
The Playbook is optional by design
The online Playbook gives suggested actions for achieving the Core outcomes, grouped by the four functions. NIST's page describes it as "neither a checklist nor set of steps to be followed in its entirety", says organisations can adopt as many or as few suggestions as fit their use case, and says it is a living resource that is updated about twice a year.[3]
A practical way to use this
This is our interpretation, not NIST guidance:
- Start with a system inventory. If you cannot list your AI systems and owners, nothing else in Govern is meaningful.
- Write one Map page per system. Purpose, users, context, known limits, what happens if it is wrong. This is the document reviewers ask for first.
- Pick measures that match the risks you mapped. For a customer-facing assistant, confabulation and information security from the twelve-risk list are likely candidates; build evals for them and record the test sets and tools used.
- Plan the Manage side before launch. Monitoring, an override path, an incident process and a decommissioning plan are all named in the text.
- Keep a Current and a Target Profile. Revisit them when models, vendors or regulations change. For agent-specific exposure, pair this with our guide to how AI agents work and how to secure them.
What remains uncertain
- The revision announced on NIST's program page was not complete as of our retrieval; subcategory wording may change.[4]
- We did not read sector profiles or regulator documents that cite the framework, so we make no claim about where it is legally required.
- A framework mapping shows process, not outcomes. It does not show a given model is safe.
Updated: 2026-10-16.
