The NIST AI Risk Management Framework is a widely referenced structure for governing AI, and an easy one to misuse. Organizations adopt it by mapping their policies to its categories, file the mapping, and carry on deciding things the way they did before.
Our position: the framework is only useful when it changes who decides and what gets recorded. In practice that comes down to three things you can point to. A named owner for each AI system. A tiered review path that decides rather than defers. And a decision log a board or a regulator could read.
What the framework is, and is not
NIST released AI RMF 1.0 on 26 January 2023 as NIST AI 100-1. It is voluntary. Its core is organized into four functions: Govern, Map, Measure and Manage. Govern is cross-cutting: it sets the culture, roles and policies that the other three depend on. NIST publishes a companion AI RMF Playbook with suggested actions, and on 26 July 2024 released the Generative AI Profile, NIST AI 600-1, which applies the framework to risks specific to generative AI.
NIST also states on its framework page that AI RMF 1.0 is being revised. Build on the four functions, which are the stable part, and check the NIST page for changes before you cite specific categories.
What the framework is not: a checklist, a certification or a statement of what any law requires. It describes outcomes. It does not tell you who in your organization owns them. That part is yours.
The usual failure: a crosswalk nobody uses
The common pattern looks thorough. A team maps existing policies to every category and subcategory, marks most of them "partially addressed", and produces a spreadsheet. Six months later a business unit wants to deploy an assistant, and nobody can say who approves it, against what criteria, or where the decision is written down.
The crosswalk answered "do our documents mention this?" The business needed "who decides, and how fast?" Those are different questions, and only the second one reduces risk.
Govern: who owns the outcome
Start with roles, not documents. Every AI system needs an accountable owner who is a business leader, not the team that built it. Around that owner, a small set of roles is usually enough:
| Role | What they own |
|---|---|
| Accountable owner | The outcome, the accepted risks and the decision to keep running it |
| Builder or vendor manager | How the system works, its testing and its changes |
| Reviewers | Security, privacy and legal review at the depth the tier requires |
| Decision forum | Approval for higher-risk systems, with authority to attach conditions |
| Oversight | Executive or board visibility of the portfolio and its exceptions |
Write these into decision rights, not an org chart. When the owner changes jobs, the role passes to a successor by name. A governance model that does not survive a reorganization was a list of people, not a model.
Map and Measure: the evidence to keep
Map is about context: what the system is for, who it affects, what data it touches and what could go wrong. Measure is about evidence that it behaves as intended. Both produce records. Keep the ones someone will actually ask for:
- An inventory entry: purpose, owner, users, data sources, vendor and model, and risk tier.
- The intended use and its limits: what the system must not be used for, in plain words.
- Test results: what was evaluated, against which acceptance criteria, and when.
- Accepted risks: named, with the conditions attached to approval.
- Monitoring signals: what is watched in production, and the threshold that triggers re-review.
The test of the evidence is simple. If the system produced a harmful result tomorrow, could you show what leadership knew, what was considered, who owned it and what supported the decision? If not, the gap is in the record, and it is cheaper to close now.
Manage: a review path, day to day
A single heavy review for everything becomes the backlog. Teams route around it, and the systems that most needed scrutiny arrive unreviewed. Tiered review fixes that. Most AI use is low risk and should take a fast lane with a short record. Depth goes where a use case touches sensitive data, affects people's rights or opportunities, or acts on its own.
| Tier | Typical trigger | Review |
|---|---|---|
| Fast lane | Approved tool, internal use, no sensitive data | Short intake, owner sign-off, logged |
| Standard review | Customer-facing output or confidential data | Security and privacy review, test results on file |
| Full review | Decisions about people, regulated data, or autonomous action | Decision forum, conditions and a re-review date |
Day to day, a request arrives through one intake form. The tier is set by the answers, not by negotiation. Reviewers work to stated criteria. The decision, its evidence and its conditions go into the decision log, along with what would reopen it: a model change, a new data source, a drop in a monitored measure. Then the log is reported upward on a fixed cadence, so oversight sees the portfolio rather than individual approvals.
A useful test of any review path: run three past requests through it. If it cannot decide them in days, with a record, it will not decide the next one either.
Where ISO/IEC 42001 fits
ISO/IEC 42001:2023, published in December 2023, specifies requirements for an AI management system. Where the NIST framework describes outcomes, ISO/IEC 42001 describes the management system around them: policy, objectives, roles, internal audit and continual improvement, in the shape auditors recognize from other ISO management standards. Many organizations use NIST for structure and ISO/IEC 42001 when customers or partners expect an auditable system. The owners, review path and decision log above serve both.
Neither framework, on its own, settles what a particular law requires of you. For two sets of rules, see our guides to the EU AI Act and Illinois AI law.
Where to start
- Build an inventory of the AI in use, sanctioned or not, with an owner for each entry.
- Define three risk tiers and the criteria that place a system in each.
- Name the reviewers and the decision forum, with authority to attach conditions.
- Open a decision log and record every approval, condition and re-review trigger.
- Prove the path on one real use case before writing more policy.
- Report the log to executive oversight on a fixed cadence.
This article describes how we apply the NIST AI RMF and ISO/IEC 42001. It is not legal advice, and using either framework does not by itself establish compliance with any law.
