A Practical Enterprise Guide to AI Governance: Mapping NIST AI RMF (and Related Guidance) to Enforceable Controls

Overview

This guide shows how to turn NIST AI RMF into enforceable enterprise controls across the AI lifecycle (build, deploy, run). You’ll get a practical control-family mapping, an evidence/logging checklist for audit readiness, and a 30/60/90-day rollout plan to govern GenAI, embedded SaaS copilots, and internal AI apps.

Introduction: AI governance is an operational problem, not a policy problem

Here is a scenario that plays out every day across enterprise security teams. Someone in finance pastes a quarterly forecast into ChatGPT to clean up the formatting. A developer uses an AI coding assistant that quietly routes completions through an external model endpoint. A new software as a service (SaaS) platform update quietly activates an embedded artificial intelligence (AI) copilot that now has access to your customer relationship management (CRM) data.

Nobody did anything wrong, exactly. But your sensitive data just left the building, and your acceptable use policy did nothing to stop it.

This is the core problem with how most organizations approach AI governance. They treat it as a documentation exercise. Draft a policy, circulate it, check the box. But with 100% of industries now engaging with AI in some form, written guidelines cannot keep pace with how fast AI is moving into your environment—and they have no mechanism to stop the risks that come with it.

The National Institute of Standards and Technology AI Risk Management Framework (NIST AI RMF) gives you the structure to think about this problem correctly. What it does not give you is enforcement. That gap between framework guidance and controls that actually work in real time is what this guide is designed to close. So let's close that gap.

We'll break down NIST AI RMF in plain English, map controls across the build, deploy, and run lifecycle, cover evidence and logging requirements, and give you a 30/60/90-day rollout you can actually execute. One goal throughout: turn governance guidance into enforceable controls with full visibility across public GenAI, embedded SaaS copilots, and internally developed AI.

What AI governance frameworks do (and don't) solve

Frameworks are not the problem. They are genuinely useful. NIST AI RMF gives security and compliance teams a shared risk taxonomy, common language, and a reporting structure that works across security, legal, IT, and app teams. When everyone is using the same vocabulary, it is much easier to align stakeholders around actual outcomes.

The problem is what frameworks cannot do, and what too many organizations assume they can.

A framework cannot block a user from pasting source code into ChatGPT. It cannot detect a prompt injection attack in real time. And it does not account for how modern AI systems actually communicate.

Most frameworks also predate the explosion of AI features embedded in enterprise SaaS platforms, which means the risk categories they describe do not fully map to where your exposure actually lives.

What breaks in practice:

• Transaction-based web filters do not work for multi-turn AI conversations
• Keyword matching is not contextual understanding
• Firewalls and virtual desktop infrastructure (VDI) solutions cannot govern AI sessions and modern protocols without significant added cost and operational complexity
• Legacy tools have no awareness of persistent WebSocket connections, Model Context Protocol (MCP) servers, or multi-turn contextual conversations that look nothing like traditional HTTP traffic

The organizations that succeed at AI governance use frameworks as the foundation for policy development and layer technical controls on top to make those policies enforceable. That translation, from principle to enforcement, is where the work actually happens.

NIST AI RMF: Key functions

The NIST AI RMF organizes AI risk into four interconnected functions. On paper, they can read like audit-speak. In practice, each one maps to a set of operational decisions your team needs to make. Here is what they actually mean.

Govern: Set the rules before you need them

Most organizations establish AI policies reactively, after an incident, after a compliance inquiry, after someone in Legal raises an alarm. The Govern function is about getting ahead of that.

Define acceptable use policies that reflect how your organization actually works. Sales teams need AI writing assistants. Engineering teams need code completion tools. A productivity tool that summarizes meeting notes carries different risk than a customer-facing chatbot handling sensitive inquiries. Your policies should reflect those distinctions, not flatten them.

Strong governance policies share four characteristics:

• Specific rather than vague: "Marketing may use approved GenAI tools for draft content creation" beats "Use AI responsibly."
• Role-based: Different functions have different needs and different risk profiles.
• Actionable: Clear enough that someone could write enforcement rules from them.
• Maintainable: Structured so updates are straightforward as AI capabilities evolve.

Establish a clear definition of sanctioned AI versus prohibited use. Blocking all AI is neither practical nor desirable. The goal is governed adoption. Identify your evidence requirements, logs, inventories, and testing results, before an auditor asks for them. Being audit-ready is dramatically easier when you design for it from the start.

Map: Know what you're actually dealing with

The Map function is where most enterprises get a humbling reality check. When security teams do their first serious AI inventory, they almost always find more than they expected, often significantly more.

The instinct is to focus on the obvious: ChatGPT, Gemini, Claude. But the harder discovery challenge is everything else.

AI asset categories that are commonly missed:

• Browser extensions with AI-powered writing assistants
• Mobile applications with AI tools on corporate devices
• API integrations where custom applications call AI services directly
• Embedded copilots that activate automatically inside your SaaS platforms
• Developer tools, including integrated development environments (IDEs), command-line interfaces (CLIs), and MCP servers

A complete inventory is not just a list of apps. It is a map of data flows, where information enters AI systems, how it moves, and where it could end up. Establish AI supply chain lineage via an AI Bill of Materials (AI-BOM): trace datasets to models to runtime usage to understand where risk originates and propagates. This is where governance starts.

Measure: Test what you think you know

Having controls in place is not the same as having controls that work. The Measure function is about closing that gap, continuously, not just at annual assessment time.

Continuous validation requires two layers: automated adversarial testing through AI red teaming (simulating attack techniques including prompt injection, jailbreaks, and context poisoning) and ongoing model evaluation as models and their risk profiles evolve.

AI-specific attack patterns that traditional tools miss:

• Indirect prompt injection: Malicious instructions embedded in documents or data sources that the AI processes—our firewall never sees it
• Context manipulation: Attacks that corrupt the information available to AI systems
• Capability elicitation: Techniques that convince AI systems to perform actions outside their intended scope
• Training data exposure: Methods that extract sensitive information from model weights

These are not edge cases. They are active attack patterns that require purpose-built detection.

Manage: Turn findings into enforcement

Governance without enforcement is just documentation, and documentation does not stop attacks.

The Manage function is where governance programs either prove their worth or expose their limits.

When adversarial testing reveals that a particular attack technique succeeds against your AI application, what happens next? In a mature program, the answer is automatic: a runtime guardrail deploys to block that technique in production. The loop between finding and fix closes without a manual remediation cycle in between.

Exception processes matter too. Legitimate business needs will fall outside standard policies. A well-designed exception process documents the business justification, applies compensating controls, and sets review dates to confirm the exception remains necessary. It keeps flexibility without creating permanent blind spots.

Control mapping across the AI lifecycle: Build, deploy, run

Most AI security programs start at runtime, inspecting traffic after AI is already in production. That is the wrong starting point. Risk accumulates across every phase: in the training data, the deployment configuration, and the runtime interaction. Controls need to match.

Build: Development and data preparation

Most build-phase risk goes undetected because traditional security tools were not designed for AI infrastructure. Overly permissive model access, unprotected training pipelines, shared credentials across environments, and missing input validation all create exposure that surfaces later, at runtime, when it is far more expensive to fix.

The starting point is inventory. That means training datasets and data sources, developer environments, authorization models (such as Microsoft Entra ID for agents and AWS Identity and Access Management (IAM)), and AI infrastructure components: large language models (LLMs), MCP servers, and agent platforms. Apply training data controls, enforce least privilege, and track model lineage—publisher, licensing terms, and risk factors all included. Know what you built with before you ship it.

AI security posture management (AI-SPM) makes this visible at scale, surfacing misconfigurations, excessive permissions, sensitive data exposure, and vulnerabilities across GenAI SaaS, embedded agentic AI in SaaS, and internally developed AI, with risk scoring to prioritize what gets fixed first. AI-BOM lineage tracks the full AI supply chain and associated authorization models. Compliance benchmarking maps posture findings to frameworks like NIST AI RMF and the EU AI Act, so you are not running a separate audit process on top of your security workflow.

Build phase checklist

• Inventory training datasets, data sources, developer environments, and AI infrastructure components
• Map authorization models (Entra ID, AWS IAM) for agents and services
• Enforce least-privilege access to training data and model endpoints
• Track model lineage: publisher, licensing terms, and associated risk factors
• Run AI-SPM to surface misconfigurations and excessive permissions before they reach production
• Establish AI-BOM traceability across your full AI supply chain

Deploy: Release, configuration, and access paths

The window between development and production is where a lot of AI security programs go quiet. Configurations get set once and are not revisited. Permissions that made sense in a dev environment carry forward into production. By the time something goes wrong, the misconfiguration is already load-bearing.

Misconfigurations and excessive permissions are far easier to fix before an AI app reaches production than after. Traditional vulnerability scanning, cloud security posture management (CSPM), cloud workload protection platforms (CWPP), and virtual firewalls leave gaps when applied to AI apps because they were built for different threat models. Pre-production assessment needs to account for AI-specific risks: not just common vulnerabilities and exposures (CVEs), but also misconfigurations, permission sprawl, and integration risks specific to AI systems. Apply approval gates and change control to AI deployments the same way you would to any production system. Treat your AI deployment pipeline as a security boundary.

A purpose-built AI security platform handles this at the deploy phase by providing risk analysis across SaaS and internally developed AI apps and infrastructure before they go live, with prioritized remediation guidance so teams know exactly what to address and in what order. Continuous automated adversarial testing across build, deploy, and runtime phases, with remediation tracking as AI environments evolve, replaces the point-in-time assessment model that leaves gaps between audit cycles. Custom policy creation and governance requirement mapping support compliance alignment at the deployment stage rather than scrambling to retrofit it after.

Deploy phase checklist

• Review all configurations and entitlements before any AI app reaches production
• Apply approval gates and change control to AI deployments the same way you would any production system
• Run pre-production AI-SPM risk analysis to catch AI-specific misconfigurations that CVE-based scanning will miss
• Validate that the system resists prompt injection, jailbreaks, and data extraction before go-live
• Map deployment configurations to governance requirements and document for audit readiness

Run: Production usage and runtime interactions

Runtime is where most security programs focus, but the threat surface here is more complex than legacy tools were built to handle. Many GenAI services rely on WebSockets rather than traditional HTTP. Developer tools increasingly use MCP. Multi-turn AI conversations carry context across interactions in ways that a transaction-based inspection model simply cannot follow. Governing AI at runtime means accounting for this protocol-level complexity, not just URL categories and request/response snapshots.

When an employee pastes confidential information into an AI prompt, you need inline inspection that can block that transmission before the data leaves your environment. When a prompt injection attack attempts to manipulate your AI application through malicious content embedded in a document it is processing, you need detection that understands what the model is being asked to do, not just what the request looks like on the wire.

Inline inspection prevents data loss and protects against advanced threats at the prompt and response layer. Access controls by user and group, with allow, block, warn, and isolation enforcement modes, let you apply graduated policy rather than blunt category blocks. Secure browser technology extends coverage to unmanaged and bring-your-own-device (BYOD) access, so unmanaged devices do not become the path of least resistance. Prompt extraction and classification covers request and response traffic across dozens of GenAI apps. Advanced AI detectors support content moderation, flagging off-topic or policy-violating usage before it becomes a compliance event. Applying zero trust principles to AI development environments adds inline controls for IDEs connecting to AI infrastructure. Runtime guardrails and detectors address prompt injection, personally identifiable information (PII), source code leakage, and unsafe outputs across production AI systems.

Run phase checklist

• Deploy access controls by user and group for all generative and embedded AI apps
• Enable inline data loss prevention (DLP) on prompts and uploads for sensitive data types
• Extend coverage to unmanaged and BYOD devices via secure browser technology
• Activate prompt extraction and classification across major GenAI apps
• Deploy runtime guardrails with detectors for prompt injection, jailbreaks, PII leakage, and content moderation
• Confirm your inspection layer handles WebSocket and MCP traffic, not just HTTP

Turning guidance into enforcement: The control families

Knowing where controls apply is only half the equation. The other half is understanding what those controls actually are and how they work together as a unified enforcement layer rather than a stack of point tools.

AI asset management: Discovery and posture

AI asset management is the foundation. You cannot enforce policies against AI you cannot see.

Shadow AI detection identifies unsanctioned generative AI applications that employees use without approval. It also surfaces AI features embedded within sanctioned SaaS platforms that may have activated without explicit awareness, because SaaS platforms are increasingly AI apps, whether you configured them that way or not.

AI-SPM goes further, evaluating AI-specific risks across your portfolio: misconfigurations, excessive permissions, sensitive data exposure, and known vulnerabilities, with risk scoring and guided remediation to focus effort where it matters most. This extends across services, agents, and retrieval-augmented generation (RAG) frameworks. AI agent detection covers both embedded SaaS agents and enterprise-deployed agents, with visibility into related traffic flows.

AI access security: Who can use what, and how

Access security determines which users can interact with which AI applications and under what conditions.

Policy enforcement modes, from least to most restrictive:

• Full access: Approved apps and user groups with no restrictions
• Warning mode: Triggers data handling reminders at the point of interaction
• Browser isolation: Prevents direct data transfer for sensitive applications
• Complete blocking: Reserved for the highest-risk cases

Isolation also functions as an enforcement mode, controlling copy/paste and actions within AI sessions. Secure browser technology extends this coverage to unmanaged devices. Granular upload controls restrict what data users can send to AI applications.

Two principles to anchor your approach: enable sanctioned AI safely rather than defaulting to blocking everything, and do not rely on keyword-only or transaction-based controls for multi-turn AI conversations.

Data security: What data can be shared

Most data leakage conversations focus on what goes into an AI prompt. The response layer is just as important and more often overlooked. A model that has been fed sensitive context through retrieval-augmented generation pipelines, connected data sources, or prior conversation turns can surface that information in its outputs even when the original prompt looked clean. Enforceable data security means covering both directions: inline DLP on prompts and uploads for source code, PII, PCI, and PHI, and response-layer detectors that catch leakage on the way out.

Content governance: Acceptable use

Content governance enforces organizational policies about how AI gets used, beyond data protection. Advanced AI detectors analyze prompts and responses to detect policy-violating usage, including toxic content, off-topic interactions, restricted topics, and competitive topics, and enforce appropriate controls. This is contextual understanding applied at scale, not keyword matching.

AI red teaming and governance mapping: Continuous policy alignment

Red teaming provides ongoing validation that AI systems resist attack and meet governance requirements. Automated adversarial testing using thousands of simulated attack techniques tests your AI applications continuously, not just at point-in-time assessments. Prompt hardening and testing simulates exploitation of system prompts, then generates hardened alternatives with step-by-step guidance.

The enforcement side is where this pays off: a runtime detector library covering jailbreaks, prompt injection, data leakage, and content moderation, combined with automated policy generation that translates red teaming findings directly into production guardrails. When a test finds a vulnerability, the fix deploys to runtime. AI security controls map to NIST AI RMF and EU AI Act requirements, making governance readiness an output of your security program rather than a separate workstream.

Evidence and auditability: What to log to prove governance

Governance programs must demonstrate compliance, not just claim it. Proper evidence collection supports audits, investigations, and regulatory inquiries.

Minimum evidence set (Baseline)

Start with asset inventory: all AI models, agents, and services operating in your environment, where they are deployed, and their dependencies. Add data assets connected to AI, including datasets, vectors, and exposure status, and access paths and entitlements showing who and what can reach sensitive training data. AI-BOM-style lineage evidence traces datasets to models to runtime usage to support traceability requirements.

Interaction evidence (Runtime)

At the runtime layer, log the following:

• Prompt and response activity through extraction and classification. You do not necessarily need to store full text. Classification metadata often satisfies audit requirements.
• DLP events with blocked/allowed status and dictionary hit type
• Access policy actions: warn, block, isolate, and copy/paste restrictions
• Content moderation events with topic classification and enforcement action
• Agent visibility evidence: detected agents, both embedded and enterprise-deployed, along with related traffic flows

Governance reporting

Compliance posture dashboards show framework alignment status and highlight areas of drift. Remediation tracking documents how identified issues get addressed. Audit-ready reporting outputs support both internal and external audits.

30/60/90-day rollout plan for enforceable governance

Implementing AI governance works best as a phased program that builds capabilities progressively while delivering value quickly.

First 30 Days: Establish enforceable baselines

Start with discovery. Surface the unsanctioned GenAI applications and embedded SaaS AI features already in use across your organization. This number is almost always larger than expected.

Priority actions in the first 30 days:

• Discover AI usage and assets: shadow AI and AI ecosystem inventory
• Define initial policies covering allowed apps, restricted data types, and acceptable use
• Enable prompt and response visibility and classification across major GenAI apps
• Turn on inline DLP for prompts covering source code, PII, PCI, and PHI data types
• Deploy access controls (warn, block, and isolate) for the top GenAI applications in use

Set your foundational guardrails early: do not treat AI as standard web traffic, and do not rely on keyword-only or transaction-based policies for multi-turn AI conversations.

Days 31 to 60: Expand controls and posture management

Priority actions in days 31 to 60:

• Extend discovery to models, agents, services, datasets, vectors, and developer tool paths including IDEs and CLIs
• Establish AI-BOM traceability from datasets and data sources to models to runtime usage, including authorization models like Entra ID for agents and AWS IAM
• Assess misconfigurations and excessive permissions, and prioritize remediation using AI-SPM risk scoring
• Implement guided remediation workflows and enforce least-privilege across your AI portfolio
• Add content moderation policies for off-topic, toxic, restricted, and competitive content
• Introduce continuous red teaming and prompt hardening for critical AI applications
• Begin compliance benchmarking and reporting against NIST AI RMF, the EU AI Act, HIPAA, and GDPR as applicable

Days 61 to 90: Operationalize continuous governance

Priority actions in days 61 to 90:

• Automate governance mapping of AI risks to frameworks for ongoing NIST AI RMF and EU AI Act readiness
• Deploy runtime guardrails and detectors for prompt injection, jailbreaks, data leakage, and content moderation
• Use automated policy generation to push red teaming findings directly into enforceable runtime policies
• Set up continuous monitoring for drift, new assets, new AI apps, and new risk classes
• Standardize audit packages with monthly and quarterly reporting cycles and evidence retention that meets your regulatory requirements

With the right framework stack in place, the question becomes execution.

Related guidance to reference beyond NIST AI RMF

NIST AI RMF provides a strong foundation for AI governance, but several complementary frameworks address specific aspects of AI risk. Use them together rather than treating them as competing options.

Depending on your industry and geography, NIS2, DORA, HIPAA, GDPR, and SAMA requirements may also apply. The practical approach: use NIST AI RMF as the governance foundation, incorporate EU AI Act requirements for applicable systems, reference the Open Worldwide Application Security Project (OWASP) for technical implementation, and leverage MITRE Adversarial Threat Landscape for AI Systems (ATLAS) for threat modeling.

How Zscaler supports enforceable AI governance

Most AI security conversations end up in the same place: a stack of point tools that each solve one slice of the problem without talking to each other. You get a posture tool, an access tool, a DLP tool, a red teaming tool, and a governance program that is more fragmented than the risk it is trying to address.

Zscaler AI Security is built differently. It extends the Zero Trust Exchange™ platform, already proven at enterprise scale for users, workloads, clouds, and branches, to cover the full AI lifecycle from build through deploy through run. Inventory, access control, posture management, and runtime guardrails are designed to work together. And when red teaming finds a vulnerability, enforcement deploys automatically. That closed loop is not a feature. It is the architecture.

What this looks like in practice:

• AI Asset Management and AI-SPM: Full AI ecosystem visibility across GenAI SaaS, embedded agentic AI in SaaS, and internally developed AI. AI-BOM lineage, AI agent detection, AI-SPM risk scoring, and prioritized remediation are all part of the same workflow.
• AI Access Security: Controls that go beyond URL categories: allow, block, warn, and isolate by user and group, with prompt extraction and classification, and Zero Trust Browser coverage for unmanaged devices.
• AI Red Teaming and AI Guardrails: Continuous adversarial testing, prompt hardening, automated policy generation, and runtime guardrails that stay current as your AI environment evolves.
• Governance mapping: AI security controls map to NIST AI RMF and EU AI Act requirements as a natural output, not a separate reporting workstream bolted on at the end.

AI governance does not have to be a choice between security and speed. The organizations moving fastest on AI adoption are the ones that built enforceable controls early, so they can say yes to AI with confidence, not just caution.

Request a demo of Zscaler AI Security today.