Enterprise AI Policy Template and Implementation Guide
Written policy becomes enforceable only when runtime systems actually check it.
Enterprise AI governance usually fails for a simple reason: nothing was ever built to enforce it. Most programs already have a written standard somewhere, approved by legal, signed off by leadership, stored in a policy repository nobody outside compliance opens twice a year. The documentation is rarely the problem. The standard describes behavior no system actually checks.
Take a sentence like "customer data must not be sent to third-party models." Written down, that's a sentence. It becomes a control only when something, somewhere, inspects a request payload and rejects it if it violates that rule. Until that inspection point exists, the sentence is aspirational text, no different in effect from a wish.
Every principle inside a real policy has to resolve into one of three things: a process control, like a model risk review before a system goes live; a runtime control, like a redaction rule applied to a prompt before it leaves the network; or an evidence artifact, like an immutable log of who changed a policy and when. Process controls are what most enterprises already handle well, since model risk committees and review boards are familiar territory borrowed from existing compliance functions. Runtime controls and evidence artifacts are where the gaps run deep, and those gaps live in infrastructure, not in the wording of a document.
That's the practical consequence auditors keep finding: written standards sitting next to systems that were never configured to apply them. An AI governance framework is the pairing of a documented policy with the runtime controls that enforce that policy on every model request. Most enterprises have built only the first half.
The common defense, "we have a policy, employees know the rules," misses what's actually running in production. Agentic AI systems don't read policy PDFs. They act on whatever permissions their runtime environment grants them. A rule that lives only in a document is invisible to the system taking the action. The system will do what its configuration allows, policy or no policy.
What enterprise AI policy must cover
A policy with a gap in its scope leaves a hole no technical control can patch later, because there's no written rule for that control to enforce. Before any gateway, registry, or access rule gets built, the policy itself has to cover specific ground completely.
A comprehensive enterprise AI acceptable use policy needs eight components: scope and applicability, approved and prohibited AI tools, data classification rules, human review requirements, confidentiality obligations, incident reporting, training requirements, and enforcement with disciplinary consequences. Each one maps to something downstream, and some map to a great deal more than others.
Scope and applicability sounds administrative, but it's the boundary line everything else depends on. It names which systems the policy governs, which employees it applies to, and which use cases count. No control knows what it's supposed to govern without that line drawn clearly.
Approved and prohibited tools can't be a general statement of preference for "approved enterprise tools." It has to be a named registry: this tool, yes; that tool, no. An AI tool that isn't on that list is an identity in the environment that nobody can account for, and unaccounted-for identities are exactly where enforcement later breaks down.
Data classification sets the rules for what kind of data can go where, and it functions as the schema every downstream access rule reads to decide what a given agent or employee may touch. That's substantial enough to warrant its own full treatment, which follows in the next section.
Human review requirements set clear thresholds for when a person has to approve an AI output or action before it takes effect. If this is skipped, agentic systems default to full autonomy no matter how risky the action is. Incident reporting defines what counts as a reportable AI incident, who it gets reported to, and on what timeline, and it's the precondition for the audit and traceability controls regulators now expect to see.
Confidentiality obligations and training requirements round out the list and matter in their own right, but they don't carry the same weight of technical consequence as the other six. Enforcement and disciplinary consequences close the loop: a policy without teeth is a recommendation, not a governance instrument. Consequences are what turn the document into something people actually change their behavior around.
Data classification as the runtime access-control schema
Data classification is the schema every downstream access rule, every prompt filter, and every agent permission inherits. Get it wrong or leave it incomplete, and every control built on top inherits that same flaw.
The standard model uses four tiers. Public data can go into any approved tool without restriction. Internal data requires an approved enterprise tool, full stop, nothing exotic. Confidential data, the category covering financials, strategic plans, customer lists, and source code, requires an approved enterprise tool that also comes with a no-training contract in place. Regulated or Restricted data, which includes personal data, health data, payment data, credentials, material non-public information, and privileged material, is strictly prohibited from any AI tool without prior review from both Legal and Security.
The no-training requirement deserves specific attention, because it's one of the two most concrete things a security team can actually implement and verify. Every approved large language model has to be configured so company data is excluded from that model's training process. That's a contractual and technical requirement, and it has to be checked at onboarding, not assumed to be true because a vendor's marketing page says so.
The second concrete detail is what happens when classification labels travel into agent workflows. An agent that pulls a document from a regulated data store inherits that document's classification tier the moment it retrieves it. The access control layer has to enforce the matching permission set at the moment of retrieval.
That dependency creates an identity problem: classification tracks data, but nothing tracks the tools and agents touching that data. Every MCP server or AI tool touching classified data is an identity inside the governance system. If that identity doesn't have a registry entry declaring its data-tier permissions, the classification schema has a hole in it, and uncontrolled access flows straight through that hole. A four-tier model only works if every tool and agent that can see data has been accounted for against it, which is exactly the problem the next layer of the stack has to solve.
Building the AI system inventory that makes classification and access control possible
None of the classification work matters against a tool nobody knows exists. A complete, continuously updated AI system inventory is the precondition every other control in this guide depends on. The governing principle is blunt: an organization cannot govern what it cannot see. Every AI model running in production needs a registry entry, and that entry needs an owner, a stated purpose, a list of data inputs, and a risk tier.
Each field in that registry exists to feed a specific control, not to satisfy an audit checklist. Purpose and data inputs tell the access control layer what the system is supposed to touch. Risk classification tells the human review workflow which oversight threshold applies. The responsible team field tells an incident response process who to call when something goes wrong. Stripping any one of these fields out leaves a control downstream without the information it needs to function.
The hardest part of building this inventory is finding everything that belongs in it. Employees bring unapproved tools into their daily workflow because those tools are faster or more familiar. Business teams spin up AI workflows on their own, outside any IT review process. Generative AI gets embedded inside SaaS products enterprises already pay for, often invisible to the discovery tools security teams rely on. Each of these is a classification-tier gap, and the access control layer has no way to close a gap it doesn't know about.
Banning tools outright doesn't solve this problem; it makes it worse. Prohibition pushes adoption underground and destroys the visibility security teams need. Giving employees a governed path to the tools they're already trying to use is what actually reduces shadow AI, because governed access generates registry entries, and registry entries are the raw material every control in this guide operates on.
Agentic systems raise the stakes further. Every new MCP server added to an environment without a corresponding registry entry is an identity nobody can account for, and an identity nobody can account for is the one that eventually gets exploited, because it sits outside every access rule the organization has written down.
Building the inventory once isn't enough. It has to be treated as a live system that gets updated continuously; a one-time audit deliverable goes stale the week after it's produced. New tool onboarding, employee offboarding, and vendor configuration changes all need to update the registry before that change reaches production. That ongoing discipline is what makes the monitoring work described in later stages of a governance program possible.
Turning approved-tool and access rules into enforced permissions at the gateway layer
An approved-tool list sitting in a policy document is a list of intentions until a gateway layer enforces it on every request. The architecture connecting policy to behavior has three layers that have to work together: the policy, which states the rule; the registry, which records identity and classification; and the gateway, which reads both at runtime and acts on every request that passes through it.
Operationalizing an approved-tool policy means the gateway inspects requests before they leave the network, applies data classification rules to the content of prompt payloads, enforces role-based access permissions tied to each agent or user identity, and rejects or redacts anything that violates the policy. All of that has to happen in the request path itself. A violation caught in a report generated the next morning is a violation that already happened.
Role-based access control for AI agents makes "what this agent can do" a decision the organization made on purpose, rather than a default nobody examined. Permissions that were never explicitly granted in the registry should default to denied. That single design choice, deny-by-default instead of allow-by-default, separates a governance program from a hope.
A gateway only governs the traffic that's actually configured to pass through it. Desktop applications, browser-based AI extensions, and coding agents running locally on employee machines can bypass a network gateway without even trying to. The enforcement perimeter has to extend out to the endpoint layer, not stop at centralized API traffic, or an entire category of AI usage runs ungoverned no matter how well-built the gateway itself is.
The same logic extends to agentic pipelines built on MCP servers. When an AI agent invokes an API, whether that's an internal service, a third-party platform, or an MCP server, that action has to sit inside the scope of access control enforcement. It can't be treated as a separate system living outside the gateway's jurisdiction just because it's technically a different kind of call.
In practice, this produces a specific, checkable behavior. Each agent's permitted tool list, its data-tier access, and its action boundaries get declared in the registry, and the gateway reads those declarations at runtime. An agent that attempts to reach a Restricted-tier data source without an explicit permission entry gets blocked at the gateway, in real time. It occurs at the moment of the attempt, visible in the gateway's real-time block, not in a log someone reviews the next day.
Human oversight requirements by risk tier
Human oversight only functions as a control once the policy specifies, tier by tier, the exact point at which a person has to step in, and once the underlying system is built to actually stop and wait when that point arrives. A policy that says "human-in-the-loop" as a general principle, with no defined trigger, isn't something an engineering team can build against.
Risk-tier mapping is what gives that principle an actual shape. A low-risk AI tool answering general employee questions doesn't need the same oversight as a system approving financial transactions, influencing HR decisions, or taking actions inside critical operational infrastructure. The oversight threshold for each of those has to be written into the policy by tier and then enforced inside the workflow itself, not left to an employee's judgment in the moment.
Making that threshold real technically means building a defined pause point into the workflow, a routing mechanism that sends the decision to the correct human reviewer, a timeout and escalation path for when that reviewer doesn't respond, and a record of what the reviewer actually saw and decided. Every one of these is an infrastructure requirement flowing directly out of a single clause in the policy about human review.
Klarna offers a concrete look at what happens when that threshold gets miscalibrated. After pushing hard toward AI-only customer support, the company saw customer satisfaction slip, and it moved to a hybrid model: keeping the AI agent for routine interactions while routing disputes, complex refunds, and hardship cases to human staff. That's a real-world case of risk-tier segmentation determining who handles oversight, arrived at only after the cost of getting the calibration wrong became visible in the metrics.
The regulatory backdrop makes this more than a best practice. Under the EU AI Act, prohibited AI practices and AI literacy duties took effect in February 2025. General-purpose AI provider obligations took effect in August 2025. Article 50 transparency rules and AI content labeling applied starting August 2, 2026, with a transition grace period running until December 2, 2026 for providers of systems already on the market before that date to meet the machine-readable marking requirement.
Two deadlines moved rather than disappeared. Annex III obligations for standalone high-risk systems shifted from August 2, 2026 to December 2, 2027. Obligations for AI embedded in products already covered by existing EU product-safety law moved to August 2, 2028. The deferral changed the calendar, not the underlying work still required to meet it.
Agentic AI and multi-agent pipelines sit explicitly inside this regulatory scope. When an AI agent invokes an API, whether that's an internal service, a third-party platform, or an MCP server, that action layer falls under the Act's cybersecurity and logging mandates. The same architecture built to enforce access control at the gateway layer is the architecture that produces the audit trail regulators are now asking enterprises to show.
