How to write an AI usage policy

By Dylan Bailey, Certified Claude Expert · Updated 4 August 2026 · 7 min read

Most AI policies fail the same way. Someone finds a template, adapts twelve pages of it, circulates it once, and it's never read again. Meanwhile the actual decisions — can I paste this client email in? — keep getting made by whoever has the deadline.

A policy that works is short enough to remember and specific enough to act on. Four questions do most of the work.

1. Which tools are approved?

Name them. Not "approved AI tools" — the actual products, and which account people should use.

This is the highest-value line in the document, because it's the one that removes the excuse. Staff reach for free consumer tools mainly when nothing else has been provided. Approving a business-tier account and saying so eliminates most unsanctioned use at a stroke.

Say what to do about anything not on the list, too: usually "ask before using", not silence.

2. What may and may not go in?

Three buckets are enough, and examples beat definitions. Use your own work, not generic categories:

• Fine — marketing copy, internal process notes, general questions, anything already public.
• Careful — internal financials, staff matters, client work with identifying details removed. Approved tools only.
• Never — client personal information, health or financial records, anything under an NDA or specific regulatory obligation.

Add one habit that carries a lot of weight: refer to clients as "Client A" rather than by name. It costs nothing and moves a great deal of work from the second bucket into the first.

3. When must a human check the output?

The rule that matters: anything that leaves the business, or that someone will rely on, gets read by a person first.

Worth spelling out where checking is non-negotiable:

• Anything going to a client or the public
• Numbers, dates, quotes and calculations
• Anything citing law, regulation or a standard
• Any action that can't be undone — sending, paying, publishing, deleting

AI output is confident regardless of whether it's right, which is precisely why the checking step can't be left to judgement in a hurry.

4. Who do I ask?

Name a person. The most common reason a policy gets breached isn't disagreement — it's an edge case at 4:45pm with nobody obvious to ask.

One named person, and an explicit line that asking is always the right call, converts most of your risk into a thirty-second conversation.

An Australian small-business example

A 15-person Adelaide engineering consultancy wrote a two-page policy, got it signed, and saw no change in behaviour — staff couldn't recall what it said.

They replaced it with a single page: the approved tool and login, the three buckets using their own project examples, the four must-check situations, and the operations manager's name.

It went on the wall by the printer and into the induction pack. Six months on, people quote it in conversation — which is the only test that matters. Same obligations, a fraction of the words, and it's actually operating.

What to leave out

• Definitions of AI. Nobody needs "artificial intelligence means…" to decide whether to paste in a contract.
• Lists of specific models. They date within months. Name products and accounts instead.
• Aspirational language. "We are committed to responsible innovation" guides no decisions.
• Rules you won't enforce. An unenforced rule teaches people the document is decorative.

The test

Hand it to someone who wasn't involved in writing it and ask: can I put this client email into AI to draft a reply?

If they can answer from the page in under thirty seconds, it's a working policy. If they have to search, interpret or guess, it's a document — and documents don't change what happens at 4:45pm on a Friday.