AI acceptable use policy documents have become the dividing line between organisations that get real value from generative tools and organisations quietly accumulating incidents they cannot see. Your staff are already using these tools. The only open question is whether they are doing it inside rules you wrote, or inside rules they invented for themselves.
This guide gives you the whole thing: a clause-by-clause template you can copy, the tool tiers and data rules that make it enforceable, a rollout plan that gets it signed, and the review cadence that stops it going stale within a quarter. Everything below is written to be lifted straight into your own document and adapted, not admired.
Most businesses reach for a policy after something has already gone slightly wrong — a client name pasted into a public chatbot, a proposal that turned out to be machine-drafted, a contract clause nobody could explain. That reactive version tends to be a list of prohibitions that ages badly. A good IT governance approach treats the document as an operating manual: it says which tools are approved, what may go into them, who stays accountable for the output, and what happens when someone gets it wrong.
Table of contents
- Why every business needs an AI acceptable use policy now
- What an AI acceptable use policy must contain
- The AI acceptable use policy template you can copy
- Approved, restricted and prohibited AI tools
- Data rules: what employees may never paste into AI
- Disclosure, review and human accountability rules
- How to roll out an AI acceptable use policy to employees
- AI acceptable use policy mistakes that undermine enforcement
- Measuring whether your AI acceptable use policy works
- Frequently asked questions about AI acceptable use policy design
- References
Why every business needs an AI acceptable use policy now
The case for writing one is no longer about anticipating future regulation. It is about the gap between what your staff are doing today and what your contracts, your insurers and your clients already assume you control.
Shadow AI is the default state, not the exception
In almost every organisation that has not published an AI acceptable use policy, staff have adopted consumer AI tools on personal accounts, on personal devices, with no logging and no data agreement. Nobody hid it maliciously. They had a deadline and a tool that helped.
The problem is not the usage. It is that the organisation carries the liability for data it cannot prove was handled properly, and has no record of which decisions were machine-assisted.
Your existing policies do not cover this
Acceptable use policies written for email and web browsing do not answer the questions that matter here. They say nothing about whether a client’s personal data may be pasted into a model, whether AI-generated code may enter your product, or who is accountable when a model invents a fact that reaches a customer.
An AI acceptable use policy exists precisely to close those gaps, which is why bolting two paragraphs onto an old document rarely survives contact with a real incident.
Clients and insurers are starting to ask
Procurement questionnaires now routinely ask whether you have an AI acceptable use policy, whether staff are trained on it, and whether AI involvement is disclosed in deliverables. Professional indemnity insurers are asking similar questions at renewal.
Having a documented, dated, acknowledged policy converts a difficult conversation into an attachment. Not having one increasingly costs deals, well before it costs a fine.
Regulation is arriving, and it assumes governance exists
The EU AI Act, the UK’s principles-based approach and the ICO’s guidance on AI all assume an organisation can describe how it governs AI use. None of them will accept “our staff use their judgement” as an answer.
What an AI acceptable use policy must contain
Length is not the measure of a good document. A two-page policy that answers the real questions beats a twenty-page one that restates the law. These are the clauses that carry the weight.
The nine clauses that do the work
Every effective AI acceptable use policy answers nine questions: why it exists, who it applies to, which tools are permitted, what data may be entered, what output may be relied on, what must be disclosed, who stays accountable, how breaches are handled, and when the document is reviewed.
Anything beyond those nine is elaboration. Anything missing from them is a gap a staff member will eventually fall through.
Policy, standard and guideline are three different documents
Keep them separate. The policy states the rules and the consequences, changes rarely, and needs formal approval. The standard lists approved tools and configurations, and changes monthly. The guideline offers good practice on prompting and review, and is advisory.
Collapsing all three into one file is the most common reason an AI acceptable use policy becomes obsolete within a quarter — the tool list ages, and the whole document loses authority with it.
| Document | States | Changes | Approved by |
|---|---|---|---|
| AI acceptable use policy | Rules, scope, consequences | Annually | Board or senior leadership |
| AI tool standard | Approved tools and settings | Monthly | IT and security lead |
| AI usage guideline | Good practice, worked examples | Continuously | Team leads |
| Client AI addendum | What you commit to externally | Per contract | Legal and commercial |
Write for the person breaking the rule by accident
The audience for an AI acceptable use policy is not your auditor. It is a competent, busy employee who wants to do the right thing and has thirty seconds to check. Every clause should be readable at that speed.
That means concrete nouns, named tools, worked examples, and no sentence that requires a legal background to parse.
The AI acceptable use policy template you can copy
What follows is the skeleton, clause by clause, with model wording you can adapt. Replace the bracketed placeholders and delete anything that does not apply to you.
Section 1 — Purpose and scope
The scope sentence is the one clause people cut and then regret. Personal devices and embedded AI features are exactly where unmanaged usage lives, so name them explicitly.
Section 2 — Approved tools
Pointing at a separate standard rather than naming products keeps your AI acceptable use policy stable while the tool list churns underneath it.
Section 3 — Permitted and prohibited data
The “if unsure, the answer is no” default is worth more than a longer list. It gives an employee a safe action in the exact moment the policy is being tested.
Section 4 — Human accountability for output
This clause is the heart of the document. It removes the defence of “the model said so” and puts a named human between the tool and the consequence.
Section 5 — Disclosure
Section 6 — Breach handling and review
Approved, restricted and prohibited AI tools
A three-tier model is the smallest structure that works. Two tiers force you to ban things you actually want people using; four tiers nobody remembers.
How to place a tool in a tier
Tiering is a data-handling decision, not a quality judgement. The questions are whether the vendor trains on your inputs by default, whether your organisation holds a contract with them, whether access is tied to managed identities, and whether usage is logged.
A capable tool used through a personal account belongs in a lower tier than a mediocre one used through your tenant. Your AI acceptable use policy should say that plainly, because staff will otherwise assume the better model is the safer choice.
| Tier | Access | Data permitted | Approval to use |
|---|---|---|---|
| Approved | Organisation account, logged | Internal and client data per data table | None needed |
| Restricted | Named users only | Public and internal only | Written, time-limited |
| Prohibited | Not permitted for work | None | Assessment required first |
| Embedded features | Inherits host application tier | As host application | Tier the host, not the button |
Embedded AI is the tier everyone forgets
AI features now ship inside tools you already approved years ago — the meeting recorder, the CRM, the design suite. An AI acceptable use policy that only lists standalone chatbots leaves all of that ungoverned.
The workable rule is that an embedded feature inherits the tier of its host application, and any feature that sends content to a new third party is treated as a new tool. If you are preparing a specific rollout, the same discipline appears in a Copilot readiness assessment.
Give people a fast route to approval
The single biggest predictor of whether an AI acceptable use policy is followed is how long approval takes. If assessment takes six weeks, staff will use the tool anyway and stop telling you.
Publish a short request form, commit to a response time, and say yes often enough that the process stays credible.
Data rules: what employees may never paste into AI
This is the section staff will actually read, so make it a table rather than prose. Name your data classes using the labels your organisation already uses.
| Information type | Public AI tool | Approved enterprise tool | Notes |
|---|---|---|---|
| Published marketing content | Allowed | Allowed | Already public |
| Internal notes, drafts, agendas | Not allowed | Allowed | Remove names first |
| Personal data of staff or clients | Never | Only with a lawful basis | Record the decision |
| Client confidential material | Never | Check the client contract | Some contracts forbid it outright |
| Source code and configuration | Never | Approved coding assistants only | Check licence terms of output |
| Credentials, keys, security detail | Never | Never | Treat entry as an incident |
| Unreleased financial information | Never | Named approvers only | Market-sensitive handling applies |
Anonymising is harder than it sounds
Staff will assume that removing a name makes data safe. It often does not: a project description, a postcode and a job title can identify someone as reliably as a name.
Say so in the AI acceptable use policy, and give one worked example of a prompt that looks anonymous but is not. One example teaches more than a paragraph of principle.
Retention and training defaults matter more than the model
Whether a vendor retains prompts, for how long, and whether it trains on them is the difference between an approved tool and a prohibited one. These settings change, and consumer tiers behave differently from business tiers of the same product.
That is why the tool list lives in a standard your team can update quickly, while the AI acceptable use policy states the principle. Broader security controls and identity management sit underneath both.
Treat accidental entry as a reportable incident
If someone pastes a client list into a public chatbot, you need to know within the hour, not at the next audit. Make self-reporting explicitly safe in the policy text and route it through your existing incident process.
Disclosure, review and human accountability rules
The output side of an AI acceptable use policy is where most drafts go thin. Prohibiting inputs is easy; governing what comes back out is the part that protects your clients.
Set a proportionate review standard
Not all output needs the same scrutiny. A useful three-level rule: internal drafts need a sanity check, client deliverables need a substantive review by a competent person, and anything with legal, financial, safety or employment consequences needs named sign-off.
Write those three levels into the policy with examples from your own work. Generic wording produces generic compliance.
Be specific about what disclosure means
Most disputes about AI disclosure come from ambiguity, not disagreement. Define “material AI involvement” with examples: a machine-drafted report section is material, a rewritten sentence is not.
Check your client contracts before you set the threshold, because some now specify it for you and your AI acceptable use policy has to be consistent with what you have already signed.
Name owners, not committees
Every clause should have an owner who can make a decision without convening anyone. A named role for tool approval, a named role for data questions, and a named role for policy ownership will do more for compliance than any amount of training.
| Role | Owns | Decides | Response time |
|---|---|---|---|
| Policy owner | The document and its review | Scope and clause changes | Annual cycle |
| Tool approver | The approved tool standard | Tier placement, exceptions | 5 working days |
| Data protection lead | Lawful basis and assessments | Personal data questions | 2 working days |
| Line manager | Team-level adherence | Review depth for deliverables | Same day |
How to roll out an AI acceptable use policy to employees
Publishing the document is roughly a fifth of the work. The rollout is what determines whether it changes behaviour or sits unread on the intranet.
Consult before you publish
Ask a cross-section of staff how they currently use AI, with an explicit amnesty for what they say. You will discover tools you did not know about and use cases worth approving, and you will write a far better AI acceptable use policy for having asked.
It also converts the launch from an imposition into something people recognise as built around their actual work.
Train on decisions, not on clauses
Reading the policy aloud does not work. Run a thirty-minute session built around six real scenarios drawn from your own business: the client email, the CV screen, the code snippet, the meeting recording, the pricing spreadsheet, the tender response.
Ask people to decide, then show the answer. Staff remember decisions they got wrong far better than clauses they scrolled past.
Get explicit acknowledgement and record it
Acknowledgement matters twice: it makes enforcement fair under the Acas Code of Practice on disciplinary procedures, and it is the evidence a client or insurer will ask for.
Record who acknowledged the AI acceptable use policy and when, include it in onboarding, and re-acknowledge after any material change.
Make the approved path easier than the unapproved one
If the sanctioned tool is slower to reach, worse configured or licensed to only half the team, staff will route around it. Provision licences before launch, put the approved tool one click from where people work, and remove friction from the request process.
Enforcement fails wherever the compliant option is the inconvenient option. That single principle explains most policy failures, and no amount of training substitutes for it.
AI acceptable use policy mistakes that undermine enforcement
These are the failure patterns that turn a reasonable document into one nobody follows.
Banning everything
A blanket prohibition produces the worst outcome available: staff use the tools anyway, on personal accounts, and stop reporting anything. You lose visibility and gain no protection.
Permit a clearly defined safe path. An AI acceptable use policy that says yes to something is enforceable in a way that a pure ban never is.
Naming products in the policy body
The moment you name a specific product in the policy itself, you have committed to a document that ages every time a vendor renames a tier. Keep names in the standard and principles in the policy.
Writing it in legal language
If the document reads like a contract, it will be treated like one — signed and never opened. Plain sentences, present tense, second person. Two pages beats twenty.
Skipping the accountability clause
Plenty of drafts cover data and never say who is responsible for the output. That omission is the one that costs you when a machine-drafted error reaches a client, and it is why the accountability clause belongs near the front. The same principle underpins ethical AI implementation more broadly.
Never reviewing it
A policy written eighteen months ago governs a tool landscape that no longer exists. Set a twelve-month maximum review interval in the text itself so the review is a commitment rather than an intention.
Measuring whether your AI acceptable use policy works
You cannot manage adoption you do not measure, and the useful measures are simpler than they sound.
Four numbers worth tracking
Track acknowledgement rate, tool assessment turnaround, self-reported incidents, and the share of AI use happening on managed accounts. Together they tell you whether the AI acceptable use policy is understood, whether the process is fast enough to trust, whether people feel safe reporting, and whether shadow usage is shrinking.
A rising self-report count in the first quarter is a good sign, not a bad one. It means people believe you when you say reporting is safe.
Review the policy against real incidents
Every reported incident is free research. At each review, read the year’s reports and ask which clause failed to prevent it: was the rule wrong, unclear, or simply unknown to the person involved?
That question improves an AI acceptable use policy faster than benchmarking against someone else’s template, because it fixes the gaps your own organisation actually falls through.
Connect it to the rest of your governance
The policy should reference your data protection, information security and procurement processes rather than duplicating them. Where AI use touches supplier assessment, the questions belong in your existing due diligence, and where it touches personal data, in your existing assessment process.
A well-connected AI acceptable use policy is short precisely because it points outward. Aligning it with a documented AI strategy keeps governance and ambition moving at the same speed.
Frequently asked questions about AI acceptable use policy design
How long should an AI acceptable use policy be?
Two to four pages for the policy itself, with the tool list and worked examples in separate documents. Anything longer stops being read, and an unread AI acceptable use policy provides no protection at all.
Do small businesses need one?
Yes, and it is easier for them. A ten-person business can write a genuinely useful AI acceptable use policy in an afternoon, because the tool list is short and the approver is in the room.
Should we ban ChatGPT and similar consumer tools?
Ban the unmanaged route, not the capability. Prohibit personal accounts for work data, provide a business-tier equivalent, and your AI acceptable use policy stops fighting the thing people find useful.
Who should own the policy?
Whoever owns information governance already. In smaller organisations that is often the operations or finance director; the important thing is that it is one named person with authority, not a committee.
Does an AI acceptable use policy satisfy the EU AI Act?
No. It is a component of the governance the Act expects, not conformity with it. Obligations under the Act depend on your role and the risk class of the systems you deploy, and are assessed against the Act itself.
How often should it be reviewed?
Every twelve months at most, and immediately after a material change: a new tool class, a new client obligation, a regulatory development, or any reported incident that the current AI acceptable use policy did not prevent.
What happens if someone breaches it?
Handle it proportionately through your normal disciplinary framework. Accidental entry that is promptly self-reported should be treated as an incident to learn from; deliberate or repeated breaches are a conduct matter.
Can we just use a downloaded template?
Use one as a skeleton and then do the two things that matter: build your own tool tiers and write your own data table. Those two sections are what make an AI acceptable use policy yours rather than decorative.
References
ICO — Guidance on AI and Data Protection
ICO — Employment Practices and Data Protection
Acas — Disciplinary Procedure Step by Step
NCSC — Guidelines for Secure AI System Development
NCSC — Cyber Security Board Toolkit
EUR-Lex — Regulation (EU) 2024/1689 on Artificial Intelligence
European Commission — Regulatory Framework for AI
UK Government — A Pro-Innovation Approach to AI Regulation
NIST — AI Risk Management Framework
