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.

Related NIST proposals: public-facing model documentation is not system-level evidence

Added 18 August 2026. Coverage note: this draft was published in July 2026 and is included here because it surfaced on NIST’s standards index during a later sweep — it is not a development of the week it was added.

NIST has a second draft in circulation, separate from TEVV-Athlon: NIST AI 300-1, an initial public draft in its Zero Drafts pilot, proposing documentation processes and templates for AI datasets and AI model architecture and parameters. Comments will be considered if received by 16 September 2026.

It is genuinely useful — and its most important feature for a deployer is what it deliberately leaves out.

The scope exclusion is the point. Clause 1 states the document does not address entire AI systems, framing that as material left to future work because system-level documentation practice is “less mature”. And the AI-model definition, together with its accompanying reviewer note, excludes post-processing modules and output guardrail classifiers — NIST explicitly invites comment on whether the model scope should expand to cover them.

Read that against what actually determines how a model behaves in your business. The guardrail classifier that decides what the model refuses is outside the documented artefact. So is the orchestration, the tools, the permissions, the interface, the human review, the monitoring, the change control and the shutdown procedure.

So a fully conformant supplier document would still leave you with the whole system to evidence. That is not a criticism of the draft — it is the correct division of labour, and it is worth naming because “we have the vendor’s model card” is a very common answer to a question the model card was never designed to answer. The gap belongs in your supplier-documentation review.

Status, precisely:

• It is a zero draft, not a published standard, and not a revision of the AI RMF.
• The Foreword states that “shall” statements describe conformity with the voluntary document and carry no regulatory intent.
• NIST intends to submit the final document to INCITS/AI for ISO/IEC JTC 1/SC 42, and says it does not expect to maintain it further — it will be “just one voice among many” in that process. SC 42’s acceptance is what remains conditional.
• The Introduction is still a placeholder, and key definitions are to be referenced from ISO/IEC 22989.
• The PDF itself carries only “July 2026”; the 29 July date comes from NIST’s standards page.

Comments go to ai-standards+doczd@nist.gov, become part of the public record, and NIST asks commenters to disclose any use of AI assistants in preparing feedback — a small but notable disclosure norm from a standards body.

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