Building an AI acceptable-use policy

Most AI policies are shelfware

Almost everyone has a policy now. That is not the problem. The problem is that the policy and the behavior have nothing to do with each other. In one 2026 survey of creative professionals, 96% of organizations reported formal AI usage restrictions, and 96% of employees in those same organizations admitted using unapproved AI tools anyway. The sample was small and vendor run, so treat it as directional, but the direction is one every security team recognizes: the document exists, the enforcement does not.

The reason is not laziness. People reach for AI because it saves them real time, and a rule that gets in the way of doing the job faster loses every time it is inconvenient. A policy that says "do not paste customer data into ChatGPT" with no control to detect or stop it is a wall with no gate. The wording feels responsible, and it does nothing.

So the goal of this guide is narrow and specific: help you write a policy that is short enough to read, concrete enough to enforce, and wired to controls that make enforcement automatic rather than aspirational. Everything below is organized around one question you should ask of every clause you draft: what control makes this real?

Enforceability is the whole game

The written policy is the easy half. The hard half is enforcement: real-time prompt inspection, shadow AI discovery, redaction of sensitive data before it leaves, and a log you can hand to an auditor. Reviews of client policies through 2026 keep surfacing the same avoidable gaps, and each one is a place where the text outran the control.

The most common gaps are worth naming so you can avoid them. Policies approve a tool by brand without a license tier, so "Copilot is approved" silently permits a consumer plan that trains on your code. Policies rely on a vendor opt-out toggle a developer can flip rather than a contract that prohibits training. Policies list registered models but ignore autonomous agents with tool use and memory, which is the fastest-growing blind spot in the estate. And almost none of them can produce visibility into what employees actually did, which is the technical core of enforcement: you cannot enforce a policy you cannot see.

The practical consequence is a drafting rule. Write each clause next to the control that enforces it. If discovery cannot find the tool, inspection cannot read the prompt, redaction cannot strip the secret, or a gate cannot block the action, then the clause is decoration. Cerbera exists to be that control layer: a transparent proxy that discovers AI across the browser, desktop, coding agents and CLIs, and MCP servers, inspects traffic inline, and gates what the policy prohibits, on the same path.

A skeleton your AUP should contain

Below is the structure of a policy that holds up in an audit and survives contact with a busy engineering team. Keep it to a few pages. Every section names the behavior in plain language and, in brackets, the control that backs it. If a section has no control, it is a candidate to cut or to fund.

1. Scope and definitions

• Who is covered: employees, contractors, and any system acting on their behalf, including autonomous agents.
• What is covered: the four surfaces where AI shows up. Browser LLMs, desktop AI apps, coding agents and CLIs, and MCP servers.
• Shared definitions up front: AI tool, agent, prompt, model provider, sensitive data. Ambiguous terms are enforcement gaps.

2. Approved vs prohibited tools

• An allowlist named to the license tier. "Copilot Business," not "Copilot." The tier is the control.
• A default stance for everything not on the list: prohibited, tolerated pending review, or blocked outright.
• A fast path to request a new tool, so the answer to "can I use X" is days, not a shrug. [enforced by discovery plus a gate on unapproved models]

3. Data classification for prompts

• What may never enter any prompt: secrets, credentials, regulated data, and customer PII unless a specific approved flow exists.
• What is fine: public information, synthetic data, and internal content already cleared for the tool in question.
• The rule is enforced, not trusted. [inline inspection and redaction strip secrets and PII before traffic leaves the endpoint]

4. Human-in-the-loop for agent actions

• Which agent actions require a human to approve before they execute: code merges, production changes, data deletion, external sends, payments.
• Which are fine to run autonomously in a sandbox with logging.
• This mirrors what ISO 42001 and the EU AI Act call for. A human who can review and override. [enforced by gating high-impact actions inline]

5. Third-party and MCP rules

• No connecting an agent to an MCP server that has not been risk-scored and approved.
• A minimum bar for any external model or tool: no training on your data, a data-processing agreement, and a known data residency.
• Broad OAuth scopes are treated as a finding, not a convenience. [enforced by MCP risk-scoring and gating]

6. Logging and monitoring

• What is logged: the tool, the user, the action, and the policy decision, retained long enough to satisfy the regimes you answer to.
• Where detection runs: locally on the endpoint, so monitoring does not itself become an exfiltration path.
• Who reviews the logs and how often. [enforced by inline visibility across all four surfaces]

7. Incident handling

• What counts as an AI incident: a leaked secret, a prohibited tool in production, a rogue MCP connection, a policy bypass.
• The response path: who is paged, how it is contained, what is preserved for review.
• A named owner. An incident procedure that lives only in a document is not a procedure.

8. Roles and enforcement

• Who owns the policy, who approves tools, who runs monitoring, who handles exceptions.
• What happens on violation: correction, retraining, and, for repeated or willful breaches, a defined disciplinary path.
• How exceptions are granted and expire, so the policy bends without breaking.

Draft, monitor, communicate, enforce

A good policy rolled out badly still fails. The sequence that works treats rollout as a change-management problem, not a publish-and-forget event. Four phases, in order.

Draft with the people who will live under it

Pull representatives from security, legal, engineering, and the loudest AI-using teams into the first draft. Legal frames the regulatory floor, engineering tells you which rules would quietly get bypassed, and the AI-heavy teams tell you what they actually use. A policy written in a vacuum is a policy written to be ignored. This is also where you decide the default stance and the allowlist, the two decisions everything else hangs from.

Start in monitor-only mode

Turn on discovery and inspection before you turn on blocking. For a few weeks, observe: which tools are in real use, where sensitive data is actually flowing, which prohibited patterns fire most. This does three things. It validates that your rules match reality, it surfaces the exceptions you forgot to write, and it gives you a baseline. Enforcing on day one, blind, produces a wave of false positives and a team that learns to route around you. Monitor first.

Communicate like you mean adoption

Tell people what is changing, why, and what stays easy. Lead with the fast path: how to get a tool approved, what is already allowed, how redaction protects them rather than watching them. The message that lands is "here is how to keep moving fast, safely," not "here is a new list of things you cannot do." A policy the team understands and mostly agrees with is one that mostly gets followed.

Enforce, gradually

Flip enforcement on for the highest-risk rules first: secrets and regulated data in prompts, unvetted MCP connections, high-impact agent actions. Expand from there as the false-positive rate stays low. Because you spent the monitor phase tuning, enforcement should feel like a small step, not a cliff. Keep a clean exception path open the whole time, or people will build their own.

A policy is a living control, not a document

The regimes you are mapping to all expect this to be ongoing. ISO 42001 requires a documented policy, an inventory of AI systems, human-in-the-loop controls, and continuous improvement of the management system. The EU AI Act, whose high-risk obligations apply from August 2026, mandates human oversight and post-market monitoring with retained records. SOC 2 and ISO 27001 expect the same governance discipline extended to AI. NIST AI RMF frames it as Govern, Map, Measure, Manage, an explicit loop, not a one-time filing. None of them are satisfied by a PDF that has not changed since launch.

So treat the policy as code with a review cadence. Re-run discovery on a schedule and alert on net-new tools, agents, and MCP servers. Review your allowlist quarterly against what people actually use, and against new license tiers that change what "approved" means. Feed every AI incident back into the rules. And keep the enforcement layer generating evidence continuously, so the artifact you show an auditor is a live log of decisions, not a screenshot of a document.

This is the payoff of writing every clause against a control from the start. The same inline path that enforces the policy also proves it was enforced, and maps that proof to ISO 42001, the EU AI Act, SOC 2, and ISO 27001 without a separate evidence-gathering project. The policy stops being paperwork and becomes a system that keeps your team fast and keeps you defensible at the same time.