Why most AI policies fail
Most AI usage policies fail for the same reason most security policies fail: they are written to protect the organisation from its staff, so staff route around them.
The classic failure is the blanket ban. It is the easiest policy to write, it is defensible in a board paper, and it produces precisely one outcome: the same AI usage as before, now happening on personal devices and personal accounts where the organisation has no visibility, no logs and no controls. The risk did not fall. The ability to see it did.
The second failure is length. A fourteen-page document written by someone with a legal background will be read once, by the person who approved it. A policy nobody can recall the contents of is not a policy; it is a compliance artefact.
The third is vagueness. "Do not enter confidential information into AI tools" sounds firm and answers nothing. Is a customer's name confidential? A draft quote? A job description? Staff facing an ambiguous rule and a deadline will resolve the ambiguity in favour of the deadline, every time.
Start with data classes, not tools
The single most useful structural decision is to organise the policy around what data, not which tool. Tools change monthly. Your data classes do not.
Three or four classes is usually right. More than five and people stop being able to hold them in their head at the moment of decision, which is the only moment that matters.
A workable set:
- Public. Already published or intended to be. Marketing copy, published pricing, job ads, public documentation. Any approved tool, no restriction.
- Internal. Not sensitive but not for outsiders. Internal process notes, draft plans, non-identifying operational data. Approved tools only.
- Confidential. Client information, commercial terms, employee records, anything identifying a person. Sanctioned enterprise tools only, and only where a data processing agreement is in place.
- Restricted. Health information, credentials, records under a specific legal obligation, anything under an NDA that names AI. Not into any AI tool without a documented assessment.
Then give each class two or three real examples drawn from your own business. Examples are what make a policy usable; abstract definitions are what make it decorative.
What goes in the policy
Keep it to a page or two. Nine things belong in it.
1. Which tools are approved, and for which data class. A named list. Not "enterprise-grade tools", but the actual names, with the tier specified, because the consumer and enterprise tiers of the same product have entirely different contractual positions.
2. How a new tool gets assessed. Who to ask, what they need, and how long it takes. If the answer is "six weeks and a committee", you have designed a process people will bypass. Aim for days.
3. The data class rules. As above, with examples.
4. Human review requirements. What must be checked before AI-assisted work leaves the business. Be specific about who is accountable. In almost every professional context the answer is that the person whose name is on the output owns it, regardless of how it was drafted.
5. What must never go in, full stop. A short, memorable list. Credentials and access keys. Anything covered by a client NDA that restricts AI use. Personal health information outside a sanctioned clinical system. Keep it to four or five items so people remember them.
6. Disclosure. Whether and when clients are told AI was used. This is moving quickly. Enterprise and government buyers increasingly ask, and some now require it in the engagement terms. Better to have language ready than to compose it inside a tender response.
7. Attribution and accuracy. AI output is a draft. Facts, figures, citations and legal or regulatory references must be verified against a real source before they go anywhere. Confidently wrong is the characteristic failure mode of these tools and the policy should name it.
8. Personal accounts. Whether staff may use their own AI subscriptions for work. The realistic answer for most businesses is: not with anything above the Public class, and not connected to company systems. Say it explicitly, because otherwise the default is silence and silence reads as permission.
9. Who owns this policy. One named person. Not "the leadership team".
The clause almost nobody writes
Here is the clause that does more for actual risk reduction than the rest of the document combined:
If you realise you have put something into an AI tool that you should not have, tell [named person] the same day. There will be no disciplinary consequence for reporting it. There may be one for concealing it.
Data exposure is only manageable if you learn about it. An employee who pastes a client contract into a consumer chatbot and realises an hour later has a choice: say something, or say nothing and hope. In an organisation where the policy reads as a disciplinary instrument, they say nothing, and you lose the ability to notify, to assess, or to contain.
This clause costs nothing and it is the reason some organisations find out about incidents and others do not.
Keeping it current
An AI policy signed and filed is out of date within a quarter. Three habits keep it alive:
- A quarterly review of the approved tool list against what is in use. If those two lists have diverged, that is information about your policy, not about your staff.
- A trigger-based review whenever a major provider changes its terms, a new tool is adopted at scale, or a regulatory position shifts.
- A refresher for staff whenever the approved list changes materially: a ten-minute update rather than a training module.
And measure the one number that tells you whether the policy is real: the gap between sanctioned usage and total usage. If sanctioned usage is climbing and shadow usage is falling, the policy is working. If both are climbing, your approved tools are not good enough.
A working outline
If you are starting from nothing, this structure covers what matters without becoming unreadable:
- Why this exists. Two sentences. What we are protecting and why we are not banning AI.
- Approved tools. The named list, by data class.
- Data classes. Three or four, each with examples from our own work.
- Never. The short, memorable list.
- Before it leaves the building. Review and verification requirements, and who is accountable.
- Telling clients. The disclosure position.
- Personal accounts. What is and is not allowed.
- If something goes wrong. The amnesty clause.
- Getting a new tool approved. Who, what, and how long.
- Who owns this. A name and a review date.
Ten sections, one to two pages, written in the same voice as the rest of your internal documents.
The part that isn't the policy
A policy on its own changes very little. What changes behaviour is the pairing: a clear line, and a sanctioned tool on the right side of it that is genuinely good.
If the approved option is slower, more restricted or harder to reach than the one people were already using, the policy becomes a document describing what staff are not doing. Fund the good option first, then write the rules that point at it.