The Question
The NIST AI Risk Management Framework has become the reference standard for enterprise AI governance in the United States and is increasingly cited in international regulatory contexts as a best-practice framework. Since its January 2023 publication, "we are implementing NIST AI RMF" has become a standard statement in enterprise AI governance communications — to boards, regulators, auditors, and customers.
The statement is almost always true in the narrow sense: the enterprise has reviewed the framework, produced a mapping document, and assigned nominal responsibility for the four core functions. It is frequently misleading in the operational sense: the NIST AI RMF is a framework, not an implementation. The distance between "we have mapped to NIST AI RMF" and "NIST AI RMF is operationally implemented" is the same distance as between "we have read the fire safety code" and "we have working sprinkler systems and evacuation procedures tested quarterly."
The documentation exercise produces a compliance narrative. The operational implementation produces governance controls that actually detect, manage, and treat AI risk. For enterprises facing regulatory examination, investor scrutiny, or the practical need to manage AI incidents, the difference is not semantic — it is the difference between a governance program that exists on paper and one that functions when it is tested.
NIST AI RMF implementation is not a documentation exercise — it is an operational transformation, and the enterprises that treat it as a checklist produce the same outcome as the enterprises that don't adopt it at all.
Why This Matters Now
In late 2024, a publicly traded technology company disclosed in its annual report that it had implemented the NIST AI Risk Management Framework as part of its AI governance program. Six months later, the company experienced a significant AI-related incident: a generative AI product feature produced systematically incorrect outputs that affected a class of customers in a measurable, documented way. The incident generated customer complaints, press coverage, and an SEC inquiry into whether the company's prior AI risk disclosures had accurately represented the state of its governance program.
The SEC inquiry focused specifically on the gap between the disclosure ("we have implemented NIST AI RMF") and the operational reality (the company had no systematic production monitoring of the AI feature's output quality, no defined performance thresholds, and no incident response process that had been activated when the systematic error first appeared in telemetry). The NIST AI RMF's MEASURE function explicitly requires analysis and assessment of AI risks, including ongoing performance monitoring. The company's implementation had covered the documentation requirements of MEASURE but not the operational monitoring requirements.
This incident, and others like it surfaced through the SEC's AI disclosure review process through 2025, has produced a meaningful shift in how governance professionals distinguish between framework adoption and operational implementation. The NIST AI RMF GOVERN function's first subcategory — GOVERN 1.1 — requires that AI risk policies exist. It does not guarantee they are followed. The MANAGE function's first subcategory — MANAGE 1.1 — requires that risk treatment plans exist. It does not guarantee they are executed. Operational implementation closes that gap.
The July 2024 publication of NIST AI 600-1, the Generative AI Profile supplementing the core NIST AI RMF, added specific guidance for LLM-related risks — hallucination, data provenance, confabulation, CBRN information disclosure, and human-AI interaction risks — making the implementation gap for generative AI deployments even larger than for traditional ML systems.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Governance CURVE™ Report assessed NIST AI RMF implementation maturity across 41 enterprise respondents on a five-level scale: Level 1 (framework awareness), Level 2 (mapping and documentation), Level 3 (policy and governance structure), Level 4 (operational controls), Level 5 (continuous measurement and improvement). The distribution confirmed the implementation gap concern.
Fifty-eight percent of respondents were at Level 2 — mapping and documentation. They had produced framework alignment documents and nominated governance owners but had not implemented the operational structures required by the GOVERN function or the monitoring processes required by MEASURE and MANAGE.
Twenty-two percent were at Level 3 — they had AI risk policies, a governance committee, and defined roles, but did not have systematic measurement processes or active risk treatment plans with verified completion.
Twelve percent were at Level 4 — operational controls including systematic AI system cataloging, recurring risk assessments with quantitative metrics, and active risk treatment workflows with tracking.
Eight percent were at Level 5 — full operational implementation with continuous improvement processes.
Among tooling vendors assessed for NIST AI RMF alignment, Credo AI demonstrated the most complete alignment, with the framework's four functions (GOVERN, MAP, MEASURE, MANAGE) directly reflected in platform architecture. IBM OpenPages with Watson mapped strongly to GOVERN and MANAGE functions within the broader enterprise risk management context. OneTrust mapped to GOVERN and portions of MAP. Arthur AI mapped primarily to MEASURE — consistent with its model monitoring architecture.
The full vendor rankings are in the 2026 Stackcurve AI Governance CURVE™ Report — free to download.
The Gap Most Buyers Miss
The NIST AI RMF's four core functions are GOVERN, MAP, MEASURE, and MANAGE. The framework describes what each function requires. Operational implementation requires translating those requirements into specific organizational structures, processes, technical controls, and verification mechanisms.
GOVERN: From policy to governance infrastructure
The GOVERN function covers the organizational practices, culture, and structures required for effective AI risk management. Documentation-level implementation produces an AI risk policy and an AI governance committee on paper. Operational implementation requires:
A functioning AI governance committee with a formal charter, defined membership (including representation from legal, compliance, business units, and technology), a meeting cadence, documented decision authority, and a record of decisions made. A committee that exists on an org chart but has not met, has not reviewed AI risk assessments, and has not made documented governance decisions is not operational.
An AI risk policy that specifies which AI systems require governance oversight, what the risk tiering criteria are, what the approved use case categories are, and what the escalation process is for AI systems outside approved categories. A policy that states "we manage AI risk in accordance with NIST AI RMF" without operational specificity is not an operational policy.
Defined roles and responsibilities — AI system owners, model risk owners, governance committee membership — with clear accountability for GOVERN function requirements and documented acceptance of those responsibilities.
MAP: From context statement to systematic AI inventory
The MAP function requires identifying and classifying AI risks in context. Documentation-level implementation produces a general AI risk taxonomy. Operational implementation requires:
A systematic AI system catalog that inventories every AI system in production use — including AI features embedded in enterprise SaaS applications — with documented context for each system covering its use case, the populations affected, the decision it influences, and its risk tier classification. Most enterprises do not have a complete AI system inventory. Producing one is the foundational MAP function requirement, and it is consistently the most operationally demanding part of NIST AI RMF implementation.
Context documentation for each cataloged AI system covering the sociotechnical context — how the AI system interacts with human decision-making, what the consequences of errors are, which regulatory frameworks apply — rather than just technical system documentation.
Risk identification specific to each cataloged system, not just a generic list of AI risk categories applied to the enterprise at large.
MEASURE: From risk register to quantitative assessment
The MEASURE function requires analysis and assessment of AI risks. Documentation-level implementation produces a risk register with qualitative risk ratings. Operational implementation requires:
Quantitative risk metrics for each AI system — performance metrics (accuracy, F1 score, AUC-ROC), fairness metrics (demographic parity, equalized odds), reliability metrics (uptime, latency, error rates) — with defined acceptable thresholds and monitoring cadences. A risk register that lists "model performance degradation" as a risk without a quantitative threshold and a monitoring process is not a MEASURE function implementation.
Recurring risk assessments with documented frequency and scope, not one-time assessments at deployment. Model performance, data drift, and bias can change after deployment. Recurring assessment is the operational requirement.
For generative AI systems, NIST AI 600-1 adds specific measurement requirements for hallucination rates, data provenance tracking, and human-AI interaction quality. These require measurement approaches that are still maturing; operational implementation means having a defined approach and executing it, not waiting for measurement standards to fully stabilize.
MANAGE: From risk treatment plan to verified remediation
The MANAGE function requires prioritizing and treating identified risks. Documentation-level implementation produces risk treatment plans that are written and filed. Operational implementation requires:
Risk treatment plans with assigned owners, defined remediation actions, timeline commitments, and verification criteria — written with enough specificity that a third party could verify whether treatment was completed. Generic risk treatment plans ("address model bias risk through ongoing monitoring") are not operational MANAGE function implementations.
An active tracking system for open risk treatment plans with ownership accountability and escalation processes when treatment timelines slip. Risk treatment plans that are not actively tracked are aspirational documents.
Verification processes — test results, monitoring data, third-party assessments — that confirm risk treatment actions have achieved their intended effect. The difference between a completed risk treatment and a closed risk treatment plan entry is verified evidence of treatment effectiveness.
Questions Your Buying Team Should Be Asking
1. For our NIST AI RMF implementation, can we demonstrate a complete AI system inventory — specifically, does our catalog include AI features embedded in enterprise SaaS applications (Salesforce Einstein, Workday AI, Microsoft Copilot) and not just internally developed models?
The AI system inventory is the foundational MAP function requirement, and it is consistently the most incomplete element of enterprise NIST AI RMF implementations. Enterprise AI governance teams frequently catalog internally developed models while missing the AI features embedded in the SaaS platforms that run core business processes. A governance program with an incomplete system inventory has governance gaps proportional to the uncataloged systems.
2. For each AI system in our inventory classified as high-risk, do we have quantitative performance and fairness metrics with defined acceptable thresholds, and are those metrics monitored on a defined cadence with alerts when thresholds are breached?
This question evaluates the MEASURE function at the operational level. The answer should be: yes, and here are the metrics, thresholds, and monitoring frequency for each high-risk system. If the answer is "we have risk registers that note monitoring as a mitigating control," the MEASURE function is at documentation level, not operational level.
3. For our NIST AI 600-1 Generative AI Profile implementation, what are our defined measurement approaches for hallucination rate, data provenance, and human-AI interaction quality in our LLM deployments?
NIST AI 600-1 was published in July 2024 and directly addresses governance requirements for generative AI systems. Enterprises that adopted NIST AI RMF in 2023 need to extend their implementation to cover the Generative AI Profile's additional requirements. If LLM deployments are not covered by defined measurement approaches for the Profile's specific risk categories, the governance program has a material gap for the AI systems generating the most enterprise deployment activity.
4. For risk treatment plans under the MANAGE function, can we produce documentation showing: the open treatment plan, the assigned owner, the remediation action taken, and the verification evidence that the action achieved its intended effect?
This question tests the MANAGE function's closed-loop requirement. The ability to produce this documentation chain — from risk identification through verified treatment — is the operational test of MANAGE function implementation. Governance programs that can answer "yes" for all high-risk systems are at Level 4 or above on the implementation maturity scale. Most cannot.
5. What is our governance committee's documented decision record for the past 12 months — specifically, what AI governance decisions has the committee made, what AI risk assessments has it reviewed, and what escalations has it adjudicated?
The AI governance committee's decision record is the GOVERN function's operational evidence. A governance committee that exists on paper but has not produced a documented decision record is not operationally implemented. The decision record is also the evidence that satisfies board reporting obligations, regulatory inquiries, and SEC disclosure verification — it is not optional documentation for mature AI governance programs.
The Stackcurve Take
NIST AI RMF is the right framework for enterprise AI governance. Its four functions — GOVERN, MAP, MEASURE, MANAGE — cover the governance requirements that regulators, auditors, and boards are increasingly examining. Its voluntary status and broad regulatory reference make it the lowest-friction path to demonstrable AI governance in the United States. Its mapping to EU AI Act, ISO 42001, and OECD AI Principles makes it internationally defensible.
The framework's value is entirely dependent on operational implementation. The enterprises that have mapped to NIST AI RMF and produced documentation are in a similar position to an enterprise that has read ISO 27001 and produced a security policy without implementing the underlying controls. The documentation provides a narrative. The operational implementation provides the governance.
The 58% of enterprises at Level 2 implementation — mapping and documentation — have invested in the narrative. They are building technical debt in the form of governance gaps that will be exposed the first time they face regulatory examination, an AI-related incident, or a board request for evidence that the governance program functions operationally.
The path from Level 2 to Level 4 is not a documentation revision. It is an operational program: complete the AI system inventory, establish quantitative measurement for high-risk systems, implement active risk treatment tracking, and verify that the governance committee functions as an actual decision-making body. It requires operational investment proportional to the AI deployment scale. The alternative is a governance narrative that fails when tested.
The 2026 Stackcurve AI Governance CURVE™ Report covers NIST AI RMF implementation maturity benchmarks, tooling alignment scores for the four core functions, and a practitioner's guide to moving from documentation to operational controls. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.