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.

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.

A concrete example, end to end
Consider a small SaaS company adding an AI agent that drafts responses to customer support tickets for human review before sending. Govern: a policy is set that the agent can only draft, never send, until a separate review proves reliability over a defined period. Map: the team identifies that the biggest realistic risk is the agent confidently stating an incorrect refund policy or promising something the company cannot deliver. Measure: over several weeks, the team samples drafted responses and measures how often they contain factual errors about policy, tracking that rate against a target. Manage: based on that error rate, the team decides whether to keep the human-review requirement indefinitely for policy-related tickets, add a retrieval step that pulls the actual current policy text into the agent's context, or both.

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.