Search for an AI policy template and you will find no shortage of downloads: HR platforms, law-firm client notes, one-page acceptable-use documents. Most give you headings. Almost none tell you what each section is for — and that is the difference between a policy your organisation can actually be held to and a document that exists so somebody can say one exists.
This guide sets out the anatomy of a defensible UK AI policy, section by section: what each part does, the legal weight it carries, and the control that has to sit behind it. If you want a working draft rather than a blank page, our AI policy generator will generate a tailored draft for your board — but read this first, so you know what you are asking it to produce.
Key takeaways
- A defensible AI policy has eight working parts: scope and definitions, a three-band use model, data rules, human oversight, supplier clauses, incident reporting, training and acknowledgement, and a named owner with a review cadence.
- Scope is where most policies fail first: it has to capture the embedded AI already running inside your existing SaaS, not just the tools staff deliberately open.
- The data and oversight sections carry the legal weight — UK GDPR binds you now, and the Data (Use and Access) Act 2025's new Articles 22A to 22D reframe automated decision-making.
- A template without controls and evidence is a disclaimer, not governance: the question a regulator or auditor asks is what the policy changed, not whether it exists.
- Sector context changes the content — charity trustees, housing associations, schools and FCA-regulated firms each face regulator expectations a generic template ignores.
Scope and definitions: name what counts, including the AI nobody bought
The first section answers one question: what does this policy govern? Get it wrong and every later section governs the wrong thing.
A definition tied to product names dates within months; one that survives describes function: any tool or feature that generates content, makes or recommends decisions, or produces predictions from data. That deliberately catches the AI nobody procured: the meeting transcription in your video-conferencing tool, the summarisation your CRM vendor switched on by default, the assistant now embedded in your office suite. A scope clause that misses these leaves most of your actual AI use ungoverned. The unsanctioned tools staff adopt themselves are a related problem, covered in our companion piece on shadow AI and what a board should do about it.
Scope also names who is covered: not just employees but contractors, volunteers and trustees, who often handle the most sensitive material with the least induction.
Permitted, conditional, prohibited: the three-band model
A single list of approved tools fails in both directions: it blocks harmless uses and says nothing about risky use of an approved tool. A three-band model classifies uses, not products.
| Band | What sits here | Example |
|---|---|---|
| Permitted | Low-stakes work where the user verifies the output | Drafting internal documents; summarising published material; code suggestions reviewed before merge |
| Conditional | Uses needing named approval and stated conditions | Anything involving personal data; client- or public-facing output; recruitment screening support |
| Prohibited | Uses the organisation will not accept on any terms | Entering special-category data into external tools; solely automated significant decisions without the safeguards the law requires; presenting AI output as independent professional judgement |
The examples are not decoration: a band without them cannot be applied consistently, and so cannot fairly be enforced. The conditional band is where the policy earns its keep — it gives people a route to say "I want to do this; who approves it, and on what terms?" rather than a binary that drives use underground.
Data rules and human oversight: the clauses with legal weight
Two sections are not preferences but restatements of binding law, and deserve the most careful drafting.
The data rules define what may never be entered into an external AI tool: personal data without a lawful basis and a checked processor agreement, special-category data, anything covered by client confidentiality or an NDA, and unpublished commercially sensitive material. The ICO's guidance on AI and data protection is blunt that there is no AI exemption from UK GDPR: pasting a tenant's complaint history or an employee's grievance into a consumer chatbot is a disclosure to a third party, whatever the tool's marketing says. The policy should also distinguish enterprise deployments — where contractual terms and training-data settings are controlled — from consumer accounts, where they usually are not. The government applies the same logic to itself: the AI Playbook for the UK Government, published in February 2025, instructs departments to control what data AI tools can access and how it may be used — a reasonable benchmark for any board.
The human oversight clause names which decisions require a named person, not just "human review" in the abstract: recruitment sifts, credit and eligibility decisions, disciplinary matters, anything producing legal or similarly significant effects for a person. The legal backdrop moved recently. The Data (Use and Access) Act 2025 reshaped UK GDPR's rules on automated decision-making — its section 80 came into force on 5 February 2026, replacing the old Article 22 with new Articles 22A to 22D, which relax the near-prohibition on solely automated decisions while preserving the right to human review where decisions are significant. The ICO's updated guidance on automated decision-making is still in draft, with final guidance expected in summer 2026, so write this clause to the principle rather than the provisional wording. The wider regulatory picture is in our guide to what UK boards govern without a single AI Act.
The operational clauses: suppliers, incidents, training, review
Four shorter sections turn the policy from a statement into a system.
Supplier and procurement clauses. Most new AI now arrives through vendors, not decisions. The policy should require, for any supplier whose product processes your data: disclosure of AI features and advance notice when new ones are added, confirmation that your data is not used to train the supplier's models, and clarity on where processing happens. Procurement applies these as standard due-diligence questions, so AI cannot enter the organisation around the side of the policy.
Incident reporting. Define what counts as an AI incident — personal data entered into an external tool in error, a fabricated output sent to a client before anyone checked it, a pattern of biased outcomes in a screening tool — and give it a no-blame reporting route connected to your existing data-breach process where personal data is involved. An incident clause nobody dares use is worse than none: it manufactures the appearance of monitoring.
Training and acknowledgement. Role-based and recorded: a trustee approving an AI-assisted process needs different training from an officer using a drafting tool. The acknowledgement — a dated, named record that each person has read and accepted the policy — is what makes it enforceable in an employment context, and what an auditor will ask to see.
Review cadence and ownership. A named owner with the authority to change the policy, a stated review interval, and defined triggers — new regulation, a serious incident, a material new tool. ISO/IEC 42001, the international AI management system standard, makes an AI policy a top-management obligation and expects it to be current and actually shaping decisions; we unpack what that standard asks of a board separately. A policy last touched two years ago is evidence against you, not for you.
Why a template alone fails
Here is the uncomfortable part: you can download a template, adapt it in an afternoon, have it adopted at the next board meeting — and change nothing. A policy without controls and evidence is a disclaimer: it protects the organisation's ability to say it had rules, not the people the rules were meant to protect.
The test for each clause is whether something operational sits behind it. A data rule needs an approved enterprise tool with training switched off, or technical blocking — not a sentence and hope. An oversight clause needs a named approver and a log of what they approved. A training clause needs a register of dated acknowledgements. An incident clause needs at least one reported incident a year; in any organisation actually using AI, zero reports means the route is not trusted, not that nothing happened. The policy is one layer of a working governance structure — risk register, controls, review rhythm — mapped in our companion guide to building a UK AI governance framework.
Tailor it to your sector, then roll it out without theatre
Charities. The Charity Commission has said it does not plan AI-specific guidance, expecting trustees to apply their existing duties to new technology — so your policy is the evidence those duties were applied. Decision-making cannot be delegated to a tool, and volunteers, often the heaviest informal AI users, must be explicitly in scope. More on our AI governance for charities page.
Housing associations. Tenant data is among the most sensitive an organisation holds — arrears, vulnerability flags, complaint histories — and the post-2023 regulatory regime under the Social Housing (Regulation) Act expects landlords to know and govern their data. Any AI triage of repairs or complaints belongs in the conditional band with named oversight. See our page on AI governance for housing associations.
Schools and trusts. The Department for Education's guidance on generative AI in education is clear that staff must apply professional judgement to AI output and that responsibility stays with the member of staff and the school. A school policy adds safeguarding and pupil-data rules a corporate template does not contain — more on our education sector page.
Regulated financial firms. The FCA has declined to write new AI-specific rules, applying its existing framework instead — the Consumer Duty and the Senior Managers and Certification Regime. There is no dedicated senior manager function for AI: accountability lands on existing SMF holders, so your policy's named-oversight clause must map to real SMF responsibilities. See AI governance for financial services.
On rollout: resist the theatre. A 40-page PDF announced by all-staff email and never mentioned again is the most common failure mode. Keep the policy short enough to read, launch it with real examples from your own organisation, open with an amnesty — a window where staff can declare the tools they already use without consequence, converting shadow AI into your scope inventory — then measure what shows it is alive: requests through the conditional band, incidents reported, the register growing.
The test is simple. One quarter after adoption, could you show a decision the policy changed — a tool declined, a use moved into the conditional band, an incident reported and acted on? If yes, you have governance. If all you can show is the document, you have a disclaimer with a logo on it.
Last reviewed: 12 June 2026.
If you want a starting point that reflects your sector and your actual AI use rather than a generic download, generate a tailored draft with our AI policy generator — it gives your board something concrete to argue with. And if the harder question is whether the policy you sign matches what your organisation actually does, our AI governance diagnostic (from £3,950) assesses your current AI use against exactly the sections above.
