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.

AI Acceptable Use Policy Template: A Working Baseline for Enterprise AI Governance

TL;DR

An enterprise AI policy works only when a gateway enforces it on every request, rather than relying on an approved-tools list.
Define allowed use by category and data classification, so the rules apply to new AI providers as well as named tools.
Resolve each request against the user’s role, identity, data classification, policy version, and route, then allow, deny, or redact it.
Record every decision with the policy version and incident-reporting trail, making past breaches reconstructable.

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.

This policy covers:
  - Direct interactions with a hosted AI service (ChatGPT, Claude, Gemini, etc.)
  - Interactions through an embedded AI feature in a SaaS product
  - Interactions through an MCP server reaching an AI model
  - Interactions through a developer copilot or coding assistant
  - Interactions through an agent or orchestrator

This policy applies to:
  - Full-time employees
  - Contractors with access to organizational data
  - Service accounts and machine identities
  - Third parties processing organizational data through an AI feature

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.

roles:
  engineering-staff:
    allowed_categories: [general-productivity, code-assistance]
    allowed_data_classifications: [public, internal-general, source-code]
    forbidden_data_classifications: [customer-pii, phi, financial-account]

  customer-support:
    allowed_categories: [general-productivity, customer-support-drafting]
    allowed_data_classifications: [public, internal-general, customer-name-only]
    forbidden_data_classifications: [customer-ssn, customer-dob, financial-account]

  data-analytics:
    allowed_categories: [general-productivity, sensitive-analysis]
    allowed_data_classifications: [public, internal-general, customer-pii (gateway-enforced)]

  hiring-team:
    allowed_categories: [general-productivity]
    allowed_data_classifications: [public, internal-general]
    forbidden_use: [hiring-decision-ai]
    rationale: |
      Hiring AI is restricted to named approved tools with FRIA on file.

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.

approved_tools:
  - name: OpenAI ChatGPT Enterprise
    enforcement: gateway
    routes_via: openai-direct
  - name: Anthropic Claude Enterprise
    enforcement: gateway
    routes_via: anthropic-direct
  - name: GitHub Copilot Enterprise
    enforcement: idp-bound
  - name: Internal Sales Copilot
    enforcement: gateway
    routes_via: bedrock-claude

approval_path_for_new_tools:
  1. Risk team intake (27-question checklist)
  2. Security architecture review
  3. Gateway integration check
  4. Legal review (DPA, BAA where relevant)
  5. CISO sign-off
  6. Rollout to a pilot group
  7. Production approval

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 following uses are prohibited under any AI tool:

1. Submitting customer data classified as PHI, SSN, financial account
   numbers, or government identifiers to any AI service not routed
   through the enterprise gateway.

2. Using AI to generate code that copies from sources protected by
   incompatible licenses without legal review.

3. Generating final hiring decisions, credit decisions, or clinical
   decisions using an AI tool without a documented FRIA and named
   approval.

4. Using AI to impersonate another person without consent.

5. Using personal AI accounts for work that processes organizational
   data.

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.

Reporting:
  Email: ai-incident@example.com
  Slack: #ai-incidents
  Hotline: +1-555-0100 (24/7)

Response targets:
  Initial triage: within 30 minutes of report
  User-facing communication: within 4 hours
  Regulator notification: per the applicable regulation
    (EU AI Act incident reporting, NIS2, HIPAA breach notification,
     state-specific AI notification regimes)

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.

{
  "request_id": "req_2026-06-21T16:14:42Z_aup",
  "natural_person": "user:1734",
  "role": "customer-support",
  "category": "customer-support-drafting",
  "tool": "OpenAI ChatGPT Enterprise",
  "data_classifications_in": ["customer-name-only"],
  "data_classifications_out": ["customer-name-only"],
  "policy_version": "aup-2026-06-21-r2",
  "decision": "allow",
  "reason": "allowed by category customer-support-drafting for role customer-support",
  "signature": "ed25519:..."
}

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.