What actually belongs in an AI acceptable use policy

Most companies between 30 and 300 people already have staff using AI tools, whether or not a policy says so. The policy that works is not the longest one. It states which data may go where, who approves a new tool, and what happens when someone gets it wrong. It does this in language a new hire reads in one sitting.

What does a working AI acceptable use policy actually need to say?

A policy that survives contact with real staff decides a short list of things, not a long one. Nine sections make up a working one. Each row here names the section, the decision it forces, and the specific failure it exists to prevent.

The customer disclosure row is not optional once a system talks to people outside the company. Article 50 of the EU AI Act already requires a provider or a deployer to tell a person they are interacting with an AI system.

It also requires labelling content the system generated, whether or not that system counts as high-risk. A staff-facing policy has to name who checks that duty before a customer-facing AI feature ships. The policy must not leave that to whoever built the feature to remember.

What should the policy refuse to try to do?

A policy that tries to be the technical control fails twice. It fails once because a paragraph of text cannot stop a paste into a browser. It fails again because staff read that overreach as proof the whole document is for show. Access limits, contract terms and vendor settings do the technical work. The policy states the rule those controls exist to support.

Listing every approved tool by name reads as complete on the day you publish it. It is wrong within weeks, because a new model or a new vendor account always arrives faster than a document gets updated. A policy built around named tools also implies that anything missing from the list is quietly fine, and a reviewer wants to see the opposite.

An outright ban is the easiest policy to write and the least effective one to run. It does not remove the reason someone went looking for an AI tool in the first place. It just moves that search out of sight, where it is much harder to see or govern.

What do you do about the tools staff are already using?

By the time you draft a policy, some staff are already using AI without asking anyone first. That means drafting client emails in a personal chatbot account or running a browser extension nobody vetted. It also means building a habit around a coding assistant they picked themselves. That is shadow AI, and treating it as rare is the first mistake a policy can make.

Two moves fix more of it than a warning email does. First, make the approved path faster than the workaround: a fast yes for a low-risk tool beats a slow review nobody wants to wait for. Second, check instead of asking. Checking browser extensions, expense claims and what the company actually pays AI vendors shows what people are really running. That beats trusting a self-reported survey.

What happens when someone breaks the policy?

Most breaches are not sabotage. Someone pastes a client’s contract into a personal chatbot account to move faster, not to leak it. That is different from someone who was told a tool was blocked and used it anyway, or who hid AI involvement in work they signed off as their own. A policy that cannot tell the two apart will punish the wrong case or excuse the real one.

One named role decides what happens next. That is the same person who owns the AI register and the policy itself, not a group chat and not a vote. They classify what happened and decide whether legal or an affected client needs to hear about it. They also choose the response, from a conversation to removal of access to company systems.

That decision runs through the disciplinary process HR already has for any other policy breach. The AI policy needs a clear point where that existing process starts, not a punishment system of its own. Silence is its own answer too. If a policy never states what happens after a breach, staff test it once and learn from the result whether any of it is real.

Who should own it, and how does it stay current?

The same person who is already accountable for AI risk overall should hold this document. A shared inbox cannot hold it, because someone has to be answerable when a customer or an auditor asks a direct question. ISO/IEC 42001 treats a policy like this as one part of a management system, reviewed on a schedule and checked against a live inventory.

A review interval only works if you tie it to something that actually changes. That can be a new hire, a new vendor account, or a client contract that names a data rule of its own. Quarterly is a reasonable default for a company this size. The exact interval matters less than the fact that one exists and someone is accountable for keeping it.

The version I run for my own practice is public at my AI policy. It is one page, a worked example of the same shape at a much smaller scale. The Starter Kit lists the documents a security review asks for and who signs each. It suits a company with more than one person to coordinate.

What doesn’t a policy like this solve?

A written policy does not tell you whether anyone inside the company actually owns AI risk today. If nobody does, there is no obvious person to hand the draft to. So the gap usually surfaces during an AI readiness and risk assessment, before it ever reaches the policy stage.

Someone determined to break the rule will do it regardless; no policy stops that. A policy removes the excuse of not knowing, and it gives the company a fair, defensible reason to act when someone crosses the line anyway.

Nobody enforces it without an owner, a review date and a stated consequence. Skip those and it is a page people skim once and never open again.