Most AI acceptable-use policies we read at SME clients are inherited from a template. They are six to ten pages long, cover every possible AI scenario the drafter could think of, mention regulations the business is not subject to, and have not been opened by anyone except the person who saved them to SharePoint. They are not policies. They are paperwork.

The policies that actually shape behaviour are the ones the team can read in under five minutes and remember the headline of. We have written a handful of these for SME clients and the shape is now fairly settled. It is five sections, two pages, and a review every six months.

Why the template policy fails

Three patterns sink the inherited-template AI policy.

It is too generic to be useful. "Employees must use AI tools responsibly" is not a policy; it is an aspiration. The employee asking "can I paste this customer email into ChatGPT to draft a reply" gets no answer from the document. So they paste it in, because the work needs doing.

It lists tools the business does not use. Templates often enumerate fifteen AI products by name, most of which the business has never bought a seat for. The team reads the list and concludes the policy was not written for them, because it was not.

It mixes the policy with the rationale. Two pages of "why AI matters and how AI is changing work" before any actual rule. Nobody gets to the rule. Whatever is on page one is the policy in practice.

The fix is not a longer policy. It is a shorter one, written for the actual stack, with the supporting material in an appendix the curious can read and the rest can ignore.

The five sections

The shape we have landed on:

1. Approved tools (one paragraph)

The named list of AI products the business has paid for and configured. "We use Microsoft Copilot for Microsoft 365 and ChatGPT Team. No other AI tool is approved for work data." That is the section. If the team wants to use something else they have to ask, because the policy is enumerative not permissive.

Three notes on this section. First, name the products by their full enterprise tier ("Microsoft Copilot for Microsoft 365", not just "Copilot"), because the consumer tier is a different product with different data-handling commitments. Second, update this section quarterly; the AI vendor landscape moves fast enough that "approved tools" goes out of date. Third, keep the unapproved list short or do not have one; the rule is "approved" not "everything except these".

2. Data classification (one paragraph, one table)

Three classes of data, each with a yes/no answer for AI use. The team comes back to this section more than any of the others, which is why it earns the space.

  • Public data. Marketing copy, published documents, general web research. Any approved AI tool, no restriction. Use it.
  • Internal data. Internal documents, meeting notes, draft work, anything not classified higher. Approved AI tools only, inside the enterprise tier. Standard work.
  • Confidential or regulated data. Customer personal data, financial information, employee records, anything covered by a confidentiality agreement, anything regulated. Do not paste this into any AI tool unless a specific configuration has been signed off, which it will not have been for the everyday Copilot or ChatGPT seat.

The table is short, the team can remember it, and that is the point.

3. Workflow scope (one paragraph)

What the AI tools are for, and what they are not for. Two lines.

What they are for: drafting, summarising, searching, first-pass analysis of documents and emails. Anything where a human is reviewing the output before it goes anywhere.

What they are not for: making decisions on behalf of customers, generating financial figures used as the source of record, drafting legal commitments without legal review, replying to customer queries without a human read. Anything in band three or band four of the risk frame, in other words.

4. What to do if something goes wrong (one paragraph)

If something has gone into an AI tool that should not have, the team needs a route. The route is: tell the IT lead, do not delete the chat (it is the evidence), do not panic. The IT lead then assesses whether anything material has happened, contacts the vendor if needed, and decides on next steps. Disciplinary action is not the default; the default is education and a process tweak.

The policy that punishes mistakes loudly is the policy that hides them. The team learns to not say when they have made a slip, and the slip becomes a real problem rather than a teachable moment. The opposite stance, treating slips as policy improvements, gets better outcomes.

5. Review cadence (one line)

"This policy is reviewed every six months by the IT lead. Last reviewed: [date]." That is the section. Without it, the policy ages and the approved-tools list goes stale.

The supporting appendix

For the curious, three appendices at the end, none of which the staff member needs to read:

  • A. Why these tools. The reasoning behind the approved list, what the enterprise tier covers, the data-handling commitments in plain English.
  • B. Worked examples. Six or seven scenarios staff have actually asked about, with the answer. "Can I paste a CV into Copilot to summarise it" gets a specific answer rather than the team guessing.
  • C. The compliance map. Where this policy maps to UK GDPR, the ICO guidance on AI, and any sector-specific regulator. This is the section that satisfies the cyber-insurance questionnaire.

The appendices are where the depth lives. The policy itself is the two pages.

How the policy actually lands

Writing the policy is half the work. Landing it is the other half.

What works: a 20-minute all-hands session walking through the five sections, with the worked examples open on screen, and time for questions. The questions tell you which bits of the policy are unclear, which gets folded back into the next revision. A copy on the intranet that is searchable, and a brief reminder six months later when the review happens.

What does not work: emailing the PDF and asking the team to confirm they have read it. They have not, and the policy is no more real than it was before.

Where this lands with us

The acceptable-use policy is a deliverable inside our AI Enablement assessment. We write it specific to the stack, with the worked examples drawn from the workflows the team actually runs. The team-briefing session is part of the engagement; it is not a separate workshop.

The policy that gets read is the policy that gets followed, and the policy that gets followed is the policy that protects the business when the next cyber-insurance renewal asks the question.

Working on an AI policy and want a second opinion before it goes to the team? Drop us a note at info@jmopartners.co.uk.

JMO|Partners · Enterprise IT, sized for SMEs.