NIST AI RMF 1.0 + Generative AI Profile, line by line.

The load-bearing claim.

Four verbs, one paragraph, the entire methodology. NIST chose verbs not nouns deliberately. GOVERN is not governance; it is the act of cultivating a culture in which AI risk is named and owned. MAP is not a mapping document; it is the act of establishing context per system. MEASURE is not metrics; it is the act of running tests, evaluations, verifications, and validations against the system. MANAGE is not risk register; it is the act of allocating treatment to a measured risk. The verbs specify continuing obligations, not artefacts.

The single most-misread sentence in the entire RMF is the one that follows the four definitions in § 5. The four functions are not sequential. They are concurrent and interdependent. A firm that treats GOVERN as a one-time policy publication, MAP as a system-launch checklist, MEASURE as a quarterly metrics review, and MANAGE as a ticket queue has not implemented the RMF. The RMF requires the four functions to operate together against every AI system the firm runs, every release the firm cuts, and every decision the firm's AI produces.

The 19 categories and 72 subcategories under the four functions are the supervisor's expansion of what each verb means in operational practice. GOVERN has 6 categories. MAP has 5. MEASURE has 4. MANAGE has 4. Each subcategory is a discrete practice that an organisation can self-attest against. NIST does not score the attestation; the document is constructed for self-assessment. But the absence of a subcategory from a firm's self-attestation reads as an absence to a federal procurement officer reviewing the firm's RMF posture.

For an AI agent operating in production, the four functions translate into per-decision evidence categories. GOVERN is the audit trail of who decided what was acceptable risk and when. MAP is the per-trace context (purpose, jurisdiction, affected parties) that frames the decision. MEASURE is the eval-suite run record plus the per-decision residual-risk record. MANAGE is the per-decision rationale and the treatment-of-risk evidence. The four functions read against an AI agent in production become four columns in the per-decision evidence package.

Culture, accountability, transparency.

GOVERN is the cross-cutting function. It is not the first stage of a pipeline; it is the soil in which the other three functions grow. NIST's framing in § 5.1 is that GOVERN cultivates a culture of AI risk management that is enabled by senior leadership, that is inclusive of diverse perspectives, and that is supported by clear policies, procedures, and practices. The function exists in the language of culture because the RMF authors observed that AI risk management without cultural reinforcement tends to collapse into a documentation exercise.

GOVERN 1 has seven subcategories, GOVERN 1.1 through GOVERN 1.7. The load-bearing one is GOVERN 1.1: legal and regulatory requirements involving AI are understood, managed, and documented. For a firm running an AI agent across multiple jurisdictions, GOVERN 1.1 alone encompasses the entire EU AI Act mapping, the FCA Consumer Duty mapping, the SR 26-2 model-risk mapping (supervisory guidance, not binding regulation), the SEBI retail-algo mapping, and any other regime that engages the firm's AI use. The RMF reads through to those regimes; it does not displace them.

For an AI agent in production, the GOVERN function is the audit trail of who decided what was acceptable risk and when. A per-release attestation that names the accountable Senior Manager, the regulatory regimes engaged, the residual risk accepted, and the date of acceptance is the operational discharge of GOVERN 1.1, GOVERN 2.1, and GOVERN 4 simultaneously. A GOVERN function that exists only as a published policy document and a quarterly steering-committee minute is the configuration the supervisor expects to fail.

GOVERN is also the function that is hardest to evidence, and the structural reason is visible in the document rather than in any survey. Firms run MAP-style work in product launches and MEASURE-style work in evaluation suites, because both attach to something an engineer already ships. GOVERN attaches to nothing shippable, and that is where the cultural and accountability infrastructure should turn the technical work into a defensible record. The Warrant package reaches part of this gap and not all of it: every per-decision record carries the regimes the decision engaged, the corpus it was read against, and a sealing timestamp, and it is independently verifiable without contacting Warrant. It does not carry the name of the human who accepted the risk. That accountability record is the firm's to keep, and GOVERN 2.1 asks for it by name.

Context and risks.

MAP is the function that establishes context per AI system. The function's five categories work together to answer five questions: what is this system for, what is it, what does it know, what does it depend on, and what does it affect. NIST's framing is that without an answer to all five questions the firm cannot meaningfully measure or manage the risks the system creates. The MAP function is where Warrant's classification stage produces its first evidence layer.

The MAP function is where a per-trace classification produces direct RMF evidence. Warrant maps each trace to a domain, a set of jurisdictions, the regulatory regimes engaged, and a risk tier with its justification; that output is MAP 1 and MAP 2 evidence in a single record. MAP 5 it does not reach — the schema carries the subject of each action, not a characterisation of who else the action affects, and the affected-party analysis stays with the firm. The MAP 4 answer for the AI supply chain is partial and by reference: the receipt records the model identity of every pipeline stage inside a configuration digest, so a model swap is visible on the record, but the rest of the component inventory sits outside the package. The capability-and-benchmark answer for MAP 3 is the eval suite the firm runs against the system on a release cadence.

For an AI agent making a customer-facing decision, MAP 5 is the operative subcategory the supervisor will pull on examination. The supervisor's question is whether the firm characterised the impact of this action on this customer (or this protected group) before the action shipped. A characterisation that exists only at the system level, not the per-action level, does not survive the question. MAP 5 is per action, not per system, and the per-action record is the one the supervisor asks to see.

Analytics, metrics, validation.

MEASURE is the function that quantifies the risks the MAP function identified. Its four categories are the load-bearing instrumentation: appropriate methods and metrics, the test, evaluation, verification and validation (TEVV) regime, the mechanism for tracking risks over time, and the feedback loop that surfaces new risks as the system operates. MEASURE is also where NIST writes most prescriptively about test methodology, and two of its subcategories name TEVV directly: MEASURE 2.1 and MEASURE 2.13.

MEASURE 2.1 and MEASURE 2.13 are the two subcategories that expand TEVV into operational practice, and they ask for different things. MEASURE 2.1 asks for the test sets, the metrics, and the tooling detail to be written down — the artefact, not the result. MEASURE 2.13 asks the firm to evaluate whether those metrics and processes were any good, which is a second-order obligation most firms never discharge. Around them sit the per-characteristic subcategories: MEASURE 2.5 covers validity and reliability, MEASURE 2.7 covers security and resilience as identified in the MAP function. Section 5.3 sets the standard the whole set is written to — rigorous software testing and performance assessment methodologies with associated measures of uncertainty — so the measurement of uncertainty is a property NIST asks the test methodology to carry, not a named subcategory to cite.

The Warrant evaluation suite (the regulator-grade-evals work) is built as a TEVV instantiation aimed at MEASURE 2.1 and MEASURE 2.13. The supervisor's question on MEASURE 2.1 (show me the TEVV evidence for the release that produced this decision) reduces to a record that is independently verifiable without contacting Warrant rather than a discovery exercise across observability tooling. /blog/regulator-grade-evals documents the approach.

MEASURE 3 is the subcategory that closes the per-decision loop. The RMF reads tracking as continuous, not periodic. A tracking mechanism that operates only at the cohort level and only on a quarterly cadence does not satisfy MEASURE 3 for an AI system that produces decisions every minute. The per-decision residual-risk record is the load-bearing piece, and the per-cohort rollup reads off the per-decision records, not the other way around. MEASURE 3 is what fails when an AI agent's monitoring rotates with the underlying observability data.

Prioritisation and treatment.

MANAGE is the function that takes the risks MAP identified and MEASURE quantified and decides what to do about them. Its four categories are: prioritise treatment based on assessment, develop strategies to maximise benefits, manage third-party risks, and document risk treatments and decisions. The MANAGE function produces the risk-treatment evidence record per decision.

MANAGE 4 is the subcategory that lands hardest on per-decision evidence. The RMF expects the firm to document the risk treatment per identified risk and the decision basis on which the treatment was selected. For an AI agent producing decisions in real time, the per-decision rationale is the document the supervisor will pull. A rationale that exists only as a system-level policy document, not as a per-action record bound to the action's outputs, does not survive the question.

Warrant's Stage 3 output is the closest thing in the package to a MANAGE 4 answer. Per action it emits an authorisation row: within_purpose, preconditions_met, human_oversight_appropriate, reversible, justification, plus refusal and refusal_reason where the pipeline declined to proceed. The justification string is the per-action rationale MANAGE 4 asks to see documented. Bound into a record that is independently verifiable without contacting Warrant, it is retrievable per action long after the action shipped, which is the survival property MANAGE 4 implicitly requires for a regime the supervisor reads in years. What the package does not carry is the treatment decision itself — accept, mitigate, transfer, avoid — so MANAGE 1 and MANAGE 4's response-and-recovery limb remain the firm's to evidence elsewhere.

Twelve risk categories specific to generative AI.

NIST published the Generative AI Profile (NIST AI 600-1) on 26 July 2024. The profile is the companion document to AI RMF 1.0 that addresses risks specific to generative AI systems. The structure follows the four functions of the parent RMF; the additions are the twelve generative-specific risk categories and the suggested actions per category.

Twelve risk categories. Each category has GOVERN, MAP, MEASURE, and MANAGE-style suggested actions, totalling more than 200 individual practices a generative-AI deployment can self-attest against. The profile is not a checklist; NIST is explicit that not every category applies to every deployment. A code-completion model in an enterprise IDE has a different risk profile than a customer-facing chatbot in a regulated industry, and the profile expects the firm to map the categories to the deployment's actual surface.

The twelve categories partition into three rough groups by how directly they engage AI evidence-of-record obligations. The first group (CBRN, dangerous content, obscene content) reaches outputs that should not have been produced; the evidence is the refusal record and the upstream filtering record. The second group (confabulation, information integrity, harmful bias, intellectual property) reaches output quality and trustworthiness; the evidence is the grounding record, the citation record, and the residual-risk record. The third group (data privacy, information security, environmental impacts, human-AI configuration, value chain and component integration) reaches operational and architectural concerns; the evidence is the supply-chain record, the human-oversight record, and the deployment-scope record.

The middle group is where Warrant's evidence shape lands hardest. A per-decision package that records the inputs, the retrieval-grounded sources, the output, and the residual risk is direct evidence against confabulation, information integrity, and harmful bias risks simultaneously. The package does not eliminate the risks; the RMF does not expect elimination. It produces the evidence record that the firm identified the risk, treated it, and accepted the residual.

Three of twelve that produce per-decision evidence.

Of the twelve generative-AI risk categories, three produce direct per-decision evidence shape that maps cleanly to the Warrant record. The remaining nine produce evidence at the system level (CBRN refusal policies), at the architecture level (information security controls), or at the supply-chain level (value chain and component integration). The three load-bearing categories for per-decision evidence are confabulation, information integrity, and human-AI configuration.

Confabulation has drawn sustained regulator commentary. The supervisor's framing is that a model that asserts false content with the same confidence as true content places the entire information chain at risk; the firm cannot defend the deployment without evidence that the chain is grounded. The mitigation evidence is per-decision: the retrieval sources the model consulted, the citations bound to the output, and the refusal pattern where the model lacked sufficient grounding. A grounding record that exists at the architecture level but not the per-decision level does not answer the supervisor's per-customer question.

Information integrity is the second-order risk that follows confabulation at scale. NIST's framing is that even where any single confabulated output is recoverable, a population of confabulated outputs degrades trust in the entire information ecosystem. The mitigation is structural: every output the AI agent produces should carry a verifiable provenance trail, and the trail should be independently inspectable. The Warrant evidence package is the structural answer; each record is independently verifiable without contacting Warrant, which is the property NIST asks for under information integrity.

Human-AI configuration is the risk that lives in the boundary between automation and oversight. NIST defines it narrowly — the arrangements between a human and a generative-AI system that produce anthropomorphization, automation bias, over-reliance, or emotional entanglement — and its suggested action GV-3.2-003 asks firms to define acceptable-use policies per human-AI configuration, for chatbots and for decision-making tasks, including the criteria for queries the system should refuse. Read against an agent, that specification is per decision class, not per system: some decisions warrant pure automation, others warrant human review, others warrant human-in-the-loop coordination. The mitigation evidence is the per-decision oversight check: did the trigger conditions fire, did a reviewer engage, what was the reviewer's identity and time-on-task. In the Warrant package the Stage 3 authorization row carries authorizations[*].human_oversight_appropriate, a per-action string, which is where that evidence lands.

RMF, ISO 42001, EU AI Act.

NIST has published official crosswalks from the AI RMF to ISO/IEC 42001:2023, to the OECD AI Principles, and to other instruments including the EU AI Act and EO 13960. The crosswalks are not for show; they are the operational answer to the question every multi-jurisdiction firm asks: do i need to run RMF, 42001, and EU AI Act compliance separately? The answer is that the three regimes overlap substantially on substance, and a single per-decision evidence shape can satisfy all three. We are not going to put a percentage on the overlap: nobody has published a defensible one, and the official crosswalk does not quantify it.

The RMF-to-42001 crosswalk is the cleanest of the set. Note what it is: NIST maps at subcategory level, one row per RMF subcategory, and the ISO clauses cited on those rows range across clauses 4 to 10 and Annex B, so no RMF function reduces to a single clause. The reading below is a thematic one, at function level, and it is ours rather than the crosswalk's. GOVERN corresponds most closely to the leadership and support clauses (5 and 7); the cultural and accountability infrastructure the RMF describes is the management-system commitment ISO codifies. MAP corresponds to planning and risk assessment (6.1); the contextualisation work is the same in both regimes. MEASURE corresponds to performance evaluation (9) — the one function-to-clause pairing the official crosswalk's own row distribution bears out. MANAGE corresponds to operation and improvement (8 and 10); the treatment-of-risk and continuous-improvement work is shared. For a row-by-row answer, read the crosswalk PDF, not this table.

The RMF-to-EU-AI-Act crosswalk runs through Articles 9, 12, and 13 of the binding regulation. Those are Chapter III high-risk obligations, and they attach when the high-risk classification does: 2 December 2027 for Annex III systems, 2 August 2028 (subject to Article 2(13)) for Annex I. Article 9 (risk management system) corresponds to RMF MAP plus MANAGE; the EU AI Act's Annex IV documentation requirement reads directly into the RMF MAP and MANAGE outputs. Article 12 (logging) maps to MEASURE 3 (mechanisms for tracking risks over time); both regimes require per-event records that survive across the regulatory horizon. Article 13 (transparency) maps to MAP 5 (impacts characterised) plus GOVERN 5 (engagement with relevant AI actors); the transparency obligation reaches the affected-party characterisation and the stakeholder-engagement record together.

The meta-answer for a CTO running an AI agent across multiple regimes is that one evidence shape can satisfy three jurisdictions. The shape is the per-decision package that captures the four-function evidence in a single record, mapped to a specific obligation under each regime. The regime-specific obligations are then a binding step at the end: same per-action record, different external citations. /blog/one-agent-many-jurisdictions walks the binding step in detail.

The category-to-field map.

The table below names the RMF function or category, the evidence the AI agent must produce per action, and the field in the Warrant evidence schema that carries it. Field paths are read from api/spec/warrant-v1-evidence.schema.json and are the actual names, not descriptions of them. Where the schema has no field for a subcategory the row says so — an honest map has holes in it, and the holes are the useful part of the table.

The mapping reads both ways. Given a procurement officer's question on an RMF category, the firm reads the third column, retrieves the field, and produces the per-decision record. Given a specific customer or internal-audit case, the firm reads the per-decision record back to the rows above. Either direction is one query against the per-decision package.

What the table is not is a citation the package emits. The RMF entries in the Warrant corpus sit at category level — nineteen of them, nist_ai_rmf.govern.1 through nist_ai_rmf.manage.4, with no subcategory entry beneath any of them — so no package binds an RMF subcategory, and none of the packages on the public record cites the RMF at all. The crosswalk above is editorial: it says which existing schema field answers the question an RMF category asks. Read it as a reading, not as a clause the record carries.

The specimen below is linked for its shape, not for its regime. It is a Frankfurt bank lending agent operating in the EU — four warranted actions, five regimes cited including EU AI Act Article 12 and Article 13 and GDPR Article 22, three compliance gaps, recorded 2026-05-06. It names NIST nowhere, and nothing in it evidences an RMF self-attestation. What transfers is the structure the third column describes: the classification block, the per-action authorisation rows, the obligation map keyed by action id, and the corpus digest the reading was taken against. A US firm running the RMF would produce a package of that shape against its own regimes.

Both instruments that pointed here have been withdrawn.

An earlier version of this page said the RMF had become the de facto federal methodology, and named two instruments as the reason. Both are dead, and the correction matters more than the original claim did.

Executive Order 14110 is revoked. Executive Order 14148, Initial Rescissions of Harmful Executive Orders and Actions, signed 20 January 2025 and published at 90 FR 8237, opens its section 2 with "The following executive actions are hereby revoked" and lists at subparagraph (ggg) "Executive Order 14110 of October 30, 2023 (Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence)". Executive Order 14179 of 23 January 2025, at 90 FR 8741, set the replacement policy; its section 5 is headed "Implementation of Order Revocation" and directs a review of every action taken under what it calls "the revoked Executive Order 14110". So 14110 is not merely superseded in spirit. It was struck by name.

OMB M-24-10 is rescinded. OMB Memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, dated 3 April 2025, states in its overview: "This memorandum rescinds and replaces Office of Management and Budget (OMB) Memorandum M-24-10, Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence." And here is the part that a stale citation hides — M-25-21 does not mention NIST or the AI Risk Management Framework once. The successor memorandum keeps the Chief AI Officer and keeps a high-impact AI category, and it does not carry the RMF forward as the methodological backbone. That claim did not survive the replacement.

What follows for a vendor is narrower and more useful than the old claim. The four-function vocabulary is still the clearest shared language for describing how a firm handles AI risk, and a buyer's technical evaluator will still understand GOVERN, MAP, MEASURE and MANAGE without a glossary. That is a communication advantage, not a compliance obligation, and the two are worth keeping apart in a sales conversation. Overstating it invites the buyer's counsel to check, and the check now comes back against you.

The binding obligations elsewhere have not moved. EU AI Act Articles 9, 12, 13 and 14 bind by regulation, from 2 December 2027 for Annex III high-risk systems and 2 August 2028 (subject to Article 2(13)) for Annex I. Those are the instruments here that create a duty; the RMF describes a method. SR 26-2 does not join them: it is Federal Reserve supervisory guidance on model risk, non-compliance with it is not independently enforceable, and its § II footnote 3 places generative and agentic AI outside its scope, so mapping an agent record against it is voluntary governance design rather than the discharge of a duty. /blog/sr-11-7-model-risk walks the US model-risk reading. Where a firm needs per-decision evidence, it needs it because a binding regime asked, and the RMF vocabulary is a convenient way to organise it.

Framework, not artefact.

The RMF is honest about its limits. NIST writes the document as a methodology, not a binding standard. The RMF does not certify; there is no RMF-compliant badge. It does not pass-fail; the categories are self-attested. It does not produce an artefact; the firm running the methodology produces whatever artefacts its choice of tooling generates, and NIST stays out of that choice.

The honesty is also the gap. A federal procurement officer reading a vendor's RMF self-attestation has no independent way to verify the attestation's evidence base. An internal auditor reading the same attestation against the firm's actual operating posture has the same problem. The RMF asks the firm to produce evidence; it does not specify what the evidence looks like or how the firm should make the evidence portable across tooling, retention horizons, and personnel changes.

The Warrant evidence package is the evidence-of-decision instantiation that the RMF asks for but does not specify how to produce. The document is per-decision. It binds what it does carry — the MAP-side classification, the per-action authorisation judgement, and the per-action obligation rows with their compliance status — to a specific action a specific AI agent took at a specific time. It is independently verifiable without contacting Warrant, so the file's integrity survives any internal infrastructure decision the firm makes. The result is an artefact the firm controls and the supervisor can verify independently.

That gap closure is the load-bearing claim of Warrant against the RMF. The methodology asks for evidence. The per-decision package is the evidence the RMF does not by itself produce, and each record is independently verifiable without contacting Warrant. The four-function vocabulary becomes the evidence's organising principle; the per-decision package becomes the evidence's physical form. The RMF self-attestation rests on records the firm can produce on demand, at any horizon the procurement officer or the internal auditor names. The document tower the RMF asks for stands on a foundation the voluntary register did not, by itself, supply.

For the firm, the operational consequence is that an RMF self-attestation can be made over a population of per-decision packages rather than a population of internal narratives. The four-function language describes what the firm does; the packages prove what the firm did. Read together, the language and the packages form a posture a procurement officer can verify without negotiating retention, a supervisor can read without site-visit cooperation, and a board can sign without trusting that the underlying observability stack will retain its data through the next decade.

Questions a CAIO and an internal auditor ask first.

Read the source directly.

• NIST AI 100-1 · Artificial Intelligence Risk Management Framework (AI RMF 1.0) · January 2023 (PDF)
• NIST AI 600-1 · AI RMF Generative AI Profile · July 2024 (PDF)
• NIST AI RMF Playbook · companion suggested-actions reference
• NIST AI RMF Roadmap · ongoing development priorities
• Executive Order 14148 · Initial Rescissions of Harmful Executive Orders and Actions · 20 January 2025 · 90 FR 8237 · § 2(ggg) revokes EO 14110 (Federal Register full text)
• Executive Order 14179 · Removing Barriers to American Leadership in Artificial Intelligence · 23 January 2025 · 90 FR 8741 (Federal Register full text)
• OMB Memorandum M-25-21 · 3 April 2025 · rescinds and replaces M-24-10 (PDF)
• Executive Order 14110 · 30 October 2023 · 88 FR 75191 · REVOKED 20 January 2025 · linked for historical reference only
• NIST AI RMF Crosswalks · ISO 42001, OECD, EU AI Act
• Warrant regulator index · the regimes we map evidence against

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on the AI RMF and the Generative AI Profile. Not legal advice. The clause texts quoted from NIST AI 100-1 (GOVERN 1, GOVERN 1.1, GOVERN 2.1, GOVERN 4, GOVERN 5, GOVERN 6, MAP 1–5, MEASURE 1–4, MEASURE 2.1, MEASURE 2.13, MANAGE 1–4) and the AI 600-1 § 2 risk list are the published NIST text, checked against the PDFs at nvlpubs.nist.gov on 6 August 2026. Two boxes are marked as assembled rather than quoted: the § 5 four-function box and the AI 600-1 box each concatenate sentences from more than one place in their source, and their citation lines say so. Corrected 28 July 2026: the federal-instrument claims in § 10 and the FAQ were checked against the Federal Register full text of EO 14148 and EO 14179 and against the OMB M-25-21 PDF. EO 14110 is revoked and M-24-10 is rescinded; the earlier text asserted both as live and described the RMF as operationally mandatory, which it is not. Corrected 6 August 2026, against NIST AI 100-1 and AI 600-1 directly: a sentence attributed to MEASURE 2.7 appeared in seven places on this page and appears nowhere in NIST AI 100-1 — MEASURE 2.7 is the security-and-resilience subcategory, and the TEVV subcategories are MEASURE 2.1 and MEASURE 2.13; GOVERN 1 has seven subcategories, not six; GOVERN 5 reads "robust engagement", not "active"; EU AI Act Article 27 is the fundamental rights impact assessment, not conformity assessment (that is Article 43); the AI 600-1 risk category is "dangerous, violent, or hateful content"; the human-AI configuration gloss and the Warrant field names in § 9 were replaced with the actual definitions and the actual schema paths. Three unsourced claims were removed rather than softened. Corrected 7 August 2026: the linked sample package was labelled as binding NIST AI RMF subcategories per action. It does neither. The Warrant corpus carries the RMF at category level only (nineteen entries, nist_ai_rmf.govern.1 to nist_ai_rmf.manage.4), and the linked record — retrieved on 7 August 2026 — is an EU lending trace citing EU AI Act Article 12 and Article 13 and GDPR Article 22, in which the string "NIST" occurs zero times. The card and the surrounding text now say what the record is.