How to write an AI acceptable-use policy for a small team

A small team's AI acceptable-use policy should fit on one page and make the approved route the easiest one. Name the tools people may use and on which accounts, sort your data into what can and cannot go into them, make the person who sends the output responsible for it, and name one owner who reviews it every quarter.

Most AI policies I'm shown were written to stop something. They list what staff must not do, they run to several pages, and they were drafted by someone who doesn't use the tools. Then everyone carries on using ChatGPT on their phones, because the policy made the safe route harder than the unsafe one. The point of a policy is not to put a ban on record. It is to change where the work actually happens.

Why does a small team need an AI policy at all?

Because your team is already using AI, and the only open question is on whose terms.

In a Censuswide survey of more than 2,000 UK employees for Microsoft, 71% said they had used AI tools their employer had not approved, and only 30% of those were concerned about the privacy of the company or customer data they put in (Euronews). Deloitte's survey of 25,000 people, published last month, found that half of the UK workers using AI had received no formal guidance or training. The National Cyber Security Centre's response was that "IT security teams should not assume they are seeing the full picture" (Claims Journal).

None of that is a small-business problem specifically, but the consequences land harder in one. A 30-person firm has no security team to notice. Under UK GDPR, a client's name and circumstances pasted into a chatbot is personal data that your business is processing, whether or not anyone meant it to be (ICO). And your clients' contracts increasingly ask what you do with their information. "We have no policy" is not an answer that survives a supplier questionnaire.

Why don't AI bans work?

Because the tools are on everyone's phone, and a ban only removes your visibility, not the use.

Samsung is the standard example. In 2023 its engineers pasted internal source code into ChatGPT, and the company's response was to ban generative AI on company devices (Bloomberg). That works, more or less, if you are a company with locked-down hardware and the resources to build an internal alternative. For a small team it just means the same work happens on a personal account, where you have no control over retention, no admin console and no idea it is happening.

The incentive is also hard to argue with. The same Microsoft research found that people using unapproved tools were saving just under eight hours a week, mostly on administrative work. Nobody gives that up because of a paragraph in the staff handbook. What they will do is move to a better tool, if you give them one.

So the policy's real job is to make three things true: the approved tool is at least as good as the one on their phone, it is obvious what may go into it, and it is obvious who is responsible for what comes out.

What should the policy actually say?

Seven short sections. Here is the shape I use, with the wording kept deliberately plain so that it's read rather than signed.

1. Why we have this. "We want everyone to use AI where it helps. This page says which tools, what goes in, and who checks what comes out." One sentence of intent changes how the rest is read: it's a licence, not a warning.
2. Approved tools, and on which accounts. A short list, each with the account type: "Claude on our Team plan, signed in with your work email. Not a personal account." The account matters more than the brand, for reasons covered in the next section.
3. What can go in. A three-colour rule is enough for most teams:
   • Green: anything public, or your own drafts. Marketing copy, published information, general research. Any approved tool.
   • Amber: internal business information, such as figures, plans, supplier terms and anonymised client work. Approved business accounts only.
   • Red: personal data about clients or staff, anything a client contract restricts, credentials, and anything covered by legal privilege. Not into a general-purpose assistant at all, unless a specific tool has been approved for that specific data.
4. What comes out is yours. "If you send it, you own it. AI output is a first draft, and you check it as if a new starter had written it." Figures, names, citations and anything going to a client get checked against the source.
5. What we tell people. When a client should know AI was involved, and how you say so. For most firms this is a line in your terms rather than a label on every email, but decide it once rather than leaving each person to decide.
6. Who to ask. One named person, not "IT" or "management". Make it someone people will actually message.
7. When this changes. "Reviewed every quarter. Tell [name] if a tool you need isn't on the list." The second sentence is the important one: it turns the approved list into something people add to rather than route around.

That is a page. If yours is three pages, the extra two are almost certainly written for an auditor rather than for the person drafting an email at four o'clock, and that person is the one you need to reach.

Which tools belong on the approved list?

The ones you're paying for on a business account, because that is where the meaningful protections sit.

The difference between consumer and business accounts is larger than most people realise. OpenAI does not train on inputs from ChatGPT Business, Enterprise or the API by default, but on Free, Plus and Pro accounts the "Improve the model for everyone" setting is on unless the user switches it off (OpenAI). Anthropic changed its consumer terms in 2025 so that Free, Pro and Max users choose whether their chats are used for training, with retention extended to five years for those who allow it. The change explicitly excluded Claude for Work and the API (Anthropic).

Same model, same interface, very different terms. A member of staff on a personal Plus account and a colleague on the company's business seat are doing quite different things with your data, and neither of them can tell from the screen. That is the single biggest reason to pay for business seats: not the features, the contract.

Two other tests decide the list. Can you remove someone's access when they leave? A tool with no admin console is a tool you cannot offboard from. And does it tie you to one supplier? I've written about choosing between frontier assistants and the ones bundled into your office suite, and about the cost of betting on one platform. A list with two tools on it survives one of them changing its terms.

Who is accountable for what the AI produces?

The person who sends it. The policy should say so in exactly those words. The individual is responsible for what they send. The business is responsible for whether it told them how. A one-page policy, read and understood, is the cheapest way to be able to say you did.

For automated work, checking is a design problem rather than "read it carefully", which I covered in how to check what an AI agent actually did. For a person drafting with an assistant, the rule in the policy is enough.

How do you get people to actually follow it?

Start by asking what they already use, with an amnesty.

A short, no-blame message works: "Tell me which AI tools you use for work, and for what. I want the approved list to include what's actually useful." You will learn more from the replies than from any audit, and the policy you write afterwards will reflect how work is really done in your business rather than how you imagine it is.

Then do three things. Pay for the business seats, so the approved tool is the better tool. Spend half an hour walking the team through the three colours with real examples from your own work, because "personal data" is abstract and "the spreadsheet of client renewals" is not. And put the quarterly review on the calendar, owned by the person named in section 6, because the tools change quickly enough that a list from a year ago is already wrong.

When is a one-page policy not enough?

When AI starts making or shaping decisions rather than drafting text.

The page above is for people using assistants to write, summarise and research. It is not sufficient if you are using AI to screen job applicants or make decisions about individuals, where GDPR has specific rules on automated decision-making and you will want a data protection impact assessment. And it is not sufficient once you have automations running without a person reading every output, because then the controls have to live in the system rather than in a document. Those cases need proper design, not a longer policy.

The bottom line

Your team is already using AI. A policy that bans it will be ignored, and one that runs to five pages won't be read. Write one page: the approved tools and the accounts they run on, three colours of data, "if you send it, you own it", one named owner, and a quarterly review. Pay for the business seats so the safe route is also the better one, and ask your team what they use before you write a word of it.

If you want help setting the policy alongside the tools and the first few uses that justify paying for them, that is the kind of work I do as fractional AI leadership: a few days a month, with someone senior owning the question rather than leaving it to whoever was keenest. A thirty-minute discovery call will tell you whether it's worth doing.