Write an AI usage policy your team will actually follow
Short, specific and permissive by default — because the alternative is a policy people route around.
Before you start
- Knowing which tools your team already uses
- Someone who can approve exceptions
What you will be able to do
- Write a policy that fits on one page
- Draw the data line where it is actually enforceable
- Give people a route to ask instead of a reason to hide
Most AI policies are written defensively, run to several pages, and are read once during onboarding.
The result is predictable: people use the tools anyway, on personal accounts, without asking. A shorter policy that says yes to most things gets followed and gives you visibility.
Find out what is already being used
Ask without consequences first. The answer shapes everything else.
Before writing anything, ask the team what they use, anonymously if that helps. You will find more tools than you expected, several of them on personal accounts.
That is the actual situation your policy has to address. Writing rules for the situation you assumed produces a document that is wrong on its first day.
Three lists, and make the green one long
Always fine · ask first · never. Most work belongs in the first list.
Structure the whole policy as three lists of concrete activities. Always fine: drafting internal text, summarising public material, code you will review. Ask first: anything customer-facing, anything with personal data, anything contractual. Never: credentials, unreleased financials, anything covered by an NDA.
If the green list is short, people will conclude the policy is anti-AI and stop consulting it. It should cover the majority of daily work.
- Write the lists as activities people recognise from their own week, not as categories of data. "Pasting a customer email" lands; "PII" does not.
Name the tools and the accounts
A policy that says "approved tools" without naming them is not a policy.
List the specific tools people may use, and say which account — the company workspace rather than a personal login. This one line does most of the real data-protection work in the document, because business tiers generally do not train on your inputs and consumer tiers may.
Keep the list somewhere editable and say who updates it, or it will be stale within a quarter and quietly ignored.
Say who to ask, by name
The unlisted case is the whole point of having a policy.
End with a person and a channel: "not sure? ask in #ai-help". Every policy has gaps, and the difference between a good one and a bad one is whether someone hitting a gap asks or guesses.
Commit to answering quickly. A route that takes three days to produce an answer is a route people stop using after the second time.
- Routing every question to legal. It is correct, it is slow, and it converts a question into a decision to proceed without asking.
One page, three lists, named tools, and a person to ask. If it does not fit on a page, it will not be followed.
Common questions
Was this guide useful?
90% of readers found this useful
Read next
Estimate what an AI feature will cost you per month
Per-token pricing looks trivially cheap and routinely surprises people at the invoice. The gap is almost always retries, context a…
Run an AI pilot that produces a decision, not a demo
A pilot that cannot fail is not a pilot. Setting the success threshold before you start is what turns an interesting experiment in…
Connect two apps with an AI step in the middle
The genuinely useful automations are not the clever ones. They are a trigger, one AI step that makes a small judgement, and a writ…
Write ad variants and test them properly
AI removes the cost of writing variants, which makes it very easy to run tests that cannot teach you anything. The discipline is i…
