NIST AI RMF Implementation Guide: From Framework to Working Program

The NIST AI RMF (AI Risk Management Framework 1.0, published by NIST in January 2023 as NIST AI 100-1) is a voluntary framework for identifying, assessing and managing the risks of AI systems across their life cycle. It organizes the work into four functions: Govern, Map, Measure and Manage. Implementing it means turning those functions into owned processes, artifacts and technical controls that run every time your organization builds, buys or changes an AI system.

That last sentence is where most programs stall. The framework is deliberately outcome-based. It tells you what a mature organization achieves, not which committee to form or which tool to buy. This guide covers what the framework actually contains, how to translate each function into operating mechanics, how to use the Playbook and the Generative AI Profile, and what a realistic first 90 days looks like.

What the NIST AI RMF actually contains

The document has two parts. Part 1 frames the problem: how AI risk differs from traditional software risk, who the AI actors are, and what makes an AI system trustworthy. Part 2 is the core: four functions, each broken into categories and subcategories.

NIST describes seven characteristics of trustworthy AI. They are useful as the vocabulary for your risk criteria:

• Valid and reliable: the system does what it is meant to do, consistently.
• Safe: it does not endanger people, property or the environment under defined conditions.
• Secure and resilient: it withstands attacks and recovers from adverse events.
• Accountable and transparent: there is clear responsibility and appropriate information about the system.
• Explainable and interpretable: people can understand how and why it produces outputs.
• Privacy-enhanced: it protects individual autonomy, identity and data.
• Fair, with harmful bias managed: it addresses systemic, computational and human biases.

These characteristics trade off against each other. A more interpretable model may be less accurate; stronger privacy controls may limit your ability to test for bias. The framework expects you to make those trade-offs explicitly and document them, which is a more honest posture than pretending every system can maximize every property.

The four functions at a glance

Function	Purpose	What it produces in practice
Govern	Build the culture, policies, roles and accountability for AI risk. Cross-cutting; informs the other three.	AI policy, risk appetite, RACI, training, third-party AI requirements, escalation paths
Map	Establish context for a specific AI system: purpose, users, impacts, assumptions, dependencies.	Use-case intake record, impact assessment, system card, risk tier
Measure	Analyze, assess and track the risks identified in Map, with quantitative and qualitative methods.	Evaluation plans, test results, red-team findings, monitoring metrics
Manage	Prioritize and act on risks: treat, transfer, accept or avoid; respond to incidents; decommission.	Risk treatment decisions, go/no-go approvals, incident runbooks, retirement plans

Govern is not a phase you finish before the others. NIST positions it as the foundation that runs through Map, Measure and Manage, which in turn repeat for each system and each significant change.

Translating each function into operating mechanics

Govern: decide who decides

The single most important Govern outcome is clear accountability. Before you write a policy, answer three questions in writing:

1. Who owns AI risk at the executive level, and to whom do they report?
2. Who can approve a high-risk AI system for production, and who can stop one?
3. How does AI risk connect to your existing enterprise risk, model risk, privacy and security functions?

Most enterprises already have partial answers. Banks have model risk management under SR 11-7. Healthcare systems have privacy and clinical safety committees. Every company has an information security program. Govern should connect to these rather than build a parallel bureaucracy. We usually recommend a small AI risk council with delegated authority, a named AI risk owner, and explicit hand-offs to existing security and privacy reviews.

Other Govern artifacts worth producing early:

• An AI policy short enough to read. State what is permitted, what requires review, and what is prohibited.
• A risk appetite statement for AI, even a qualitative one. It is what lets reviewers say yes quickly to low-risk work.
• Third-party AI requirements: what you require of vendors whose products embed models, including disclosure of model use, data handling and incident notification.
• Role-based training: developers, product owners, reviewers and executives need different things.

See our broader treatment of structures and roles in the enterprise AI governance framework article.

Map: know what you have and why it matters

Map is where AI RMF implementation becomes concrete. Every AI system needs a context record that captures its intended purpose, the people affected, the decisions it informs or makes, the data it uses, the models and vendors in its supply chain, and the known limitations.

The foundation is an AI system inventory. It sounds administrative; it is the hardest part of the first quarter. Shadow AI is real: teams subscribe to SaaS products with embedded models, call model APIs from scripts, and add AI features to existing tools. A useful inventory draws from several sources: procurement and expense data, API gateway and egress logs, cloud billing for model services, code repository scans for SDK imports, and a lightweight self-declaration form.

From the inventory, apply a risk tiering method. Three or four tiers is enough. Tier criteria typically include:

• Does the system make or materially influence decisions about people (credit, employment, care, benefits)?
• Does it act autonomously, for example an agent that can write to systems of record?
• Does it process regulated or sensitive data?
• Is its output shown directly to customers or the public?
• How reversible is harm if it fails?

The tier determines how much Measure and Manage effort the system gets. That proportionality is the difference between a program that scales and one that becomes a queue.

Measure: evidence, not assurances

Measure asks you to assess the risks Map identified using appropriate methods, and to keep tracking them. For AI systems this means evaluation, and evaluation is an engineering discipline, not a document.

A practical Measure capability includes:

• Pre-deployment evaluation suites tied to the risk tier: task accuracy on a representative test set, robustness to input variation, bias analysis where people are affected, and for generative systems, groundedness and harmful-content testing.
• Adversarial testing proportionate to exposure. For LLM applications, test against the OWASP Top 10 for LLM Applications and use MITRE ATLAS to structure threat scenarios. Our LLM security threat model article covers this in depth.
• Production monitoring: drift, quality sampling, refusal and error rates, cost, and user feedback, flowing to named owners with thresholds that trigger review.
• Measurement limits documented: where you cannot measure a risk well, say so. The framework explicitly values acknowledging uncertainty.

Architecturally, Measure goes much faster when evaluation and telemetry are platform services rather than something each team builds. If every model call passes through a gateway that logs prompts, responses, model versions and latency to a governed store, most of the monitoring evidence already exists.

Manage: act on what you learned

Manage converts assessment into decisions. For each identified risk, you treat it (add a control), transfer it (contract, insurance), avoid it (change the design or do not deploy), or accept it with a named approver. Manage also covers incident response and decommissioning.

Two Manage mechanisms deserve early attention:

• A release gate for each tier. Low-tier systems might need only a completed intake and standard platform controls. High-tier systems need documented evaluation results, a risk acceptance signed by an accountable executive, human oversight design, and a rollback plan.
• AI incident handling integrated with your existing incident process. Define what an AI incident is (harmful output reaching a customer, data exposure through a prompt, an agent taking an unintended action), who triages it, and how it feeds back into Map.

Using the AI RMF Playbook without drowning in it

The NIST AI RMF Playbook is a companion resource that, for each subcategory, offers suggested actions, transparency and documentation ideas, and references. It is voluntary and explicitly not a checklist.

Teams get into trouble when they treat the Playbook as a compliance inventory and try to evidence every suggested action for every system. A better approach:

1. Select the subcategories that matter for your highest risk tier and your regulatory exposure.
2. For each, pick one or two Playbook actions that fit how your organization already works.
3. Record which subcategories you have deliberately deferred and why.
4. Revisit the selection when your AI portfolio or regulatory exposure changes.

NIST also describes profiles: a current profile (where you are) and a target profile (where you want to be) for a sector, use case or organization. Writing both, even in a spreadsheet, is the simplest way to turn the framework into a prioritized roadmap and to show leadership progress over time.

The Generative AI Profile (NIST AI 600-1)

In July 2024 NIST published NIST AI 600-1, the Generative AI Profile. It identifies risks that are unique to or exacerbated by generative AI and maps suggested actions to the AI RMF functions. The risks it names include:

• CBRN information or capabilities
• Confabulation (confidently stated false output)
• Dangerous, violent or hateful content
• Data privacy
• Environmental impacts
• Harmful bias and homogenization
• Human-AI configuration (over-reliance, automation bias, anthropomorphization)
• Information integrity
• Information security
• Intellectual property
• Obscene, degrading or abusive content
• Value chain and component integration

For most enterprises, confabulation, data privacy, information security, intellectual property and value chain risk dominate. Value chain risk is often underestimated: when you build on a foundation model API, your risk posture depends on the provider’s training data practices, model update cadence, data retention terms and incident disclosure. Your Map records should capture model provider, model version, and contractual data terms for every generative system, and your platform should pin model versions so an upstream change does not silently alter behavior in production.

A practical first 90 days

This is the sequence we use when standing up a NIST AI RMF program. It assumes an accountable owner with real authority and a few people’s time, not a large team.

Days 1-30: foundation

1. Name the executive owner and form a small AI risk council with a written charter.
2. Draft a short AI policy and an acceptable use standard for generative AI tools.
3. Start the AI system inventory from procurement, cloud billing and gateway or egress data.
4. Define three or four risk tiers with clear criteria.
5. Write the current profile: an honest assessment against the subcategories you selected.

Days 31-60: process

1. Launch a use-case intake form that captures Map context and assigns a provisional tier.
2. Define release gates and required evidence for each tier.
3. Run the process end to end on two or three real systems, including one high-tier system.
4. Agree the minimum evaluation standard for generative systems, using NIST AI 600-1 to choose which risks to test.
5. Add AI-specific terms to vendor due diligence and contract templates.

Days 61-90: evidence and cadence

1. Centralize model access through a gateway or approved endpoints so usage and telemetry are captured by default.
2. Stand up production monitoring for the high-tier systems, with owners and thresholds.
3. Integrate AI incidents into your incident response runbook and run a tabletop exercise.
4. Write the target profile and a 12-month roadmap.
5. Report to leadership: inventory coverage, systems by tier, open risk acceptances, and roadmap.

Common failure modes

• Policy without inventory. A beautiful policy that governs systems nobody has found.
• One gate for everything. Every chatbot experiment gets the same review as a credit model, the queue grows, and teams route around the process.
• Measurement as paperwork. Evaluation plans written but never executed, or executed once and never repeated after model updates.
• No connection to existing functions. A parallel AI risk process that security, privacy and model risk teams do not recognize.
• Ignoring the supply chain. Treating vendor-provided models as someone else’s risk.

How we help

We implement the NIST AI RMF as a working operating model and a set of platform controls, not a binder: inventory, tiering, release gates, evaluation pipelines and monitoring built into your AI architecture. Our AI governance and risk practice leads this work, and we can start with a short assessment of your current profile. Contact us to discuss where you are today.