The NIST AI Risk Management Framework has become the default reference for AI governance in the United States and a common one elsewhere. Procurement questionnaires cite it, board papers cite it, and vendor decks claim alignment with it. Far fewer organisations can show how they meet it.
Where the framework stands
| Date | Document | What it does |
|---|---|---|
| Jan 2023 | AI RMF 1.0 (NIST AI 100-1) | Four functions (Govern, Map, Measure, Manage), 19 categories, 72 subcategories |
| Feb 2024 | Cybersecurity Framework 2.0 | Adds a Govern function, which makes CSF and the AI RMF easier to run together |
| Jul 2024 | Generative AI Profile (NIST AI 600-1) | Twelve risks specific to generative AI, from confabulation to value-chain integration, with suggested actions |
| Late 2025 | Preliminary draft Cyber AI Profile | Ties CSF 2.0 to the AI RMF for securing AI and using AI in security operations |
| Apr 2026 | Concept note: critical infrastructure profile | Will guide operators on risk practices when they adopt AI-enabled capabilities |
| 2026 | AI RMF 1.0 revision | Underway as part of the White House AI Action Plan |
Two facts shape everything else. The framework is voluntary, and NIST offers no certification against it. There is no badge to earn. If a customer, auditor or regulator asks whether you follow it, the only answer is evidence.
Three ways adoption breaks
1. "Aligned with NIST" with no trace
The most common pattern I see is a policy that says the organisation follows the AI RMF, with nothing connecting a subcategory to an owner or a piece of evidence. Ask "who owns MAP 4.1 for this system, and where is the assessment?" and the trail stops.
2. A profile built once
Teams build a current-state profile for an audit or a customer questionnaire, then leave it. Six months later the model has been swapped, a new vendor is in the stack, and the profile describes a system that no longer exists. Profiles need a trigger: any change to model, data source, vendor or use case reopens the relevant lines.
3. Three registers for one control
Privacy keeps a register, security keeps another, and the new AI governance function starts a third. Each describes the same control in different words. Evidence is collected three times, and gaps hide in the seams.
What I recommend
- Cite the version. Write "AI RMF 1.0 (NIST AI 100-1)" in your documents. That statement stays accurate when the revision lands, and you can map forward deliberately.
- Map each control once. Keep one control register and crosswalk it to ISO/IEC 42001 Annex A and the EU AI Act articles that apply to you. One piece of evidence then serves all three.
- Use the GenAI profile as a test list. The twelve risks in AI 600-1 make a practical checklist for pre-launch testing of any generative feature.
- Start with the inventory. GOVERN 1.6 asks for an inventory of AI systems. Nothing else can be scoped without one, and most first inventories turn up tools nobody approved.
A short crosswalk excerpt
| AI RMF | What has to exist | ISO/IEC 42001 | EU AI Act |
|---|---|---|---|
MAP 4.1 | Legal and technical risk of third-party models, data and APIs is assessed and documented | A.10 | Art. 25 |
MANAGE 2.4 | A named person can disengage or roll back the system, and has rehearsed it | A.9 | Art. 14 |
MANAGE 4.3 | Incidents reach users, vendors and regulators on a defined clock | A.8.4 | Art. 73 |
A full crosswalk for one organisation usually runs to a few hundred lines once it is scoped to the systems actually in use. The useful part is the evidence column, which is different for every company.