Write an AI acceptable use policy people actually follow
Two weeks, in the right order. Inventory first, decisions second, drafting third, because a policy written before you know what is in use prohibits the tools your teams depend on and misses the ones nobody named.
By Parminder Kumar Sharma · · 8 min read
The order that decides whether this works
Write the inventory first. Then the policy.
That sounds like process advice and it is the whole tutorial. A policy written before you know what is in use prohibits tools teams already depend on, misses the ones nobody thought to name, and makes the first governance conversation an adversarial one. You then spend a year finding out what people are actually doing, from people who now have a reason not to tell you.
Two weeks, in order
- Days 1–4Find what is in use
- Days 5–7Make the decisions
- Days 8–9Write it
- Days 10–14Land it
- 1Measure, do not survey Telemetry, expense data, sign-on logs
- 2The AI nobody bought Features switched on inside software already licensed
- 3Prohibited data classes Named, so nobody has to guess what counts
- 4The amnesty clause Disclosure does not attract discipline
Days 1 to 4: find out what is actually in use
Measure, do not survey
Network and SaaS telemetry, expense data, single sign-on logs, browser extension inventories. Asking produces a list of what people think is sanctioned. Measuring produces the real one.
If the inventory contains no surprises, it is not finished.
You should see: Your list contains at least one tool nobody in the room knew about.
Include the AI nobody bought
The largest category in most organisations is AI that arrived switched on inside existing products: meeting transcription, drafting assistance, summarisation in the ticketing system, code completion in the IDE. Nobody procured it, nobody assessed it, and staff do not think of it as "using AI".
You should see: Your list covers features inside software you already licence.
Record what data reaches each one
Personal data, client confidential, source code, unpublished financials, or nothing sensitive. This is what turns a list into something you can prioritise, and it is the input to the prohibition section later.
You should see: One line per tool naming the most sensitive class of data it sees.
Days 5 to 7: make the decisions
A policy is a set of decisions. If you have not made them, you are not writing a policy, you are writing a document about one.
Decisions only you can make
- Your overall posture: enable broadly, enable by role, or restrict to approved cases.
- Which data classes must never be entered into an AI tool.
- Who approves a new tool, and how long that takes.
- Who owns the policy and can grant an exception.
- What happens when output is relied on and turns out to be wrong.
Things a template can supply
- Structure and headings.
- Standard definitions.
- Boilerplate on scope and applicability.
- The parts nobody argues about.
The six decisions the policy actually makes
A policy is a set of decisions written down. Everything else in the document is framing. These six are the ones people will look up, and a policy that leaves any of them ambiguous will be interpreted by whoever is in a hurry.
What to decide, and the answer that causes fewest disputes
| Decision | The question people ask | An answer that holds |
|---|---|---|
| Approved tools | Can I use this one | A named list, plus a route to add to it that takes days rather than a quarter |
| Client data | Can I paste a client document in | Not into anything not on the list. Into approved tools only where the contract permits it, and the contract is the test |
| Personal data | What about names and emails | Only where a lawful basis already covers the processing. The tool does not create one |
| Code | Can I paste our source in | Approved tools only, and never credentials, keys or configuration, which is where the real exposure is |
| Attribution | Do I have to say I used AI | For anything published externally or forming part of a deliverable, yes. For a first draft nobody sees, no |
| Accountability | Who is responsible if it is wrong | The person who used it. This sentence is the whole policy and it belongs near the top |
The last row is the one that changes behaviour. Most drafts bury accountability in a closing paragraph about compliance, and most readers never reach it. Put it in the first screen and much of the rest becomes obvious.
Days 8 to 9: write it
Lead with what is permitted
Policies that open with prohibitions get skimmed and resented. Policies that open with "here is what you can use, and here is the boundary" get read. Same content, different order, materially different compliance.
You should see: A reader can tell in the first paragraph what they are allowed to do.
Name the prohibited data classes explicitly
"Sensitive information" is not a boundary; it delegates the judgement back to the person you were trying to help. Name the classes: personal data, client confidential, credentials, unpublished financials, legally privileged material, HR case files.
You should see: No reasonable person could be unsure whether a given document is covered.
Cover the things people do not think of as AI
Meeting note-takers sitting in confidential discussions are the most common quiet exposure in organisations that believe they have this under control.
You should see: The policy explicitly mentions transcription and features inside existing tools.
Say who is accountable for the output
AI output is a draft, not a source. Whoever produced the work is accountable for it to the same standard as work they produced without assistance, and where an output affects a person, a competent human has to be able to explain the decision without reference to the tool.
You should see: A sentence making clear that the person using the tool remains responsible.
Why most of these policies fail
Three failure modes, and the first is by far the most common.
It bans the thing people are already doing. A policy that prohibits tools in daily use across the organisation does not stop the use. It moves the use off corporate accounts and onto personal ones, which removes the logging, the data controls and any chance of knowing what happened. The inventory step exists precisely so the policy is written about reality rather than about a preference.
It is written for an auditor rather than for the person deciding. A policy that opens with scope, definitions and regulatory context is a compliance artefact. The reader wants to know whether they can paste this document into that tool, and if the answer takes four screens to reach they will guess.
It has no route to say yes. If the only mechanism is a prohibition list with no way to get something added, every new tool becomes a violation by default. A named owner and a stated turnaround, even a slow one, converts shadow use into requests.
How long it should be, and what to leave out
One page. Two if the organisation is large enough that the approval route needs explaining. Anything longer is not read, and an unread policy provides no defence and changes no behaviour.
What earns its place: the six decisions above, the named owner, the route to request a new tool, and the accountability sentence.
What to leave out, because it belongs elsewhere and dilutes what does not. Definitions of artificial intelligence, which nobody looks up and which date badly. Regulatory background, which belongs in the governance framework this policy sits under. Tool-specific configuration instructions, which change faster than a policy can be reissued and belong in a knowledge base article the policy links to. And any attempt to enumerate prohibited use cases exhaustively, which fails the moment somebody invents a new one.
The test is whether a new joiner can read it in three minutes and answer the question that brought them to it. If they cannot, the length is the problem rather than the wording.
Days 10 to 14: land it
A policy nobody has read is not a control, and "it was circulated" is not evidence of anything.
Take this with you
Before you call it done
- The approval route has been tested by someone actually using it, end to end.
- The policy names a real owner who knows they own it.
- Training exists and attendance is recorded, because under the EU AI Act literacy duty what matters is that support was offered, resourced and evidenced.
- Someone outside the drafting group has read it and understood it without explanation.
- A review date is set, because in this area an unreviewed policy is wrong within months.
- The inventory that produced it is stored alongside it, dated.
Verified
Written 5 August 2026. The literacy duty position reflects Article 4 of the EU AI Act as replaced by Regulation (EU) 2026/1744, which made it an obligation of effort rather than of result.
