The NIST AI Risk Management Framework (AI RMF) was published by the National Institute of Standards and Technology in January 2023. It has since become the de facto US standard for organizational AI governance — referenced in FTC guidance, state AI regulations, executive orders, and an increasing number of enterprise vendor questionnaires.
If you are going through a SOC 2 audit, preparing for an enterprise procurement review, or building an AI governance program that you can describe to a regulator or board, the AI RMF is the framework you are most likely to be asked about.
This guide is not a summary of the framework. It is an implementation guide — what the four core functions mean in practice, what controls satisfy them, and how a team without a dedicated AI governance function can implement them.
What the NIST AI RMF is (and is not)
The AI RMF is a voluntary framework. It does not impose legal obligations and does not carry the force of regulation. What it does:
- Provides a common vocabulary for discussing AI risks across organizations
- Defines four core functions (Govern, Map, Measure, Manage) with supporting categories and subcategories
- Offers a “Playbook” of suggested actions for each subcategory
- Aligns with other NIST frameworks (Cybersecurity Framework, Privacy Framework) for organizations already using them
The framework is intentionally technology-agnostic and audience-agnostic — it applies to small teams building AI features and large enterprises deploying production AI systems. This breadth means the framework is not prescriptive about specific controls, which is both its strength (it fits many contexts) and the implementation challenge (organizations must decide what “implementing” it actually means for them).
The practical question is: given the four core functions, what does a lean organization actually need to do?
The four functions: what they mean and what controls satisfy them
GOVERN
The Govern function establishes the policies, processes, and roles that make AI risk management possible. It is the organizational infrastructure layer — without it, Map, Measure, and Manage operate without accountability.
What GOVERN asks:
- Is there organizational accountability for AI risk?
- Are policies in place for how AI is developed and deployed?
- Are roles and responsibilities defined for AI governance?
- Is AI governance integrated into broader enterprise risk management?
What this means in practice:
Most lean organizations implement Govern by designating one person — typically the CISO, head of IT, or a senior engineer — as the owner of AI governance, and documenting three things:
-
An AI usage policy that defines which tools are approved, what data may enter those tools, and what employee responsibilities are. This should be a written document, versioned and dated, with a named reviewer and review schedule.
-
An AI tool inventory that lists approved AI tools with their risk classifications, data categories they may access, and the DPA or contractual status for each provider.
-
A governance process — even a lightweight one — that defines how new AI tools are evaluated before approval. This does not need to be a formal committee. It can be “new AI tools are reviewed by [named person] before approval, using [criteria].”
Common gap: The policy exists in a handbook but has no named owner, no review date, and was not updated when the team started using new tools in 2024 or 2025. A policy with an outdated tool list is not evidence of governance — it is evidence of a stale policy.
Evidence that satisfies GOVERN:
- Written AI usage policy with a current tool list and named reviewer
- AI tool inventory with risk ratings and DPA status
- A documented approval process for new tools (even a lightweight one)
MAP
The Map function identifies and contextualizes AI risks. Where Govern establishes the organizational infrastructure, Map identifies what AI systems exist, what they do, and what could go wrong.
What MAP asks:
- What AI systems does the organization use or develop?
- What are the intended uses and known limitations of each?
- What is the risk context — who is affected, what data is involved, what could go wrong?
- Are risks classified by likelihood and impact?
What this means in practice:
For an organization using AI tools (rather than building AI systems), the Map function primarily means:
-
AI tool discovery — understanding what AI tools are actually in use, not just what is approved. Shadow AI — tools employees adopted without going through an approval process — creates risk precisely because it is not in any risk register. Discovery requires active monitoring (network logs, endpoint visibility, or a usage survey) rather than relying on employees to self-report.
-
Risk classification per tool — for each tool in the inventory, classify the risk: what data categories does it process? What could go wrong if that data is exposed or mishandled? What is the likelihood of a problem given the tool’s usage pattern? Risk classifications do not need to be elaborate — a simple high/medium/low rating with a brief rationale per tool is sufficient for lean teams.
-
Use case documentation — for AI tools used in risk-relevant contexts (AI generating client-facing content, AI assistants with access to production data, AI agents with tool call permissions), document the specific use case and its limitations. An AI tool that summarizes internal notes is lower risk than an AI agent with database access and email send permissions.
Common gap: The tool inventory exists but reflects approved tools only. Shadow AI tools — which often process the same or more sensitive data than approved tools — are not inventoried because no one had visibility into their use.
Evidence that satisfies MAP:
- AI tool inventory that includes both approved and detected-but-unapproved tools
- Risk classification per tool with documented rationale
- Use case documentation for AI in risk-relevant workflows
MEASURE
The Measure function evaluates AI risks against established criteria and tracks whether controls are operating effectively. It is the monitoring and testing layer.
What MEASURE asks:
- Are AI risks being monitored?
- Are controls operating as designed?
- Is there an audit trail of AI system behavior?
- Are policy violations detected?
What this means in practice:
For organizations using AI tools, Measure primarily means:
-
AI activity monitoring — logging AI tool usage in a way that supports both policy enforcement and incident investigation. The key questions: can you detect if an employee submitted restricted data to an AI tool? Can you reconstruct what happened if there is an incident?
-
Policy effectiveness testing — periodic review of whether the controls defined in the Govern function are actually operating. This can be as simple as a quarterly review of the AI activity log: are there violations? Were they detected? Were they responded to? A control that has never been tested is a control whose effectiveness is unknown.
-
Vendor monitoring — for AI providers processing sensitive data, tracking whether their risk profile has changed: new data processing terms, new sub-processors, security incidents at the provider, changes to data residency.
The key Measure distinction: Provider-side logs (OpenAI usage dashboard, Azure AI logs, Anthropic activity logs) are not sufficient to satisfy Measure. They show that your organization made API calls to the provider. They do not show: what policy was in place when the call was made, whether the call was within the scope of that policy, or what happened to the data the provider processed. An independent monitoring layer — one your organization controls — is necessary for effective Measure.
Evidence that satisfies MEASURE:
- An AI activity log capturing user, tool, timestamp, policy decision, and any content detection events
- Evidence of periodic log review (documented review dates and outcomes)
- Vendor change monitoring process (subscription to provider security bulletins, periodic DPA review)
- Evidence that the monitoring would detect a policy violation (a sample of detected events, or documentation that automated alerting is configured and tested)
MANAGE
The Manage function is the response layer — addressing identified risks, remediating problems, and continuously improving the governance program.
What MANAGE asks:
- Are identified risks being addressed?
- Is there a process for responding to AI-related incidents?
- Are governance processes being improved over time?
- Is risk information being shared with relevant stakeholders?
What this means in practice:
-
Risk treatment decisions — for each risk identified in Map and tracked in Measure, document what the organization is doing about it. Risk treatment options: accept (document the acceptance and rationale), mitigate (implement a control), transfer (contractual protection with provider), or avoid (discontinue the AI use).
-
Incident response for AI — extend the existing incident response process to include AI-specific scenarios. At minimum: what happens if an employee submits restricted data to an AI tool? Who is notified? What investigation steps are taken? Is there a GDPR notification obligation? Having a documented runbook for AI incidents, even a brief one, is evidence of Manage in operation.
-
Continuous improvement — the AI RMF treats governance as a cycle, not a project. The governance program should improve based on what Measure reveals: if the log shows a category of policy violations that keeps recurring, the Manage function means adjusting the policy or the technical controls to address them.
Evidence that satisfies MANAGE:
- Risk treatment decisions documented for each identified risk in the inventory
- An AI incident response runbook (or an addendum to the existing IR plan)
- Evidence of governance program updates in response to monitoring findings
- Stakeholder reporting on AI governance status (a brief quarterly summary to the board or leadership)
Mapping NIST AI RMF to practical controls
| AI RMF Function | Key requirement | Practical control |
|---|---|---|
| GOVERN | Named accountability | Designated AI governance owner with documented responsibilities |
| GOVERN | Written policy | AI usage policy with current tool list, data categories, and review date |
| MAP | Tool inventory | AI tool registry with risk ratings, including shadow AI detection |
| MAP | Risk context | Use case documentation for risk-relevant AI deployments |
| MEASURE | Activity monitoring | Independent AI activity log controlled by your organization |
| MEASURE | Control testing | Periodic review of logs and policy enforcement evidence |
| MANAGE | Risk treatment | Documented decisions for each identified risk |
| MANAGE | Incident response | AI incident runbook integrated into existing IR process |
The common implementation shortcut that fails
The most common approach for organizations trying to “implement NIST AI RMF” without dedicated resources is to map existing documentation to the framework’s categories. This produces a gap analysis document that shows which subcategories are “covered” by existing policies.
The problem with this approach is that NIST AI RMF, like most risk frameworks, cares about evidence of operating controls — not documentation that controls exist. A mapping document that says “our acceptable use policy covers GOVERN-1.1” does not demonstrate that the policy is being enforced, that the tool inventory is current, or that anyone is monitoring AI activity.
The distinction matters particularly in the Measure function, where “operating effectiveness” — not just documentation — is the test. An AI activity log showing that a data classification control detected and blocked a sensitive prompt is stronger evidence of Measure than a policy document that says “we monitor AI activity.”
The practical implication: implement the controls before documenting the mapping. The documentation should describe real controls in operation, not policies that aspire to controls that do not yet exist.
What “NIST AI RMF aligned” means for a vendor questionnaire
Enterprise buyers and procurement teams increasingly ask whether vendors are “NIST AI RMF aligned” or “NIST AI RMF compliant.” These terms are not technically defined — the framework is voluntary and has no certification or compliance determination process.
In practice, when a client questionnaire asks about NIST AI RMF alignment, they are asking whether you have implemented governance across the four functions. The best response is not “yes, we are aligned” (which is unverifiable) but a brief description of what you actually have:
- “We maintain a written AI usage policy reviewed quarterly with a named owner. Our approved AI tool inventory includes [N] tools with risk classifications and DPA status. We operate an independent AI activity log that captures [fields]. We have an AI incident response addendum in our existing IR runbook.”
This kind of answer — specific, evidence-grounded, with named artifacts — is more credible than a claim of framework alignment and more useful to the buyer assessing your actual governance posture.
Qadar AI Shield is designed to deliver the Measure function out of the box: independent AI activity logging, policy enforcement controls with operating effectiveness evidence, and an audit trail that satisfies NIST AI RMF fieldwork requests. See how it works.