The rulebook people actually read
Writing an AI governance policy that people follow
Search for an AI policy template and you get university documents written for academic integrity boards. A business needs something different: short, specific about real tools, and enforceable. This guide walks through the ten sections a working policy contains, gives you the template free, and offers the drafted-for-you route if writing it is not the best use of your week.
First principles
What is an AI policy?
An AI policy is the document that tells everyone in your organisation which AI tools they may use, for which tasks, with what data, and who to ask when the answer is not obvious. It turns your company's position on AI from folklore into rules that can be followed, checked and enforced.
Within a full AI governance framework, the policy is the layer most staff will ever touch. The framework holds the inventory, the risk method and the review cadence; the policy is where all of that lands as instructions a person can act on before lunch.
Names for it vary: company AI policy, AI usage policy, AI acceptable use policy. The labels matter less than the test of a good one, which is that a new starter can read it in ten minutes and then answer correctly when a colleague asks "can I put this in ChatGPT?"
The AI policy template, free
All ten sections pre-structured, with drafting notes and example wording to adapt to your organisation. Written for UK businesses, not lecture halls. Nothing to fill in before you can have it.
Section by section
What an AI governance policy should include
Ten sections, in the order they should appear. For each: what the section covers, and the drafting decision that separates a policy that works from one that decorates the intranet.
Purpose and scope
What it covers: Why the policy exists, who it applies to (employees, contractors, anyone with access to company data) and which AI it covers: standalone tools, features embedded in existing software, and anything the company builds.
Getting it right: Two paragraphs at most. If the scope statement cannot be read aloud in thirty seconds, the rest of the policy will not be read at all.
Definitions and the approved tool register
What it covers: Plain-language definitions of the terms the policy relies on, and a living list of approved tools with the account type and data level permitted for each.
Getting it right: Name real products (ChatGPT, Microsoft Copilot, Gemini and whatever else your teams use), not abstract categories. Keep the register as an appendix or linked page so tool changes never require a policy re-issue.
Roles and accountability
What it covers: Who owns the policy, who approves new tools and use cases, who handles exception requests, and where staff go with questions.
Getting it right: Named roles, not committees. Every request in the policy needs a route that answers within a working week, or people will stop asking.
Acceptable use
What it covers: What staff may do with approved tools: drafting, summarising, research, code assistance, whatever your risk appetite supports, and the conditions attached, such as review before anything AI-assisted leaves the building.
Getting it right: Write it permissively. A policy that reads as a list of bans drives usage underground, which is precisely the state you are trying to escape.
Prohibited use
What it covers: The hard lines: entering client confidential or personal data into unapproved tools, presenting unreviewed AI output as finished work, using AI for decisions about people without sign-off, and impersonation or content that misleads.
Getting it right: Short and absolute. Every line here should be defensible in front of the person it stops, which keeps the list meaningful rather than legal wallpaper.
Data rules
What it covers: Which classes of information may go into which tier of tool: public, internal, confidential, personal data. This is the section that prevents the incident everyone worries about.
Getting it right: Tie it to your existing data classification if you have one. If you do not, three tiers written for this policy are enough to start.
Buying and connecting AI
What it covers: How new tools get approved: who assesses them, what a vendor must answer about training data and retention, and the rule that AI features inside existing software need the same look before they are switched on.
Getting it right: Route this through whatever procurement checks you already run rather than inventing a parallel process. New processes get bypassed; amended ones get followed.
Human review and accountability for outputs
What it covers: The principle that a person owns every AI-assisted output: accuracy checked, sources verified where they are claimed, and the author answerable for it exactly as if they had written it unaided.
Getting it right: Spell out where review is mandatory (client deliverables, published content, anything contractual) so the requirement is checkable, not aspirational.
Incidents and exceptions
What it covers: What to do when data goes where it should not, when an AI output causes harm, or when someone needs a tool the register does not allow. Reporting route, response owner, exception process.
Getting it right: State plainly that self-reporting a mistake is treated better than concealing one. Without that sentence, this section collects nothing.
Review, training and enforcement
What it covers: How often the policy is revisited, how staff learn what it says (induction, refreshers), and what happens when it is breached.
Getting it right: Put a named owner and a review date on the document itself. An undated policy signals that nobody is watching, and readers act accordingly.
The follow-through
Making it a policy people follow
Policies fail in predictable ways. They ban everything, so staff use personal accounts on personal phones and the organisation loses even its visibility. They speak in abstractions ("generative systems", "algorithmic outputs") that nobody maps to the tool in front of them. Or they arrive by email, once, and are never mentioned again.
The fixes are equally predictable. Give people a sanctioned route to the tools they already want, so compliance is the convenient option. Use product names and worked examples: "you may paste this, you may not paste that". Put the policy into induction and revisit it when the tool register changes, not on an anniversary nobody remembers.
And keep it to a handful of pages. Length is where good policies go to die: every additional section trades a little completeness for a lot of readership.
If you'd rather we wrote it
The policy pack, drafted for you
The template gets many organisations there. Others want the document written by people who draft these for a living, anchored in how their business actually uses AI. The policy pack starts with a working session on your tools, data and risk appetite, and delivers the full policy, the approved tool register, a one-page staff summary and the rollout communications.
It is included in the AI Readiness Assessment, £8,500 to £16,700 by scope, with every figure on the pricing page ahead of any conversation. No discovery theatre, no quote that depends on how the call went.
Quick answers
AI policy questions, answered
What is an AI policy?
An AI policy (also called a company AI policy or AI usage policy) is the document that tells your people which AI tools they may use, for what tasks, with what data, and who approves exceptions. It is the everyday rulebook layer of your wider AI governance framework, and usually the first governance artefact worth publishing.
What should an AI policy include?
Ten sections cover it: purpose and scope, definitions with an approved tool register, roles and accountability, acceptable use, prohibited use, data rules, procurement of new AI, human review of outputs, incidents and exceptions, and review with training and enforcement. The walkthrough on this page expands each one, and the free template pre-structures them all.
Do we need an AI policy if we only use ChatGPT and Copilot?
That situation is exactly what the policy is for. Two questions decide it: what data are staff putting into ChatGPT, and what internal content can Copilot surface to whom? Both tools are safe under clear rules and risky without them, and a policy covering approved account types, data tiers and output review answers the due diligence question clients are starting to ask.
Is an AI policy the same as an AI acceptable use policy?
Acceptable use is one section of a full AI governance policy, the part that lists what staff may and may not do. Some organisations publish it standalone, which works as a starting point but leaves out procurement, incident handling and review. The template includes both, so you can ship the short version first and grow into the rest.
Policy, written and adopted
Ship a policy your staff will actually use
Start from the free template, or book a scoping call and have the full policy pack drafted around the tools and data your organisation really works with.