How to Write an AI Use Policy for Employees
Writing an AI use policy for employees is now less about permission and more about evidence. Staff are already using these tools. The question a regulator, a client or an insurer will ask is not whether you allowed it, but whether you can show what was allowed, who was told, and what happened to the data. A two-page document that answers those three things beats a thirty-page one that answers none of them.
Start from what the rules actually require
There is no single UK statute mandating an AI policy. What exists is a set of duties that a policy is the cheapest way to discharge.
- EU AI Act, Article 4. If any part of your organisation falls in scope, you must ensure a sufficient level of AI literacy among your staff and among other people dealing with the operation and use of AI systems on your behalf. That obligation has applied since 2 February 2025. It reaches contractors, not just employees, and the Act's enforcement machinery, including national authorities and penalties, applies from 2 August 2026.
- UK GDPR and the Data Protection Act 2018. Feeding personal data into a third-party model is processing. It needs a lawful basis, it needs to be covered by your privacy information, and a novel or high-risk use needs a data protection impact assessment. Article 22 constrains decisions made about people by automated means alone.
- Confidentiality and contract. Most client and supplier NDAs predate generative AI and say nothing about it, which does not make pasting the material into a public chatbot permissible.
- Sector rules. Regulated firms carry their own outsourcing, record-keeping and competence requirements on top.
The Information Commissioner's Office published its own internal AI policy for staff and contractors in August 2025, requiring risk assessments, DPIAs and equality reviews before deployment, an internal inventory of tools, and general AI literacy training alongside system-specific training. It is a reasonable shape to borrow: the regulator writing a policy for itself is a fair signal of what it expects to see elsewhere.
The structure that works
Nine sections. Keep the whole thing under about 1,500 words, because a policy nobody finishes is a policy nobody follows.
| Section | What it must settle |
|---|---|
| 1. Purpose and scope | Who it binds: employees, contractors, agency staff, anyone acting on your behalf |
| 2. Approved tools | A named list, plus the route to get something added |
| 3. Data rules | What may never be entered, in plain categories |
| 4. Human review | Who checks output before it leaves, and against what |
| 5. Disclosure | Which outputs must be labelled as AI-assisted |
| 6. Prohibited uses | Decisions about people, and anything with a legal or similarly significant effect |
| 7. Accountability | The employee owns the output they send, regardless of how it was made |
| 8. Training | What everyone gets, what tool users get, and the record kept |
| 9. Owner and review date | One name, one date, on the front page |
Section 3 is the one that matters
Most policies fail here, because they say "do not enter confidential information" and leave every employee to define confidential. Use categories people recognise, with a traffic light.
- Red, never: personal data of customers, patients or employees; anything under an NDA; unpublished financial results; credentials, keys and tokens; legally privileged material; source code from a private repository unless the tool is on the approved enterprise list.
- Amber, only in approved enterprise tools: internal documents, draft strategy, anonymised or aggregated operational data, internal code.
- Green, anywhere approved: published material, public research, general drafting and rewriting with no company-specific content.
Name the tools against each tier. "Approved enterprise tool" means nothing to a member of staff at 4pm on a deadline; a list of three product names does.
Human review, written as a rule not a hope
"Always check AI output" is not a control. A control names who, when and against what. Something like: any output leaving the organisation is reviewed by a named person competent in the subject; every factual claim, citation, figure and legal reference is verified against a primary source; generated code is reviewed and tested to the same standard as human code; the reviewer signs off in the usual workflow. That version can be audited. The other version cannot.
Disclosure, by output type
Disclosure rules go wrong when they are written per tool. Write them per output. A rough internal first draft rarely needs a label. A client deliverable, a published article, code merged into production, a regulatory submission or anything touching professional standards usually does. Decide the categories once, list them, and staff will stop asking.
Rolling it out so it actually lands
- Find out what is already in use before you write a word. An anonymous survey and a look at browser or expense data will tell you the real picture, and the policy has to cover it.
- Approve a small number of tools quickly. Speed here is a control: if approval takes three months, staff use whatever is to hand.
- Train, and record it. General AI literacy for everyone, tool-specific briefing for users. Keep the register. Under the EU AI Act's literacy duty there is no obligation to test staff, but you should be able to show what training was given.
- Keep an inventory. Which tools, which teams, what data, which risk assessment. This is the artefact procurement and auditors ask for.
- Review every six months and after any material change in a tool's terms.
Three mistakes to avoid
Banning without an alternative. Usage moves to personal devices and phones, where you have no visibility and no logs. That is a worse position than a permissive policy with clear red lines.
Writing the policy around one product. Name a tool and the document expires the next time procurement changes supplier. Write around categories and capabilities, and keep the approved list as a separate appendix you can update without reissuing the policy.
Treating it as an IT document. The real decisions here are about client confidentiality, professional standards and fairness to the people your outputs affect. That makes it a governance document with an IT annexe, not the other way round.
For the wider control framework this sits inside, see our comparison of the leading AI governance frameworks and our guide to building an AI governance framework. For the underlying law, read the EU AI Act explained for UK business. More governance guides at the e-BusinessEthics homepage.
Frequently Asked Questions
Do we legally have to have an AI use policy?
No UK statute names one. But if your organisation falls within the EU AI Act, Article 4 has required a sufficient level of AI literacy among staff and anyone operating AI on your behalf since 2 February 2025, and a written policy plus a training record is the practical way to evidence it. Under UK GDPR, processing personal data through an AI tool still needs a lawful basis and, often, a DPIA.
What should an AI use policy contain?
Scope, a clear list of approved tools, a traffic-light guide to what data may and may not go into them, mandatory human review before anything goes out, disclosure rules, an intake route for new tools, a named owner, and a review date. Anything longer than a few pages will not be read.
Can we just ban AI at work?
You can, but the CIPD found employees using AI daily while a minority of employers had any formal policy, and a ban you cannot enforce simply moves the usage onto personal devices where you can see none of it. A short list of approved tools with clear red lines gives you more control than a prohibition.
Who should own the policy?
One named person, usually in legal, compliance or IT, with authority to approve or refuse a tool. Committees own nothing. The owner needs a route to the board, because the decisions that matter, which tools are approved and what data may touch them, carry risk the board is accountable for.
Should employees have to disclose AI-assisted work?
Set the rule by output, not by tool. Internal drafting rarely needs disclosure. Client deliverables, published content, code that ships, and anything with a regulatory or professional-standards dimension usually does. Write down which category each kind of work falls into rather than leaving people to guess.
How often should the policy be reviewed?
Every six months at minimum, and immediately when a major tool changes its terms or a new one is adopted at scale. Put the review date on the front page. A policy naming a tool that was retired a year ago tells staff the document is decorative.
Sources
- Regulation (EU) 2024/1689 (the AI Act), Article 4 on AI literacy: eur-lex.europa.eu
- Information Commissioner's Office, artificial intelligence and biometrics strategy and plan of action: ico.org.uk
- Data Protection Act 2018: legislation.gov.uk
Positions checked on 20 August 2026. The EU AI Act timetable has moved before; verify any date against the Official Journal before relying on it.