An AI policy is the internal document that states which AI tools your staff may use, what data they may put into those tools, who reviews the output before it leaves the building, and who is accountable when something goes wrong.
A workable AI policy needs nine sections: scope, approved tools, data classification, prohibited uses, human review, disclosure, accountability, training, and incident reporting with a review cycle. Each one has to name something specific: a tool, a data category, a role, a deadline. Sections that name nothing are the reason most policies change nothing.
If you have been handed this job, the good news is that your organisation is behind, so the bar is low. Of the 1,870 AI-using businesses surveyed for the government's UK Business Data Survey 2026, fieldwork run between October 2025 and January 2026, 83% had no documented AI policy and only 5% had a formal written one. The tools arrived faster than the paperwork: AI use among UK businesses with 10 or more employees reached about 35% by June 2026, up from around 12% in September 2023, according to the ONS Business Insights and Conditions Survey of 38,637 businesses.
What follows is the structure, section by section, with an example of what a usable clause sounds like and the specific way each section fails when it is written vaguely. The failure modes are the part worth your attention. A vague policy passes internal review, gets circulated, and stops nothing.
What makes a section worth including
A section earns its place if somebody could breach it. That is the whole test, and it rules out about half of what ends up in a first draft.
Three questions to run over every clause you write:
Could a reasonable person comply, or fail to comply? "Use AI responsibly" cannot be failed. "Do not enter client data into an unapproved tool" can.
Does it name something? A tool, a data category, a job title, a number of days. Abstractions are unenforceable and unmemorable.
Is there someone to ask? Every rule generates edge cases. If the clause does not point at a person who decides, the edge case becomes precedent by accident.
Anything that fails all three is a values statement. Values statements are fine, but put them in the introduction and do not pretend they are controls.
1. Scope: who and what this covers
Scope states which people the policy binds and which tools and activities fall inside it. It is the shortest section and the one most often written too narrowly.
Sounds like: "This policy applies to all employees, contractors, agency staff and interns. It covers any AI tool used for company work, including tools accessed through personal accounts, free tiers and personal devices."
Fails when: it says "applies to all staff" and stops. Contractors and personal accounts are where the uncontrolled use actually sits, because neither goes through IT procurement. A scope section that omits them exempts the highest-risk population in the building.
2. Approved tools, and the route to add one
This section names the tools people may use and, just as importantly, how to get a new one approved. Both halves are required.
Sounds like: "Approved for general use: Microsoft Copilot, ChatGPT Enterprise, Claude, Google Gemini. To request a new tool, submit the AI tool request form. The AI risk owner responds within 10 working days."
Fails when: it gives a list with no door. If the sanctioned route to a new tool is slower than the workaround, people take the workaround, and you have created the shadow AI problem you were trying to close. The response deadline is not bureaucratic decoration. It is the thing that makes the front door faster than the window.
3. Data classification: what must never go into an AI tool
This section lists the categories of information that may not be entered into any AI tool, ideally mapped onto the data classification scheme you already have.
Sounds like: "Never enter into any AI tool: personal data of customers, candidates or staff; client material covered by an NDA; unreleased financial results; credentials, keys or access tokens; or anything classified Confidential or above."
Fails when: it says "do not input sensitive information". Sensitivity is a judgement call, and you are asking someone to make it at 4pm with a deadline. Name the categories. If personal data is in scope, the ICO's guidance on AI and data protection also expects you to establish who is controller and who is processor, and to complete a data protection impact assessment before deployment rather than after.
4. Prohibited uses
Prohibited uses cover what is off limits regardless of which tool is used or what data goes in. Keep it short enough that people finish reading it.
Sounds like: "AI must not make or materially influence a final decision on hiring, promotion, dismissal, disciplinary outcomes, or credit and pricing offered to an individual, without documented review by the accountable manager."
Fails when: it prohibits "unethical or inappropriate use", which prohibits nothing. It also fails in the other direction. A prohibition list running to two pages gets skimmed, and a skimmed rule is an unenforced rule. Six specific prohibitions beat 30 vague ones.
5. Human review before anything leaves the building
This section defines which AI-assisted outputs need a human check, who is competent to give it, and who carries the consequences if it is wrong.
Sounds like: "Any AI-assisted output sent to a client, a regulator or the public must be reviewed by a named person competent to judge its accuracy. That reviewer is accountable for the content, not the tool and not the author."
Fails when: it says outputs "should be checked for accuracy". Checked by whom, against what, and who answers for it. The sentence that does the work is the one attaching a person's name to the outcome. Without it, review becomes a step everyone assumes somebody else performed.
6. Disclosure: when you say AI was involved
Disclosure sets out where AI involvement must be declared, internally and externally. The trick is picking a small number of situations that matter.
Sounds like: "Disclose AI involvement in: published written content, candidate-facing recruitment communications, and any analysis presented to the board or an external auditor. Routine internal drafting, summarising and formatting does not require disclosure."
Fails when: it requires disclosure on everything. A universal disclosure rule is abandoned within a fortnight, and then no disclosure happens anywhere, including the three places it mattered. Naming the exceptions is what makes the rule survivable.
7. Accountability: who owns the policy and who decides
One named role owns the policy, interprets it when it is ambiguous, and is the person a confused employee contacts. Not a committee.
Sounds like: "This policy is owned by the Director of Operations. Questions of interpretation are decided by that role. Breaches are handled under the existing disciplinary procedure, not a separate AI process."
Fails when: ownership sits with "the AI steering group". Nobody can put a question to a steering group on a Tuesday afternoon and get an answer before they have to send the email. Routing breaches into your existing disciplinary procedure matters too, because inventing a parallel process guarantees the parallel process is never used.
8. Training and AI literacy
This section states who must be trained, by when, and how completion is recorded. Recording it is the part that turns an intention into evidence.
Sounds like: "All staff with access to approved AI tools complete AI literacy training within 30 days of access being granted, refreshed annually. Completion is recorded in the HR system and reported to the policy owner each quarter."
Fails when: it says staff "will be supported to develop their AI skills". If you provide or deploy AI systems that touch the EU, Article 4 of the EU AI Act has applied since 2 February 2025, and national market surveillance authorities began supervising and enforcing the AI literacy duty on 2 August 2026. What an authority can inspect is a completion record, not a sentiment. Deciding what the training should actually contain, and in what order, is a separate exercise from writing the clause, and worth reading up on before you commit to a deadline in the policy: we have covered how to sequence an AI training rollout across a 100-person team in detail.
9. Incident reporting and the review cycle
This section defines what counts as an AI incident, who to tell, how quickly, and when the policy itself gets revisited.
Sounds like: "Report to the policy owner within one working day: any personal or confidential data entered into an unapproved tool; any materially incorrect AI output that reached a customer; any suspected breach of this policy. This policy is reviewed every six months, and additionally whenever a tool is approved or withdrawn, a vendor changes its data handling terms, or a relevant regulation reaches a compliance milestone."
Fails when: it never defines an incident. With no definition, nothing gets reported, and a policy with zero reported incidents in 12 months looks like a policy that is working. It is far more likely to be a policy nobody knows how to invoke.
How to turn this into an actual document
Draft it in an afternoon, then spend the following fortnight trying to break it. The drafting is quick once you accept the structure. The time goes on getting the specifics agreed.
Write the nine sections with your own names in them. Your tools, your roles, your deadlines, your data categories. Two to three hours.
Send it to legal or your data protection officer. Point them at the data classification and prohibited-use sections specifically, rather than asking for a general review, which tends to come back as a general shrug.
Give it to three people who will be governed by it. Ask them to find the sentence they could ignore without anybody noticing. They will find several. Those are the sentences to rewrite.
Date it, name the owner, record acknowledgements. An undated policy with no acknowledgement trail is difficult to rely on in front of a client, an insurer or a regulator.
Roll it out properly. A policy nobody reads has the same effect as no policy, and the same dynamics that stall tool adoption stall policy adoption. Our piece on getting employees to actually use AI applies almost unchanged.
Realistic timeline: a complete first draft in one afternoon, a signed-off version in two to four weeks, most of which is spent waiting for other people.
What this template will not do for you
This is a starting structure, not a legal document, and not legal advice. Sector rules will add to it. Financial services firms, healthcare providers and legal practices all carry supervisory obligations that sit on top of anything here, and those obligations should be checked with someone qualified to advise on them rather than inferred from a blog post.
Two further limits worth stating plainly. A policy is a control document, not an enforcement mechanism: it tells people what the rules are and gives you something to point at afterwards, but on its own it does not change behaviour any more than a fire safety notice puts out fires.
And these nine sections are the document, not the governance around it. Risk classification, framework alignment, incident response design and audit cadence are a larger piece of work that sits underneath the policy. If that is the stage you are at, our guide to developing an AI policy and governance framework covers the layer below this one.
FAQs: writing an AI policy
Is an AI policy a legal requirement in the UK?
No UK statute requires a business to have a standalone AI policy. The government's white paper A pro-innovation approach to AI regulation set out the position that AI is overseen by existing sector regulators applying five cross-cutting principles, rather than by a single AI statute, and that remains the shape of UK regulation. That does not make the policy optional in practice: UK GDPR and the Data Protection Act 2018 apply in full to personal data your staff paste into a chatbot, and a dated policy with acknowledgement records is how you evidence that you took those duties seriously. If your AI use touches people in the EU, the EU AI Act applies directly regardless of where you are based.
Do we need a separate AI policy or can we add it to our IT policy?
Either works, and the choice matters less than the specifics inside it. A section within your existing acceptable use policy is faster to approve and easier to keep consistent with the rest of your IT rules. A standalone document is easier to point at, easier to send to a client or insurer who asks, and easier to review on its own cycle. Organisations with more than a handful of approved tools usually end up with the standalone version.
Who should own the AI policy?
One named individual, senior enough to say no to a department head. In practice this is most often the COO, the director of operations, the head of IT or the data protection officer, depending on where the sharpest risk sits for your business. Avoid handing it to a committee. The owner's real job is answering interpretation questions quickly, and committees are structurally bad at that.
How often should an AI policy be reviewed?
Every six months as a baseline, plus a review triggered by specific events rather than the calendar. Trigger events worth writing in: a new tool approved or withdrawn, a vendor changing its data handling or model training terms, a change to your data classification scheme, or a regulation reaching a new compliance milestone. Annual-only review cycles struggle to keep pace with how quickly the approved tools list changes.
Where to go from here
Write the draft this week. Nine sections, your own names in the brackets, three colleagues trying to poke holes in it. That gets you further than most organisations have managed, and it takes an afternoon rather than a quarter.
If you would rather not start from a blank page, or you need the governance layer underneath it built properly, that is what our AI services team does. Tell us where you have got to and we will tell you what is missing.
