How to write a one-page AI policy your team will actually read

Almost every SMB we work with eventually realises they need an AI policy. Almost as many then make the same mistake: they ask a law firm for a twenty-page document, or copy a template from the internet, or write something so vague that nobody can tell what it actually means. The result, in every case, is the same. The policy gets filed. Nobody reads it. People carry on using AI exactly as they were before, and the business has bought itself the worst of both worlds: false comfort at the top and zero behaviour change on the ground.

What a good AI policy is for

A good AI policy does three things. It tells the team what they can do with confidence. It tells them what they must not do. And it tells them who to ask when they're unsure. That's it. Anything more is usually decoration. Anything less leaves dangerous ambiguity. The bar to clear is that an employee who's never heard of AI before could read your policy and know how to behave by the end of it.

Why one page

Length and compliance are inversely correlated. A one-page policy is read in full by most of the team within a week of being shared. A ten-page policy is read in full by almost nobody. A twenty-page policy is read only by the legal team and the very nervous. If your policy can't fit on a single side of A4 in a readable font, it isn't a policy - it's a binder, and binders don't change behaviour.

The five things to include

Strip everything else out and make sure these five sections are there. Each one should be a short paragraph or a small list, not an essay.

• Scope. Who the policy applies to (employees, contractors, anyone using company devices), and which tools it covers.
• Approved tools. The specific list of AI tools the business has signed off for work use. Update quarterly.
• Off-limits data. The categories of information that must never be pasted into a public AI tool. Be specific: 'client lists, financial information, anything covered by an NDA, personal data we hold about customers or staff'.
• Disclosure rules. When and how the team should tell clients or colleagues that AI was used in producing something - usually 'when it would matter to them'.
• Help and incidents. Who to ask if you're unsure, and what to do if something has gone wrong.

What to leave out

Long preambles about the business's commitment to ethical AI. Theoretical discussions of model bias. Quotations from the Information Commissioner's Office. Lists of every possible AI tool that exists in the world. None of these change behaviour, and all of them lengthen the document past the point at which anybody will read it. Keep the philosophical material in a separate paper for the leadership team if you must - keep the policy itself ruthlessly practical.

Tone matters more than you think

A policy written in legalese will be ignored by the people it most needs to influence. A policy written in plain, slightly warm language - 'here's how we use AI well at this company' rather than 'use of artificial intelligence systems is governed by the following provisions' - gets read and remembered. The tone signals whether the business sees AI as something exciting to do well or something dangerous to be controlled. Both are partly true; the framing changes adoption.

Update it regularly, lightly

An AI policy that hasn't changed in twelve months is almost certainly out of date. The tools change. The risks change. The use cases change. Set a quarterly review with the named owner. Most of the time the changes will be small - adding a tool to the approved list, tightening one definition, reflecting a new piece of guidance from a regulator. Small, regular updates keep the policy alive. Annual rewrites tend to produce documents that are six months out of date the moment they're signed off.

Make it easy to find

Half the value of a policy comes from people being able to find it in the moment they need it. Pin it in the company wiki. Link to it from the onboarding pack. Include it in the new-starter checklist. Mention it in the AI section of the all-hands. If somebody has to ask three people where the AI policy lives, the policy might as well not exist.

Pair it with a short briefing

Writing the policy is half the job. The other half is a thirty-minute team briefing where the owner walks through it, takes questions, and tells two or three concrete stories about what 'good' and 'bad' look like in practice. People remember the stories. They forget the bullet points. Plan for both.

A simple template to start from

If you want a starting structure, write five short paragraphs in this order. One: who this applies to. Two: which AI tools we've approved for work, with a link to the live list. Three: what data must never be pasted into a public AI tool. Four: when and how to tell clients or colleagues that AI was involved. Five: who to ask for help and what to do if something goes wrong, with a name and an email address. Read it aloud. If any sentence sounds like a contract, rewrite it. If any rule isn't crystal clear, sharpen it. Stop when the page is full.

Get this right and the policy stops being a defensive document and becomes a useful tool. The team uses AI more confidently because they know where the lines are. Leadership sleeps better because they can see the basics are covered. And when a regulator or a key customer asks how the business handles AI, the answer fits on a single page that anybody can read in two minutes.