Using the NIST AI RMF in practice
The NIST AI Risk Management Framework will not tell you whether your system is safe enough to launch. It sets no thresholds, defines no pass mark and creates no obligations, and any consultant presenting it as a compliance standard has misread it. What it does supply, at no cost, is a well-organised vocabulary for the work and a sequence that stops teams measuring things before they have agreed what the system is for. That is genuinely useful, and it is a smaller claim than the framework usually gets sold with.
What is the NIST AI RMF and what is it not?
It is a voluntary framework published by the US National Institute of Standards and Technology in January 2023, structured around four functions and accompanied by a playbook of suggested actions. It is not a regulation, not certifiable, and not a checklist that produces a compliant system when completed. Its output is a set of documented decisions, not a verdict.
The framework also names seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST treats validity and reliability as the precondition for the rest, which is a more pointed statement than it looks. A model that is not accurate cannot be made trustworthy by adding explanations to its wrong answers.
The reason to use it anyway is that most organisations already have security and privacy processes structured around NIST language, and reusing that structure for AI costs far less than inventing a parallel one. If your risk register, your control library and your assurance calendar already speak this dialect, the AI RMF slots in. If they do not, the framework's main gift is a decent taxonomy and you should feel free to take only that.
What are the four functions?
GOVERN, MAP, MEASURE and MANAGE. GOVERN is cross-cutting and applies throughout rather than being a stage. The other three run roughly in order for any given system: understand the context, evaluate against it, then act on what the evaluation found. Between them the four break into nineteen categories and a much longer list of subcategories, which is where the framework becomes detailed enough to be useful and long enough to be intimidating.
The distribution of effort in real implementations is lopsided. GOVERN and MAP are cheap because they are largely conversations and writing. MEASURE is expensive because it requires test sets, metrics and someone competent to interpret them. MANAGE is where organisations discover that their risk treatments have no owner.
| Function | The question it forces | Typical artefact | Done badly it looks like |
|---|---|---|---|
| GOVERN | Who is accountable, under what policy, with what authority to stop things | Policy, roles, escalation route, supplier and third-party requirements | A published policy with no named owner and no gate in any workflow |
| MAP | What is this system for, in what context, affecting whom, with what alternatives | System context record, stakeholder and impact list, in-scope and out-of-scope uses | A one-line purpose statement copied from the vendor's marketing page |
| MEASURE | How do we know it works, for whom does it work worse, and how would we notice | Test set, metrics with thresholds, subgroup results, monitoring plan | Aggregate accuracy on the training distribution, reported once, never repeated |
| MANAGE | Given what we found, what are we doing about it and who is doing it | Prioritised risk treatments, owners, dates, incident and recovery plan | A risk register where every entry is accepted and none is assigned |
Where should you actually start?
With MAP, on one real system that is already live, rather than with GOVERN across the whole organisation. Writing policy first is the intuitive order and it reliably produces a document nobody can apply, because the authors have not yet met the awkward specifics that policy has to resolve.
Take one system that matters, and complete the context work properly: what decision it participates in, who is affected, what happens when it is wrong in each direction, what the non-AI alternative was and how well that performed. That last question is the one teams skip and the one that most often changes the conclusion, because the honest baseline is frequently an inconsistent human process that nobody ever measured.
The first MAP exercise usually takes a couple of working sessions and produces two side effects worth more than the artefact. It reveals that nobody agrees on what the system is for, and it reveals who actually owns it. Both are findings. Do that on three systems before writing any policy, and the policy will be shorter and enforceable.
Why does MEASURE stall?
Because it asks for evidence, and evidence needs a labelled evaluation set that reflects real use, which almost nobody has when they start. Aggregate accuracy from the vendor is not evidence about your population, and a demo is not a test. Building the evaluation set is the actual project, and it is usually the largest single line of work in an AI RMF implementation.
The second reason is that MEASURE asks for measurement of things that resist it. NIST is direct about this: some trustworthy characteristics have no settled metric, and the framework asks you to document the gap rather than pretend to a number. Explainability, in particular, has plenty of techniques and very little agreement on what a good result looks like, and an implementation that reports a confident score for it is measuring the tool rather than the system.
A workable first pass is to measure three things properly rather than seven things nominally: performance on a held-out set drawn from real production inputs, performance broken down by the subgroups your legal exposure actually concerns, and behaviour on a deliberately adversarial set of inputs you wrote yourself. Anything you cannot measure yet gets recorded as an open gap with a named owner, which is a legitimate output.
How does it fit with the EU AI Act and ISO 42001?
They are complementary and they overlap heavily, which is why crosswalk tables between them are widely published. The AI Act sets the duties and the deadlines. ISO/IEC 42001 sets the auditable management system and gives you something certifiable. The AI RMF supplies the internal method and, usefully, is written at the level of the individual system rather than the organisation.
Working the AI RMF honestly generates most of the evidence a high-risk system needs under the AI Act: the risk management process, the data governance record, the documentation of intended purpose and limitations, the test results, the post-market monitoring plan. It does not generate them in the form the Act specifies, and it covers none of the conformity assessment, registration or CE marking machinery, which have no NIST equivalent because that is not what NIST does.
The practical arrangement, if you are subject to the Act, is to let the Act define which systems get the full treatment and let the AI RMF define what the treatment consists of. Using the AI RMF to decide scope is the error, because it has no notion of a prohibited practice and no thresholds at all.
Does it cover generative AI?
The core framework is technology-neutral and predates the current wave of deployment, which is why NIST published a separate Generative AI Profile in 2024. The profile keeps the four functions and adds risks that generative systems raise distinctly, including confabulation, information integrity, intellectual property, data privacy through memorised training content, information security, harmful bias and homogenisation, and value chain risk where you inherit a model whose provenance you cannot inspect.
Two of those deserve attention from anyone deploying a chat interface. Human-AI configuration covers the way people over-trust fluent output, which is a design problem rather than a model problem and is fixed in the interface. Value chain and component integration covers the fact that you can be several parties removed from whoever trained the weights, so your supplier's answer about training data may be a restatement of an answer they were given.
The concrete step this week, for a generative deployment, is to write twenty adversarial prompts specific to your domain, run them, and record what came back verbatim. That single exercise satisfies more of MEASURE than any amount of vendor documentation, and it usually surfaces at least one behaviour nobody expected.
Common questions
- What are the four functions of the NIST AI Risk Management Framework?
- GOVERN, MAP, MEASURE and MANAGE. GOVERN is cross-cutting and covers accountability, policy and authority. MAP establishes what a system is for, in what context and affecting whom. MEASURE evaluates it against those expectations, including by subgroup. MANAGE prioritises and acts on what the evaluation found. Together they break into nineteen categories and a longer list of subcategories.
- Is the NIST AI RMF mandatory?
- No. It is a voluntary framework published by the US National Institute of Standards and Technology, with no certification, no thresholds and no legal force in itself. Organisations adopt it because it supplies a well-organised method and reuses vocabulary already present in their security and privacy processes. Some contracts and public sector procurements reference it, which makes it binding by agreement rather than by law.
- How does the NIST AI RMF relate to the EU AI Act?
- They answer different questions and are commonly used together. The EU AI Act determines which systems are prohibited, which are high risk and what obligations and deadlines attach. The NIST framework supplies the internal method for meeting obligations of that kind, at the level of an individual system. Working the framework honestly produces much of the evidence a high-risk system needs, though not in the format the Act prescribes, and it covers none of the conformity assessment or registration process.
- Where should an organisation start with the NIST AI RMF?
- With the MAP function on one system that is already live, not with writing policy across the organisation. Establishing what a real system is for, who it affects, what happens when it is wrong and how the previous non-AI process performed usually reveals that nobody agrees on the purpose and nobody clearly owns it. Doing that on two or three systems first makes any subsequent policy shorter and enforceable.
- What is the NIST Generative AI Profile?
- A companion publication that applies the four core functions to risks that generative systems raise distinctly, including confabulation, information integrity, intellectual property, privacy leakage from memorised training data, information security, harmful bias and homogenisation, over-trust in fluent output, and value chain risk where the deploying organisation is several parties removed from whoever trained the model.
- What are the seven characteristics of trustworthy AI in the NIST framework?
- Valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST treats validity and reliability as the precondition for the others, on the reasoning that a system which is not accurate cannot be made trustworthy by adding explanation or transparency to its incorrect outputs.
