If you asked me to name the single most useful document for building an AI governance program from scratch, I would not name the EU AI Act or ISO/IEC 42001. I would name the NIST AI Risk Management Framework.
This is not because it is the most rigorous or the most comprehensive. The AI Act is more prescriptive, ISO 42001 is more certifiable, and both attract more headlines. But the NIST AI RMF has something the other two do not have to the same degree: it is a working document written for the people who actually have to do the work.
The four functions (Govern, Map, Measure, Manage) are not just labels. They are a decomposition of what AI risk management actually involves, sequenced in a way that makes sense when you are standing in front of a whiteboard trying to figure out how to organise a control framework. The 72 subcategories underneath them are specific enough to translate into work items but flexible enough to adapt to organisational context. The 200+ actions in the Generative AI Profile give you a starting menu you can shape to your systems.
This article is a working guide to the NIST AI RMF as it stands in mid-2026. It covers the four functions, the twelve GenAI-specific risks, the new work on agentic profiles and critical infrastructure, and how the framework maps to the regulatory obligations we covered in batch 1.
The framework in one paragraph
The NIST AI Risk Management Framework version 1.0 was published in January 2023. It is voluntary. It applies to any AI system regardless of sector. It defines four core functions (GOVERN, MAP, MEASURE, MANAGE), 19 categories underneath them, and 72 subcategories underneath those. It is accompanied by a Playbook containing suggested implementation actions, an AI Risk Management Playbook, and the AI Resource Center that indexes related NIST publications. The Generative AI Profile (NIST AI 600-1), published July 2024, extends the framework specifically for GenAI systems and adds 12 risk categories with over 200 suggested actions. In April 2026 NIST released a concept note for a Critical Infrastructure Profile, and in February 2026 the Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative with an Agent Interoperability Profile planned for late 2026.
That is the whole thing at 30,000 feet. Now let us get into the useful part.
GOVERN: culture, structure, accountability
GOVERN is the first function because everything else depends on it. If your organisation does not have the governance structures to make decisions, allocate accountability, and enforce policy, none of the mapping, measuring, or managing will stick.
GOVERN has six categories. GV-1 addresses policies, processes, procedures, and practices. GV-2 addresses accountability structures. GV-3 addresses workforce diversity, equity, inclusion, and accessibility. GV-4 addresses organisational teams committed to a culture that considers and communicates AI risk. GV-5 addresses processes for robust engagement with relevant AI actors. GV-6 addresses policies and processes to address AI risks and benefits from third-party software and data.
Read that list carefully. Three of the six categories are about culture, workforce, and engagement, not about documentation. This is deliberate. NIST built the framework around the observation that most AI risk management failures are cultural before they are technical. An organisation that does not have people with the right skills, the right incentives, and the right authority to challenge decisions will produce paper compliance and operational failure.
What GOVERN looks like in practice.
You need an AI policy, and it needs to be signed off at an executive level. The policy sets out what AI is used for, what it is not used for, and who is accountable for what. It references the risk tiering methodology we covered in article 2 and applies it consistently.
You need clear roles and responsibilities. Someone owns each AI system across its lifecycle. Someone owns the AI risk framework itself. Second-line risk has a defined role in reviewing AI use cases. Internal audit has a role in checking that the framework is operating as intended. Board oversight is formalised.
You need workforce capability. This is where GV-3 and GV-4 land in practice. Do your risk owners understand the systems well enough to challenge the technical teams? Do your technical teams understand risk well enough to translate concerns into design decisions? Do your business units understand governance well enough to route their use cases through the right process? If the answer to any of these is no, GOVERN is broken regardless of what your policies say.
You need third-party governance. GV-6 addresses this directly. Most enterprise AI depends on third-party components: foundation models, tooling, data sources, orchestration frameworks. You need a defensible process for assessing these dependencies and managing their risk.
MAP: understanding the systems and their context
MAP is the function that most organisations underestimate.
MAP has five categories. MP-1 addresses context establishment (mission, goals, business processes). MP-2 addresses categorisation of the AI system. MP-3 addresses AI capabilities, targeted usage, goals, and expected benefits. MP-4 addresses risks and benefits. MP-5 addresses impacts to individuals, groups, communities, organisations, and society.
The idea behind MAP is simple: you cannot manage risk you have not identified, and you cannot identify risk without understanding the specific system in its specific context. A hiring algorithm at a small firm hiring twelve people a year has a different risk profile from a hiring algorithm at a firm hiring twelve thousand people a year, even if the model is identical. Context matters.
What MAP looks like in practice.
You have an inventory of every AI system, whether built or purchased, in production or in development. The inventory captures the specifics of what the system does, who uses it, what data it processes, what decisions it influences, and what its intended purpose is.
For each inventory item, you have a documented risk assessment. This is not a one-page checklist. It walks through the specific ways the system could produce harm to individuals, groups, and the organisation itself, given the specific way it is deployed.
You have identified the AI actors: the people involved in developing, procuring, deploying, and using the system. Each actor has a defined role in the risk management framework. This becomes especially important for third-party AI, where actors from vendor organisations are effectively part of your risk landscape.
You have documented context assumptions. What is the system trained on? What data drift would invalidate its performance? What environmental changes would change its risk profile? Where are the boundaries of its intended use? This documentation is what you refer to when the world changes underneath the system, which it will.
Figure 1: The four core functions
Figure 1 shows the four functions and their relationship. GOVERN sits at the centre, enabling and enabled by the other three. MAP feeds MEASURE, which feeds MANAGE, which loops back to inform GOVERN and MAP. This is not a linear process. It is a continuous cycle that runs throughout the lifecycle of every AI system in your organisation. The functions are not stages you complete once; they are ongoing disciplines you sustain.
MEASURE: quantifying what you have mapped
MEASURE is where the framework gets specific about metrics and analysis.
MEASURE has four categories. MS-1 addresses appropriate methods and metrics. MS-2 addresses AI system evaluation. MS-3 addresses monitoring risks and impact throughout the AI lifecycle. MS-4 addresses feedback about measurement effectiveness.
What MEASURE looks like in practice.
You have selected metrics that actually reflect what you care about. This is harder than it sounds. Accuracy is easy to measure and often misleading; fairness has many mathematical definitions and choosing among them is a policy decision; explainability metrics are still developing. The MEASURE function requires you to think carefully about what you are measuring and why.
You test systems before deployment. Not just for accuracy, but for the specific failure modes you identified in MAP. Adversarial testing, bias testing, robustness testing, and appropriate evaluation of generative outputs where applicable.
You monitor systems in production. Continuous monitoring, not annual review. You watch for performance degradation, data drift, fairness drift, and increases in the specific harm indicators you identified. You have thresholds and alerts. You have incident triggers.
You have a process to reassess measurement effectiveness. Metrics that made sense when the system was deployed may not make sense two years in. MS-4 pushes you to check that your measurements are still telling you what you need to know.
MANAGE: acting on what you measure
MANAGE is where the framework closes the loop.
MANAGE has four categories. MG-1 addresses risk response prioritisation. MG-2 addresses risk mitigation strategies. MG-3 addresses continuous risk management. MG-4 addresses risk documentation and communication.
What MANAGE looks like in practice.
You have prioritised risks. Not all risks get equal treatment. You have a framework (typically borrowing from the risk-tiered philosophy we covered in article 2) for deciding which risks get treated first, which get accepted, which get transferred, and which get avoided.
You have mitigation strategies. For each significant risk, you have a documented plan for how it is being addressed: technical controls, procedural controls, or accepted with governance oversight. The plan is not aspirational; it is operational.
You have incident response readiness. When things go wrong, you have a playbook. Article 17 goes into this in depth.
You communicate risk to the people who need to know it. This closes the loop back to GOVERN. Board reporting, executive briefings, second-line risk engagement, and audit reporting all draw from MANAGE.
The Generative AI Profile
The GenAI Profile, published as NIST AI 600-1 in July 2024, is the framework’s specific response to the risks that generative AI introduces beyond traditional machine learning. It identifies 12 GAI-specific risks and provides over 200 suggested actions mapped across the four core functions.
The 12 risks are: CBRN Information (chemical, biological, radiological, nuclear weapon information); Confabulation (hallucination); Dangerous, Violent, or Hateful Content; Data Privacy; Environmental Impacts; Harmful Bias or Homogenisation; Human-AI Configuration; Information Integrity; Information Security; Intellectual Property; Obscene, Degrading, or Abusive Content; and Value Chain and Component Integration.
Two things about the GenAI Profile are worth highlighting.
First, it is designed to layer on top of the base AI RMF, not to replace it. If you have implemented the core framework, adding the GenAI Profile means extending your existing controls with the specific actions relevant to GenAI systems. You do not build a separate framework for GenAI.
Second, the risks it identifies are not exclusive to GenAI. Data Privacy, Information Security, and Harmful Bias exist for traditional ML too. What the Profile does is call out the ways these risks manifest differently in GenAI contexts and offer specific mitigations. Confabulation and CBRN Information are the risks most specific to GenAI; the others are amplifications of pre-existing risks.
The emerging profiles: Critical Infrastructure and Agents
Two profiles under active development in 2026 are worth watching.
The Critical Infrastructure Profile, released as a concept note on 7 April 2026, will guide critical infrastructure operators (energy, transportation, healthcare, water, financial services) on applying the AI RMF to AI-enabled capabilities in their sectors. The profile is expected to emphasise safety, resilience, and integration with existing sector-specific supervisory frameworks.
The AI Agent Standards Initiative, launched February 2026 through the newly-established Center for AI Standards and Innovation (CAISI), will produce voluntary guidelines for AI agents covering identity and authorisation, security and risk management, and monitoring and logging. An AI Agent Interoperability Profile is planned for Q4 2026. The Cloud Security Alliance has published a proposed Agentic Profile that extends the AI RMF with agent-specific subcategories; while not official NIST output, it indicates the direction of travel.
Both profiles reflect the same principle: the base framework applies to all AI systems, and specific contexts require specific extensions rather than parallel frameworks. This is a sensible design choice and it is the reason the AI RMF has been more durable than many observers expected.
How the AI RMF maps to regulation
For most enterprises the AI RMF is not the regulation; it is the operational layer that supports regulatory compliance across multiple jurisdictions.
For the EU AI Act, the AI RMF maps well to the risk management, data governance, monitoring, and documentation obligations for high-risk systems. It does not substitute for the specific conformity assessment requirements, but implementing the RMF gives you most of the substrate the Act expects.
For ISO/IEC 42001, the AI RMF provides a compatible risk management approach that satisfies the standard’s requirements for AI risk assessment and treatment. Article 11 goes into this in detail.
For the Colorado Consumer Protections for Artificial Intelligence Act, replaced in May 2026 by SB 26-189 (Automated Decision-Making Technology), an earlier safe harbor for NIST or ISO 42001 conformance did not survive the transition. NIST alignment nonetheless remains strong evidence of reasonable care.
For APRA and MAS expectations, the RMF’s functions map directly onto the governance, lifecycle, monitoring, and assurance elements those regulators expect. Neither regulator mandates the RMF, but both accept it as compatible with their expectations.
For US federal procurement, alignment with the AI RMF is increasingly showing up as a requirement. Federal contractors delivering AI capabilities should assume this direction of travel continues.
Figure 2: The RMF-to-obligations map
Figure 2 shows how the four RMF functions map to specific obligations in the EU AI Act, ISO/IEC 42001, APRA prudential expectations, and MAS AI Risk Management Guidelines. The colour of each cell indicates strength of alignment. What the figure makes clear is that a single, well-implemented RMF-based control framework can satisfy substantial portions of all four regimes, with jurisdiction-specific gaps addressed by targeted additions rather than parallel structures.
A practical implementation sequence
If you are starting from scratch, here is the sequence I would recommend.
Start with GOVERN. Establish the policy, the accountability structure, and the operating model. Do not skip this. Every hour spent here pays back tenfold when the operational work begins.
Then MAP your top-tier systems. Do not try to inventory everything at once. Start with the systems that have the highest business value, the highest risk exposure, or the highest regulator attention. Get MAP done well for those, then extend.
Then MEASURE those same systems. Instrument them. Deploy monitoring. Establish baselines. Build the muscle for continuous measurement before you try to scale it.
Then MANAGE. With the measurement in place, risk response becomes tractable. You are no longer guessing at what needs treatment; you have data.
Then extend to the next tier of systems. Repeat MAP, MEASURE, MANAGE. GOVERN continues in parallel.
Then layer the GenAI Profile onto GenAI-specific systems. If your first-tier systems already include GenAI, incorporate the Profile from the start.
Then prepare for the agentic and critical infrastructure profiles as they finalise, if your systems fall in those categories.
Where the framework helps and where it does not
Two honest observations to close on.
The AI RMF is not a compliance framework in the strict sense. It does not produce a certificate. It does not produce a checklist you can hand to an auditor. It is a management framework that produces disciplines, documentation, and controls that will support compliance with many specific regimes. That is a feature, not a bug. Organisations looking for a certificate typically pair the RMF with ISO/IEC 42001 for that reason.
The AI RMF is also not sufficient on its own for high-risk sectors. Financial services entities have specific supervisory expectations. Healthcare has HIPAA and, in the US, FDA obligations for AI-enabled devices. Critical infrastructure has sector-specific security requirements. The RMF gives you the base; sectoral extension does the rest.
The next article covers ISO/IEC 42001, which pairs with the AI RMF for certifiable governance structure. Together they form the two most widely adopted general-purpose AI governance frameworks in the world, and they are designed to be used together rather than as alternatives.