What should an AI acceptable use policy include?

A usable policy names which tools are approved, defines what data may never be sent to AI, states what happens on a violation, and maps each rule to a control that can actually observe or enforce it. The last part is what separates a real policy from a wish. A rule that nothing can detect is documentation, not governance.

Why do most AI policies fail?

Because they are written as a PDF and enforced by hope. They tell employees not to paste secrets into AI tools, but nothing on the device checks whether anyone does, so there is no signal when the rule is broken and no evidence for an audit. Policies that are not wired to a control decay into paperwork within a quarter.

How do you enforce an AI acceptable use policy?

Enforce it at the endpoint, where AI requests originate in plaintext. A device-level agent can read each prompt, attribute it to a user, and apply the policy in real time: redact secrets, block disallowed data, and log every decision. That turns each written clause into an observable, provable control instead of an honor-system request.

How to Write an AI Acceptable Use Policy People Actually Follow

Most AI acceptable use policies fail for the same reason: they are a list of rules with nothing behind them. The document says "do not paste customer data or secrets into AI tools," it gets acknowledged in an onboarding click, and then no system on earth checks whether anyone follows it. A policy that cannot be observed is not a control. It is a paragraph. This is how to write one that maps to something real, with the structure and the clauses to start from.

The test every clause has to pass

Before you write a word, adopt one rule: every clause must map to a control that can observe or enforce it. If a line in your policy cannot be detected when it is broken, it is not a policy line, it is a hope.

Run each proposed rule through three questions:

Can we see it happen? If an employee violates this, does any system generate a signal?
Can we attribute it? Do we know which person and device, or only that "someone, somewhere" did it?
Can we prove it later? If an auditor or an incident review asks, is there a record?

A rule that fails all three is decoration. Keep it only if you are honest that it is aspirational, and do not count it as a control in your risk register.

The structure that works

A policy people actually follow is short, specific, and unambiguous about consequences. Five sections is enough.

1. Approved tools

Name them. "Employees may use the following AI tools for work: [your sanctioned list]." Vague policies that gesture at "approved enterprise AI" invite everyone to decide for themselves. A named list gives people a clear default and gives you a clear line for what counts as shadow AI.

2. Data that may never go to AI

Be concrete and use categories your people recognize:

Credentials, API keys, and secrets of any kind.
Customer or employee personal information.
Source code from private repositories, unless using an approved coding assistant.
Unreleased financial figures, legal matters, and material non-public information.

Concrete beats comprehensive. Four categories everyone remembers outperform twenty nobody reads.

3. What is expected

State the positive behavior, not just the prohibitions. "Use approved tools. Keep the four restricted data categories out of every prompt. When in doubt, ask before you paste." People follow rules they can hold in their head.

4. What happens on a violation

Say it plainly. First-time accidental exposure gets a coaching conversation and a redaction. Repeated or willful exposure escalates. Ambiguity here reads as "nothing happens," and people calibrate accordingly.

5. How it is enforced

This is the section most policies omit, and its absence is why the rest is ignored. State that AI usage on managed devices is governed by a control that inspects requests before they leave, that sensitive data is redacted or blocked in the moment, and that decisions are logged. When people know the rule is actually watched, the rule actually works.

Wire it to a control, or it decays

Here is the pattern that kills AI policies: a well-intentioned document ships, everyone acknowledges it, and within a quarter it is a file nobody opens while the behavior it forbids continues invisibly. The document did not fail because it was badly written. It failed because it was never connected to anything that could see whether it was followed.

The fix is to enforce at the layer where AI requests are still legible and attributable: the endpoint. Before a prompt is encrypted and sent, a device-level control can read it, match it against your restricted-data categories, and act. Now each clause has a counterpart in reality:

"Do not send secrets to AI" becomes: secrets are detected in the prompt and redacted before it leaves.
"Use approved tools" becomes: requests to unapproved tools are flagged and logged with the user and device attached.
"We can prove compliance" becomes: every allow, redact, and block is an audit event you can export.

The policy stops being a promise employees make and becomes a property the system guarantees.

A note on tone

The best AI policies are not adversarial. They assume employees want to do good work with good tools and mostly leak data by accident, in a hurry, not on purpose. Write for that person. Make the approved path easy, make the restricted categories memorable, and let the enforcement layer quietly catch the honest mistakes before they become incidents. A policy that helps people succeed gets followed. A policy that only threatens gets routed around.

If you want a starting point wired to real enforcement, the fastest way to see the gap between your current policy and what your endpoints are actually doing is to measure the traffic directly.