An AI usage policy for a UK organisation: what to put on one page

Why one page beats twelve

A policy has one job: to let a reasonable colleague decide, in the moment, whether they can paste this thing into that box. If the answer takes longer to find than the task would take to do without the tool, they will skip the policy, and often the tool with it. The BCG AI at Work 2025 survey found that where employees lack the tools they need, more than half say they will find alternatives and use them anyway. Unofficial use is the cost of a policy nobody can apply.

The long templates fail for a second reason. They are written for organisations that build AI systems, so they cover model training, algorithmic bias audits and automated decision-making. If your team uses Copilot to draft emails and summarise meetings, most of that is irrelevant, and its presence tells staff the document was not written for them. Cover the developer questions in the procurement file. Keep the staff page about staff.

The one page, section by section

1. 1

   Which tools, which accounts

   Name the assistant the organisation has licensed and the account people must use it through (the work tenant, the Team or Enterprise workspace, the managed Google account). Say plainly that personal accounts on the free consumer versions are not for work content. This single line removes the largest risk on the list.

2. 2

   What may go in

   Describe the everyday material that is fine inside the licensed tool: your own drafts, internal notes, published information, anonymised examples, documents the person is already permitted to read. Be concrete for your work. A property consultancy names the heads of terms; an agency names the client brief.

3. 3

   What never goes in

   List the categories, not a vague warning. Personal data beyond what the task needs. Anything covered by a client confidentiality clause or NDA unless the contract and the tool’s terms both allow it. Unpublished financial results. Passwords, keys and credentials. Special category data under UK GDPR (health, ethnicity, religion, trade union membership and the rest) unless a specific lawful basis and a DPIA say otherwise. Anything under legal privilege without the supervising lawyer’s say-so.

4. 4

   Who checks the output

   The person who would have been accountable for the work without AI stays accountable for it with AI. Outputs are drafts until a named human has read them. Anything leaving the organisation, going to a client, a regulator or a court, is checked for facts, figures, quotations and citations, because these tools produce plausible ones that are wrong.

5. 5

   How we say we used it

   Decide once whether client-facing work discloses AI assistance, and how. Some engagement letters and framework agreements already require it. Where a regulator has spoken, follow them. Where nothing applies, a simple rule: we disclose when a client asks and we never claim work was done in a way it was not.

6. 6

   Where the good prompts live

   Name the shared place (a SharePoint page, a Drive folder, a Notion database) where working prompts and workflows are saved, and who looks after it. A policy that only forbids things teaches nothing; this line is where it starts to help.

7. 7

   Who to ask, and when we review

   One named person for questions, one for data protection, and a review date no more than six months out. The tools change quarterly. So should the page.

The UK GDPR points that actually apply to a deployer

The ICO’s guidance on AI and data protection is written mainly for organisations that design and train systems. For a deployer whose staff use a licensed assistant, the same principles reduce to a handful of practical questions.

• Lawful basis and purpose. If personal data goes into the tool, you need the same lawful basis you would need to process it any other way, for the same purpose. Using a tool does not create a new purpose, and it does not extend an existing one. A CV summarised for a hiring decision you were already making is one thing; the same CV run through a tool to profile the candidate is another.
• Data minimisation. Put in what the task needs and no more. Most drafting and summarising tasks do not need names, dates of birth or addresses at all. Teach people to strip them, and to ask for the output back in a form that does not need them either.
• Accuracy. UK GDPR expects personal data to be accurate. A tool that invents a detail about a real person, and a colleague who files it, is a breach in the making. This is the practical reason the human check is not optional.
• Security and the processor. Read the tool’s data processing terms and know where the data goes. The vendor summaries in the next section are a starting point, not a substitute. Your DPO or IT lead should confirm which tier of licence you hold, because the consumer versions of these products carry different terms from the business ones.
• DPIA when the risk is high. The ICO expects a data protection impact assessment where processing is likely to result in high risk, which for most everyday drafting it is not. It may well be for anything touching recruitment, performance management, vulnerable people or large volumes of client personal data. The ICO publishes an AI and data protection risk toolkit that makes the assessment tractable.
• Transparency and individual rights. People whose data you process still have the right to know how, and to object. If AI assistance is a material part of how you handle personal data, your privacy notice should say so in plain words.

The ICO’s response to its consultation series on generative AI sets out its current thinking on where responsibility sits across the supply chain, and is worth twenty minutes of a DPO’s time. None of the above is legal advice. It is the list of questions to take to the person who can give you some.

What the four vendors say about your data

Each of the four main assistants publishes commitments for its business tiers that differ sharply from the consumer versions. These are the points that matter for the "what may go in" section, quoted from the vendors’ own pages as at September 2026. Terms change, so link to the source in your policy rather than paraphrasing it.

• Microsoft 365 Copilot. Microsoft states that prompts, responses and data accessed through Microsoft Graph are not used to train its foundation models, that Copilot only surfaces content a user already has at least view permission for, that it honours sensitivity labels and Purview encryption, and that for EU customers it is an EU Data Boundary service. Source: Microsoft Learn, Data, privacy, and security for Microsoft 365 Copilot. The permissions point cuts both ways: Copilot will surface anything a person can already open, so oversharing in SharePoint becomes visible fast.
• ChatGPT Business, Enterprise and the API. OpenAI states that data from these products is not used to train or improve its models by default, that the organisation owns its inputs and outputs, and that administrators can set retention periods. Source: OpenAI, Enterprise privacy. The consumer ChatGPT tiers work differently, which is why the account rule on your one page matters.
• Gemini for Google Workspace. Google states that prompts are customer data under the Cloud Data Processing Addendum, are not used to train models outside your domain without permission, are not reviewed by humans, and that Gemini can only see files the user can see. Source: Google Workspace, Generative AI privacy hub.
• Claude for Work and the Anthropic API. Anthropic states that by default it does not use inputs or outputs from its commercial products to train its models, with an exception where a user opts in by submitting feedback, which an organisation owner can switch off. Source: Anthropic privacy centre.

Writing it with the team, not for them

A rule a team wrote for itself gets followed. A rule that arrived by email gets forgotten. When we run a session, the guardrails page is written in the room in the last hour, with the manager present, and it is argued over. That argument is where people learn what the rules mean. You can do the same without us: put a draft in front of the team, ask them to break it, and keep what survives.

Write a one-page AI usage policy for [organisation type and size, e.g. a 40-person marketing agency in Manchester] whose staff use [assistant and tier, e.g. Microsoft 365 Copilot through our work tenant] for drafting, summarising and analysis.

Use exactly these seven headings: Which tools and accounts; What may go in; What never goes in; Who checks the output; How we tell clients; Where good prompts live; Who to ask and when we review. Under each, write two to five short numbered rules a new starter could apply on their second day without asking anyone.

Make the examples specific to our work: [list three or four document types you handle, e.g. client briefs, media plans, invoices, pitch decks]. Where a rule depends on our contracts, our licence tier or a decision I have not given you, write [CHECK] after it. UK English. No jargon. Do not describe this as legal advice; add one line at the end saying it should be reviewed by our data protection lead.

Our constraints so far: [paste confidentiality clauses, IT policy extracts, regulator guidance that applies to you]

Below is a draft one-page AI usage policy for our team. Act as three different colleagues in turn: a new starter on their second day, a senior person who is sceptical of the tools, and someone who already uses a personal ChatGPT account for work without telling anyone.

For each person, list the three situations this week where they would not be able to tell from the page whether something is allowed, and the one rule they would ignore because it is impractical. Then suggest the smallest edit to each rule that would fix it. Do not add new sections.

[Paste the draft policy]