How to write an AI acceptable use policy your team will actually read

Most AI acceptable use policies we see are eight pages of legalese that no employee has ever read past the first paragraph. They tend to be written by lawyers borrowing template language from larger enterprises, they cover risks that don't apply to the business, and they fail at the one thing they're supposed to do: change what people actually do at their desks.

A good SMB AI policy is short - one to two pages. It's specific about the tools you actually use. It uses examples not abstractions. And it's written so that a normal person in your business can read it in three minutes and know what they're allowed to do. Here's how to write one.

Start with the three questions that actually matter

Before you write a word, answer three questions for your business.

• Which AI tools are approved, and for what kinds of work? Be specific. 'Microsoft 365 Copilot for any office task', 'ChatGPT Team for research and writing', 'free consumer ChatGPT only on a personal device for non-work things'. The opposite of approved isn't 'banned' - it's 'ask first'.
• What kinds of information must never go into any AI tool, even an approved one? Customer personal data, employee personal data, anything covered by a confidentiality clause, anything you haven't yet announced commercially. Name the categories in plain English.
• Who is the person to ask when something isn't clear? Name them. A real person, with a real email address, who is empowered to give a quick answer.

Those three answers are 80% of your policy. Everything else is supporting detail.

Write it in the second person

'Employees shall not input confidential information into generative AI services' is the kind of sentence policies are full of and people skim. 'Don't paste customer data into ChatGPT' is the kind of sentence people remember on Tuesday afternoon when they're tempted to do exactly that.

Use 'you'. Use short sentences. Use real examples your team will recognise. The policy is a communication tool, not a legal contract - the legal contract is the employment agreement and the data protection clauses are elsewhere.

Use the 'do this, not that' format

For every rule, give a concrete example of the right behaviour and the wrong behaviour. This is far more useful than a list of abstract principles.

• DO use Copilot to draft a reply to a customer complaint based on the email thread in your inbox.
• DON'T paste the customer's full account history into ChatGPT to 'help analyse the situation'.
• DO ask Copilot to summarise an internal meeting you were in.
• DON'T ask any AI tool to predict whether to hire someone based on their CV.

Five or six of these covers most of what people will actually encounter. It's vastly more memorable than principles like 'use AI responsibly'.

Cover the bits that always come up

Three topics generate the most questions in our experience and deserve their own short sections.

First, attribution and disclosure. If a team member uses AI to draft a piece of client work, do they need to disclose that? In most B2B services contexts the answer is 'use it as a tool, take responsibility for the output as your own work, don't claim the AI did it and don't hide that you used it if asked'. Write that down.

Second, hallucinations and accuracy. AI tools confidently invent facts, citations, statistics and quotes. The policy should be explicit that anything customer-facing or decision-grade needs to be checked by a human before it goes out. Make it the user's responsibility, not the tool's.

Third, copyright and ownership. Outputs from major AI tools are generally considered usable for commercial purposes, but the team should not paste copyrighted material in (full articles, third-party reports, competitor white papers) and should not generate images of identifiable real people without consent. Two sentences each, in plain English.

Approve a clear list, refresh it quarterly

Maintain a short, visible list of approved AI tools for your business. Make it easy to find - the company intranet front page, or the welcome handbook. Refresh it quarterly. When a new tool comes along (and they do, constantly), the named owner of the policy makes the call to add or not add it, and updates the list.

This solves a problem that otherwise quietly grows: shadow AI use. If the approved list is up to date and reasonable, people will use those tools. If it's stuck in 2024, they'll go and use whatever they read about on LinkedIn last week, with no oversight at all.

Train the policy, don't just publish it

A policy nobody knows about is decorative. Spend 15 minutes on it in every new starter induction. Run a 30-minute refresher annually for the whole company. And tie it to your AI training: every time you train someone on Copilot, the last five minutes covers the policy. That's enough cadence to keep it alive without becoming heavy.

What to leave out

Things that don't belong in your acceptable use policy: detailed technical architecture, vendor contract terms, GDPR clauses (those live in your data protection documentation), exhaustive lists of every possible AI tool in existence, philosophical positions on whether AI is good or bad for society. Keep the policy operational. The other stuff has its own home.

The honest summary

The best AI policy in an SMB fits on two sides of A4, names a real person to ask, lists the approved tools, gives concrete do-and-don't examples, and is refreshed quarterly. It will not win awards for completeness. It will, however, get read by your team and actually change behaviour - which is the entire point. Long policies that nobody reads are not safer than short policies that everyone reads; they're just slower to write.