How to write an AI policy employees will actually use

Most AI policies fail in one of two ways. Either they do not exist, and staff quietly paste client data into whatever tool they fancy, or they run to twenty pages of legal throat-clearing that nobody reads, remembers, or follows. Both leave a business exposed. The first has no rules; the second has rules in name only.

The useful target sits between them: a policy short and specific enough that an ordinary employee can hold it in their head and apply it on a Tuesday afternoon without asking anyone. That is a higher bar than length. A page people use protects you more than a binder people ignore.

What the real risks actually are

It helps to anchor the policy in the genuine risks rather than imagined ones. The UK's National Cyber Security Centre is blunt about the main one: information you put into a public AI tool through prompts is visible to the company that owns the model, and your queries may well be used to train future versions. Its guidance on AI and cyber security recommends treating access to these tools as something to allow deliberately, with a clear business reason and a usage policy behind it, rather than leaving it to chance. The government's own AI Opportunities Action Plan takes the same deliberate line on adoption across business.

The data-protection side is just as concrete. The Information Commissioner's Office is clear in its guidance on AI and data protection that existing UK GDPR duties (lawful basis, data minimisation, accuracy and accountability) apply in full to AI; the technology does not earn an exemption. For higher-risk uses, a data protection impact assessment may be required. The EU AI Act goes further still, making a baseline of staff AI literacy a legal duty for organisations that deploy AI under its Article 4; even outside its direct scope, that is a fair bar for a UK policy to meet. A good policy turns all of this into something a non-specialist can actually do.

The seven-line AI policy

Here is the structure we use. Each line is one decision, written in plain language, with a real example beside it.

1. Approved tools. Name the specific tools people may use for work, and say that anything else needs a quick ask first. Vagueness here is how shadow use begins.
2. Information that must not be entered. List it concretely: client personal data, anything under NDA, commercially sensitive figures, credentials. "Be sensible" is not a rule. A short do-not-paste list is.
3. Permitted and prohibited uses. Say what AI is welcome for (drafting, summarising, research starting points) and what it is not (final decisions about people, anything presented as fact without checking).
4. Required checking. State that AI output is a draft to be verified, never an answer to be trusted, and name who is responsible for the check on important work.
5. Human approval points. Identify the decisions that always need a person to sign off before anything leaves the building, especially anything with a legal or significant effect on someone.
6. Recording and disclosure. Say when AI use should be noted, and when it should be disclosed to a client or colleague. Quiet honesty here prevents loud problems later.
7. Where to ask for help. Name a person. Most breaches of a policy are not defiance; they are someone unsure who guessed rather than asked.

A policy nobody remembers protects nobody.

What this looks like in practice

Consider a twelve-person marketing agency that had no policy and plenty of quiet AI use. Drafting the seven lines took a single meeting. The approved-tools line ended an awkward situation in which three people were each paying for a different tool on personal accounts, with no shared view of where client work was going. The do-not-paste line named the things that actually mattered, client campaign data and unreleased figures, which had been going into a public chatbot without anyone meaning any harm. The checking line made explicit what good people already half-assumed, that a confident draft is still only a draft. And the approval line put a person between an AI-written client email and the send button.

None of it was heavy, and that was the point. Within a fortnight the team had started referring to "the seven lines" as shorthand, which is the real test. A policy people can quote is a policy people use, and it did more to reduce the genuine risk than the unread document it replaced would ever have done. (An illustrative example, not a specific agency.)

A necessary word on legal advice

This is operational good practice, not legal advice, and it is worth being precise about the difference. Some of what a policy touches is genuinely a statutory requirement, the UK GDPR duties the ICO describes are law, not preference. Other parts are simply sensible habits. Depending on your sector and the personal data you handle, you may need specialist legal or data-protection advice to get the detail right, and the official ICO and NCSC guidance linked here is the right starting point. A template gives you the shape; it does not replace professional advice where the stakes call for it.

The honest limits

Two cautions. First, a policy is necessary but not sufficient. Rules on paper do not change behaviour on their own; people follow a policy they understand and that does not make their job harder than the workaround. If your approved tools are worse than the ones people reach for, no policy will hold, which is why unapproved use is often a signal worth reading rather than a crime to punish.

Second, do not write rules you will not enforce or cannot explain. An over-strict policy that bans everything useful simply moves the activity out of sight. Proportion matters: match the control to the consequence, tight where the data is sensitive, light where a mistake is cheap and reversible.

What to do next

Draft your seven lines this week, using real examples from your own business rather than generic ones. Read each line and ask whether an average employee could follow it without a lawyer or a second opinion. If not, simplify until they can. Then put one name against "where to ask for help" and make sure that person actually exists.

The tool

To make a start painless, we have built the Practical Small-Business AI Policy Template: an editable one-to-three-page policy built on the seven lines above, with example wording you can adapt, scenario boxes for the awkward cases, and a clear statement that it is a practical starting point rather than legal advice.

Download the Practical Small-Business AI Policy Template (PDF)

A workable policy is one part of the simple governance pack that comes out of an AI Reality Check or 90-Day Adoption Build with a team, alongside approved tools and escalation routes. It pairs naturally with knowing how much to hand to AI in the first place and with treating your experiments as the basis of a real strategy.

Sources and further reading

• ICO, Guidance on AI and data protection. UK regulator. Source for UK GDPR duties applying in full to AI, and when a DPIA is required. Official guidance, not legal advice.
• NCSC, AI and cyber security: what you need to know. UK National Cyber Security Centre. Source for the data-in risk and for allowing tool access deliberately.
• EU AI Act, Article 4: AI literacy. Applicable from 2 February 2025. Context for expecting staff to understand the tools they use.
• UK Government, AI Opportunities Action Plan, January 2025. Context for safe, deliberate adoption across business.