NIST AI Risk Management Framework: GOVERN, MAP, MEASURE, MANAGE at the request layer

TL;DR

• A practical NIST AI RMF program connects each governance decision to evidence from real AI requests, not scattered logs and tickets.
• GOVERN needs an accountable owner, testable policy conditions, approval rules, and the policy version active when a request decision occurred.
• MAP and MEASURE require a deployment inventory, risk context, behavior tests, monitoring thresholds, and request records that show identity, route, policy, and action.
• MANAGE closes the loop by recording treatment, changing the production control, and verifying that the change took effect, while controls outside the gateway remain separate.

NIST published the AI Risk Management Framework 1.0 in January 2023 with four functions: GOVERN, MAP, MEASURE, and MANAGE. A security team usually encounters those words in a PDF or a steering-committee deck. An assessor encounters the evidence trail: a named owner, an approved policy, a model inventory, a test result, and a decision record attached to a real event.

The NIST Generative AI Profile, published in July 2024, makes the practical gap clear. Generative AI adds risks such as confabulation, data privacy and value-chain dependency. A program needs a way to connect its governance statements to the AI requests that put those risks into production.

I use one blunt test for AI RMF programs: can the person responsible for a policy retrieve the evidence for an actual request on a Tuesday afternoon? If the answer is a scavenger hunt through application logs, tickets, and vendor consoles, the framework has not reached operations.

GOVERN: the accountable policy set

GOVERN runs across the other three functions. It assigns responsibility, establishes policy, and makes AI risk part of the organization’s wider risk decisions.

A workable GOVERN package includes an AI-use policy signed by the accountable executive, a risk appetite statement, a role map, and a review cadence. Each policy needs a condition that an operator can recognize. “Protect sensitive data” gives nobody a test. “Block a payroll administrator from sending employee tax identifiers to an unapproved model route” gives the team a test, an owner, and a record to inspect.

The visual detail is a policy sitting in a shared drive with a last-modified date from 2024. A policy version attached to a request decision shows that the policy was active when the event occurred.

Beyond setting the rule, GOVERN assigns who can approve an exception, receive a policy-hit alert, and review changes. Those decisions belong in the risk record rather than in a developer’s chat thread.

MAP: the AI inventory and risk context

MAP identifies the AI systems in use, their intended purpose, affected people, data, and dependencies. The core artifact is an inventory, but an inventory needs more than a vendor name.

For each deployment, record the application, model endpoint, provider, business owner, originating identity type, data classes, intended use, downstream recipient, and approval state. Include vendor software that makes LLM requests on the organization’s behalf. Procurement records often describe that software as HR, CRM, or support tooling, which leaves its embedded model call out of an AI inventory.

An HTTP gateway can supply useful MAP evidence only for traffic routed through that gateway. It can show an authenticated user or agent calling a configured LLM endpoint, the selected route, and the policy decision. It cannot discover a browser extension, a local process, or a vendor call that never crosses the inspected egress path. That boundary belongs in the inventory itself.

The inventory should link each deployment to a risk assessment. A customer-support assistant handling account data has a different risk profile from an internal code assistant. The two systems may call the same provider while requiring different policy conditions and different review owners.

MEASURE: tests, signals, and evidence

MEASURE evaluates the risks identified in MAP. NIST describes measurement as both testing before deployment and monitoring after deployment. The resulting package normally contains a test plan, evaluation results, monitoring thresholds, issue records, and the evidence used to reach a decision.

For an LLM application, separate model behavior testing from request-policy measurement. Red-team results, prompt-injection tests, and task-quality evaluations test behavior. Request records show who sent an input, the intended model route, the applied policy, and the action taken at runtime. Both matter, yet they answer different questions.

I would rather see ten well-labeled evaluation cases and a complete sample of policy decisions than a glossy score with no route back to the inputs. Audit work begins when a reviewer can select an event and reproduce the decision context.

Use the measurement plan to define the sample period, retention, alert threshold, reviewer, and remediation trigger. That keeps a “monitoring dashboard” from becoming a screen nobody owns after launch.

MANAGE: treatment and follow-through

MANAGE prioritizes and acts on measured risks. The artifacts are treatment decisions, approved policy changes, incident records, owner assignments, and verification that the action took effect.

A concrete example: an evaluation finds that a contractor role can send an internal legal document to a route approved only for public information. The treatment record should name the risk owner, the policy change, the effective time, the exception path, and the verification sample. A request-level enforcement point can apply that policy to later routed LLM calls and retain the decision record. Endpoint controls, identity administration, and vendor configuration still own their separate portions of the response.

That division avoids a familiar failure. A team records a mitigation in its risk register, then leaves the production route unchanged. MANAGE needs a connection between the decision and the system that implements it.

The four functions in one operating loop

GOVERN approves the rule and accountable owner. MAP documents the application and its risk context. MEASURE tests the application and collects operating signals. MANAGE records the treatment and verifies it.

For routed AI traffic, a per-decision record can support several points in that loop: inventory reconciliation for MAP, operating samples for MEASURE, and proof of an effective policy update for MANAGE. It is supporting evidence, not a substitute for a risk assessment, model evaluation, incident process, or identity-provider control.

DeepInspect evaluates HTTP traffic between an authenticated user or agent and an LLM endpoint. It can use identity context and route policy for that request, then retain a decision record. Local execution, credential compromise, browser-only activity, and provider-side actions require controls at their own layers.

Related assurance work

Teams commonly map AI RMF artifacts to ISO 42001 controls, AI governance and risk management, and SOC 2 Common Criteria evidence. The overlap helps a team reuse evidence, but each framework retains its own scope and assessment method.

NIST AI RMF is voluntary guidance. Contract requirements, agency policies, sector rules, and customer commitments can make portions of the program operationally required. Keep those obligations separate from the framework’s published status, then map the evidence for each one.

DeepInspect

DeepInspect is a stateless policy gateway for HTTP AI traffic between authenticated users or agents and LLMs. At that boundary, it evaluates identity-aware policy and creates a per-decision audit record. MAP owners can use it as routed-traffic inventory input. MEASURE reviewers can retrieve operating samples, while MANAGE owners can inspect evidence of a policy decision.

The gateway does not replace the governance committee, the model evaluation process, or the controls outside the request path. It gives those owners a durable record of the requests the gateway actually handled.

Let's talk today.