›

Team and company adoption

Writing an AI policy that isn't bullshit

One page your team will actually read, instead of ten they won't.

Listen to this articleAI-generated voice

Most AI policies are bullshit. They're long, cautious, and written by someone who hasn't used the tools. Full of clauses that nobody reads. Signed by people who immediately go back to doing whatever they were doing.

A useful AI policy looks different. It's short, specific, and reflects how people actually use AI. It says what's allowed, what isn't, and what to do when something is unclear. The second kind is the one worth writing.

Why most policies fail

Three reasons, and they compound. The policy is written before anyone is really using AI, so it's theoretical: it anticipates problems that won't happen and misses the ones that will. It tries to cover everything, runs to twenty pages, and nobody reads it, so people follow vague intuition instead. And it's written in legal language for an audience of ordinary colleagues, so even the ones who read it don't know what they're being asked to do.

The result satisfies a compliance checkbox without changing behaviour, which was the entire point of having one.

Put it in

  • The approved tools, and which tier they're on

  • What AI is used for here, in five to ten lines

  • What it's never used for. The highest-value section

  • Who to ask when a situation isn't covered

  • The default when in doubt

Leave it out

  • Any explanation of what AI is

  • An attempt to list every possible use case

  • Data protection law restated instead of referenced

  • "We believe in responsible AI" and similar

  • Any rule you know nobody will enforce

If nobody is reading your AI policy, you don't have an AI policy.

One page, four sections

  • Tools. Three to five sentences naming what's approved and on which tier. "Our default is Claude for Work and everyone has access. For a second opinion you may also use ChatGPT Team. Both are on paid business tiers with data protections in place."

  • What we use it for. Five to ten short lines. Drafting, summarising, generating options, restructuring notes, translating, fixing tone, supporting research with verification.

  • What we don't use it for. Most of the value sits here, because this is the part that tells people exactly what to avoid. Client personal data, credentials and API keys, anything under NDA, AI output passed off as original analysis, material business decisions taken on AI output alone, final review of client-facing legal or financial content.

  • When in doubt. Two or three sentences. Who to ask, and the default: if you'd hesitate to disclose this AI use to a client or a colleague, don't do it.

Write it from what people already do

The order matters more than the wording. Ask everyone how they're using AI right now, what's working, and what gives them pause. Look for the patterns: what is clearly fine, what is clearly not, and the grey cases people are unsure about. Write the policy around what you found, then show it to the team for feedback rather than sign-off, revise once, publish, and put a recurring date in the calendar to revise it again.

That takes about a week. Larger organisations will also need the formal documents, a data protection assessment, contractual language for clients. Those handle compliance. The one page handles behaviour. They're different jobs and you need both.

Three things to do this week

01

Write it after real use, not before

A policy written in advance describes an imaginary team. Watch what people actually do first, then write that down.

02

Cover the unclear case explicitly

Most of the value is one line telling people who to ask when the policy doesn't cover their situation.

03

Leave out the primer

Nobody needs an explanation of what AI is inside a policy. Save that for the training material.

One-page policy skeleton

AI POLICY: [COMPANY] Last reviewed: [DATE] 1. TOOLS Our default AI tool is [tool, tier]. Everyone on the team has access. You may also use [second tool, tier]. Both are on paid business tiers with data protections in place. 2. WHAT WE USE AI FOR - Drafting emails and longer-form documents - Summarising meetings and long material - Generating ideas and options - Restructuring rough notes - Translating between languages - Fixing tone and style - Supporting research, with verification 3. WHAT WE DON'T USE AI FOR - Client personal data in any AI tool, unless covered by client-specific data agreements - Login credentials, API keys or authentication tokens - Any document under NDA without explicit confirmation - Content passed off as original analysis without verification - Material business decisions made on AI output alone - Final review of client-facing legal, financial or contractual content 4. WHEN IN DOUBT If you're unsure whether something is appropriate AI use, ask [name/role] before doing it. The default is: if you'd hesitate to disclose this AI use to a client or colleague, don't do it.

Conclusion

01

One to two pages, written after people are already using AI, not before.

02

What's allowed, what isn't, and what to do when it's unclear. In plain language.

03

Twenty pages nobody reads isn't a policy. It's a compliance artefact.

Mark as read

Go to next