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.
Before the sections there is one audit that has to happen first, because two of them depend on what it turns up. After them there is the one-page version most of your colleagues will ever see.
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.
What can your AI tools already reach?
Your AI tools can reach whatever the person prompting them can already open, which in most organisations is a wider set of files than anybody has checked. Microsoft is explicit about the mechanism: Copilot and agents retrieve data from Microsoft Graph and respect existing permissions, sharing settings, and policies. Copilot hands nobody new access. It makes the access they already had searchable in plain language, which is a different problem and a bigger one.
That decides the drafting order. Sections 2 and 3 below ask you to name your approved tools and your forbidden data categories, and neither can be written truthfully until you know what is connected to what. Four checks, every one of them capable of failing.
The tools you are already paying for. Start from the licence and expense list rather than a staff survey, because a survey misses everything switched on inside software you bought for another reason. That inventory is its own job, and we have covered how to build an approved AI tools list that lasts. A fail here looks like finding an AI feature enabled by default in a product nobody thinks of as an AI tool.
What each connector is scoped to. In the Microsoft 365 admin centre, under Copilot then Connectors, every connection carries one of two permission settings: "Only people with access to this data source", which respects the source system's access control lists, or "Visible to everyone", which grants access to all users in the organisation. Microsoft warns that incorrect access permission settings, such as granting access to Everyone, can lead to oversharing of sensitive content, and states that updating a connector's permissions after you create the connection is not currently supported, so a wrongly scoped connection has to be deleted and rebuilt. The same question applies to ChatGPT Enterprise and Claude: what has been connected, by whom, and visible to whom. A fail looks like nobody being able to say which of the two settings was chosen.
Where sharing is already too broad. SharePoint sets sharing settings to the most permissive option by default, and Microsoft lists broken permission inheritance and complex access models among the signals that mark a site as high risk. Three reports in the SharePoint admin centre answer this in an afternoon: the site permissions baseline report, the "Everyone except external users" report, which shows the top 100 sites where content was shared with the entire organisation in the past 28 days, and the sharing links activity reports. A fail looks like a site holding client material with an "Anyone" link attached to it.
Who can build something that writes. Reading is the smaller risk. An automation built in Power Automate, n8n or Copilot Studio moves data between systems on a schedule with nobody watching it. NCSC guidance published on 20 August 2026 sets the expectation: give every agent its own unique identity, restrict its credentials to only the permissions it needs for the task being performed, run it sandboxed, deny inbound and outbound network traffic by default, and treat agent activity as a form of user activity in monitoring. A fail looks like an automation still running under a departed employee's account.
The fourth check is the one organisations answer worst, and there are numbers on it. 75% of AI decision makers say either that they have no idea, or that fewer than 1% of their workforce knows how to build and deploy an AI automation, according to ivee's research with 500 UK AI decision makers, surveyed in August 2026. The "no idea" half is the one that matters for a policy: you cannot write a rule about automations if you do not know who is capable of building one. An AI decision maker in the same research described the position: "Someone has requested access to an automation tool and I haven't allowed it yet, as I do not know the wider risks to the business."
Budget half a day if you hold Microsoft 365 admin rights yourself, and a fortnight if your first job is working out who does. The output is not a report. It is the real tool list for section 2, the real data categories for section 3, and usually two or three sharing problems worth fixing before a policy turns them into somebody's documented breach.
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.
The one page that goes to everybody else
The nine-section document is for the policy owner, the auditor, and the client who asks to see it. The version that changes what people do is one page, three colours, and no defined terms. Write both, and treat the one-pager as the operative document for everyone who is not the owner.
Nobody memorises nine sections. Most people can hold three rules and one name, which is about what a red, amber and green card fits.
Red, never. Three to five named categories lifted straight from section 3. Customer and staff personal data, client material under NDA, unreleased numbers, credentials and access keys. No judgement calls and no use of the word sensitive.
Amber, ask first. The situations needing a named person's sign-off before the output leaves the building, with the response time you committed to in section 2 printed beside them. That number is the part that stops people routing around you.
Green, go. The approved tools by name, and the everyday work you want people using them for. A card carrying only prohibitions reads as a ban and gets treated as one.
Leave off the definitions, the review cycle, the framework alignment and the scope clause. All four belong in the policy, and none of them change a decision anyone makes on a Tuesday afternoon.
The test is quick and slightly uncomfortable. Hand the card to somebody who has never read the policy, take it back after 30 seconds, and ask them to name the red list. If they cannot, the red list is too long, not the reader too slow.
Put it where the work happens: the intranet page people actually land on, the induction pack, and pinned in whichever chat tool the team lives in. An emailed attachment is read once. State one caveat on the card itself, that it is a summary and the policy governs. If the card and the policy ever disagree, the policy wins, and if they disagree more than once, the card is the document that needs rewriting.
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.
What data can Microsoft Copilot access?
Microsoft 365 Copilot accesses what the signed-in user can already open, and nothing beyond it. Microsoft states that Copilot and agents retrieve data from Microsoft Graph and respect existing permissions, sharing settings, and policies. The consequence is that Copilot exposes oversharing that already existed rather than creating new access: a file a colleague could technically open but was never meant to find becomes findable by asking a question. Run the site permissions baseline and "Everyone except external users" reports in the SharePoint admin centre before rollout rather than after it.
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.
