Almost every organization I talk to has already adopted the NIST AI Risk Management Framework. What they mean is that someone put a slide in a deck with four boxes on it — GOVERN, MAP, MEASURE, MANAGE — and the steering committee nodded.

That is not adoption. That’s alignment by assertion.

The AI RMF is deliberately outcome-based: it describes what a trustworthy AI program achieves, not how your particular company achieves it. That flexibility is a feature for a standards body and a problem for the person who has to make it real. Operationalizing it means converting each function into four concrete things: a named owner, a required artifact, a workflow that produces the artifact, and evidence that the workflow ran. If a subcategory can’t be reduced to those four, it isn’t operational — it’s aspirational.

Here’s the translation I use.

GOVERN: the function that makes the other three enforceable

GOVERN is cross-cutting for a reason. MAP, MEASURE and MANAGE are activities that happen to an AI system; GOVERN is the authority that decides those activities are mandatory. Skip it and you get a framework that motivated teams follow and busy teams don’t.

Operationally, GOVERN is a short list of durable objects:

  • An AI policy that defines what AI is in scope (including embedded AI in purchased SaaS — the category everyone forgets), what’s prohibited, and who can approve exceptions. My free AI acceptable-use policy template is a reasonable starting point if you’re drafting from zero.
  • An AI governance forum with a written charter: standing membership from Technology, Risk, Legal, Privacy, Procurement and the business, a defined quorum, a decision log, and an escalation path to an existing executive risk committee. Not a new empire — a new agenda item with teeth.
  • A risk tiering standard. This is the single highest-leverage artifact in the whole program, because it’s what stops governance from applying uniformly and therefore applying nowhere. Tier on consequence and autonomy: does the system affect a person’s access to a service, employment, credit or care? Does it act, or only suggest? Is a human meaningfully in the loop, or nominally?
  • An RACI across the functions that touch AI, which deserves its own treatment because it’s where most programs quietly fail.
  • A defined risk appetite. “We will not deploy fully autonomous AI in customer-facing credit decisions” is a governance statement. “We take AI risk seriously” is not.

The test for GOVERN maturity is unglamorous: can someone deploying an AI use case find, in under five minutes, the document that tells them what they’re required to do? If not, everything downstream is optional in practice.

MAP: you cannot govern an inventory you don’t have

MAP establishes context — what the system is, who it affects, what could go wrong, and under what assumptions it was built. In practice, MAP collapses into two mechanisms.

First, an AI system inventory. Every AI governance program I’ve seen stall has stalled here. The inventory is the spine: without it there’s no denominator for any metric, no scope for any audit, and no way to answer the question a regulator or board member will eventually ask, which is simply “how many AI systems do you have, and which ones matter?”

Build it with more fields than feel necessary at intake — owner, vendor, model provider, data categories consumed, whether it processes personal or regulated data, autonomy level, risk tier, human-oversight mechanism, deployment date, review date, retirement criteria. Populating it later is enormously harder than capturing it at intake.

Second, an intake and impact assessment workflow. MAP subcategories are essentially a structured interrogation: what’s the intended purpose, what’s the deployment context, who are the affected stakeholders, what are the known limitations, what happens when it’s wrong? Turn that into a form that routes by risk tier, and you’ve operationalized most of MAP. The AI lifecycle post covers the workflow design in detail.

One caution learned the hard way: make the intake proportionate. A 60-question assessment for a low-risk internal summarization tool teaches the organization to route around governance. Tier the depth of assessment to the tier of the system.

MEASURE: the function everyone underinvests in

MEASURE is where AI governance stops resembling traditional IT risk management. Traditional controls are largely binary — encryption is on or off. AI system behaviour is probabilistic, drifts over time, and degrades in ways that don’t trigger an alert.

The NIST trustworthiness characteristics give you the measurement dimensions: validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and fairness with harmful bias managed. Your job is to decide, per risk tier, which of those get measured, how, how often, and by whom — and to be honest that some are qualitative.

What this looks like in practice:

  • Pre-deployment evaluation against defined acceptance criteria, with results recorded against the inventory entry. Not “we tested it and it seemed fine.”
  • Red-teaming and adversarial testing for higher-tier and generative systems. The NIST Generative AI Profile (AI 600-1) is a genuinely useful risk taxonomy here — confabulation, data leakage, harmful content, information integrity, value-chain risks. I’ve spent enough time red-teaming Copilot deployments for oversharing to say plainly: the failure modes you find in testing are rarely the ones on your risk register beforehand.
  • Post-deployment monitoring for drift, degradation, and volume of human overrides. That last metric is underrated — a spike in humans overriding the model is your earliest signal that something has shifted.
  • A feedback channel for users and affected people to report problematic outputs, with a triage path. If reports go into a mailbox no one owns, you have a channel, not a control.

The uncomfortable truth about MEASURE is that it requires effort proportional to the number of deployed systems, forever. Which is exactly why the risk tiering standard in GOVERN matters so much — it’s what makes MEASURE affordable.

MANAGE: decisions, not documents

MANAGE is about acting on what you measured — prioritizing, treating, monitoring and responding. It’s the function that turns the program from an assessment exercise into a risk management function.

The operational pieces:

  • Risk treatment decisions recorded against the inventory, with the four standard options (mitigate, transfer, avoid, accept) and a named accountable owner for accepted risk. Accepted AI risk should have an expiry date and a named accountable executive, or it isn’t accepted — it’s ignored.
  • AI incident response, integrated into your existing IR process rather than parallel to it. Add AI-specific scenarios: model produced discriminatory output, agent took an unauthorized action, prompt injection succeeded, vendor changed the underlying model without notice. That last one causes more real incidents than most teams expect.
  • Third-party AI risk, because most of your AI risk arrives through procurement rather than through your own model development.
  • Decommissioning, which is the most neglected control in the entire framework. Retired models leave behind API keys, cached embeddings, fine-tuning datasets and downstream dependencies.

Where the framework meets the standard

A question that comes up in every program: if we’re doing NIST AI RMF, do we need ISO/IEC 42001?

They do different jobs. The AI RMF is a risk framework — voluntary, outcome-oriented, excellent for structuring how you think about AI risk. ISO/IEC 42001 is a management system standard — certifiable, auditable, and structured around the same clause architecture as ISO 27001. The RMF tells you what to reason about; 42001 gives you the management system that proves you did it consistently, and a certificate a customer or regulator will recognize.

Most mature programs I’ve worked with end up using both: RMF vocabulary for risk analysis, 42001 structure for the management system. I’ve written about how to build the 42001 side and where it plugs into an existing ISMS.

Start where the evidence is thinnest

If you’re standing this up, resist the urge to work through the framework top to bottom. Do this instead:

  1. Build the inventory. Nothing else works without it.
  2. Write the risk tiering standard, so effort follows consequence.
  3. Stand up intake, so the inventory stops going stale the day you finish it.
  4. Define the minimum evidence set per tier — then hold the line on it.

Everything else is refinement. Four functions, four questions per function: who owns it, what does it produce, what workflow produces it, and where’s the proof? Answer those consistently and you have an operational AI risk management program rather than a framework you’ve aligned to.

If you’re translating the AI RMF into something your risk, legal and audit stakeholders can actually run — and defend — I’m happy to compare notes.