AI Acceptable Use Policy: A Template You Can Actually Enforce

Most AI acceptable use policies are written, signed, filed, and then change nothing about how the company actually uses AI. I went and read twenty-four of them to work out why. They get written because someone senior asked for an AI policy, they get signed, they get filed, and then nothing about how the company actually uses AI changes. The document exists so the question can be closed.

This page has two parts. First, the structural argument for what a policy has to contain to be worth the signature, which is the part almost every template gets wrong. Then the full policy itself, on the page, free, no form, no download gate. Copy it, change the names, use it. If all you want is the template, skip to the template.

I write this from the operator seat. I run growth inside a US managed service provider and spend my week on the buying side of exactly this problem, which means I see what companies sign and then what they actually do afterwards. The gap between the two is the whole subject.

What 24 published AI policies actually contain

Before writing this I went and read the policies. Twenty-four of them, every one publicly readable and fetched in full: security vendor templates, MSP blog templates, HR software templates, a law firm, universities, and eight government bodies from a US federal agency down to two city councils. Each was coded clause by clause. Another fourteen candidates were excluded because they were form-gated, blocked, or turned out to describe a policy without containing one.

The result is not that these documents are short or lazy. The median is around 1,550 words, and the longest runs to 3,500. They are substantial documents. The problem is what they are substantial about.

The asymmetry, which is the actual problem

Look at the two ends of that chart together. Fifty-four percent of these policies explain how an employee requests a new tool. Eight percent commit to telling them how long that will take. Seventeen percent name a person with contact details. Seventeen percent make any commitment back to the employee. Seventeen percent ask for a signature.

These documents are almost entirely one-directional. They are written as a list of obligations flowing towards the employee, and they promise essentially nothing in return. That is why they get signed and filed and change nothing: from where the employee sits, the policy is something being done to them, and the only rational response to a rule with no route to a yes is to route around it quietly.

Two more findings from the corpus worth having.

Nobody combines the two governance axes. Thirty-three percent sort rules by data sensitivity. Thirty-three percent provide an actual list of approved tools. Not one document in the twenty-four did both. Organisations pick an axis, tool identity or data classification, and having picked one they leave the other empty. The policy below deliberately carries both, because they answer different questions and neither is sufficient alone.

The two most complete documents in the corpus are not real policies. They are governance-framework demonstrations published on GitHub by individual practitioners, using invented company names. Strip those out and the picture gets thinner still. In the whole set, exactly one document was a genuine, primary-source, published policy from an operating private company. Several large firms are widely reported to have AI policies; almost none of them publish the text. Whatever your company writes, it is being written with very little visible prior art.

One honest note on the numbers. Seven of the eight government documents state an explicit default for unlisted tools and disclose what is monitored, which is very likely a compliance mandate rather than good instincts. Take government out and the explicit-default figure drops from 67% to about 56%. The employee-facing clauses stay at their floor either way.

The test that predicts whether a policy holds

Four of the twenty-four ask employees to keep a manual log of their own AI usage: record the tool, the data, the date, the purpose. It is a minority clause, and three of the four are government bodies, so I would not claim it is typical. But it is worth holding up because it is the clearest example of a failure mode that runs through the whole corpus.

Read that clause as an employee. You are mid-task, you paste three paragraphs into a chat window, and the policy expects you to stop, open a separate log, and write down what you just did and why. Nobody sustains that. Not once a day, and certainly not fifteen times. Within a fortnight the log is empty, and an empty log is worse than no log, because the company now believes it has an audit trail.

The instinct behind it is right: somebody should know what data is going where. The instinct has just been converted into a task assigned to the person least able to carry it, at the exact moment they are least willing to.

So the test for any clause in any AI policy is this. Ask who has to do work for this rule to hold, and whether they will still be doing it in six weeks. Rules that depend on a busy person remembering a procedure at the moment of temptation do not hold. Rules that depend on a decision made once, in advance, by somebody accountable, do. Most of what follows is an attempt to move as much of the policy as possible into the second category.

What a policy has to do to be worth signing

Seven tests. A policy that fails any of them is decoration.

1. It names a person, with contact details, on page one. Almost every template tells staff to stop and ask when they are unsure. Very few of them say who to ask. An escalation route without a named human at the end of it is not a route. Put a name, a role, an email and a phone number at the top, and the "when in doubt, stop and ask" instruction becomes something an employee can actually follow in the ten seconds they are willing to spend on it.

2. It sorts rules by data sensitivity, not by tool. This is the most common structural error. Policies get organised around the tools, one section for ChatGPT, one for Copilot, one for the rest, which means the policy is obsolete the week a new tool appears, and it teaches staff to ask the wrong question. The question is never "is this tool allowed". It is "is this data allowed out of the building". Sort by what the data is, and the rules survive the tool list changing, which it will, constantly.

3. It states what is approved, and says explicitly what happens to everything not on the list. A list of approved tools with no default is an invitation. State the default in one sentence: anything not on this list is not approved, and here is how to get it added.

4. It gives people a route to say yes. A policy that only forbids gets routed around. Somebody finds a tool that would genuinely save them four hours a week, the policy says no, and they use it anyway on their personal login where you will never see it. The request-and-approve workflow is not an administrative afterthought, it is the pressure release valve that keeps the rest of the policy honest. It deserves its own section and a response time commitment.

5. It says what the company monitors and what it does not. This is the half that almost no template writes, and it is the half that decides whether staff cooperate or route around you. If you are going to have any visibility over AI usage, say so in the policy, in plain terms, including the limits. People accept monitoring they understand and resent monitoring they discover.

6. It is signed. An unacknowledged policy is advice. A signed one is an agreement, and it is also the consent artefact that makes any monitoring defensible later. The signature block costs you nothing and changes the legal character of the document.

7. It has a review date that is tied to something real. Annual review is where policies go to die, because the AI tool landscape does not move annually. Quarterly, attached to a meeting that already exists in the calendar, is the version that actually happens.

Sorting by sensitivity, in practice

Three levels is enough for most companies, four if you genuinely have a category that needs different handling from everything else. The vocabulary matters more than the taxonomy: use words your staff already use.

The reason this beats a tool-by-tool structure is that it answers the question the employee is actually holding. They are not wondering whether Claude is on some list. They are wondering whether this particular paragraph is the kind of thing that gets people fired. Answer that, and most of the policy stops needing to be read.

One addition worth making if your business has a category where a mistake is not recoverable, regulated health data, payment credentials, unreleased financials: add a fourth level above confidential, and make it behave differently rather than just sounding more serious. A level that carries a scarier adjective but the same rule as the one below it is decoration. If the top level exists, it should mean the answer is no even in approved tools, without a specific written exception.

The policy

Below is the full text. Replace everything in square brackets. It is deliberately longer than the one-pagers, because the one-pagers are short by leaving out the parts that make a policy hold.

AI Acceptable Use Policy, [Company Name]

Policy owner: [Name], [Role]
Contact: [email] · [phone]
Version: 1.0 · Effective: [date] · Next review: [date, three months out]

Who this applies to: everyone who works for [Company Name], including employees, contractors, and temporary staff, on any device used for work, whether the company owns it or you do.

1. Why this policy exists

We want people here using AI tools. They make parts of this job faster and better, and we are not going to pretend otherwise or quietly ban them and hope. The risk is not that you use AI. The risk is that information leaves this company through a tool nobody chose, into a system nobody reviewed, and we find out from somebody else. This policy exists so you can use these tools confidently without having to guess where the line is.

2. Who to ask

[Name] owns this policy. If you are unsure whether something is allowed, stop and ask them at [email] or [phone] before you paste. Asking is never the wrong call, and nobody has ever been in trouble here for asking first. If [Name] is unavailable and you cannot wait, treat the data as confidential and do not proceed.

3. What data you can put where

Every piece of information you handle falls into one of three levels. Judge the data, not the tool.

Low, public. Anything already public or intended to be. Published content, general questions, public research. Use any approved tool freely.

Medium, internal. Information that is ours but not sensitive. Drafts, internal notes, plans, anonymised operational data. Approved tools only, and read the output before you use it.

High, confidential. Client data, anyone's personal data, financial statements, contracts, passwords, API keys, and anything covered by an NDA. This does not go into a public AI tool at all. If you have a genuine need to use AI on this kind of material, ask [Name] first and we will find a way that works.

If you cannot tell which level something is, treat it as the higher one and ask.

4. Approved tools

Anything not on this list is not approved. That is not a judgement about the tool, it just means nobody has looked at it yet. Section 5 is how you get it looked at.

Where a tool is approved, use the company account, not your personal one. Personal accounts often train on what you put in, company accounts usually do not, and we cannot check the settings on an account we do not control.

If a client contract forbids AI processing of their data, that beats everything in this policy. The strictest applicable rule always wins.

5. Getting a new tool approved

If a tool would genuinely help you, ask for it. This is a real process, not a formality designed to make you give up.

Send [Name] the tool name, the link, what you want to use it for, and which data level you would be putting into it. You will get an answer within [five working days]. If the answer is no, you will get the reason. If we cannot approve the tool itself, we will try to find you something that does the same job.

This also applies to AI features appearing inside tools we already use, and to AI-built software you are considering buying. A feature switched on inside an existing product is still a new place your data can go, and it deserves the same question.

Do not buy or sign up for an AI tool with company money or a company email before it is approved.

6. The rules

Check the data level before you paste. That one habit prevents nearly every incident this policy is designed to prevent.

Use approved tools, on company accounts.

Check the output before you use it. These tools produce confident, well-written, incorrect answers. Anything client-facing, financial, legal or contractual is your responsibility, not the model's.

Do not paste anything into an AI tool that you would not put in an email to someone outside the company. It is a rough test and it works.

Tell someone if it goes wrong. If you pasted something you should not have, tell [Name] the same day. There is no penalty for reporting it. There are consequences for hiding it, because the difference between a contained mistake and a serious one is usually how quickly we hear about it.

When you are not sure, stop and ask.

7. What we monitor, and what we do not

Being straight with you about this is the point of the section.

What we do: [describe here, honestly and specifically. For example: we can see which AI tools are being accessed from company devices and accounts, and we review that at a summary level to keep the approved list current.]

What we do not do: we do not read your prompts, we do not keep a file on individuals, and we do not use any of this for performance review. This exists to protect company and client data, not to watch you work.

What we keep: summary information only, for [90] days.

If we ever change what is monitored, you will be told before it changes, not after.

8. When something goes wrong

Tell [Name] the same day. Say what you put in, which tool, and roughly when. You will not be blamed for a first honest report. We will assess whether anything needs disclosing to a client or a regulator, and we will tell you what happens next.

Repeated deliberate breaches, particularly of the confidential data rule, are a disciplinary matter. Honest mistakes reported quickly are not.

9. Review

This policy is reviewed every three months at [named recurring meeting], and immediately if a significant new tool appears or an incident occurs. The approved tools table is expected to change often, and changing it does not require a new version of the whole document.

10. Acknowledgement

I have read the [Company Name] AI Acceptable Use Policy. I understand which data I may use with which tools, who to ask when I am unsure, and what to do if something goes wrong.

Name: ______________________ Signature: ______________________ Date: ____________

The three clauses most templates skip, and why they matter

Section 7, what we monitor. Nearly every AI policy is written entirely as obligations on the employee. None of it flows the other way. That imbalance is why staff treat these documents as something being done to them. Writing down what the company will and will not look at costs you nothing if you are behaving reasonably, and it converts the policy from a set of restrictions into a two-sided agreement. It is also the clause that makes any future visibility defensible, because you disclosed it in advance rather than deploying it quietly.

Section 5, the request route, as a real section. Most templates handle this as half a sentence, if at all. Give it a section, a named recipient and a response time. The number of people who will route around your policy is directly proportional to how hard you make it to get a yes.

Section 8, the no-blame first report. Without it, the rational move for an employee who has just pasted a client contract into the wrong window is to say nothing and hope. That is the single most expensive outcome available, and you have designed your way into it by making honesty costly.

The five routes AI takes into a company

Most policies are written as though AI arrives one way: a person opens a chat tool and types into it. That is one route out of five, and it happens to be the only one a tool list can govern. The other four are where the interesting failures live.

The useful way to sort them is not by what kind of AI it is. It is by how it got in, who decided, and what you can still see afterwards. Those three questions decide whether a policy clause can do anything at all.

Read down the "who decided" column and the pattern is obvious. Route 1 is the only one where a human at your company made a conscious choice you could have influenced. Everywhere else, AI got in because a vendor shipped something, or because a competent person solved a problem the fastest way available.

Read down the visibility column and the second pattern appears. Your visibility is highest exactly where the decision was most deliberate, and lowest where nobody decided anything. That is backwards from what you want, and it is why an approved tools list on its own is a partial control no matter how carefully you maintain it.

This is not an argument against the policy. Route 1 is still the largest volume of day to day risk in most small and mid-size companies, and the policy handles it well. It is an argument for knowing which routes your document covers, so that the ones it does not cover stay visible instead of quietly reading as clean.

What this policy does not close

Using the five routes above: this document governs route 1 properly, reaches route 3 only if somebody is paying attention, and does very little about routes 2, 4 and 5.

Route 2, features that arrived, is the one to fix first, because it is the cheapest. Section 5 covers it in principle, since an AI feature switched on inside an existing product is a new place your data can go and deserves the same question as a new tool. In practice that only works if somebody is actually reading vendor release notes, which is a real job and is usually nobody's. Assign it to a person by name or accept that the route is ungoverned.

Route 4, AI that acts, needs a different document. An acceptable use policy governs what people may put into a tool. It has nothing to say about an automation holding credentials that can send mail or move files on someone's behalf. If you have agents running anywhere in the business, that is a separate piece of work and worth knowing you have not done rather than assuming this covers it.

Route 5, AI browsers, is worth watching rather than acting on today, unless your staff are already using one. If they move, a good deal of the visibility you thought you had quietly stops applying, and you would rather find that out now than during an incident.

None of this is a reason to skip the policy. It is a reason to keep the review cadence at three months instead of twelve, and to say out loud which routes are still open.

Rolling it out without the eye-rolling

Announce it before it lands, and say why. The framing that works is permission, not restriction: here are the tools you can use, here is who to ask, here is what happens if you get it wrong, and none of it is designed to catch you out.

Fill in the approved tools table before you circulate it. A policy that arrives with an empty table reads as a ban.

Get the signatures. Not for the paperwork, but because the act of signing is the only moment you can be reasonably confident everyone read it.

Then put the review in the calendar. The version of this document that matters is the one that gets revised in three months because two new tools appeared and somebody had a near miss. The version that gets signed and filed was never a control in the first place.

FAQ