What makes a first draft fail?

Length and abstraction, usually together. A policy of principles gives no answer to the only question anybody actually has, which is whether this specific thing may go into that specific tool. Naming approved tools, classifying material and giving a route for unclear cases makes it actionable, and actionable is the whole point.

Should it ban anything outright?

Categories of material, yes, and it should be specific about which. Blanket tool bans are the part that tends to fail, because they work only where a sanctioned alternative covers the need. A prohibition with nothing behind it relocates the behaviour rather than ending it, and removes your visibility of it.

How often should it be revisited?

Often enough to keep up with what people are actually using, which in practice means a light review every few months rather than an annual set piece. The trigger worth watching is somebody asking about a tool the document does not mention, because that is the gap appearing while it is still small.

Somebody close enough to the work to know what people are actually trying to do, with review from whoever owns risk. Written purely by a risk function it tends to prohibit usefully vague amounts of activity; written purely by practitioners it tends to omit the material classifications that matter most.

Glossary

AI policy

An AI policy is the internal document setting out which AI tools staff may use, for what kinds of work, through which accounts, and what has to be checked before output is relied on.

In plain terms

It is the answer to a question people are already asking each other in corridors: am I allowed to put this into that. A good one is short, specific and readable in a few minutes, naming the tools that are approved, the kinds of material that must not go into any of them, and who to ask when a case is not covered. A bad one is a page of principles nobody can act on, which is why so many exist and so few are consulted.

Why it matters

Because without one the decision devolves to each individual, and they will make it, quietly and reasonably, based on what seems fine. That is how unapproved use starts and it is not a discipline failure: people cannot follow a rule that has not been written. A policy is also the cheapest control available, needing no procurement and no engineering, which is why it is usually the first thing an organisation does and why doing it badly is such a common waste of the opportunity.

How it works

It names tools and accounts, not just behaviours. The distinction that carries most of the risk is between a personal login and an administered organisational one, so a policy that approves a product without specifying which account it must be used through has left the important half unsaid.

It classifies material rather than listing every case. Nobody can enumerate the situations people will meet, so the workable form describes categories: what may never go into an external tool, what may with care, and what is unrestricted. People can then reason about a case that was never anticipated, which is the test a policy actually has to pass.

It says who decides the unclear cases and how long they take to answer. A policy with no route for the question it did not cover pushes people back into guessing, and the guess will be resolved in favour of getting the work done. Naming a person and a realistic response time does more for compliance than another paragraph of principle.

It states what has to be checked before output is used. The failure mode with generative tools is not usually the input but the unreviewed output, so a policy that only governs what goes in has addressed half the exposure and the less likely half at that.

It is short enough to be read, which is a design constraint rather than a nicety. A document nobody finishes governs nothing, and length is the commonest reason a policy exists on paper and not in practice. One page that people act on beats twelve that they skim once during onboarding.

Two first drafts

The difference between these is not seriousness or rigour; the left-hand version often took longer to write. It is that the right-hand version anticipates the moment the policy has to work, which is a person with a document open and a deadline, wondering whether to paste. At that moment nobody consults twelve pages and nobody derives a conclusion from a principle. They want to know whether this tool is approved, whether this kind of material is allowed, and who to ask if the answer is not obvious. A policy that answers those three questions in the time it takes to read a paragraph will be followed by people who would otherwise have guessed, and guessing in favour of the work is what produced the unapproved use in the first place.

Seen in the wild

Name which product tier is approved and require the organisational account rather than a personal one, since the terms differ between them.
ChatGPT
Approve a tool for internal questions over documents the organisation already controls, where the material never leaves systems you administer.
Glean
Permit a locally run model for material that may not be sent to any external service, and say who is responsible for keeping it updated.
Ollama

Common misconceptions

People assume

A policy will stop unapproved tool use.

In fact

On its own it rarely does, because the behaviour was driven by the approved route being slower rather than by ignorance of a rule. A policy paired with a sanctioned alternative works; a policy alone tends to move the activity somewhere less visible and add a reason not to mention it.

People assume

It should cover every eventuality.

In fact

That produces a document nobody reads, which governs nothing. Categories of material plus a named person for the unclear cases covers far more real situations than an exhaustive list, and it survives the arrival of tools that did not exist when it was written.

Telling them apart

AI policy vs AI governance

AI policy

The document. What staff may do, with which tools, through which accounts.

AI governance

The practice around it. Who approves, who reviews, who answers when something goes wrong.

One can be written in an afternoon; the other is a standing set of roles and decisions.

Questions

What makes a first draft fail?: Length and abstraction, usually together. A policy of principles gives no answer to the only question anybody actually has, which is whether this specific thing may go into that specific tool. Naming approved tools, classifying material and giving a route for unclear cases makes it actionable, and actionable is the whole point.
Should it ban anything outright?: Categories of material, yes, and it should be specific about which. Blanket tool bans are the part that tends to fail, because they work only where a sanctioned alternative covers the need. A prohibition with nothing behind it relocates the behaviour rather than ending it, and removes your visibility of it.
How often should it be revisited?: Often enough to keep up with what people are actually using, which in practice means a light review every few months rather than an annual set piece. The trigger worth watching is somebody asking about a tool the document does not mention, because that is the gap appearing while it is still small.
Who should write it?: Somebody close enough to the work to know what people are actually trying to do, with review from whoever owns risk. Written purely by a risk function it tends to prohibit usefully vague amounts of activity; written purely by practitioners it tends to omit the material classifications that matter most.

Key takeaways

It names approved tools and the accounts they must be used through, not just behaviours.
Classify material into categories rather than enumerating every case.
Give a named person and a realistic answer time for the cases it does not cover.
Govern the unreviewed output, not only what goes in.
A policy paired with a sanctioned alternative works; a policy alone usually relocates the behaviour.