The NIST AI Risk Management Framework
The NIST AI Risk Management Framework organizes AI risk into four functions — Govern, Map, Measure, and Manage — and voluntary doesn't mean optional. This overview explains what each function actually requires of an organization, how the framework differs from the NIST Cybersecurity Framework, and what demonstrating alignment looks like beyond documentation.
NIST AI Risk Management Framework: What It Is and What It Asks of Your Organization
The NIST AI Risk Management Framework is not a compliance requirement. That's the part most organizations misread.
"Voluntary" gets interpreted as "optional" — something to reference when convenient, adopt when there's bandwidth, or skip when no regulation explicitly requires it. But the National Institute of Standards and Technology Artificial Intelligence Risk Management Framework (NIST AI RMF), released in January 2023, has become the professional baseline against which AI risk programs are evaluated: by enterprise clients in vendor due diligence, by regulators who recognize its structure as evidence of good practice, and by boards asking whether the organization has a coherent approach to AI risk. The question isn't whether the framework is legally required. It's whether an organization can show a systematic approach to AI governance — and NIST AI RMF is what that looks like.
What the Framework Is Built To Do
The NIST AI RMF was designed around a specific problem: AI risk is different from the risks most governance programs are built to handle.
Traditional risk management assumes that once a system is deployed correctly, it behaves predictably. AI systems don't. A model trained on historical data can drift as real-world conditions change. A tool that performs accurately on average can perform inaccurately — and harmfully — for specific populations. A system that was fit for its original purpose can be redeployed in a context it was never designed for. These aren't edge cases. They're predictable failure modes that require ongoing governance, not a one-time sign-off.
The framework is voluntary — it carries no regulatory penalty for non-adoption in the US. It is risk-based — it doesn't prescribe identical controls for every AI system, but asks organizations to calibrate their governance to the stakes involved. And it is sector-agnostic — it applies to a healthcare company using AI for patient triage and a retailer using AI for inventory management through the same conceptual structure, adapted to each organization's context.
What it does not do is tell organizations exactly what to build. That flexibility is both the framework's strength and its most common implementation failure. Without required outputs, it's possible to adopt the NIST AI RMF on paper without changing any actual governance practice.
The Four Functions
The core of the NIST AI RMF is organized around four functions: Govern, Map, Measure, and Manage. These aren't sequential steps — they're interconnected activities that operate across an AI system's full lifecycle. A tool doesn't get governed once at deployment and then left alone. It gets governed continuously, with each function running in parallel.
Govern
Govern is the accountability structure that makes the other three functions executable. It covers the organizational decisions that need to be made before technical work begins: who owns AI risk in this organization, what authority they have, what policies apply to AI development and deployment, how new tools get approved, and what happens when a system fails or produces harm.
Without a functioning Govern layer, the outputs of Map, Measure, and Manage are documentation without institutional weight. A risk finding can be documented and ignored. A concerning result can be flagged and not acted on. Govern is the mechanism that converts findings into decisions.
Govern encompasses organizational policies, defined roles and responsibilities, risk tolerance decisions made at the executive level, workforce training expectations, and oversight of third-party and vendor AI. It is designed to run as an enterprise function — not as an IT problem or a legal problem — because AI risk has technical, legal, operational, and reputational dimensions that no single team can see alone.
Map
Map is the discovery and context-setting function. Its core question: what AI systems does the organization operate, who is affected by them, and what could go wrong?
In practice, Map produces an AI inventory — a documented account of every system in production, including vendor tools, embedded APIs, and department-level subscriptions — alongside an assessment of each system's purpose, affected populations, applicable laws, and potential failure modes. Organizations that complete a thorough Map exercise regularly discover AI tools they didn't know they had. Shadow AI — tools deployed by business units without formal IT or governance review — is the most common finding.
Map also establishes the context that makes Measure meaningful. Without understanding who a system affects and what the stakes are, there's no basis for deciding which performance metrics matter or what thresholds should trigger a response.
Measure
Measure is the assessment function. Given the systems identified in Map, Measure asks: how risky are they, and how are they actually performing?
This includes technical assessments — accuracy, reliability, error rates — and sociotechnical ones. A model can be statistically accurate overall and still produce systematically worse outcomes for specific demographic groups. A document summarization tool can perform well in testing and still create compliance exposure when employees treat its outputs as final legal advice. Measure captures both dimensions.
NIST frames measurement against seven characteristics of trustworthy AI: validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and fairness. Not every system requires rigorous assessment across all seven — the risk-based design of the framework means measurement depth should correspond to the stakes of the system being evaluated.
Critically, Measure is not a one-time activity. It runs continuously through a deployed system's life, monitoring for performance drift — the gradual degradation that occurs as real-world conditions diverge from training data — and for changes in how the system is being used that might have introduced new risks.
Manage
Manage is the response function. Given the risk picture Measure has documented, what does the organization actually do about it?
This is where governance stops being a documentation exercise and starts requiring decisions. Management actions range from technical controls — adjusting model thresholds, adding human review requirements, restricting the system's scope — to policy controls, like deciding a tool is not appropriate for a particular use case regardless of how it performs in testing. Manage also covers incident response: when something goes wrong, what is the process for identifying what happened, containing the harm, and preventing recurrence?
The Manage function depends on Govern working correctly. A risk finding that produces a management recommendation has no force unless someone with organizational authority is responsible for implementing it.
One of the most common AI governance failures: organizations complete Map and Measure rigorously, produce detailed findings — and then have no governance structure with the authority to act on them. The result is a documented record of known risk combined with no recorded response.
How NIST AI RMF Differs from the NIST Cybersecurity Framework
Organizations already familiar with the NIST Cybersecurity Framework (CSF) sometimes assume the two are interchangeable for AI. They aren't.
The Cybersecurity Framework focuses on protecting systems from external threats: identifying assets, protecting against breaches, detecting intrusions, responding to incidents, and recovering from attacks. Its primary concern is keeping bad actors out.
The AI RMF addresses failure modes the CSF was not designed to handle. A model can be perfectly secure from a cybersecurity standpoint — no unauthorized access, no data breach — and still produce discriminatory outcomes, generate harmful misinformation, or make consequential decisions based on inputs it was never meant to process. AI risk includes opacity (decisions made by systems whose reasoning cannot be explained), performance drift (accuracy degradation over time), and sociotechnical risk (harm that emerges from the interaction between the model's outputs and human behavior). These require a different governance structure than the one built for cybersecurity.
What "Demonstrating Alignment" Actually Means
Because the NIST AI RMF carries no certification and no legal mandate, organizations sometimes wonder what "alignment" actually means in practice. The answer is organizational: alignment means the four functions are operational, not just described.
A Map that exists as a one-time inventory exercise isn't operational. A Govern structure that can recommend but not block a deployment isn't functional. Measure that produces metrics nobody acts on isn't governance — it's data collection. The evidence of NIST alignment that regulators, auditors, and enterprise clients can actually evaluate is whether decisions get made, documented, and traceable to the framework's structure.
When a regulator investigates an AI-related incident, the questions they ask follow the framework's logic: Did you assess this system before deploying it? Did you monitor it afterward? When a problem appeared, who was responsible for responding? What did they do? An organization aligned to NIST AI RMF can answer those questions with documentation and named accountability. An organization that completed the framework on paper cannot.
Regulatory requirements in this area are actively evolving. This article reflects the landscape as of April 2026 — verify current obligations with qualified legal counsel before making compliance decisions.
Where to Start
An organization building toward NIST AI RMF alignment doesn't need to complete all four functions simultaneously. The most useful starting point is usually the intersection of Govern and Map: establish who owns AI risk, then build visibility into what AI is actually in production.
The first governance deliverable is typically an AI intake process — a defined gate that every new AI tool or deployment must pass before going into production. The intake process forces Map-function questions before deployment rather than after: What's the purpose? Who is affected if something goes wrong? What data is involved? Which laws apply? This produces a documented record and names an owner simultaneously.
The most honest thing about the NIST AI RMF is that it doesn't tell organizations where to draw the lines. It provides a structure for making those decisions deliberately, documenting them clearly, and being able to explain them to anyone who asks. That's the capability most organizations don't yet have — and it's what the framework is designed to build.
Pro Tip: When evaluating how AI-aligned your organization actually is, ask one operational question rather than reviewing documentation: if your highest-stakes AI tool produced a harmful output tomorrow, could you tell a regulator — within 48 hours — who approved it, who monitors it, and what the response process is? If you can, the Govern and Manage functions are working. If you'd have to reconstruct those answers from emails and Slack threads, you're NIST-described but not NIST-aligned.
Quick Reference: The Four Functions at a Glance
| Function | Core Question | Key Output |
|---|---|---|
| Govern | Who owns AI risk and what authority do they have? | Accountability structures, policies, intake process, risk tolerance |
| Map | What AI do we have and what are the stakes? | AI inventory, stakeholder analysis, applicable law, potential failure modes |
| Measure | How risky are these systems and how are they performing? | Testing results, bias assessments, performance metrics, monitoring thresholds |
| Manage | What do we do about identified risks? | Risk treatment decisions, controls, incident response, continuous improvement |
Continue Learning
This is a free preview module. Method 9 members access the full library of compliance frameworks, assessment tools, and implementation templates.
Explore Membership