Is NIST AI RMF mandatory?

The NIST AI Risk Management Framework is voluntary at the federal level. Several enforceable regimes incorporate it as a baseline. Federal procurement under Executive Order 14110 requires AI risk management consistent with the NIST AI RMF for systems used by federal agencies. Texas TRAIGA cites the RMF as one accepted demonstration of reasonable care for entities subject to the statute. The California AI Transparency Act incorporates RMF concepts in its risk disclosure requirements. Companies that sell into regulated markets or federal agencies should treat the NIST AI RMF as effectively mandatory even though no federal statute names it as the required framework.

What is the difference between NIST AI RMF and NIST AI 600-1?

NIST AI RMF 1.0 is the general framework covering all AI systems. NIST AI 600-1, the Generative AI Profile, applies the framework specifically to generative AI and adds twelve risk categories that are unique to generative models. Organizations deploying generative AI should treat both as the operative reference. The Generative AI Profile does not replace the RMF. It supplements it with risk categories and measurement guidance specific to LLMs and multimodal systems.

Can application logs satisfy the Measure function?

Standard application logs fail the Measure function for most risk categories under the Generative AI Profile. The application records that a request was processed. The application does not record whether the prompt contained PHI, whether the response contained confabulated content, or whether the response surfaced harmful bias. Measurement at that resolution requires inspection of the request and response payloads at the AI traffic layer, with classification applied and outcome recorded. An external enforcement proxy that inspects every AI request produces the records the Measure function requires.

How does the NIST AI RMF interact with the EU AI Act?

The two frameworks are complementary. NIST AI RMF is voluntary and process-focused. The EU AI Act is mandatory for in-scope systems and outcome-focused. Article 12 of the EU AI Act requires automatic recording of events for high-risk systems. That recording requirement aligns with the Measure function of the RMF. Companies that build NIST AI RMF alignment using a per-request evidence layer can satisfy both frameworks from the same infrastructure. The same record that backs the Measure function backs the Article 12 audit trail.

Where do most organizations fail their first NIST AI RMF assessment?

The Map and Measure functions are where most organizations lose points. Map fails because the AI inventory misses shadow AI usage by employees on unmanaged devices. Measure fails because the operational logs do not contain the prompt content, identity context, or data classification at the resolution NIST expects. Govern and Manage typically pass because they rely on policy artifacts that the compliance team can produce on demand. The deficiencies sit on the operational side, which is why per-request evidence

NIST AI RMF Implementation: From Govern, Map, Measure, Manage to Production Controls

NIST AI RMF 1.0 defines four core functions: Govern, Map, Measure, Manage. NIST released it in January 2023 and followed with the Generative AI Profile (NIST AI 600-1) in July 2024. The framework is voluntary, but federal procurement under Executive Order 14110, Texas TRAIGA, and several state AI laws cite the RMF as a reasonableness baseline. Implementation in production AI deployments runs to dozens of operational decisions across identity, data classification, policy enforcement, and audit infrastructure.

I want to walk through what each function requires at the implementation level, what most organizations actually do, and where the gap between a written policy and a defensible control sits.

Govern in practice

The Govern function establishes the policies, accountability lines, and process that hold the rest of the framework together. NIST lists eight subcategories under Govern, covering legal and regulatory compliance, risk tolerance documentation, accountability assignment, workforce diversity in AI roles, third-party risk, and incident response.

Most organizations produce a Govern artifact and stop there. The AI Acceptable Use Policy exists. The board has approved an AI risk appetite statement. A Chief AI Officer or equivalent has been named. The artifacts satisfy the documentation requirement under Govern 1.1 and 1.2. They produce zero per-request evidence that the policy was enforced when a user asked an LLM to summarize a customer record.

The Govern function expects continuous evidence of enforcement, not just the existence of the policy. NIST AI RMF subcategory 1.4 requires processes for organizational policies and procedures that "address AI risks and benefits, including third-party risk." A policy with no enforcement record fails the subcategory test at the first audit.

Map function: identifying AI in scope

The Map function asks the organization to identify where AI is deployed, what risks each deployment introduces, and what stakeholders are affected. NIST lists five categories under Map: context establishment, AI system categorization, AI capability and limitations characterization, risk and benefit measurement criteria, and stakeholder identification.

In production, the Map function fails on shadow AI. Cloud Radix research found that 78% of employees use unauthorized AI tools at work and 86% of IT leaders are completely blind to those interactions. An AI inventory that lists the sanctioned ChatGPT Enterprise tenant misses the 78% of usage flowing to free-tier endpoints from corporate browsers and unmanaged devices.

Mapping unsanctioned usage requires network-level visibility into AI API destinations: api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and the long tail of fine-tuning and inference vendors. Egress logs from a forward proxy or DNS resolver are the typical starting point. Egress logs alone produce destination data without prompt-level content, which fails the Measure function described below.

Measure function: per-request evidence

The Measure function is where the operational gap opens. NIST lists four categories under Measure: measurement methodology, AI risk and impact metrics, tracking AI risks over time, and feedback from external sources.

The categories require quantitative evidence about how the AI is performing in production. The Generative AI Profile (NIST AI 600-1) adds twelve risk categories specific to generative AI: confabulation, dangerous content, data privacy, environmental impact, harmful bias, human-AI configuration, information integrity, information security, intellectual property, obscene content, value chain transparency, and human-subjects exploitation. Each risk category requires its own measurement approach.

Application logs do not satisfy the Measure function for any of those categories. The application records that a request was processed. The application does not record whether the prompt contained PHI, whether the response surfaced harmful bias, or whether the model rejected an instruction it should have followed. Measurement at that resolution requires inspection of the request and response payloads at the AI traffic layer.

Manage function: closing the loop

The Manage function asks the organization to act on what Measure found: prioritize risks, allocate resources to AI risk treatment, document incidents, and feed lessons back into Govern. NIST lists four categories under Manage: planning the risk response, allocating resources, third-party risk monitoring, and risk treatment documentation.

The Manage function depends on the prior functions producing actionable signal. If Govern produces only policy documents and Measure produces only application logs, Manage has nothing to act on. The reverse failure mode is also common: Measure produces signal that Manage cannot route because there is no severity classification or response runbook. Both failures show up in the same audit finding: the framework artifacts exist, the operational evidence does not.

A working Manage implementation requires per-incident records that contain identity, role, data classification, policy version, decision outcome, and timestamps. With those records, the response team can reconstruct any AI request, the policy that governed it, and the outcome, then decide whether it needs investigation, retraining, policy adjustment, or external disclosure.

The compliance gap most teams hit

Most organizations I look at have policy documents covering all four functions. The Govern artifacts are produced by a compliance team. The Map inventory is produced by an IT team. The Measure metrics are produced by a data science team. The Manage workflow is owned by a security team. The artifacts sit in separate tools and do not share a common record format.

The pattern that survives audit is a single per-request record that captures the identity context, data classification, policy state, and decision outcome. That record is what Govern points to as evidence that the policy is enforced. That record is what Map uses to identify which AI systems are in scope. That record is what Measure aggregates into risk metrics. That record is what Manage triages when an incident is reported. One record, four functions, one audit trail.

Producing that record requires inspection of AI traffic at the request boundary, identity context attached to each request, and tamper-evident commitment of the record before the model response returns to the application.

How NIST AI RMF maps to other frameworks

The NIST AI RMF aligns with several regulatory frameworks that take effect in 2026. EU AI Act Article 12 requires automatic recording of events over the lifetime of high-risk AI systems, which is the same evidence requirement that backs the Measure function. Fannie Mae LL-2026-04, effective August 6, 2026, requires AI inventory and audit trails for AI-assisted decisions, which maps to Map and Measure.

Texas TRAIGA, in effect since January 1, 2026, cites the NIST AI RMF as one accepted basis for demonstrating reasonable care under the statute. Companies that document NIST AI RMF alignment with operational evidence have a stronger defense in TRAIGA enforcement actions than companies that document policy alignment alone.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users and agents and any LLM. Every request is evaluated against identity, role, data classification, and per-route policy. Every decision produces a signed audit record that captures identity, policy version, classification, decision outcome, and timestamp.

That record is the evidence the Measure function needs, the inventory the Map function needs, the enforcement signal the Govern function needs, and the input the Manage function needs to triage incidents. One inline control produces evidence across all four NIST AI RMF functions.

If you are building NIST AI RMF alignment and your current evidence is application logs and policy documents, the gap is at the request layer. Book a demo today.