NIST AI Risk Management Framework for Deployment Teams
Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser
This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.
NIST published the AI Risk Management Framework as voluntary guidance for managing risks across the AI lifecycle. It is organised around four functions — GOVERN, MAP, MEASURE and MANAGE — with GOVERN cutting across the other three. It confers no obligation and no certification, which is exactly why it is useful: it is a thinking structure rather than an audit checklist, and it is the framework in this set most readable by an engineer.
NIST AI RMF Voluntary framework — no obligation, no certification
- Version 1.0
- Publisher National Institute of Standards and Technology (U.S. Department of Commerce)
- Last verified 2026-09-13
A voluntary framework NIST published to help organisations manage risks across the AI lifecycle. It is organised around four core functions — GOVERN, MAP, MEASURE and MANAGE — with GOVERN cutting across the other three. NIST also publishes a Generative AI Profile as a companion, applying the core to generative systems specifically.
What this tool does not do
- The framework is voluntary. It creates no obligation and there is no certification against it.
- AI RMF 1.0 is the version this tool maps to, and NIST has signalled a revision. Our mapping records the version it was written against; treat a mapping to a superseded version as stale until re-verified.
- The AI RMF describes outcomes rather than prescribing implementations, so a mapping from a specific technical control to a category is interpretive by nature and is labelled accordingly.
The four functions, applied to one deployment
The AI RMF describes outcomes rather than prescribing implementations, which makes it flexible and makes mapping to it interpretive. Applied to a self-hosted LLM deployment, the four functions ask fairly concrete questions:
GOVERN — the cross-cutting one. Who owns this system? What policy governs whether it may be built at all? Who decides that a residual risk is acceptable, and is that person different from the person who wants to ship? Do the people operating it understand its limitations? This is also where the EU AI Act's Article 4 AI-literacy duty lands most naturally, if you are running both.
MAP — establish context. What is this system for, who does it affect, what does it touch, and what could go wrong for whom? This is where an intended-purpose statement gets written, and where the deployment's data path gets drawn rather than assumed. MAP is the function most often skipped, and skipping it is why teams end up measuring things that do not matter.
MEASURE — analyse, benchmark and track. How do you know the system does what you think? Against what baseline, on what data, how often, and disaggregated across which groups? For an LLM deployment this is uncomfortable, because the honest answer is frequently "we tried it and it seemed fine". MEASURE is the function that turns that into an artefact.
MANAGE — treat and monitor. Which risks are being accepted, mitigated, transferred or avoided, and by whose decision? What happens after deployment — who watches, what triggers a response, and what is the rollback? MANAGE 4 in particular covers post-deployment monitoring and response, which is the same ground as the AI Act's Article 72 and 73.
Why `frameworkVersion` is mandatory in this tool
NIST has signalled that AI RMF 1.0 is under revision. That is ordinary — frameworks are maintained — but it has a specific consequence for a mapping database: a mapping to "NIST AI RMF" with no version attached is a mapping to nothing in particular, and it rots silently. Nobody notices, because the mapping still renders.
So every framework record in this tool carries a mandatory version and a last-verified date, both of which appear on the framework card above and in every exported profile. When the revision lands, the honest response is to re-verify the mappings against the new text and bump the version — not to leave a 1.0 mapping rendering under a 2.0 heading.
NIST also publishes a Generative AI Profile as a companion to the core framework, applying it to generative systems specifically. If your deployment is a generative LLM — which on this site it almost certainly is — that profile is the more directly relevant document, and it is worth reading before the core framework rather than after.
Where AI RMF is stronger than the alternatives
Three things it does better than the certifiable standards, for a team that has to actually build something:
It is free and readable. ISO standards cost money per copy per reader, which in practice means the engineers implementing the controls have not read them. AI RMF is published openly.
It is explicit that context determines risk. The MAP function exists because the framework's authors understood that the same system is differently risky in different settings — the same premise this entire tool is built on.
It does not pretend certainty. There is no pass mark, so there is no incentive to construct one. For an organisation that is not chasing a certificate, that removes a whole category of theatre.
Its corresponding weakness is that voluntary guidance with no assessment attached tends to become a document nobody revisits. If you adopt it, attach it to something with a deadline — a release gate, a quarterly review — or it will be a PDF.
Deployment controls that relate to AI RMF functions
Function and category identifiers with our own descriptions. Because AI RMF describes outcomes rather than prescribing implementations, a mapping from a specific technical control to a category is interpretive by nature, and the confidence field reflects that.
AI risk management process CTL-RISK-001
A documented, iterative process that identifies the risks this AI system poses to health, safety and fundamental rights, estimates them against the intended purpose and reasonably foreseeable misuse, and records the mitigations adopted. Reviewed on a schedule and after material change, not written once.
MAP / MEASURE — Strong · high confidence
Establishing context and identifying risks, then analysing and tracking them
The MAP function establishes context and identifies risks; MEASURE analyses and tracks them. Together they describe the same activity as this control, though AI RMF frames it as outcomes to achieve rather than a document to produce.
Last verified 2026-09-13
Human oversight of AI output CTL-OVERSIGHT-001
A named human role that can understand the system's output and limitations, decide not to use it, and override or reverse it — with the authority and the time to actually do so. Oversight is a staffed procedure, not a checkbox in a UI.
MANAGE 2 / GOVERN 3 — Strong · medium confidence
Risk treatment in deployment, and accountability structures including human roles
AI RMF places human-AI configuration and accountability in GOVERN, with the operational treatment in MANAGE. The framing is outcome-based, so a mapping to specific subcategories is interpretive.
Last verified 2026-09-13
Input and reference data governance CTL-DATA-001
Know what data reaches the model and whether it is fit for the purpose: where it came from, whether it is relevant and sufficiently representative for the people the system is used on, what is excluded, and how errors and gaps are handled. For a retrieval system this covers the corpus, not just the prompt.
MAP 2 / MEASURE 2 — Strong · medium confidence
Categorising the system and its data, and evaluating for representativeness and bias
MAP establishes what the data is and what it represents; MEASURE evaluates it, including for bias. Together they cover this control, framed as outcomes.
Last verified 2026-09-13
Inference and audit logging CTL-LOGGING-001
Record what the system was asked, what it answered, which model version answered, who was involved and when — to a retention period you chose deliberately. For high-risk systems the deployer must keep the automatically generated logs.
MEASURE 3 / MANAGE 4 — Strong · medium confidence
Mechanisms to track risks over time, and post-deployment monitoring
AI RMF treats logging as an input to tracking and monitoring rather than as a control in itself.
Last verified 2026-09-13
Disclosure to the people who use or are affected by the system CTL-TRANSPARENCY-001
Tell people they are interacting with an AI system, at the point of interaction. Where the system is high-risk and makes or assists decisions about a person, inform that person as well.
GOVERN 4 / MAP 5 — Conceptual · medium confidence
Culture of transparency, and understanding impacts on individuals and communities
Conceptual: AI RMF promotes transparency as an organisational property rather than specifying a disclosure to end users.
Last verified 2026-09-13
System and model documentation CTL-DOC-001
A record of what is deployed: the model and its exact version, the quantisation and serving stack, the hardware, the configuration, the known limitations, and the intended purpose. This is the document every other control cites.
MAP 1 / GOVERN 1 — Strong · medium confidence
Establishing and documenting system context, and policies for AI risk management
Documentation of context and intended use is a MAP outcome; the policy requiring it sits in GOVERN.
Last verified 2026-09-13
AI incident detection and response CTL-INCIDENT-001
A route for someone to report that the system did something wrong, a person who owns the response, and a record of what happened. For high-risk systems, serious incidents carry a reporting duty with a deadline.
MANAGE 4 — Strong · high confidence
Post-deployment monitoring, response, recovery and communication plans
MANAGE 4 addresses response and recovery for AI risks after deployment, including communication.
Last verified 2026-09-13
Post-deployment performance monitoring CTL-MONITOR-001
Measure whether the system still does what the documentation says it does. For a system affecting people, measure it across the groups it affects, not only in aggregate.
MEASURE 4 / MANAGE 4 — Strong · high confidence
Gathering feedback on measurement efficacy, and post-deployment monitoring
These are the AI RMF outcomes about knowing whether the system still performs as intended after release.
Last verified 2026-09-13
Named accountability and AI literacy CTL-GOV-001
Someone owns this system by name. The people operating it understand what it can and cannot do. Article 4 of the AI Act makes AI literacy a duty for providers and deployers, and it applied from February 2025 — earlier than most of the rest.
GOVERN 2 / GOVERN 3 — Direct · high confidence
Accountability structures, and diverse teams with defined responsibilities
GOVERN is the cross-cutting function and accountability is its core subject.
Last verified 2026-09-13
Assess a specific deployment
The generic answer is on this page. The specific one depends on what your system is for, who it affects and what it decides — which is what the assessment asks about.
Automated assessment based on the information you provide. Not legal advice, certification or an audit.