The NIST AI Risk Management Framework: An Operational Breakdown

TL;DR

The NIST AI Risk Management Framework organises AI governance across four interconnected functions — GOVERN, MAP, MEASURE, MANAGE. What the official documentation presents as a reference architecture, this breakdown translates into a sequenced operational model for real deployment teams.

What the Framework Actually Demands

The NIST AI RMF is not a checklist. It is a continuous, living process — one that must be embedded in how your organisation builds, deploys, and monitors AI systems, not bolted on after the fact.

01 / GOVERN — Establish the Accountability Layer

Before any AI system touches a production environment, an accountability structure must exist. GOVERN is the function that creates the organisational conditions for everything else to work.

What this means operationally:

• Assign a named AI Risk Owner for each deployed system — not a committee, a person
• Publish an internal AI use policy that distinguishes permitted, restricted, and prohibited use cases
• Establish a cross-functional AI review board with authority to pause or terminate deployments
• Create documentation standards: every deployed AI system must have a maintained System Card

The most common failure here is treating governance as a legal/compliance task. It is an operational task. The teams building and running AI systems are the primary governance actors.

02 / MAP — Know What You Are Deploying

MAP requires organisations to understand the full context of an AI system before deployment: what it does, who it affects, and what can go wrong.

Practical MAP outputs:

• Use-case definition: what specific decision or output does this system produce?
• Affected-population mapping: which people does this system’s outputs touch, and in what way?
• Failure mode inventory: document the five most plausible ways this system fails, and the downstream impact of each
• Data lineage record: where did the training data come from, and what biases might it carry?

MAP is where most organisations fall short. Rushed deployments skip structured pre-deployment analysis. The result is discovered harms rather than prevented ones.

03 / MEASURE — Quantify Risk, Continuously

MEASURE establishes the metrics, evaluation methods, and monitoring cadences that allow an organisation to know — not assume — that an AI system is performing safely and as intended.

Core MEASURE requirements:

• Baseline performance metrics established pre-deployment, not post
• Bias and fairness evaluations across the demographic subgroups relevant to the use case
• Ongoing monitoring dashboards with defined alert thresholds
• Human-in-the-loop review rates: what proportion of AI outputs are reviewed by humans, and how is that proportion decided?

The key insight from NIST: measurement is not a one-time evaluation. It is a continuous operational function.

04 / MANAGE — Respond and Remediate

MANAGE is the incident response and continuous improvement function. It assumes things will go wrong and establishes the mechanisms to respond.

MANAGE infrastructure:

• Defined escalation paths for AI-related incidents — from detection to response to resolution
• Rollback and override capabilities for every production AI system
• Post-incident review processes that feed learning back into GOVERN and MAP
• Regular re-evaluation cadences (quarterly minimum for high-risk systems)

MANAGE closes the loop. Governance without response capability is a liability, not a protection.

TEVV-Athlon: the draft that operationalises MEASURE

Added 10 August 2026. This section describes an initial public draft, not final NIST guidance.

On 7 August 2026 NIST announced NIST AI 200-2, TEVV-Athlon: A Framework for Evaluating AI Systems, as an initial public draft. Comments are open for 60 days and close 6 October 2026.

The single most important fact about it is the one most coverage omits. TEVV-Athlon is not a competing evaluation framework sitting alongside the AI RMF. The draft states its position inside it directly:

The TEVV-Athlon is an abstract approach that implements the Measure function of the NIST AI RMF.

If you already run an AI RMF programme, this is not a new obligation. It is the missing operational detail for the function this page describes as the hardest to do properly.

Get the two terms the right way round. The draft distinguishes them explicitly: the TEVV-Athlon Framework is the methodology for creating an evaluation; a TEVV-Athlon is the assessment an organisation produces by applying it. NIST issued the framework. You produce the athlon. The name comes from multi-event sporting formats — triathlon, decathlon — testing ability across several events rather than one.

The four stages, and where they attach

Stage 1 is operationalised as seven questions built on the Heilmeier Catechism and the Feynman method, opening with:

What are the goals of your TEVV assessment? Articulate your objectives using absolutely no jargon.

Only questions 1, 2 and an approximate answer to 3 — time and cost — are required to leave Stage 1. The working vocabulary underneath is Events, Tools and Blocks: a system is tested via a set of Events and Tools that produce data on Blocks related to the measurement concepts of interest.

Two passages worth quoting to anyone selling you benchmark-based assurance

Section 4.6 is titled “Beware of Goodhart’s Law”:

strong benchmark performance or metric scores do not always indicate broader system quality or suitability for deployment

And section 4.5 refuses to treat validation as a milestone:

Measurement validation is an ongoing process rather than a one-time activity

with revalidation prompted by changed deployment settings, user populations, operational environments or system capabilities. That is the same argument this page makes about MEASURE, now with a NIST citation behind it.

Status, and what not to claim

• It is a draft. The Editorial Review Board approval line is still a placeholder. Nothing in it is final.
• The document carries “August 2026” on its cover with no day. 7 August is the announcement date and the day the comment window opened — cite it that way rather than as a publication date.
• It creates no legal duty, certifies nothing, replaces nothing, and prescribes no fixed acceptance thresholds. The decision on acceptable residual risk stays with the deploying organisation.
• Scope explicitly includes agentic systems, alongside statistical ML, large language and multi-modal models.
• Its AI lifecycle classification is based on an OECD taxonomy — useful if you are mapping to international frameworks.

Two details worth knowing if you intend to respond: comments go to TEVV-Athlon@nist.gov with “NIST AI 200-2” in the subject, and all comments are subject to release under FOIA — NIST asks that they not contain proprietary information. NIST also discloses that it may use AI tools to summarise or analyse comments, and states your data will not be used to train AI models.

One further disclosure, of interest to this site’s readers on its own terms: the draft records that it “was edited with the assistance of Gemini, developed by Google, and ChatGPT, developed by OpenAI”, with all content reviewed and verified by the authors. A NIST publication disclosing AI editing assistance is itself a datapoint on emerging disclosure practice.

The Integration Reality

The four NIST functions are not sequential steps — they are concurrent processes that must operate simultaneously once AI is in production. GOVERN is always active. MAP happens before deployment and again whenever the system changes meaningfully. MEASURE runs continuously. MANAGE responds as events occur.

The AI Human Proof standard maps directly to this structure, operationalising each function for the specific risk profiles of commercial AI deployment.

Sources