Most AI policies are written for a filing cabinet. They exist so that somebody can point at them after an incident, which is a legitimate purpose but a different one from changing what people do on a Tuesday afternoon.
You can tell the difference quickly. A policy written to be defensible opens with scope and definitions, runs to nine pages and reaches the practical question somewhere around page six, hedged. The practical question being: can I paste this client email into Copilot? A policy written to be followed answers that in the first paragraph.
Staff are not reading nine pages. They have a deadline and a tool that would help with it. If your policy does not answer their question in the time they are willing to give it, they will answer the question themselves.
Start from the questions people actually ask
We have written a few of these now, always by collecting the real questions first. They are remarkably consistent across businesses:
- Can I use ChatGPT or Claude for work at all, or only the Microsoft one we pay for?
- Can I paste a client email into it?
- Can I upload a contract, a policy document, a spreadsheet of names?
- Can I use it to write something a client will read? Do I have to say that I did?
- What about the meeting transcription thing that keeps asking to join calls?
- If it gets something wrong and I did not catch it, is that on me?
Answer those six plainly and you have covered the great majority of day-to-day exposure. Everything else is edge cases you can handle as they arise.
Three lists, not a framework
The structure that works is embarrassingly simple. Three lists, on one page.
Approved tools. Named products, not categories. "An enterprise-grade AI assistant" means nothing to somebody deciding whether to open a browser tab. "Microsoft 365 Copilot and Claude, through the company account" means something. If a tool is not on the list it is not approved, which is also how people find out that the list needs updating.
Data that never goes in. Again, specific. Client financial records, anything covered by a confidentiality clause, personal information about staff, credentials, anything you would not email to the wrong person. The test people remember is the one about a competitor reading it over your shoulder.
Work that always gets checked. Anything a client sees. Anything that becomes a record. Anything that informs a decision with money attached. The person who used the tool owns the output, exactly as they would own a paragraph they had typed themselves.
Say what happens when somebody gets it wrong
This is the part most policies dodge and the part that decides whether yours works.
If the answer to "I pasted something I should not have" is a disciplinary process, you will never hear about it again. You will not stop it happening. You will simply lose your only early warning that it did.
The answer that works is: tell somebody the same day, nothing happens to you, we deal with it. That costs you the satisfaction of a consequence. It buys you the ability to respond to an exposure in hours rather than finding out at renewal time when an insurer asks a question nobody can answer.
Put a date on it
Every AI policy we have seen without a review date has been out of date within a year, usually because a vendor turned a feature on by default. Quarterly is about right for the next while. It takes twenty minutes and the main output is usually one line added to the approved-tools list.
What good looks like
One page. Six answers. Three lists. A named person to ask. A review date.
If yours is longer than that, the extra pages are almost certainly working for the filing cabinet rather than for the person with the deadline. Both are fine to have. Just do not confuse one for the other, because only one of them changes what happens on Tuesday afternoon.