The NIST AI Risk Management Framework is voluntary guidance from the American National Institute of Standards and Technology on how to think about the risks of an AI system, published in January 2023 after a mandate from Congress and two years of public drafts. It carries no certification and no penalty, and its value to a product team is that it is the least bureaucratic structure available for asking whether the right things have been thought about. At least one American state law now offers a defence to organisations that follow it, which is the first sign of a voluntary document acquiring teeth.
The sections below take the four functions, the seven characteristics the framework says a trustworthy system has, why the framework suits a product team, the generative AI profile, where the framework sits beside the law and the standard, how it is used without a programme, and end with a fifteen minute naming exercise.
The four functions
Govern is the one that runs through the others. Who is accountable, what the organisation's risk tolerance is, what policies apply, how decisions are recorded and how people are trained. Without it the other three produce artefacts nobody owns.
Map establishes context. What the system is for, who it affects, what could go wrong, and what assumptions the design rests on. This is where the harms worth worrying about are decided, and doing it badly makes everything downstream measure the wrong things.
Measure analyses and tracks what Map identified. Evaluation against the team's own cases, performance broken down by subgroup, red teaming, and the metrics that will be watched after launch. The framework is explicit that qualitative measures count where numbers are not available, which matters because most important harms have no metric.
Manage acts on it. Prioritise which risks to treat, decide what to accept and record why, put the controls in, and maintain them as the system and the world change.
The seven characteristics of a trustworthy system
The functions are the process, and the framework also says what the process is aiming at. A trustworthy system is valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy enhanced, and fair with harmful bias managed. The list is useful because it is a checklist a team can run a feature against in ten minutes, and because the framework is candid that the seven trade against one another, so that a more explainable model may be a less accurate one and the balance is a decision somebody has to own.
Why the framework suits a product team
It asks the questions a product decision needs, where a compliance function would ask different ones, and it is written in language a person can act on.
Map is a discovery exercise, Measure is evaluation, and Manage is a prioritisation call with a rationale written beside it. Those are all things product people already do, and the framework mostly insists they get done deliberately and never in passing.
The generative AI profile
In July 2024 NIST published a companion covering risks specific to generative systems, including confabulation, dangerous content, data privacy, information integrity, harmful bias and the security surface, with several hundred suggested actions mapped to the four functions. It is the more useful document for a team shipping a feature built on a foundation model, because the core framework is written for AI generally.
Where the framework sits beside the law and the standard
The EU AI Act is law and says what an organisation must do. ISO/IEC 42001, published in December 2023, is a standard an organisation can be certified against and says how to run a management system. NIST is voluntary guidance and says how to think about the risk.
They overlap heavily in substance. A team that has genuinely done Map, Measure and Manage has most of the material the Act's technical documentation asks for, which is the practical argument for using it even where nothing obliges the team to.
Using the framework without a programme
The small version is a page per feature. What it does and who it affects, what could go wrong and how badly, what was measured and what it showed, what the team decided to accept and why, and who owns it.
That page is Map, Measure, Manage and Govern at a scale a team can sustain, and it is worth more than a framework adopted in name and abandoned in practice.
Practise this
The exercise needs one feature of the team's own, fifteen minutes, and the names of real people, with team names left out.
Put the four functions down the page and write a single human name against each, along with the artefact that person would produce if asked to show the work, and when it was last touched. A team name is no answer and neither is a name attached to nothing, so a row is left blank sooner than filled charitably.
Feature ..........................................
Function Who, by name What they would show you Last touched
Govern ............ ......................... ..........
Map ............ ......................... ..........
Measure ............ ......................... ..........
Manage ............ ......................... ..........
Govern risk tolerance, policy, who decides, who is trained
Map what it is for, who it affects, what could go wrong
Measure evaluation, subgroup performance, red teaming, live metrics
Manage what we treat, what we accept and why, the controls
One row is usually empty, and it is usually Govern. Map tends to belong to whoever wrote the brief and Measure to whoever built the evaluation set, while the person who decides how much risk is acceptable and puts a name to that decision often turns out to be nobody in particular, or everybody, which behaves the same way on the day something goes wrong. Read the last column too, because a name attached to a document nobody has opened in a year is an owner in title only.
Naming four people for one feature shows which function the organisation is running on goodwill, and that is the one that gives way under pressure.