The NIST AI Risk Management Framework, explained

Unlike HIPAA or the CCPA, nothing forces a company to follow the NIST AI Risk Management Framework. It is voluntary, and that is exactly why it is worth understanding on its own terms: it is one of the clearest, most widely referenced structures for actually thinking through AI risk, and a growing number of enterprise buyers and vendor security reviews ask about it even though no law requires it. Here is what it is, why it exists, and what each of its four functions looks like with a concrete example.

What the NIST AI RMF actually is

The NIST AI Risk Management Framework (AI RMF) was published January 26, 2023 by NIST, the National Institute of Standards and Technology, part of the US Department of Commerce. It is a voluntary framework, not a law and not a certification, for identifying and managing risk across an AI system's lifecycle, from initial design through deployment and ongoing operation. NIST does not certify or audit organizations against it; there is no pass or fail assessment issued by NIST. It is a structure a company can choose to organize its own AI risk practices around.

The framework is built around four core functions: Govern, Map, Measure, and Manage. They are not strictly sequential steps executed once. Govern is cross-cutting and runs continuously across the other three, while Map, Measure, and Manage typically cycle as a system evolves, gets new capabilities, or moves to a new use case.

Why it exists

Before frameworks like this, AI risk management inside most companies was ad hoc: a security review here, a fairness check there, usually inconsistent between teams and often skipped entirely under deadline pressure. NIST built the AI RMF in response to a real gap: AI systems fail in ways that are harder to predict and harder to test for than traditional software, through things like biased outputs, hallucinated facts presented confidently, or a model behaving differently on inputs it was never tested against. A voluntary, structured framework gives organizations a common language and a repeatable process for catching these risks before they reach production, instead of every team improvising its own approach.

Why a company follows it

Since it carries no legal force, a company follows the NIST AI RMF for practical reasons: it is quickly becoming the reference structure that enterprise buyers, insurers, and even some regulators point to when they ask "how do you manage AI risk," so having real answers mapped to its four functions makes those conversations far more credible than an ad hoc description of internal practices. It is also just a genuinely useful way to organize the work: rather than inventing a risk process from scratch, a team can borrow a structure that has already been stress-tested across many organizations and use cases.

The four functions, explained one by one

Govern

Govern is the cross-cutting function: the culture, accountability structures, policies, and oversight that apply across the whole AI lifecycle, not to one system in isolation. It answers questions like who is accountable for a given AI system's risk, what policies exist for approving new capabilities, and how decisions get documented. Example: a company decides that before any AI agent is granted a new tool permission (say, the ability to send emails on a user's behalf), a named person has to review and sign off on that specific capability, and that decision gets logged. That is Govern in practice: a real accountability step, not a policy document nobody reads.

In the framework itself (Table 1 of AI RMF 1.0), Govern has six categories: Govern 1, policies, processes and practices for mapping, measuring and managing AI risk; Govern 2, accountability structures and training; Govern 3, workforce diversity, equity, inclusion and accessibility in risk decisions; Govern 4, a culture that considers and communicates AI risk; Govern 5, engagement with relevant AI actors and outside feedback; and Govern 6, risks from third-party software, data and the supply chain.

Where a risk register fits. The AI RMF does not use the phrase "risk register". What it does ask for, in subcategory Govern 1.6, is that "mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities", and in Govern 4.2 that teams document the risks and potential impacts of the AI they build and use. In our experience, the practical way to show both is one living register: a row per AI system with its owner, purpose, the risks found in Map, the latest Measure results and the Manage decision for each. That register is our recommendation, not a NIST requirement.

Map

Map is about context: understanding a specific system's purpose, who it affects, and what could realistically go wrong for that particular use case, before assuming a generic risk checklist covers it. A customer support chatbot and a medical triage assistant carry very different risk profiles even if they use the same underlying model. Example: before launching an AI assistant that helps users draft financial planning questions, the team maps out every place its output could cause real-world harm, such as a user mistaking a general answer for personalized financial advice, or the assistant referencing outdated tax rules, and documents those as the specific risks this system needs to address.

Measure

Measure is about assessing and quantifying the risks identified in Map, through testing, metrics, and ongoing monitoring, rather than relying on intuition about whether a system is safe. Example: the team running red-team tests against an AI agent, deliberately trying prompt injection attacks and recording how often the agent's behavior can be manipulated, then tracking that failure rate over time as the system changes. Measure turns a suspected risk into a number or a documented finding that Manage can act on.

Manage

Manage is about acting on what Measure found: prioritizing risks, deciding how to treat them, and handling incidents when they occur. Not every measured risk gets the same response. Example: after Measure shows the financial planning assistant occasionally references outdated tax figures, Manage is the decision process that follows: does this need a stronger retrieval guardrail pulling from a verified, current source, a human-in-the-loop review step before certain answers go out, or is the risk severe enough to hold the launch until it is fixed. Manage is where a measured risk turns into an actual product or process change.

The Generative AI Profile: NIST AI 600-1

The AI RMF itself is general-purpose, covering AI systems broadly. In July 2024, NIST published a companion document, the Generative AI Profile, formally titled NIST AI 600-1. It applies the same four functions (Govern, Map, Measure, Manage) specifically to risks associated with generative AI: hallucination (confidently stated but false output), memorization of training data (a model reproducing specific training examples, including potentially sensitive ones), and the generation of harmful content, among others. For any team building with large language models specifically, the Generative AI Profile is the more directly applicable document, since it translates the general framework into risks that actually show up in LLM-based products.

NIST AI 600-1 names 12 risks that are unique to or exacerbated by generative AI:

1. CBRN information or capabilities
2. Confabulation (confidently stated but false content)
3. Dangerous, violent, or hateful content
4. Data privacy
5. Environmental impacts
6. Harmful bias or homogenization
7. Human-AI configuration
8. Information integrity
9. Information security
10. Intellectual property
11. Obscene, degrading, and/or abusive content
12. Value chain and component integration

The rest of the profile is a long list of suggested actions, each tied to an AI RMF subcategory and to the risks above. Most teams will not need all 12: a support chatbot rarely touches CBRN information, but confabulation, data privacy, information security and value chain risks apply to almost every LLM product.

How to implement the NIST AI RMF

NIST does not prescribe an order. The AI RMF Playbook says its suggestions are voluntary and "neither a checklist nor set of steps to be followed in its entirety". The framework also describes profiles: a "current profile" of how you manage AI risk today and a "target profile" of where you want to be, with the gap between them as the work plan. The sequence below is how we would start, and it is our recommendation, not NIST's:

1. Inventory your AI systems (Govern 1.6), including vendor tools and models used inside other products.
2. Name an accountable owner for each system and decide who signs off on risk (Govern 2).
3. Map each system's context: its purpose, who it affects and what could realistically go wrong.
4. Pick the risks that matter, using the 12 in NIST AI 600-1 as a checklist if the system is generative.
5. Measure them with tests you can repeat: evaluation sets, red-team runs, error sampling in production.
6. Decide and record a Manage response for each risk: fix, add a control, accept, or do not launch.
7. Write down your current and target profiles and review them on a set schedule (Govern 1.5 asks for periodic review).

Use the Playbook's suggested actions for the subcategories you pick. It is published as PDF, CSV, Excel and JSON, which makes it easy to filter.

Using the NIST AI RMF for agentic AI

As of November 11, 2026, NIST has published no profile specifically for AI agents. The four functions still apply, and in our view agents put more weight on a few subcategories: Govern 3.2 (defining roles and responsibilities for human-AI configurations and oversight), Govern 6 (third-party tools, models and data an agent calls), and Govern 4.3 (testing and identifying incidents). In practice that means an inventory of every tool an agent can call, a named approver for each new permission, logs that show what the agent did, and tests for prompt injection and tool misuse. Our AI agent security checklist covers those tests.

Is the framework being updated?

NIST's own AI Risk Management Framework page says AI RMF 1.0 is being revised as part of the White House AI Action Plan. It gives no date or scope for that revision, and as of November 11, 2026 it names no newer version, so the January 2023 framework and the July 2024 Generative AI Profile are the published documents to work from. NIST also released a concept note on April 7, 2026 for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. The four functions are the part most likely to stay familiar, but check NIST's page before citing a version number in a vendor review.

What GreyScript AI does, and does not, do here

GreyScript AI structures AI system development around the NIST AI RMF's four functions as a practical way to categorize and manage risk, including using the Generative AI Profile where the system is LLM-based. NIST does not certify or audit organizations against the framework, so there is no certificate to issue in the first place, and we do not issue certifications or audit reports of our own either. A formal, independent risk assessment is the reader's own to commission if one is needed. See our AI governance and security service for how this fits into a build.

If your main concern is what to test before an AI agent goes live rather than the governance structure around it, our AI agent security checklist covers the adversarial testing side in detail, which maps closely to the Measure function described above.