Updated June 9, 2026
TL;DR: Mapping AI controls to NIST AI RMF 1.0 requires system-level enforcement across all four functions, Govern, Map, Measure, and Manage, that generates audit artifacts auditors can examine directly. A crosswalk table and per-function artifact checklist are included below. The mapping only holds up when each subcategory maps to a system-level enforcement mechanism that generates continuous evidence, not a policy document that depends on manual compliance between audit cycles.
Most AI governance programs produce documents, not controls. Policies get written, crosswalk tables get built, and audit cycles pass, until an auditor asks for evidence of continuous enforcement and the only answer is a spreadsheet that was last updated before the last model deployment.
That gap is widening. Engineering teams ship AI-integrated workflows faster than governance processes can capture them, and the audit artifacts auditors now expect for AI systems don't exist inside the spreadsheet-and-email approach traditional IT teams built for infrastructure controls.
A documented policy that isn't enforced at the system level is not a control. It is a liability waiting to surface in the next audit cycle. NIST AI RMF 1.0 (NIST.AI.100-1), published January 26, 2023, organizes AI risk management around four functions, Govern, Map, Measure, and Manage, that operate as a continuous, iterative cycle, not sequential checkboxes. Mapping to that framework is the right starting point, but only when the mapping produces system-level enforcement that generates continuous evidence.
This guide walks through each function, connects it to specific enterprise controls, and shows what audit-ready documentation looks like in practice.
The Govern function establishes organizational accountability for AI risk. It covers:
Without a functioning Govern function, the other three functions have no defined authority structure to report into.
Use this table as your working crosswalk. Map each subcategory to an enforcement mechanism and the artifact it produces.
|
NIST AI RMF Function |
Subcategory |
Example Enterprise Control |
Enforcement Mechanism |
|---|---|---|---|
|
Govern |
GOVERN 1.1: Legal and regulatory requirements involving AI are understood, managed, and documented |
AI regulatory register with documented requirements |
AI governance policies configured on the Admin Console Govern page |
|
Govern |
GOVERN 1.2: The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures |
AI ethics and trustworthiness policy with defined principles |
AI system registration links policies to every registered model and tool |
|
Map |
MAP 1.1: Intended purpose, potentially beneficial uses, context-specific laws, norms, expectations, and deployment settings are understood and documented |
Documented AI system inventory capturing context, intended use, and deployment scope per system |
AI system registration capturing context, intended use, and deployment scope per registered system |
|
Map |
MAP 5.2: AI system risk or benefit levels are mapped based on AI risk assessments, categorizations, and resulting prioritization |
Risk assessment documentation per AI system capturing risk level, categorization, and prioritization |
System context and risk classification captured at registration and linked to governance policies |
|
Measure |
MEASURE 2.5: The AI system satisfies its design goals and intended purpose, evaluated against TEVV documentation and audit evidence |
Structured audit logs tied to specific AI interactions and retained as TEVV evidence |
SIEM- and SOAR-ready audit logs generated inside the customer's infrastructure |
|
Measure |
MEASURE 4.1: Monitoring approaches are in place, including mechanisms for capturing and evaluating user and AI actor inputs |
Continuous monitoring dashboards, threshold alerts, and structured detection event records |
Native SIEM/SOAR forwarding to Splunk and Datadog |
|
Manage |
MANAGE 2.2: Mechanisms to sustain the value of deployed AI systems are evaluated and applied |
Documented AI incident response runbook and risk treatment procedures |
Detection events forwarded natively to SIEM/SOAR for investigation |
|
Manage |
MANAGE 4.1: Post-deployment monitoring plans are implemented, including mechanisms for capturing and evaluating inputs, appeals, overrides, decommissioning, incident response, recovery, and change management |
Post-deployment monitoring logs, incident response records, and change management documentation |
Audit logs capture policy violations with structured event records |
GOVERN 1.1 requires that legal and regulatory requirements involving AI are understood, managed, and documented. That requirement is impossible to satisfy when you don't have a complete inventory of which AI systems are in scope. A control plane architecture that enforces governance at the system level provides a structured approach to this problem. One implementation approach is a structured AI System registration capability that lets organizations register models, Model Context Protocol (MCP) servers, datasets, and dependencies into governed AI Systems. MCP is a standardized protocol that allows AI systems to connect to external tools, databases, and data sources, expanding what the model can access and act on at runtime. This produces a structured inventory auditors can examine directly. Deploying this capability via a self-hosted control plane ensures registration and policy enforcement happen inside the organization's own infrastructure rather than on a vendor's.
GOVERN 1.2 requires that trustworthy AI characteristics are integrated into organizational policies, processes, procedures, and practices. When accountability lives in a document but operational controls don't mirror it, auditors will find the gap. The Prediction Guard Admin Console Govern page lets security and GRC teams configure AI governance policies once, and the control plane enforces those policies at the API level across every AI interaction, regardless of which SDK the developer used, as demonstrated in the secure AI control plane overview (video: policy configuration and API-level enforcement walkthrough). Developers don't change their code. Only the base_url changes.
The Map function establishes risk context for each specific AI system: its intended use, the data it processes, the potential impacts of failure or misuse, and the third-party components it depends on. Without Map, Measure has nothing meaningful to assess and Manage has no defined risk surface to treat.
MAP 1.1 requires a documented description of each AI system and its context. The closest analog in existing enterprise controls is ISO 27001:2022 Annex A.5.9, part of the Organizational Controls, which requires organizations to identify information assets and maintain a documented inventory. For AI systems, that inventory must extend beyond hardware and software to include models, tools, MCP servers, and the datasets they process. Teams operating across fragmented AI environments often find that their ISO 27001 asset inventory captures none of their AI assets, leaving a direct gap in MAP 1.1 coverage.
MAP 5.2 requires that risk context for each AI system is documented, including potential impacts and affected stakeholders. To make MAP 5.2 concrete, take a hypothetical AI document processing workflow handling regulated financial data: the MAP 5.2 artifact would include data inputs (document types and classification), potential failure modes (incorrect extraction, unauthorized disclosure), affected stakeholders (customers and regulators), and the controls that reduce each risk. This documentation feeds directly into the Measure function's assessment scope.
The AI Bill of Materials (AIBOM) is the exportable view of what you registered in AI System registration, produced in CycloneDX format. CycloneDX is an open standard format for software bill of materials that provides a structured, machine-readable inventory format recognized by security and compliance tools, making it easier for auditors to validate asset inventories across organizations. For the Map function, it answers the auditor's asset question: which models are in production, which tools are connected, and which datasets are in scope. Regulated organizations need an audit artifact they can present to an auditor without assembling it manually from spreadsheets. Prediction Guard built the CycloneDX AIBOM export to satisfy that requirement, and the company sponsors the OWASP AIBOM project to advance the broader standard for AI asset transparency.
The Measure function requires quantitative and qualitative assessment of the risks identified in Map. For compliance leaders, this is where advisory guidelines fail: an AI governance policy document can't generate a test result or a monitoring log.
MEASURE 2.5 requires that AI risk evaluation methods are identified and that documentation is tied to specific system interactions. A self-hosted control plane enforces NIST AI RMF and OWASP policies at the API level across every model interaction, generating structured audit logs consumed by the organization's SIEM inside their own infrastructure. The control plane generates the log. The customer's SIEM stores it. For a regulated organization, audit evidence that lives on a vendor's infrastructure is evidence outside the organization's control.
MEASURE 4.1 requires that AI system monitoring is continuous, not periodic. To make MEASURE 4.1 concrete, consider a hypothetical manufacturing environment handling controlled unclassified information (CUI): every AI interaction that touches controlled data flows through the control plane, where system-level security checks run at the API level. Detection events, including prompt injection attempts, policy violations, and output anomalies, forward natively into Splunk or Datadog via the SIEM/SOAR integration. The compliance team has a continuous evidence stream, not a point-in-time snapshot assembled before each audit.
Three audit artifact types support Measure function evidence requirements:
The Manage function requires allocating resources to treat identified risks, documenting residual risk, and responding to incidents. For AI systems, risk treatment options are avoidance (remove the activity), mitigation (apply a system-level control that reduces the risk), acceptance (document residual risk with explicit sign-off), and transfer (shift risk via contract or insurance). Acceptance requires a documented rationale. Transfer requires a vendor agreement that assigns accountability and specifies audit rights.
MANAGE 2.2 requires that mechanisms to sustain the value of deployed AI systems are evaluated and applied, including executable incident response plans. A defensible implementation: when the control plane detects an AI governance policy violation, it generates a structured detection event that forwards to your SIEM via native Splunk or Datadog integration. Your security operations team investigates using their existing workflow, with the original AI input, the AI governance policy triggered, and the response action all documented in the event record. That chain of evidence satisfies the MANAGE 2.2 artifact requirement without manual assembly.
Control drift occurs when a control satisfied a previous audit but no longer reflects operational reality, and it is the most common source of compliance findings that catch teams off guard. MANAGE 4.1 addresses post-deployment AI system monitoring plans, including mechanisms for incident response, change management, and ongoing operational monitoring. System-level enforcement prevents drift by design: AI governance policies configured on the Admin Console Govern page apply to every API call, not just the ones made on the day the policy was last reviewed. Most organizations now conduct 4 or more audits annually, and manual drift detection between those cycles is operationally unsustainable for the 58% reporting that frequency in 2025.
Audit readiness requires more than a completed crosswalk table: it requires specific, examiner-facing documentation for each NIST AI RMF function. The sections below provide a per-function artifact checklist and a structured process for populating and maintaining your control mapping.
Use this checklist to verify that each NIST AI RMF function has the specific documentation an auditor will request. Print or export this table as your internal audit preparation guide.
|
NIST AI RMF function |
Suggested artifact 1 |
Suggested artifact 2 |
Suggested artifact 3 |
|---|---|---|---|
|
Govern |
Signed AI governance policy |
Documented AI system inventory |
RACI (Responsible, Accountable, Consulted, Informed) or ownership assignments |
|
Map |
AI system inventory with documented use case and risk classification |
Data flow diagrams |
Risk impact assessments per system |
|
Measure |
Structured interaction audit logs |
Documented risk evaluation results per system |
Continuous monitoring dashboard exports |
|
Manage |
Incident response reports |
Documented residual risk acceptance records |
Remediation evidence with timestamps |
Fill the crosswalk table in this order to build a defensible mapping:
The crosswalk table is only as accurate as the system state it reflects. Point-in-time documentation drifts the moment the engineering team deploys a new model or connects a new tool that isn't registered. Continuous enforcement at the API level means the control applies to new interactions automatically, and keeping AI System registration current means the AIBOM export reflects what's actually in production. That is structurally different from manually updating a spreadsheet after each deployment, as covered in the self-hosted sovereignty episode.
NIST AI RMF does not exist in isolation. Most regulated organizations must satisfy OWASP, ISO/IEC 42001, or EU AI Act requirements alongside it. The sections below show how a single control plane implementation can satisfy multiple frameworks without duplicating documentation.
For organizations deploying AI agents, the OWASP Agentic AI Top Ten (2026) is the applicable security taxonomy for production agentic systems with tool access, RAG pipelines, and multi-model architectures. OWASP is a security-specific taxonomy that plugs into NIST AI RMF under the Measure and Manage functions. A practical cross-mapping: configuring agentic threat detection (covering agent goal hijacking, tool misuse, and prompt injection) in the control plane satisfies both the OWASP agentic requirements and the NIST Measure/Manage artifact requirements simultaneously, as covered in EP04: practical implementation of OWASP guidance.
The most efficient approach to multi-framework compliance is a single control that satisfies multiple requirements. A structured AI interaction audit log generated by a self-hosted control plane satisfies MEASURE 2.5 (NIST), ISO 27001:2022 Annex A.8.15 logging control, and EU AI Act monitoring obligations, producing a single audit artifact that covers all three frameworks. Fragmented data has made compliance more difficult for 63% of executives, and centralizing enforcement inside a single control plane resolves that fragmentation at the architectural level, which is the approach detailed in the AI tools harmonization guide. For organizations with EU exposure, ISO/IEC 42001:2023 maps directly to all four NIST AI RMF functions, so organizations that build their control mapping around NIST AI RMF functions also build most of the evidence they need for ISO 42001 and EU AI Act alignment.
For organizations in manufacturing, defense-adjacent, or aerospace environments where data cannot leave the organization's perimeter, every artifact in this guide is generated inside your own infrastructure when using Prediction Guard.
Book a deployment scoping call to assess whether self-hosted deployment fits your infrastructure and regulatory requirements.
System-level enforcement applies governance policies to every AI interaction automatically, generating audit logs that reflect actual enforcement state rather than a point-in-time snapshot assembled for audit. No manual review or engineer intervention is required between cycles.
Document the control once with a clear enforcement mechanism, then reference it across all applicable subcategories in your crosswalk table. A single structured audit log satisfies both MEASURE 2.5 and MANAGE 2.2 without requiring separate artifacts.
Partially: AI System registration automates the Map function's asset inventory artifact, SIEM-ready audit logs automate Measure function evidence, and Admin Console configuration automates Govern enforcement. Narrative risk assessments and residual risk sign-offs still require human judgment.
Native SIEM/SOAR integration generates a structured event for every AI interaction, creating continuous monitoring by architecture rather than procedure. The structured event records generated per interaction are available in your SIEM for auditor review across any defined audit period.
Admin Console: The Prediction Guard administration interface where security and GRC teams configure AI governance policies, manage AI System registration, and access enforcement settings. Policies configured in the Admin Console apply at the API level across every AI interaction routed through the Prediction Guard control plane.
NIST AI RMF (AI Risk Management Framework): A framework published by the National Institute of Standards and Technology on January 26, 2023 (NIST.AI.100-1) that organizes AI risk management around four functions, Govern, Map, Measure, and Manage. The functions operate as a continuous, iterative cycle rather than sequential checkboxes, and the accompanying NIST AI RMF Playbook breaks each function into subcategories with suggested actions that compliance teams use as a starting point for control mapping.
Control plane: The infrastructure that enforces governance policies, routes requests, and generates audit logs across all AI interactions. A self-hosted control plane applies policy rules at the API level automatically for every model call, distinguishing system-level enforcement from advisory guidelines that depend on manual compliance and generating continuous audit evidence inside the organization's own infrastructure.
AIBOM (AI Bill of Materials): A structured, exportable inventory of every AI component registered in a governed environment, including models, MCP servers, datasets, and dependencies, produced in CycloneDX format as a byproduct of AI System registration. For the NIST AI RMF Map function, the AIBOM answers the auditor's asset question directly: which models are in production, which tools are connected, and which datasets are in scope.
Control drift: The divergence between a documented governance control and actual system enforcement that accumulates between formal audit cycles. Control drift is the most common source of compliance findings that catch teams off guard, and it occurs when a control satisfied a previous audit but no longer reflects operational reality, for example when a new model is deployed without being registered or a policy document is updated without a corresponding change to system-level enforcement.
MCP server (Model Context Protocol server): A server implementing the Model Context Protocol, an open standard that allows AI systems to connect to external tools, databases, and data sources, expanding what the model can access and act on at runtime. MCP servers are captured as governed components in AI System registration because they extend model capabilities and introduce data flows that fall within the scope of NIST AI RMF Map function documentation requirements.