What actually belongs in an AI acceptable use policy

Roughly 99% of the organizations we engage with have no AI acceptable use policy at all. That number holds whether the organization is regulated or unregulated, which surprises people who assume this is a compliance-driven exercise. It is not. Regulated firms are no more likely to have one than a marketing agency; they simply face steeper consequences when something goes wrong.

What almost all of them have done is deploy AI first. Licenses get bought, staff start using tools, and governance is treated as something to sort out later. By the time anyone writes a policy, there is already a year of undocumented usage to reckon with.

Why most AI policies fail on arrival

When we do find a policy, it is usually one to two pages, clearly assembled in an afternoon, and composed almost entirely of prohibitions. Do not enter confidential data. Do not rely on AI output. Do not use unapproved tools. Every statement is defensible and the document as a whole is nearly useless.

The problem is not length. A short policy that was thought about carefully beats a long one nobody reads. The problem is that a list of prohibitions answers only half of the question an employee actually has. They do not want to know what is forbidden in the abstract; they want to know whether the specific thing they are about to do is acceptable. A policy that never describes good use forces every employee to make that judgment alone, which is precisely the situation the policy was supposed to eliminate.

A policy that only prohibits tells your staff you were worried. A policy that also permits tells them what to do instead.

The second failure is generality. Policies are written in categories — "confidential information," "sensitive data," "unapproved applications" — because categories feel comprehensive and are faster to write. But employees do not experience their work as categories. They experience it as a specific document in front of them and a specific tool open in another tab.

Describe good use, not only prohibited use

The most valuable section of a policy is the one most organizations omit entirely: a plain description of what productive, sanctioned AI use looks like in your business. This does more work than any prohibition, for three reasons. It gives staff a safe default, so the cautious ones stop avoiding tools that would help them. It sets a reference point, so novel situations can be reasoned about by analogy. And it signals that the organization intends to use AI rather than merely survive it, which determines whether people bring their usage into the open or keep it hidden.

Write this section with real examples from your own operations. Drafting a first pass of a client update, summarizing a long thread before a meeting, restructuring a document you wrote, generating test data, explaining an unfamiliar contract clause in plain language. The more it reads like your actual week, the more it gets used.

Name specific applications and specific use cases

This is the difference between a policy that changes behavior and one that decorates a shared drive. Do not write "approved AI tools may be used for appropriate business purposes." Name the tools. State what each one is approved for, and what class of information may go into it.

The distinction that matters most is rarely the tool itself but the tier and configuration you are using. The same vendor's consumer product and enterprise product can have opposite data handling defaults. A policy that says "you may use this assistant" without specifying which account, on which plan, under which settings, has not actually said anything.

Classify data in three tiers, not seven

Data classification schemes fail when they are too elaborate to recall under time pressure. Three tiers is usually the practical maximum: information that is already public, information that is internal but not sensitive, and information that would cause real harm if it left. Map each tier to which tools may handle it and stop there. If your industry imposes specific categories — patient records, cardholder data, client files under privilege — call those out explicitly by name rather than trusting a tier label to cover them.

The test for this section is whether an employee can recite the rule from memory. If they have to open the document to check, they will guess instead.

The section almost everyone leaves out

Employees will find useful AI tools faster than any review process can evaluate them. This is not a discipline problem; it is a rate problem, and it will not slow down. If your policy has no path for someone to say "I found something that would help me, may I use it?", you have guaranteed one of two outcomes: they do not use it and you lose the benefit, or they use it anyway and you lose the visibility.

A workable request process needs three things, and the third is the one that gets dropped.

1. 01A submission path that takes minutes. A short form or a single named person. If requesting permission is more work than quietly proceeding, people quietly proceed.
2. 02Stated review criteria. Whether the vendor trains on inputs, whether an enterprise tier disables that, where data is stored, what the tool integrates with, and what permissions it requests.
3. 03A deadline you actually honor. Five to ten business days, in writing. An open-ended review is functionally a denial, and staff learn to route around it. This is the commitment most policies avoid making, and it is the one that determines whether the policy works.

Without a request workflow, a policy does not prevent shadow AI. It causes it.

Set a review cadence, because the tools change monthly

An AI policy written eighteen months ago is describing a market that no longer exists. Capabilities that did not exist then are now default features, and settings that mattered then have been renamed or removed. Put the policy on a schedule — twice a year is a reasonable floor — and name one person who owns it. A policy with no named owner does not get updated, and a stale policy carries a particular risk: staff who follow it believe they are compliant when they are not.

What to do about the usage that already happened

Since most organizations write their first policy well after adoption, you will need to address a period of undocumented use. Handle it as a no-blame inventory. Ask people which tools they have been using and what they put into them, state plainly that the goal is to understand exposure rather than to discipline anyone, and mean it.

This works only if the amnesty is genuine. The first time someone is penalized for an honest disclosure, you lose the visibility permanently and you will not get it back. If the inventory surfaces something serious — regulated data in a consumer tool, proprietary material in a product that trains on inputs — that is a specific remediation to work through, not a reason to make an example of the person who told you.

A structure you can write this week

A first version does not need legal review to be worth having. It needs to cover the highest-risk activities and be short enough that people finish reading it. Ten minutes is a good target.

• Purpose and scope — who it covers, including contractors and anyone handling your data.
• Definitions — what counts as an AI tool. Be broad: assistants, notetakers, browser extensions, and AI features inside software you already own.
• Approved tools — named, with the tier and what each is approved for. Expect to revise this often.
• Good use — concrete examples from your operations.
• Prohibited use — specific data types and specific tool categories, not abstractions.
• Data handling — your three tiers mapped to tools, with any regulated categories named explicitly.
• Request workflow — how to ask, the criteria, and the deadline.
• Verification expectations — who is accountable for AI-assisted output before it leaves the organization.
• Oversight and reporting — how issues are raised and who reviews them.
• Acknowledgment — a signature, which is what makes it enforceable later.

Do not ban everything by default

The most common overcorrection, particularly from organizations that have just had a scare, is a blanket prohibition. It reliably fails. Staff who have found genuine value in these tools do not stop using them; they stop telling you. You have converted a governance problem you could see into one you cannot, and you have given up the ability to steer usage toward tools you have actually vetted.

The objective is not to eliminate AI use. It is to make the sanctioned path the easiest one available.