How to Write an AI Use Policy Your Team Will Follow

Start from what people are already doing

Before writing a word, find out how AI is being used in your organisation today. Not the sanctioned list — the real one. Expense reports show personal subscriptions. Browser and identity logs show which assistants people sign into. A short, non-punitive survey asking what people use and for what will get honest answers if it is clearly not an audit, and the answers are usually more mundane and more widespread than the leadership team expects.

This matters because a policy written against an imagined situation will forbid things nobody does and stay silent about the thing half the company does daily. It also tells you which needs are real, and a policy that quietly bans a workflow people depend on has not stopped that workflow. It has moved it to a personal account, where you have neither control nor visibility.

Name the tools, not the category

An employee at their desk at nine in the morning needs to know whether the thing in front of them is allowed. "Enterprise-grade assistants with appropriate contractual protections" does not answer that question, and the person asking it will resolve the ambiguity in whichever direction gets their work done. List the approved tools by name, with the plan or tier where that matters, because the free and paid tiers of the same product often differ on exactly the terms you care about.

Keep the list somewhere it can change without reissuing the policy — a linked page owned by whoever runs the approval process. The policy states the rule; the list is operational data, and coupling the two means the list goes stale at the speed of document revisions rather than the speed of the market.

Reuse the data classification you already have

Most organisations already have labels for their data, whatever they are called: public, internal, confidential, restricted. Use those, and state which classes may go into which tools. Inventing a new vocabulary for AI creates a second scheme people have to learn and reconcile, and the reconciliation will be done by guesswork at the moment of use.

Where you do need AI-specific detail, keep it concrete: customer records, credentials and access tokens, unreleased financials, anything under a confidentiality obligation to a third party, personal data about identifiable people. Then say what to do when someone is unsure, because that is the case the rules will not cover, and a named person or channel to ask is worth more than another paragraph of definition.

Say what happens to the output

Most policies cover input and stop there. That leaves the more common failure unaddressed: a fluent, wrong answer travelling onward because it looked finished. State the review expectation for the outputs that matter. Whether AI-assisted code needs a human review before merge. Whether a draft going to a customer needs someone to read it. Whether generated material can be published without saying so. Whether a number in a report needs to be traced to its source.

Frame these as the review the work already deserves rather than as AI-specific bureaucracy. Nobody merges unreviewed code from a new contractor either. Setting the expectation in those terms makes it intuitive, and it avoids the impression that AI output is under suspicion while everything else is trusted.

Give people a route to ask

Every restrictive policy needs a door. If someone needs a tool that is not on the list, there has to be a way to request it, a stated response time, and a real chance of a yes. Without that, the approved list becomes a ceiling on what the organisation can do, and the gap between the ceiling and the need is filled by unmanaged accounts. A request path with a two-week answer does more for compliance than another page of prohibitions.

Make it short and findable

A policy people cannot find is a policy people cannot follow. One page, linked from wherever the tools are, mentioned in onboarding, and written in the language people use rather than in contract prose. If it takes more than a couple of minutes to read, the parts that matter will be skipped along with the parts that do not, and length is not evidence of rigour.

Treat it as a living document

Give it an owner and a review date. This field changes fast enough that a policy written a year ago will name products that have been renamed or retired and say nothing about capabilities that did not exist when it was drafted, and a document that is visibly out of date teaches people that none of it is current.

Then watch the exception requests, because they are the best available feedback on whether the policy is right. Several requests of the same shape mean the rule is wrong or the approved options do not cover a genuine need, and the correct response is to change the rule rather than keep granting the same waiver. A policy that never generates exceptions is not necessarily well written — it may simply be one nobody consults.