NIST AI RMF Explained: How to Govern AI Risk

You must be able to hand an auditor, this afternoon, a dated record showing what was tested before each model went live, who accepted the remaining risk, and what has been checked since the last update. A policy states intent; a record shows what happened.

An analysis of 14 November 2026 of the NIST AI Risk Management Framework and its application across the AI lifecycle argues that the framework offers a structured vocabulary for identifying, assessing and managing AI risk, provided it is read as an evidence discipline rather than a certification or compliance badge. The framework emerged from a consensus-driven process including public consultation, workshops and formal requests for comment. In our assessment, the distinction between a policy and a dated decision trail is where boards, counsel and regulators now focus their scrutiny, and it is the space the framework is most useful for closing.

What is the NIST AI RMF, and what does it actually require?

The NIST AI Risk Management Framework is voluntary United States federal guidance for organisations that design, develop, deploy or use AI. It creates no duties, no certification and no pass mark. Version 1.0 was released on 26 January 2023. Its four functions and seven trustworthy-AI characteristics form a shared vocabulary that a board, a legal team and an engineering group can use in the same conversation.

Two misreadings cause most confusion. The first treats the framework as a certification to be earned; 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 does not discharge them. 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.

How do the four functions work in practice?

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.

Map identifies context, stakeholders, intended use and potential harms. Measure applies quantitative, qualitative or mixed-method assessment to those mapped risks. Manage prioritises responses. Govern establishes policy, accountability and oversight throughout. A healthy cycle leaves a dated record at every step that someone who was not 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.

The quickest way to hold the four in mind is as four questions, each with an output you should be able to show someone. What risks does this system create in this context? How will you measure whether those risks are controlled? What will you do if measurement shows the controls are not working? Who owns each decision and when will it be reviewed?

Which of the seven trustworthy-AI characteristics matter most for your system?

NIST lists validity and reliability; safety; security and resilience; accountability and transparency; explainability and interpretability; privacy enhancement; and fairness with harmful bias managed. These are not a checklist, and NIST does not 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.

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 reasonable method is to 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. A profile of characteristics is not a maturity badge. It is a record of which exposures you decided mattered most for this system, and why.

What does a profile do, and how do you build one that reflects your own risk tolerance?

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. What they are not is equally important: they are not generic maturity levels, and they are not mandatory templates. The framework deliberately declines to prescribe a single profile template.

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.

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 when you deploy a generative-AI system?

NIST AI 600-1, the Generative AI Profile, applies the framework 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. 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.

What should you ask for in writing before deploying any AI system?

Ask for four things in writing. The framework is voluntary and prescribes no universal score, evidence standard or pass-fail threshold. That gap is the practical point: effectiveness depends on thresholds your organisation sets and can defend.

1. Name each AI system and its intended use — document which model each workflow uses, what it is meant to do and the lawful basis for the data it touches.
2. Record the risk assessment for each system — show which risks were mapped, which characteristics were prioritised and why, and who accepted the remaining exposure.
3. Provide the measurement and testing records — document which test sets, metrics and tools were used, what the results showed and when reassessment is due.
4. Show the ownership and escalation chain — name the person accountable for each system, the review cycle and the procedure for reporting performance issues or incidents.

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.

One thing to hold onto: a verification trail supports review and control. It does not establish correctness, and judgement and the final decision stay with the person who signs. When you need to show what was checked, by whom and on which source, a visible trail is the deliverable. Take the highest-risk AI use in your organisation, request those four items for it, and note what is missing. The gap list is the start of your Govern record, and it is more informative than any maturity score you could buy.