The three ways an AI policy fails

The AI policy has become the document every organisation feels it should have, and most now do. Very few of those policies work, and the failures are not random. They cluster into three modes, each with its own tell, and a policy that avoids all three is rarer than it should be given how learnable the avoidance is.

Failure one: too vague

"Staff shall use AI responsibly, ethically and in line with our values."

The tell: no named tools, no named data classes, no named duties. Nothing an employee could clearly follow or clearly breach. Vague policies fail twice over. They give no protection to the conscientious employee who wants a line to stand behind, and they give no basis for action when something goes wrong, because "you acted irresponsibly" is an opinion, not a finding.

The cure is specificity. "Never enter client-confidential material into a tool that is not on the approved list" is followable and enforceable. "Be careful" is neither. If a clause could not, in principle, be breached, it is not a rule; it is decoration.

Failure two: too strict

"The use of generative AI tools is prohibited."

The blanket ban feels safe and produces the opposite. The deadline pressure that drove staff to AI tools does not go away; the tools stay one browser tab away; use continues and goes invisible. An organisation with a clear permission structure has visible AI use it can manage. An organisation with a ban has invisible use it cannot: no approved tools steering people away from risky ones, no verification habits, no incident reports, and its most conscientious people working at a disadvantage while the cavalier carry on.

Targeted bans are legitimate: specific tools, specific data classes, specific contexts. A blanket ban is usually a sign that nobody did the work of drawing real lines.

Failure three: unread

The most common failure and the most self-inflicted. Fourteen pages, launched by all-staff email in March, quoted next during an investigation in November. The tell: months later, nobody can recite a single rule from it, and the practical questions still circulate on chat with folk answers.

Length causes it, launch-by-email causes it, and the absence of training and attestation causes it. A two-page policy that everyone was actually trained on outperforms a comprehensive suite nobody opened, in every audit and every dispute.

The test that catches all three

Before drafting a clause, list the questions your staff are already asking, or answering for themselves. The universal ten:

1. Which AI tools may I use, and on which account?
2. What may I never paste into them?
3. Can I use AI for this client's or this student's work?
4. Do I have to check the output, and who is responsible if it is wrong?
5. Do I have to tell anyone I used AI, and whom?
6. Can I use my personal AI subscription for work?
7. What do I do when a tool I want is not on the list?
8. What happens if I make a mistake?
9. Who decides all of the above?
10. Where do I ask when none of the above answers me?

A policy that answers all ten in plain language is a good policy, whatever else it lacks. A policy that answers none of them is a values statement wearing a policy's clothes.

Four design choices that do most of the work

• Split the policy from the tools list. The policy holds the stable rules; the approved tools list lives in a separate standard the governance lead can update monthly without re-approval. This one structural choice is what keeps a two-page policy current in a market where tools change monthly.
• Make the sender own the output. One clause kills the "the AI wrote it" defence: the person who sends, publishes or acts on AI-assisted output is responsible for it, and verifies it as if they had written every word.
• Protect honest reporting in writing. State in the policy that prompt self-reporting of incidents is treated as compliance behaviour and weighs as mitigation. The moment a self-reported near-miss is punished harder than a concealed one, the reporting channel dies, and with it your early-warning system.
• Launch it like a project, not an email. Managers briefed first, thirty minutes of real training, a signed acknowledgement from everyone, and an amnesty window in which existing quiet AI use surfaces without sanction. What surfaces becomes your tool-approval queue; what stays hidden afterwards is now a choice, which changes its character.

None of this is exotic. The three failures persist because writing a specific, proportionate, trained policy takes more initial effort than publishing an aspirational one. The effort is repaid the first time something goes wrong and the policy turns out to say something.