AI Acceptable Use Policy Template: A Working Baseline for Enterprise AI Governance
An AI acceptable use policy that lists banned tools is already outdated by the time the ink dries. A useful policy describes the categories of allowed use, the data classifications each category may touch, the enforcement mechanism that prevents drift, and the audit posture that makes a breach reconstructable. This template covers the policy structure, the per-role permissions, the enforcement plane that turns the policy from advisory into binding, and the audit record that survives the post-incident review.
The CISO who circulates an "approved AI tools list" by email on a Friday has a policy artifact by Monday and a shadow AI problem by Tuesday. The 78% of employees who use unauthorized AI tools (Cloud Radix, 2026) read the list, find the gaps, and route around them. The policy that survives is the one wired to a gateway that enforces the rule per request, not the one stapled to onboarding.
I want to walk through a template that holds the structure of a real policy, the per-role permissions that make it operational, the enforcement plane that turns the policy from advisory into binding, and the audit record that makes a breach reconstructable.
Section 1: Scope and definitions
The policy applies to every interaction between a person or service in the organization and an AI system, regardless of where the AI runs.
The scope statement is what makes the policy enforceable across the surface. A policy that names ChatGPT specifically misses Copilot, Claude in the IDE, and the next provider that has not launched yet.
Section 2: Categories of allowed use
A useful policy categorizes use rather than listing tools. Categories map to the data classification each may touch.
| Category | Description | Data classifications allowed | |---|---|---| | General productivity | Drafting non-confidential text, summarizing public materials, brainstorming | Public, internal-general | | Code assistance | Writing or reviewing code that does not contain customer data or secrets | Public, internal-general, source-code | | Customer support drafting | Drafting customer-facing messages with redaction in place | Customer-name-only (PII redacted) | | Sensitive analysis | Analysis of customer-PII or financial data through approved internal AI features | Customer-PII, financial-figures (gateway-enforced) | | Restricted use | High-stakes decisions (hiring, credit, clinical) | Requires named approval and FRIA | | Prohibited use | Any use that violates legal, ethical, or contractual obligations | None |
The category boundary is the policy's contract. Below the category, the per-role table is the implementation.
Section 3: Per-role permissions
The permission table assigns categories to roles. The directory provides the role; the gateway resolves the permission per request.
The forbidden classifications travel with the role. The gateway evaluates the rule per request; a customer-support agent who pastes a full SSN into a chat receives a redacted response with an audit row that records the attempt.
Section 4: Enforcement mechanism
The policy is binding only if a control point evaluates it per request. Three layers of enforcement work together.
The directory layer publishes the role and identity for every person and service account. SSO and SCIM keep the layer current.
The gateway layer evaluates the policy on the AI request. The identity, the classification, the policy version, and the route resolve to an allow or deny decision. The decision produces an audit row.
The endpoint layer optionally redirects the user's browser-based AI traffic through the gateway. A managed-browser policy or a network proxy routes ChatGPT, Claude, and Gemini traffic through the gateway so the policy applies even when the user is not using an enterprise-built application.
A policy without the gateway layer is advisory. The policy that ships with the gateway is the one that the regulator's question resolves against.
Section 5: Approved tools and the path to approve a new one
The policy lists approved tools with their enforcement state.
The approval path is in the policy so the request to add a new tool is structured rather than ad hoc.
Section 6: Prohibited uses
A short list of named prohibitions complements the categorization.
The prohibitions are short. The category boundary above does most of the work; the prohibitions catch the edge cases the category boundary does not address.
Section 7: Reporting and incident response
The policy specifies how a user reports a suspected AI-related incident and how the security team responds.
The reporting clause is what makes the audit log useful. A user who suspects a leak through an AI tool has a channel to surface it; the audit log gives the security team the trail.
Section 8: The audit record the policy promises
The audit row produced by the gateway carries the fields the policy commits to.
The audit row's policy_version ties the decision to the exact text of the policy in force. A policy that changes after the decision does not break the chain; the version retrieves the policy text the decision was evaluated against.
How this maps to ISO 42001 and the EU AI Act
ISO 42001 expects an AI policy as part of the AIMS Clause 5. The template above satisfies the policy artifact requirement; the gateway provides the operational evidence Clause 6 expects.
EU AI Act Article 26 imposes the deployer obligations. The role table, the per-route enforcement, and the audit record together satisfy the deployer's traceability obligation; the EU AI Act Article 12 logging requirement resolves against the same audit pipeline.
DeepInspect
DeepInspect is the gateway layer the policy template depends on. The identity binding from the IdP, the classification at the request boundary, the policy version on every decision, and the audit record per request live in the gateway. The policy text above becomes a policy bundle in the gateway's registry; rule changes flow through the same change-management process as any other policy.
The gateway runs in-line with sub-50ms p95 enforcement overhead from internal DeepInspect testing. Book a policy-mapping session at deepinspect.ai to walk through this template against your current role and tool inventory.
Frequently asked questions
- Do we have to enforce every category at the gateway?
The starting position is to enforce the categories where the data classification matters most. General productivity for public data can be advisory; sensitive analysis must be enforced. The gateway lets the policy evolve from advisory to enforced one category at a time.
- How does this work for personal devices?
A managed-browser policy or a per-device proxy routes the AI traffic through the gateway. The audit record records the same identity regardless of whether the device is corporate-managed or personal-but-enrolled.
- What about contractor access?
Contractors are part of the directory through a contractor tenant or a B2B SSO link. The role table treats them the same way it treats employees; the access scopes are typically narrower.
- How often should the policy refresh?
Quarterly is the floor; the policy refreshes whenever a regulation changes that touches an in-scope clause. The EU AI Act August 2, 2026 deadline is one trigger; the next Colorado, Texas, or California AI law will be another.
- What about generative-AI features inside SaaS we already use?
Embedded AI features in SaaS need the vendor due diligence pass (27-question checklist) and a directory-level decision about which roles can use them. The gateway can sit in front of the SaaS for the AI traffic where the SaaS exposes its AI API; for inline AI features, the SaaS becomes a vendor risk the contract has to absorb.