An AI policy is two sides of A4 answering six questions: what counts as AI here, which tools are approved and how one gets added, what may go into them, who owns the output, when its use is disclosed, and what happens when it goes wrong. It starts with a list of what people already use, and takes an afternoon.
Most of the ones in circulation are longer than that, and most of them are not read. The reason it is worth writing one anyway is in the government's own numbers. The Cyber Security Breaches Survey 2025/2026 (opens in a new tab), published in April 2026 on fieldwork from the previous autumn, found around a third of UK businesses (31%) using, adopting or considering AI, and about a quarter of those (24%) with any cyber security practices in place to manage the risk that comes with it. The tools are in. The rules are not. An AI policy is the document that closes that gap, and it is the cheapest item on the whole AI governance (opens in a new tab) list.
What You'll Need Before You Start
An AI policy needs four inputs, and none of them is a template. They are the tools already in use, your existing incident process, the ICO's guidance on personal data, and one named owner.
| Input | Where it comes from | Why it is on the list |
|---|---|---|
| The real tool inventory | Step 1 below | You cannot write a rule about a tool you do not know exists |
| Your existing incident process | Whoever runs it today | AI incidents route into it, not into a new one (Step 7) |
| ICO guidance on AI and data protection (opens in a new tab) | ICO | The UK GDPR obligations apply whether or not you have a policy; borrow its structure rather than invent one |
| NCSC, AI and cyber security: what you need to know (opens in a new tab) (February 2024) | NCSC | Its questions for boards and senior managers are a serviceable spine for the governance section |
| One named owner | You decide | A policy with no owner has no review date, and a policy with no review date is already out of date |
Two things you do not need. You do not need ISO 42001, the certifiable management system standard for AI ⚠, to write a policy – though if certification is on the table, draft the policy so it can slot into that management system later rather than be rewritten, and our ISO 42001 page (opens in a new tab) covers what that involves. And you do not need to wait for the government's AI Management Essentials tool. DSIT consulted on it as a voluntary self-assessment aimed largely at smaller organisations, and in its response of 6 February 2026 (opens in a new tab) confirmed it will not be publishing the tool and will not be requiring it in government procurement, with refined guidance for SMEs promised instead. If you have been holding off until AIME landed, it is not landing. Write the policy.
Time and difficulty. The writing takes an afternoon. The inventory in Step 1 takes longer, and it is where the value is.
Step 1: Inventory the AI Tools Already in Use
Find out what people are actually using before you write a single rule, because the first draft of an AI policy is not a policy. It is an inventory.
Cover four categories: the sanctioned tools, the ones somebody expensed, the ones bundled into software you already own and switched on by default, and the ones people use on personal accounts because the approved tool is slower or has not been bought yet. That last category is the one that matters. IBM's Cost of a Data Breach Report 2026 (opens in a new tab), covering the year to February 2026, put shadow AI in 43% of security incidents, up from 20% the year before.
Ask. Then ask again in a way that does not sound like an investigation, because the second answer is usually the honest one. A policy written against an imagined estate rather than the real one will read, to the people expected to follow it, as though it were written by someone who has never done their job. Six places to look, in the order they yield something, are in our post on finding shadow AI (opens in a new tab).
Mistake this prevents: writing rules for the tools you bought and none for the tools people use.
Step 2: Define What Counts as AI in Your Organisation
Write the scope in language a non-specialist can apply on a Tuesday morning. Generative assistants, coding assistants, meeting transcription, anything with a chat box, anything embedded in a tool you already licence.
Define it too tightly and you will be relitigating the definition every time a vendor ships a feature. Define it as “any tool that generates, summarises, transcribes or makes recommendations from your data” and the next feature is covered on the day it appears.
Mistake this prevents: a scope that dates the moment your CRM adds a summarise button.
Step 3: Name the Approved Tools and the Route Onto the List
List the tools people may use, then, more importantly, state how a new one gets added, who decides, and how long it takes.
The route matters more than the list. A policy with an approved list and no route onto it is a policy that guarantees shadow AI. People will not stop. They will stop telling you. Set a service level for the decision – ten working days is a reasonable anchor – and name the person who makes it, so a request has somewhere to go.
Mistake this prevents: an approved list that is complete on the day it is published and never again.
Step 4: Set the Rules for What Information May Go In
State, by category, what may never be entered into an AI tool, because this is the clause that does the real work.
Be concrete: customer data, personal data, source code, contract terms, anything under NDA, anything covered by a client's own security schedule. The ICO's guidance on AI and data protection (opens in a new tab) is the anchor for the personal data side, and its chapters, which follow the data protection principles, are a reasonable structure to borrow from. If a category is allowed into one approved tool and not another, say which.
Mistake this prevents: a rule that says “use good judgement” and is therefore not a rule.
Step 5: Make a Named Person Accountable for the Output
Write one sentence: whoever sends it, signs it, ships it or publishes it owns it.
AI-drafted work is the drafter's responsibility in exactly the way a junior's draft is the reviewer's responsibility. Say this explicitly. It is the single sentence most often left out, and it is the one every dispute eventually turns on.
Mistake this prevents: “the tool wrote it” being available as a defence.
Step 6: Decide When AI Use Is Disclosed
Say when AI involvement has to be declared, and to whom, for anything that goes to a client, a regulator or a court.
You may not need a heavy rule. You do need a decided one. A workable default: disclose where the client's own contract or security schedule asks for it, where a regulator's guidance expects it, and wherever the work would be materially different if a person had produced it unaided.
Mistake this prevents: the disclosure question being answered for the first time under questioning.
Step 7: Route AI Incidents Into the Existing Incident Process
Point AI incidents at the incident process you already have, on the same clock, to the same people. Do not build a parallel one.
If someone pastes a client list into a public assistant, that is a data incident. It should reach the people who handle data incidents, within the time your existing process already sets, and be logged where the others are logged. The NCSC's guidance (opens in a new tab) argues for security built in from inception rather than bolted on afterwards; the incident process is where that principle is cheapest to apply.
Mistake this prevents: an AI incident that nobody reports because nobody knows where it goes.
Step 8: Cut It to Two Sides of A4 and Give It a Review Date
Cut the document to two sides of A4 and put a review date on it. Six months is about right at the moment, given how quickly the tools change.
Writing the thing is not the hard part. Writing the thing takes an afternoon and a decent coffee. Getting it down to something anyone will finish reading is the hard part, and the temptation to pad it with definitions, scope statements and a glossary is strong, mostly because that section is the easy one to write. If it runs longer than your expenses policy, it will be read about as often.
Which is the useful comparison, actually. Nobody reads the expenses policy either. But every person in the business knows they need a receipt, knows roughly what the limit is, and knows who to ask. That is what a working policy looks like from the outside: not a document people have read, but a set of rules people can state from memory. Write for that outcome and the length looks after itself.
Tie the review to the approved list, because that is the part that goes stale first.
Mistake this prevents: a twelve-page policy that creates the belief the question has been dealt with.
How to Verify It Worked
The policy is working when three things are true within six months of publishing it, and none of them involves anyone having read it.
| Test | Pass looks like | Fail looks like |
|---|---|---|
| Ask five people what they may not paste into an AI tool | Four of them can name the categories from memory | Blank looks, or “it's on the intranet somewhere” |
| Check the request route from Step 3 | At least one tool has been requested and decided within the service level | Nothing requested in six months. Either the list is perfect or people have stopped asking. It is not the first one |
| Trace one AI incident, real or tabletop, through Step 7 | It reaches the incident owner on the existing clock | It reaches a line manager, an email thread, and nobody else |
The numbers say most organisations have not got here yet. IBM's 2026 report (opens in a new tab) puts 32% of organisations as having policies in place to manage AI and prevent shadow AI, with another 33% still developing them, up from 22% the year before. Of the organisations that were breached, 68% had no AI governance capable of managing AI or detecting shadow AI at all. The gap between the tools arriving and the rules arriving is where the incidents in that report happened.
Troubleshooting: Why an AI Policy Fails in Practice
| Symptom | Cause | Fix |
|---|---|---|
| “Nobody has requested a new tool since we published it” | The route in Step 3 is too slow, or has no named decision-maker | Set a ten-day service level and name the person; announce both |
| “People are still using personal accounts” | The approved tool is slower or worse than the one they were using | Approve the tool they were using, or one at least as good. Supply beats prohibition |
| “The policy is twelve pages and nobody can say what it says” | Padding: definitions, glossary, preamble | Step 8. Two sides. Move everything else to an appendix nobody has to read |
| “A vendor switched on an AI feature and we don't know if it's in scope” | Scope in Step 2 written by product name rather than by function | Redefine scope by what the tool does with your data |
| “An AI incident went to a line manager and stopped there” | No routing into the existing process | Step 7. One line in the policy, one line in the incident runbook |
| “We were waiting for AIME before writing ours” | Outdated advice | DSIT confirmed in February 2026 it will not publish AIME. Write the policy |
AI Policy FAQs
How Long Should an AI Policy Be?
Two sides of A4. If it runs longer than your expenses policy it will be read about as often. Definitions, glossary and background belong in an appendix, if anywhere.
Do We Need an AI Policy If We Do Not Build AI?
Yes. Most AI risk in a typical business comes from staff using bought or free tools, not from building models. IBM's 2026 report (opens in a new tab) found shadow AI in 43% of security incidents. The policy governs use, not development.
Is an AI Policy the Same as an AI Acceptable Use Policy?
Not quite. An acceptable use policy is the staff-facing rules on what may and may not be done. The AI policy above contains those rules and also sets scope, approval, accountability, disclosure and incident routing.
Who Should Own the AI Policy?
One named person with authority to approve tools within a fixed time. In most organisations that is the person who already owns information security or data protection, not a committee.
How Often Should an AI Policy Be Reviewed?
Every six months at present, tied to the approved tool list, because that is the part that goes stale first. Lengthen the interval once two consecutive reviews change nothing.
Why the Shortest AI Policy Is Usually the One That Works
A policy is not governance. It is the part of governance that everyone in the business actually touches, and the cheapest thing on the list.
Most organisations will get there eventually. The ones that get there before an incident forces it will have written a shorter document, in less of a hurry, and will not be explaining the delay to anybody. The wider question of who owns AI decisions and how they get made is AI governance (opens in a new tab), which is a bigger conversation than a document, and the question of what the tools you have already approved are doing with your data is an AI risk assessment (opens in a new tab).
If you would like a second pair of eyes on a draft, or you would rather someone else did the inventory, do get in touch. AI policy development (opens in a new tab) is one of the things we do, and it is rarely the expensive part.
