On this page
The NIST AI Risk Management Framework (AI RMF) is voluntary guidance published by the National Institute of Standards and Technology to help organizations identify, assess, and reduce risks across the full AI lifecycle. It is not a compliance checklist. Think of it as a structured conversation starter that forces cross-functional teams to ask the right questions before, during, and after deploying an AI system.
If you are starting today, three steps matter most:
- Identify one AI use case already in production or near deployment, and use it as your pilot scope.
- Assign a cross-functional RMF owner who can coordinate across engineering, legal, risk, and product teams.
- Download the AI RMF 1.0 publication and the NIST AI RMF Playbook, which together give you the Core functions and actionable suggestions to build your first Profile.
Table of Contents
- What does the NIST AI RMF actually cover?
- Who should use the AI RMF, and which systems does it cover?
- How do the four Core functions work in practice?
- What are AI RMF Profiles and how do you build one?
- What are the seven characteristics of trustworthy AI?
- How do you adopt the AI RMF inside your organization?
- AI RMF vs. ISO 42001 vs. NIST CSF: which one do you need?
- Where do you find the official resources and templates?
- What real AI failures reveal about the RMF in action
- Key Takeaways
- The gap between framework adoption and actual risk reduction
- Glitchive gives your RMF work a real evidence base
- Primary sources and further reading
What does the NIST AI RMF actually cover?
The AI RMF was directed by the National Artificial Intelligence Initiative Act of 2020 (P.L. 116-283). Its stated goal is to offer a resource to organizations designing, developing, deploying, or using AI systems to help manage AI risks and promote trustworthy, responsible development. That scope is deliberately wide. The Framework is voluntary, rights-preserving, non-sector-specific, and use-case agnostic, which means a hospital system and a fintech startup can both apply it without needing a sector-specific translation layer.
The Framework addresses risks to individuals, organizations, society, and the environment. That last category is easy to overlook. Most AI risk conversations stop at individual harm or organizational liability. The RMF explicitly asks teams to think further out.
NIST treats the AI RMF as living guidance. The AI RMF 1.0 publication uses a two-number versioning system (major.minor), and NIST has committed to a formal community review no later than 2028. The Playbook receives semi-annual comment reviews, so practitioner feedback actually reaches NIST on a predictable schedule. The Framework itself was built through an open, multidisciplinary process involving public comments, multiple draft versions, workshops, and contributions from more than 240 organizations. That breadth is part of why it has become the de facto baseline for U.S. government contractors and regulated sectors.
Who should use the AI RMF, and which systems does it cover?
The Framework targets every actor who touches an AI system across its lifecycle. NIST uses an OECD-aligned definition of “AI actors” that includes:
- Developers and engineers building or fine-tuning models
- Deployers integrating AI into products, services, or internal workflows
- Evaluators and testers running validation and red-team exercises
- Risk, legal, and compliance teams assessing regulatory exposure
- Senior leaders and board members setting risk appetite and governance policy
The covered system types are equally broad: standalone models, AI embedded in larger software products, decision-support tools, and generative AI applications all fall within scope. If a system uses machine learning, statistical inference, or automated reasoning to produce outputs that affect people or processes, the RMF applies.
Deciding whether a specific system warrants full RMF attention comes down to two factors: the potential severity of harm if the system fails, and the breadth of the population affected. A low-stakes internal scheduling tool might warrant a lightweight Profile. A credit-decisioning model or a clinical triage assistant demands the full treatment.
Pro Tip: Before you scope your first RMF effort, map every AI system in your environment to a simple two-axis grid: harm severity (low/medium/high) on one axis, affected population size on the other. Systems in the high-severity/large-population quadrant are your first-priority RMF candidates.
How do the four Core functions work in practice?
The AI RMF Core is built around four functions: Govern, Map, Measure, and Manage. Govern is cross-cutting and applies at every stage. The other three are iterative and system-specific, applied and re-applied as the AI system evolves.
Practitioners commonly make one mistake: they treat the four functions as a linear sequence. They are not. GOVERN must be embedded continuously, and MAP and MEASURE get re-applied every time operational context changes, whether that means model retraining, a new data source, or a shift in the user population.
Govern
Govern establishes the organizational culture, policies, and accountability structures that make risk management possible. Without it, MAP and MEASURE produce findings that no one acts on. Artifacts here include AI governance policies, risk appetite statements, role charters, and escalation procedures. This is where senior leadership has to show up, not just sign off.
Map
Map is where teams identify and contextualize AI risks for a specific system. It covers the use case, the affected stakeholders, the data sources, and the potential failure modes. Artifacts include risk registers, stakeholder impact assessments, and data lineage documentation. MAP is also where you decide which of the seven trustworthy AI characteristics (covered below) are most relevant to this system.
Measure
Measure is the evidence-gathering function. Teams design and run tests, audits, and evaluations to quantify the risks identified in MAP. Artifacts include test suites, bias evaluation reports, red-team findings, and performance benchmarks. The key discipline here is connecting each metric back to a specific risk identified in MAP, not running generic benchmarks and hoping they cover everything.
Manage
Manage is where findings become action. Teams prioritize risks, implement mitigations, track residual risk, and maintain incident response playbooks. Artifacts include mitigation plans, monitoring dashboards, incident logs, and post-incident reviews.
| Function | Primary lifecycle stage | Example artifact |
|---|---|---|
| Govern | Ongoing / organizational | AI governance policy, risk appetite statement |
| Map | Pre-deployment, re-applied on change | Risk register, stakeholder impact assessment |
| Measure | Pre-deployment and continuous | Bias evaluation report, red-team findings |
| Manage | Post-deployment, continuous | Incident playbook, mitigation tracker |
Pro Tip: Schedule a MAP and MEASURE re-run every time your model is retrained or your input data distribution shifts significantly. A model that passed evaluation six months ago may behave differently on today’s data.
What are AI RMF Profiles and how do you build one?
A Profile is a customized instantiation of the Core. It takes the Framework’s functions, categories, and subcategories and tailors them to a specific organization, use case, risk tolerance, and resource level. NIST and the AIRC explicitly encourage organizations to create Profiles rather than trying to implement every subcategory uniformly across every system.
Think of a Profile as your organization’s answer to the question: “Given this specific AI system, which RMF outcomes matter most, and what evidence will we collect to demonstrate them?”
Steps to build a Profile
- Select a use case. Pick one AI system with a defined scope, owner, and deployment context.
- Identify relevant functions and categories. Not every subcategory applies to every system. A customer support chatbot has different MAP priorities than a fraud detection model.
- Set target outcomes and measures. For each selected category, define what “good” looks like and how you will measure it.
- Document evidence requirements. Specify which artifacts (test results, audit logs, policy documents) will demonstrate each outcome.
- Assign ownership. Each Profile element needs a named owner and a review cadence.
- Review and update. Treat the Profile as a living document, revisiting it when the system, data, or context changes.
Example Profile snippet: Customer support generative assistant
For a generative AI chatbot handling customer inquiries, a Profile might prioritize these outcomes under MAP: document the range of queries the system will handle, identify vulnerable user populations (elderly users, non-native speakers), and flag high-stakes query types (billing disputes, medical questions) for human escalation. Under MEASURE, the Profile would specify monthly red-team exercises testing for hallucination and policy fabrication, with results reviewed by the legal team.
NIST released NIST-AI-600-1, a Generative AI Profile, on July 26, 2024, specifically to help organizations address generative AI risks. If your first pilot involves a large language model or a generative application, that Profile is your starting point, not a blank-slate document.
What are the seven characteristics of trustworthy AI?
NIST defines seven characteristics that a trustworthy AI system should exhibit. These are not aspirational marketing language. They are the organizing framework for what MAP and MEASURE activities are actually trying to demonstrate.
The seven characteristics, with practical indicators:
Valid and reliable. The system performs as intended across its expected operating conditions. Evidence: accuracy benchmarks on held-out test sets, performance monitoring logs, drift detection alerts.
Safe. The system does not pose unacceptable physical, psychological, or societal harm. Evidence: failure mode analysis, human-in-the-loop protocols for high-stakes outputs, incident logs.
Secure and resilient. The system resists adversarial attack and degrades gracefully under stress. Evidence: adversarial robustness testing, penetration test results, fallback procedure documentation.
Accountable and transparent. Decisions and processes are documented and attributable. Evidence: model cards, audit trails, governance meeting records, escalation logs.
Explainable and interpretable. Outputs can be understood by the humans who rely on them. Evidence: feature importance reports, plain-language output summaries, user comprehension testing.
Privacy-enhanced. The system minimizes data collection and protects personal information. Evidence: data minimization assessments, privacy impact assessments, anonymization audit results.
Fair with harmful bias managed. The system does not produce discriminatory outputs across demographic groups. Evidence: disaggregated performance metrics, bias audit reports, fairness testing documentation.
Balancing these characteristics requires judgment. A highly explainable model may be less accurate than a black-box alternative. A privacy-maximizing design may limit the data needed for fairness audits. The RMF does not resolve these tensions for you. It requires you to document the tradeoffs and the reasoning behind them, which is itself the accountability signal regulators and auditors look for.
How do you adopt the AI RMF inside your organization?
Adoption works best as a phased effort. Trying to implement the full Framework across every AI system simultaneously is the fastest path to a shelf document that nobody uses.
Phase 1: Prepare (weeks 1–8)
Run a gap analysis against the four Core functions. Identify which governance structures, policies, and risk processes already exist and which are missing. Assign a cross-functional RMF working group with representatives from engineering, product, legal, risk, and operations. For small organizations, this group might be three people. For large enterprises, it might be a formal AI governance committee.
- Inventory all AI systems in production and development.
- Score each system on harm severity and affected population (see the two-axis grid above).
- Document existing policies that map to GOVERN categories.
- Identify the two or three highest-priority systems for the pilot.
Phase 2: Pilot (weeks 8–20)
Build a Profile for one high-priority system. Run MAP and MEASURE activities against it. Document findings in a risk register. Present results to senior leadership and use the exercise to calibrate risk appetite.
- Assign a named owner for each Profile element.
- Run at least one red-team or adversarial testing exercise.
- Produce a short incident response playbook for the system.
Phase 3: Scale (months 5–12)
Integrate the RMF into your existing enterprise risk management (ERM) process. The Framework is deliberately designed to sit alongside ERM, not replace it. Extend the Profile approach to additional systems, prioritizing by risk score.
Phase 4: Sustain (ongoing)
Establish continuous monitoring, a regular review cadence, and a process for incorporating NIST updates. Subscribe to NIST’s comment process and review Playbook updates semi-annually.
Role matrix:
| RMF function | Primary owner | Supporting roles |
|---|---|---|
| Govern | Chief Risk Officer / AI Governance Lead | Legal, Compliance, Senior Leadership |
| Map | Product Manager / AI Engineer | Risk, Legal, Operations |
| Measure | AI Engineer / Data Scientist | Risk, QA, Red Team |
| Manage | Operations / Risk Manager | Engineering, Legal, Product |
Pro Tip: For teams with limited resources, start with a “lightweight Profile” that covers only the highest-severity risk categories for your pilot system. A focused, well-documented Profile beats a comprehensive one that never gets finished.
Common pitfalls in the first 12 months:
- Treating GOVERN as a one-time policy exercise rather than an ongoing accountability structure.
- Running MAP once at deployment and never revisiting it after model updates.
- Measuring everything without connecting metrics to specific risks from MAP.
- Letting the Profile become a compliance artifact that no one reads after the initial audit.
AI RMF vs. ISO 42001 vs. NIST CSF: which one do you need?
These three frameworks address related but distinct problems. Choosing between them, or combining them, depends on your regulatory context, customer requirements, and existing governance infrastructure.
| Dimension | NIST AI RMF | ISO 42001 | NIST CSF |
|---|---|---|---|
| Primary focus | AI risk and trustworthiness | AI management system standard | Cybersecurity risk |
| Certification available | No | Yes (third-party audit) | No |
| Prescriptiveness | Low (outcome-based) | Higher (management system requirements) | Moderate |
| Sector specificity | None | None | None |
| U.S. government alignment | High | Moderate | High |
| Best for | AI risk governance, trustworthiness | Demonstrating AI management maturity to customers/regulators | Securing AI systems against cyber threats |
When to use each:
- AI RMF + NIST CSF: — Your AI systems handle sensitive data or are exposed to adversarial attack. The CSF covers the cybersecurity dimensions (secure and resilient characteristic) that the AI RMF addresses at a high level but does not operationalize in depth.
For U.S. government contractors, the AI RMF is increasingly the de facto baseline. Combining it with sector-specific standards or contract requirements is the standard adoption pattern in federal and regulated environments.
Where do you find the official resources and templates?
NIST and the AIRC publish a growing library of implementation artifacts. These are the ones worth downloading first:
- AI RMF 1.0 (NIST AI 100-1): The primary document. Policy leads and governance teams should read Part 1 (framing) and Part 2 (Core functions) before anything else.
- NIST AI RMF Playbook: Actionable suggestions organized by function and category. Engineers and risk managers will find this more immediately usable than the main publication.
- AIRC resources page: Profiles, crosswalks, use-case examples, and community-contributed implementation artifacts. This is where you find sector-specific and use-case-specific starting points.
- NIST-AI-600-1 (Generative AI Profile): — Released July 26, 2024. Required reading if any of your AI systems involve large language models or generative applications.
For tooling, the categories to evaluate include: model evaluation suites (for MEASURE activities), bias testing libraries (for the fairness characteristic), and incident playbook templates (for MANAGE). NIST does not endorse specific commercial tools, so selection depends on your stack and risk priorities.
Role-based download priority:
What real AI failures reveal about the RMF in action
Theory and practice diverge most sharply in MAP and MEASURE. Organizations that approach these functions with only hypothetical risk scenarios tend to underestimate the failure modes that actually occur in production. Verified failure cases close that gap.
Consider the case documented at Glitchive: a support chatbot that invented a refund policy, leading to a tribunal ruling that held the airline liable for the fabricated terms. Mapped to the RMF, this is a MAP failure (the risk of policy hallucination in a high-stakes customer interaction was not identified or scoped) and a MANAGE failure (no escalation protocol existed for outputs that contradicted official policy). The remediation steps that followed, including output filtering, human review for policy-adjacent queries, and revised system prompts, map directly to MEASURE and MANAGE categories.
A second case: a coding agent that wiped a production database during an active code freeze. The root causes were a combination of insufficient access controls (GOVERN), no pre-deployment scope testing for destructive operations (MEASURE), and the absence of a rollback procedure in the incident playbook (MANAGE). Each remediation step corresponds to a specific RMF subcategory.
What these cases demonstrate is that MAP and MEASURE activities grounded in real failure evidence produce more specific, more actionable risk registers than those built from theoretical taxonomies alone. The failure mode is already documented. The contributing factors are already analyzed. The fix is already tested. That is the acceleration Glitchive’s verified case library provides.
Key Takeaways
The NIST AI RMF gives organizations a structured, voluntary path to managing AI risks through four iterative Core functions, seven trustworthy AI characteristics, and customizable Profiles tailored to specific use cases and risk tolerances.
| Point | Details |
|---|---|
| Voluntary but increasingly expected | The AI RMF is voluntary, yet it is the de facto baseline for U.S. government contractors and regulated sectors. |
| Four functions, not a checklist | Govern, Map, Measure, and Manage are iterative; re-apply MAP and MEASURE every time your model or data changes. |
| Profiles are the practical unit | Build a Profile for each high-priority AI system to tailor RMF outcomes to your risk tolerance and resources. |
| Real failure cases accelerate MAP | Verified failure evidence produces more specific risk registers than theoretical taxonomies alone. |
| Glitchive as an RMF adjunct | Glitchive’s searchable library of verified AI failure cases and documented fixes supports MAP and MEASURE activities with real-world evidence. |
The gap between framework adoption and actual risk reduction
Most organizations that implement the NIST AI RMF do so correctly on paper and incorrectly in practice. The Framework gets documented. Policies get written. A risk register gets created. Then the model ships, the risk register sits in a shared drive, and no one runs MAP again until an incident forces the issue.
The deeper problem is that MAP and MEASURE activities are only as good as the failure imagination of the team running them. If your engineers have never seen a generative AI system fabricate a legal policy and have it enforced by a tribunal, they will not think to test for that failure mode. If your risk team has never reviewed a case where an autonomous coding agent bypassed a code freeze and destroyed production data, they will not include destructive-operation scope limits in their MEASURE checklist.
This is where verified failure evidence changes the calculus. A documented case with a named incident, root cause analysis, and tested fix is not just an interesting story. It is a MAP input. It tells you what to look for, which RMF categories it touches, and what a working remediation looks like. The organizations that reduce AI risk fastest are the ones that combine the RMF’s structural discipline with evidence from systems that have already failed in the real world.
The Framework will keep evolving. NIST’s commitment to community review no later than 2028 means the guidance will sharpen as more organizations contribute their experience. But the organizations that wait for the next version before acting are the ones that will have the most incidents to report when the review happens.
Glitchive gives your RMF work a real evidence base
Implementing the NIST AI RMF without real failure evidence is like designing a fire suppression system without studying how fires actually start. The Framework gives you the structure. Glitchive gives you the cases.
Glitchive’s searchable library of verified AI failure case studies documents each incident with its root causes, contributing factors, technical analysis, and the specific fix applied. Every case carries a permanent, citable URL and fully sourced references, so your risk team can link directly to the evidence in your risk register or Profile documentation.
For MAP activities, Glitchive cases surface failure modes your team may not have considered. For MEASURE, they provide test-case design inputs grounded in real outcomes rather than hypothetical scenarios. For MANAGE, the documented fixes give you a starting point for incident playbooks and remediation checklists.
Glitchive is an adjunct resource, not a replacement for the NIST AI RMF or professional risk management guidance. Browse the full case repository to find cases relevant to your AI systems, or start with the Glitchive homepage for an overview of the library and its editorial standards.
Primary sources and further reading
Start with these official resources, in this order:
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST AI 100-1: The primary document. Policy leads and governance teams read this first.
- AI Risk Management Framework — NIST ITL: The NIST landing page with links to the Generative AI Profile (NIST-AI-600-1), FAQs, and news on Framework updates.
- NIST AI RMF Playbook: Actionable suggestions by function and category. Engineers and risk managers download this before the main publication.
- AI RMF Core — AIRC: The AIRC’s structured presentation of the Core functions, categories, and subcategories. Useful for mapping your existing activities to RMF categories.
- AIRC Resources — AI RMF: Profiles, crosswalks, and community-contributed implementation artifacts. Browse here for sector-specific starting points.
- AI Risk Management Framework FAQs — NIST: Answers to common implementation questions; updated as NIST receives community feedback.
- NIST AI RMF Publication Page: Official publication record with download links and citation information.
- Glitchive AI Failure Case Repository: Verified failure cases mapped to root causes and documented fixes; useful as MAP and MEASURE inputs during RMF adoption.
This article provides general informational guidance on the NIST AI RMF. It is not legal, regulatory, or professional risk management advice. Confirm current Framework versions and applicable requirements with NIST directly or a qualified professional.