NIST AI RMF Explained: How to Govern AI Risk

The question worth asking isn't whether your organisation has an AI policy. Most can produce one. It's whether you could hand an auditor, this afternoon, the dated record showing what was tested before a model went live, who accepted the remaining risk, and what has been checked again since the last update. A policy states intent. A record shows what happened. The distance between those two things is where boards, counsel and regulators now spend their time, and it's the space the NIST AI RMF is most useful for closing, provided it's read as an evidence discipline rather than a badge. What follows treats each function as a place to leave a dated trace, and each decision as one a named person owns.

What Is the NIST AI RMF and Why Does It Matter?

The NIST AI Risk Management Framework, or NIST AI RMF, is voluntary United States federal guidance for organisations that design, develop, deploy or use AI. It gives them a structured way to identify, assess and manage AI risk across the lifecycle, so trustworthy systems can be built and demonstrated rather than merely asserted. Version 1.0 was released on January 26, 2023, and it sits apart from binding law: it creates no duties, no certification and no pass mark. Its four functions and its seven trustworthy-AI characteristics form a shared vocabulary that a board, a legal team and an engineering group can use in the same conversation.

Congress directed NIST to collaborate with the private and public sectors to develop a voluntary AI Risk Management Framework. NIST then developed it through a consensus-driven, open, transparent and collaborative process, including a Request for Information, draft versions for public comment and workshops. The NIST AI RMF 1.0 launch record describes a process built on a formal Request for Information, several draft versions released for public comment and a series of workshops. That history matters more than it might appear. A document shaped through public consultation reads as a consensus governance reference, not as a proprietary control checklist sold by one vendor.

NIST describes the framework as voluntary, rights-preserving, non-sector-specific and use-case agnostic. In practice that means the same document is meant to serve a hospital, a bank, a public agency and a software vendor, at any size, in any national market. It is not a rulebook for one industry, and it is not a substitute for the rules that do bind you.

Think of it as a pre-flight checklist rather than an airworthiness certificate. The list tells the crew what to inspect and record before take-off. The captain still decides whether the aircraft flies, and no checklist promises the flight is safe.

Two misreadings cause most of the confusion. The first treats the AI RMF as a certification to be earned. It isn't one; NIST issues no certificate and recognises no accredited body for it. The second treats it as a legal checklist that, once complete, settles compliance. Binding obligations come from legislation, such as the EU AI Act for deployments in the EU, and from sector regulators in whichever jurisdiction applies to you. The framework can help you organise the evidence those duties demand; it doesn't discharge them.

A useful test: can you name the decision the framework would inform in your organisation this quarter? If the honest answer is a general commitment to responsible AI, the framework hasn't been applied yet, only endorsed.

How Do the Four Functions Work Together Across the AI Lifecycle?

The four functions work as a loop, not as four sequential projects. Govern runs across the whole lifecycle and sets the rules, roles and oversight that make the other three repeatable. Map, Measure and Manage then turn in a cycle for each system, and the cycle restarts whenever the model, the prompts, the data or the context of use changes. NIST's AI Risk Management Framework pages describe exactly that structure: Map identifies context, stakeholders, intended use and potential harms; Measure applies quantitative, qualitative or mixed-method assessment to those mapped risks; Manage prioritises responses; and Govern establishes policy, accountability and oversight throughout.

The quickest way to hold the four in mind is as four questions, each with an output you should be able to show someone.

• Govern — Question it answers: Who is accountable, and which rules apply?; Example output: Policies, named roles, oversight routine
• Map — Question it answers: What is the system for, and who could be harmed?; Example output: Context statement, stakeholder list, harm register
• Measure — Question it answers: How serious is the risk, and how do we know?; Example output: Test results, chosen metrics, documented uncertainty
• Manage — Question it answers: What do we do about it, and in what order?; Example output: Prioritised responses, owners, review dates

The diagram below shows the same structure as a continuous cycle, with Govern sitting above the three functions that repeat.

Five steps for one system, and the slip that usually happens

1. Govern first, and name a person. Before design begins, record the accountable owner, the risk tolerance that owner is working to, and the rule that decides whether the system may be approved. The usual slip is leaving approval to informal agreement between a product lead and an engineer, so nobody can say later who authorised deployment.
2. Map before you measure. Write down intended use, deployment context, who is affected and what could go wrong. Skipping Map is the most expensive shortcut in the framework, because a risk that was never named never gets measured, and a dashboard can look thorough while missing the harm that matters.
3. Measure from the largest risk downwards. NIST asks for methods and metrics to be selected starting with the most significant risks, and for any risk or trustworthiness property that can't be measured to be documented rather than dropped. The slip is treating Measure as a single pre-launch test. It's a running activity, and a recorded gap is worth more than a metric invented to fill it.
4. Manage means choosing, not listing. Every identified risk needs a decision (treat, accept, transfer or stop), an owner, a date, and a note of the residual risk that remains after the control. A register that records only mitigations, never the residue, tells a board nothing about what it is still carrying.
5. Reassess on a schedule. NIST recommends reviewing whether metrics remain suitable and controls remain effective, incorporating error reports and the potential impact on affected communities. Put the review date in the calendar at the same moment as the approval, or it won't happen.

NIST's companion Playbook, whose first complete version was announced on March 30, 2023, translates these functions into suggested actions, references and implementation guidance. The AI RMF Playbook stays voluntary and adaptable: an organisation may adopt all of the suggestions, some of them, or none, according to its sector, use case and risk profile.

What a healthy cycle looks like: every step leaves a dated record that someone who wasn't in the room can follow. A reviewer should be able to trace a named risk from Map, to the method used in Measure, to the decision recorded in Manage, and to the person who signed it off.

Which Trustworthy AI Characteristics Should You Weigh?

Seven, and none of them wins by default. NIST AI RMF 1.0 lists validity and reliability; safety; security and resilience; accountability and transparency; explainability and interpretability; privacy enhancement; and fairness with harmful bias managed, as set out in the NIST AI RMF 1.0 publication.

• Validity and reliability: the system does what it claims, consistently.
• Safety: it doesn't cause physical or psychological harm in its intended context.
• Security and resilience: it resists attack and degrades predictably when it fails.
• Accountability and transparency: a named party answers for outcomes, and decisions can be examined.
• Explainability and interpretability: the people affected can understand enough to contest a result.
• Privacy enhancement: personal data is minimised and protected through design.
• Fairness with harmful bias managed: disparities are measured and treated, not assumed away.

These are not a checklist, and NIST doesn't claim one outweighs the others. Trustworthy AI requires balancing them against the context of use, which means your organisation has to make a context-specific decision and write down what it accepted.

Two use cases, two different balances

In our analysis, a tool that drafts client correspondence weighs privacy and accountability most heavily. The plausible harm is a misplaced identifier or an unsupported statement that reaches a client under the firm's name, so the controls that matter are pseudonymisation, review before sending and a clear owner for what goes out. A tool that triages patient messages weighs safety and explainability first, because a missed escalation harms a person and a clinician who can't see why the system ranked a message low cannot safely override it.

The common error is treating a passed accuracy test as evidence of fairness or privacy. It establishes neither. A model can score well on a benchmark and still leak identifiers from a prompt, or treat one group of applicants differently from another.

A profile of characteristics isn't a maturity badge. It's a record of which exposures you decided mattered most for this system, and why.

A reasonable method: pick the two or three characteristics most exposed in your use case, state the reason in one sentence each, and record who accepted the trade-off and when. Independent multi-model review can support validity checks as one piece of evidence. It doesn't establish correctness. Where patient-facing or legally consequential outputs are involved, the official health-data and medical-device rules of your jurisdiction govern, not this framework.

How Do NIST AI RMF Profiles Fit Your Setting?

A profile is the framework applied to your setting. NIST defines profiles as implementations of the framework's functions, categories and subcategories for a specific setting or application, built from the user's requirements, risk tolerance and available resources, as described in the NIST AI RMF resources. What they are not is equally important: they aren't generic maturity levels, and they aren't mandatory templates. The framework deliberately declines to prescribe a single profile template.

• Application — Example named by NIST: Hiring; What the profile adapts: Functions and subcategories for AI used in hiring decisions
• Application — Example named by NIST: Fair housing; What the profile adapts: Functions and subcategories for AI used in housing decisions
• Technology — Example named by NIST: Large language models; What the profile adapts: Controls for LLM use and its distinct risks
• Technology — Example named by NIST: Cloud services; What the profile adapts: Controls for AI delivered through cloud services
• Cross-sector activity — Example named by NIST: AI acquisition; What the profile adapts: Controls for buying or procuring AI systems

Choosing the profile closest to the decision

Start with the profile nearest the decision in front of you, then add controls where your own risk tolerance requires more than the profile suggests. A recruitment team, for example, tailors the hiring profile to its own process: it records which subcategories it adopts, which it defers and why, names the owner for each, and sets review dates before the next hiring cycle rather than after it.

That deferral record matters. A profile that lists only what you adopted looks complete and hides the judgement calls. A profile that also lists what you set aside, with a reason and a compensating control, is the version that survives scrutiny.

Teams that run this well usually keep one working document per system, and the practical AI risk register setup we publish covers the maintenance routine that keeps that document current instead of ceremonial.

The question to answer is concrete: which profile matches the system in your organisation, and whose risk tolerance does it reflect? If the answer is "the vendor's", the profile reflects someone else's appetite.

What Changes for Generative AI Under NIST AI 600-1?

What changes when an AI system generates text, images, code or audio? NIST AI 600-1, the Generative AI Profile, applies the AI RMF to risks that are new or intensified by generative AI. It gives organisations a way to consider those risks within the framework's existing approach.

The level of review should reflect the potential consequences. A drafting assistant used for internal meeting notes may need lighter checks than a model supporting legal, medical, compliance or public-sector work. Higher-impact uses call for stronger testing, independent assessment, source validation and clear escalation procedures.

For the Measure function, keep records of the test sets, metrics and tools used in testing, evaluation, verification and validation (TEVV). Reassess them regularly to see whether they remain suitable. The profile also recommends assigning roles and setting policies and procedures for communicating generative-AI incidents and performance to downstream stakeholders and potentially affected people.

Treat each record as a dated link in the decision trail: it should help a board or counsel see what was tested, what the results showed and who acted on them. A test result does not, by itself, establish that an output is correct.

The eight fields worth keeping for each high-impact output

1. Raw model outputs. Preserve the text as generated, before human or automated edits.
2. Prompts or claims tested. Record what was asked and which factual claims were challenged.
3. Source provenance. Identify the references checked and what they said.
4. Evaluator identity or model role. Note who or what performed each check and its role.
5. Challenge results. Record where an independent reviewer disagreed and why.
6. Correction history. Show what changed between the initial output and the final version.
7. Privacy findings. Record whether personal data appeared inappropriately and how it was handled.
8. Final disposition. State what was accepted, who accepted it and what uncertainty remained.

Together, these fields can support reproducibility, incident investigation and review of unresolved uncertainty. They do not establish accuracy. Its multi-model verification approach is designed to leave reviewer disagreements visible in the evidence trail.

Records show what happened; measurement choices show how an organisation judges whether its controls work. The four measures for validating generative AI offer a way to examine that measurement design.

For a short walkthrough of generative-AI risk control in practice, see the session below.

Can a reviewer trace who checked a claim, which sources informed the check and what uncertainty remained? If the record cannot answer those questions, it is not yet a useful evidence trail.

Which Governance Evidence Should You Ask For Before Relying on AI?

Ask for four things, and ask for them in writing. The AI RMF is voluntary and prescribes no universal score, evidence standard or pass/fail threshold, and NIST's own framework FAQs point to the roadmap, which lists measuring the effectiveness of the AI RMF as an unresolved area needing methods to capture and evaluate how organisations use it. That gap is the practical point: effectiveness depends on thresholds your organisation sets and can defend.

1. A contract register. For AI, the evidence line is a register listing each AI contract, its owner, the rights exchanged, available logs and access, gaps, and a remediation deadline. Without it, a review can't establish which systems were even in scope.
2. An agent register. For AI agents, the evidence line is a register listing each agent's identity, owner, permitted scope, approver and the location of its logs. An agent acting with unclear permissions and unlocatable logs is a governance blind spot, not a productivity feature.
3. Verification records for high-impact outputs. The eight fields above can help a reviewer reconstruct the documented decision trail and identify what remains uncertain; they may not eliminate the need for interviews.
4. A written threshold for each key risk. Which result triggers escalation, who decides, and when the control is re-tested. NIST asks for measurement to start with the most significant risks; your threshold document is where that priority becomes operational rather than aspirational.

The first two requests carry most of the weight, because without them nobody can say which systems the other two cover. Teams that skip registers tend to discover the omission during an incident, when reconstructing the estate is slowest and most expensive.

If this is your first pass and the request list feels heavy, the AI readiness guide for growth-stage CEOs from Stimulead frames similar due-diligence questions in a sequence that smaller teams can work through without a dedicated function. For the documentation side, our audit evidence examples and documentation guide shows what a defensible record looks like when it reaches a reviewer.

One thing to hold onto: a verification trail supports review and control. It doesn't establish correctness, and judgement and the final decision stay with the person who signs.

The recommendation is narrow enough to act on this quarter. Take the highest-risk AI use in your organisation, request those four items for it, and note what's missing. The gap list is the start of your Govern record, and it's more informative than any maturity score you could buy.

When you need to show what was checked, by whom and on which source, a visible trail is the deliverable.

More articles on this subject are collected in the AI governance overview.

Sources: Key factual claims about the framework's release date, legal origin, voluntary status and four-function structure are attributed to NIST's AI RMF 1.0 launch record and its AI Risk Management Framework pages.