The NIST AI Risk Management Framework (AI RMF) is a voluntary framework from the US National Institute of Standards and Technology for managing the risks of AI systems across their life cycle. It organizes the work into four functions: Govern, Map, Measure and Manage. Its Generative AI Profile, NIST AI 600-1, applies those functions to large language models and other generative systems. This guide explains both and shows how a bank, insurer or health system turns them into evidence a reviewer can test. It is part of our Agentic AI Governance & Model Risk series.
NIST published the framework in January 2023. It is voluntary, it applies to any sector, and it does not tell you which controls to buy. It describes outcomes an organization should reach and leaves the method to you. NIST has said the framework is being revised, so check the NIST site for the current text before you cite section numbers in a policy.
The framework has two parts. Part 1 explains how to frame AI risk and what makes an AI system trustworthy. Part 2 is the Core: the four functions, broken into categories and subcategories. NIST also publishes a companion Playbook with suggested actions and references for each outcome. NIST says organizations can borrow as many or as few of those suggestions as apply.
Framework Structure and Trustworthy AI Characteristics
There is no NIST AI RMF certification. NIST does not certify organizations against it, and no auditor can issue one. What the framework gives a regulated firm is a common structure. Model risk, security, privacy and compliance teams can map their existing controls to the same outcomes and find the gaps between them.
It does not replace sector rules. A bank still answers to its supervisors and to SR 26-2. A health system still answers to HIPAA. The framework sits underneath as the way to organize the AI evidence those reviews ask for.
Part 1 defines what the framework is trying to protect. NIST lists seven characteristics of a trustworthy AI system:
Valid and reliable Safe Secure and resilient Accountable and transparent Explainable and interpretable Privacy-enhanced Fair, with harmful bias managed
NIST treats valid and reliable as the base: a system that does not work as intended cannot be trustworthy in any other way. Accountable and transparent spans the other six, because each of them depends on someone being able to see and answer for what the system did.
In practice, each characteristic becomes a test question. Is the model accurate on our data? Can it be made to leak customer records? Can we explain a decline to the customer? Who answers for it when it is wrong? A governance program that cannot answer those questions with evidence has not applied the framework, whatever its policy says.
The Four Functions and Profiles
The Core is where the work happens. Govern runs across the other three. Map, Measure and Manage repeat for each AI system through its life.
Function What it asks Categories Evidence it produces in a regulated firm Govern Who owns AI risk, and what are the rules? 6 AI policy, risk tolerance, roles and accountability, training records, third-party AI terms Map What is this system, who does it affect, and what could go wrong? 5 AI inventory entry, intended use, affected parties, data sources, known limitations Measure How risky is it, and how do we know? 4 Test plans and results, metrics, bias and robustness testing, monitoring reports Manage What do we do about the risks we found? 4 Risk acceptance or treatment decisions, runtime controls, incident response, decommissioning records
Each category breaks into numbered subcategories, such as GOVERN 1.1 or MEASURE 2.7. Those numbers are useful as keys. If every control, test and policy in your program carries the subcategory it supports, an auditor can trace any outcome to its evidence in one step.
The functions are not a one-time sequence. A model that passes Measure at launch goes back through Map when its data, its users or its vendor changes. Most findings come from systems that were measured once and never mapped again.
The framework is generic on purpose. Profiles make it specific. NIST describes three kinds.
A use-case profile applies the functions to one setting, such as credit underwriting or claims triage, with that setting's risk tolerance and resources.
A temporal profile compares two states. The current profile describes how you manage AI risk today. The target profile describes the outcomes you need. The gap between them is your plan, ranked by what matters most to you.
A cross-sectoral profile covers risks shared across many settings, such as large language models or cloud services. The Generative AI Profile is the main example.
For most regulated firms, the useful starting point is a current and target profile for each risk tier in the AI inventory. High-risk systems, such as anything that affects credit, coverage, claims or clinical decisions, get the full target profile. Low-risk internal tools get a lighter one.
The Generative AI Profile (NIST AI 600-1)
NIST published the Generative AI Profile in July 2024 as a cross-sectoral profile for generative AI. It names 12 risks that generative AI creates or makes worse, then lists suggested actions for each, organized by the same functions and subcategories as the Core. Each action has an ID that ties it back to the framework. GV-1.1-001 is the first suggested action under GOVERN 1.1.
Risk (NIST name) What it looks like in a bank, insurer or health system CBRN Information or Capabilities Mainly a model-provider concern. Most enterprise deployments record it and rely on the provider's controls. Confabulation An assistant states a wrong fee, policy limit or dosage with full confidence. Dangerous, Violent, or Hateful Content A customer-facing chat produces abusive or threatening text. Data Privacy Customer data or patient records surface in a response, a log or a fine-tuned model. Environmental Impacts Compute and energy use of training and inference. Usually reported, rarely the top risk. Harmful Bias or Homogenization Underwriting or credit summaries that treat groups differently, or many teams relying on one model's judgment. Human-AI Configuration Staff approve an agent's recommendation without real review, or trust it beyond what it was tested for. Information Integrity False or misleading generated content reaches customers, regulators or the public. Information Security Prompt injection in an email or document makes an assistant leak data or call a tool it should not. Intellectual Property Generated text or code reproduces licensed material. Obscene, Degrading, and/or Abusive Content Mostly a concern for open, customer-facing tools and image generation. Value Chain and Component Integration A third-party model, plugin or tool server changes behavior without notice.
The profile also sets out four primary considerations that cut across the risks: governance, content provenance, pre-deployment testing and incident disclosure. For a regulated firm, pre-deployment testing and incident disclosure are where most of the new work sits. Testing a generative system means testing for confabulation, leakage and injection, not only accuracy. Incident disclosure means knowing, before launch, what counts as an AI incident and who has to be told.
Not every risk applies to every deployment. Record each one in the system's profile as applicable or not, with a reason. A reviewer will accept "not applicable, internal summarization tool with no customer output" far more readily than silence.
Applying the Framework to AI Agents
The framework was written before AI agents were common, but its functions fit them well. An agent is a generative system that also acts: it calls APIs, queries databases and uses tools, often through the Model Context Protocol (MCP). That raises the weight of three risks from the profile: Information Security, Human-AI Configuration, and Value Chain and Component Integration.
Map changes the most. An agent's inventory entry has to list what it can do, not just what it is: every tool, API and data source it can reach, and the authority it acts under. If that list does not exist, Measure has nothing to test against.
Measure has to include behavior, not only output. Tests should cover whether the agent can be steered by injected instructions, whether it stays within its tools, and whether it stops when a check fails.
Manage is where agents need controls that run, not documents. Four controls carry most of the weight:
Its own identity for each agent, with least-privilege access that can be revoked. An enforcement point on every call the agent makes. An AI gateway applies policy to calls to models, MCP servers and APIs, and logs each decision. A decision log that records what the agent read, what it did, and under which policy. A stop control that suspends the agent without a code change.
Above the gateway, an agent control plane manages the agents themselves: inventory, identity, lifecycle, evaluation and suspension. Several platforms offer one. On WSO2, it is WSO2 Agent Manager.
Integration with Other Standards and Regulations
The AI RMF rarely stands alone. Regulated firms map it to the requirements they are actually examined on.
For banks, SR 26-2 is the interagency model risk guidance that replaced SR 11-7. It sets the supervisory expectations for model inventory, development, validation and governance. The AI RMF does not change those expectations. It gives a structure for the AI-specific evidence, especially for generative and agentic systems, that a model risk program now has to produce. Our page on AI governance for banks and SR 26-2 covers that mapping.
ISO/IEC 42001 is a management system standard for AI. Unlike the AI RMF, an organization can be certified against it, and that certification comes from an accredited certification body. Firms that want certification often use the AI RMF to design their risk work and ISO/IEC 42001 to run it as a managed, auditable system. NIST's resource center lists crosswalks between the AI RMF and other standards, including one for ISO/IEC 42001 submitted by a third party.
The EU AI Act matters for firms with EU customers, staff or operations. It is law, not a voluntary framework, and its obligations depend on how a system is classified. The AI RMF helps produce the risk evidence the Act asks for, but mapping to the Act is a separate exercise.
Implementation and What Reviewers Examine
Adopting the framework: six steps Name an owner and set risk tolerance. One accountable executive, a written AI policy, and risk tiers that say which systems need the most scrutiny. This is Govern. Build the AI inventory. Every model, generative tool and agent in use, including vendor features switched on inside existing software. Record owner, purpose, data, users, tier and, for agents, the tools they can reach. This is Map. Write the current profile. For each high-risk system, record which subcategories you meet today and the evidence for each. Set the target profile. Decide which outcomes each tier must reach, including the Generative AI Profile actions that apply. The gap becomes the plan. Test before launch and on change. Accuracy, bias, robustness, leakage and injection testing, scaled to the tier, with results stored where an auditor can find them. This is Measure. Put controls in the runtime and plan for incidents. Identity, enforcement, logs and a stop control for agents. A defined AI incident process with named people. This is Manage.
Reviewers rarely ask whether you "follow NIST." They ask for evidence that the outcomes are met. Expect requests like these:
A complete AI inventory, including vendor AI features and agents, with an owner and risk tier for each entry. A written AI policy and risk tolerance, approved by the right committee, with a review date. A current and target profile, or equivalent gap analysis, for high-risk systems. Test results from before launch and after material changes, including generative AI risks such as confabulation, data leakage and prompt injection. Bias and fairness testing for systems that affect credit, coverage, claims, pricing or care. A record of which Generative AI Profile risks apply to each system, and why the others do not. For agents, the list of tools and data each one can reach, its identity, and proof that access is limited to that list. Decision logs that show what an AI system did and under which policy, produced from system records rather than rebuilt after the fact. Third-party AI terms covering data use, model changes and incident notice. An AI incident process, with at least one exercise or real incident worked through and documented. Monitoring in production, with thresholds and a record of what happened when one was crossed.
If you can produce each of these without asking the developers, the program is ready for review.
The framework is easy to read and hard to evidence. Most firms already have pieces of it spread across model risk, security and privacy teams. The work is joining them into one inventory, one set of profiles and controls that run in production. Duczer East provides AI governance consulting for banks, insurers and health systems, from the inventory and gap analysis to the runtime controls that close it.
