AI acceptable use policy template for staff and builders.
A policy for how people use AI tools at work and how teams build AI systems, written to be read. Copy it, fill the brackets, and publish it with a register of approved tools.
What is an AI acceptable use policy?
An AI acceptable use policy is the internal rule set for using AI at work: which tools are approved, what data may go into them, who checks the output, what is prohibited, and how incidents are reported. It protects confidential and personal data and gives staff a legitimate route to use AI rather than a reason to hide it.
Most organisations already have AI in use whether or not they approved it: chat assistants, coding assistants, meeting transcribers and AI features that arrived in existing software. The policy's first job is to make that use visible and bring it under contracts you control.
How to use this template
- Build the register first. List the AI tools already in use and the data classes each is approved for. A policy that says “approved tools only” without a list is unenforceable.
- Match section 5 to your classification scheme. Use the labels your organisation already uses; do not invent new ones for AI.
- Name real contacts. Every bracketed role should be a person or a team inbox that answers.
- Delete section 9 if you build nothing. Keep it if any team fine-tunes models, runs retrieval over company data or ships AI features.
- Pair it with training. Section 11 is how you evidence the policy reached people.
The template
AI ACCEPTABLE USE POLICY
Owner: [role, e.g. CISO or Head of AI Governance]
Approved by: [name, date] Version: [1.0] Next review: [date]
1. PURPOSE
This policy sets out how people at [Organisation] may use artificial intelligence
(AI) tools and systems at work, so that we get the benefit of them without
leaking confidential or personal data, breaking the law, or relying on output
nobody checked.
2. SCOPE
It applies to all employees, contractors and interns, and to any AI system used
for [Organisation]'s work, whether it is:
(a) a third-party tool (for example a chat assistant, coding assistant, meeting
transcriber, or AI feature inside software we already use); or
(b) a system we build, fine-tune or deploy for customers or internal use.
3. DEFINITIONS
"AI tool" means any software that generates text, code, images, audio, video or
decisions from a model trained on data.
"Approved AI tool" means a tool listed in the AI Register (Appendix A) with the
data classes it is approved for.
"Confidential data" and "personal data" have the meanings in our Information
Classification Policy.
4. APPROVED TOOLS
4.1 Use only approved AI tools for work, through accounts provided by
[Organisation]. Do not use personal accounts for work data.
4.2 To request a new tool, submit it to [team/email]. It will be assessed for
data use (including whether inputs are used to train the vendor's models),
security, contract terms and data location before approval.
4.3 AI features switched on inside existing software count as new tools and need
approval before use with confidential or personal data.
5. DATA YOU MAY AND MAY NOT PUT INTO AI TOOLS
5.1 Public information: any approved tool.
5.2 Internal information: approved tools marked "internal" or above.
5.3 Confidential information, source code and customer data: only tools marked
"confidential", under an enterprise agreement that excludes training on our
inputs.
5.4 Never enter into any AI tool, unless the tool is specifically approved for
it in writing:
- passwords, API keys, tokens or private keys;
- personal data of customers, employees or others, including children's data;
- special category or sensitive data (health, financial, biometric data);
- information under a confidentiality obligation to a third party.
6. USING OUTPUT
6.1 You are responsible for anything you use, send or ship that an AI tool
helped produce. Check it for accuracy, bias, security flaws and licensing
before relying on it.
6.2 AI-generated code goes through the same review, testing and security
scanning as any other code.
6.3 Do not present AI output as a verified fact, legal advice or a professional
opinion without a qualified person checking it.
6.4 Do not use AI output to make a decision with legal or similarly significant
effect on a person (hiring, firing, credit, access to services) without
meaningful human review and the approval of [role].
7. TRANSPARENCY
7.1 When a customer or member of the public interacts with an AI system we
operate, tell them it is AI unless it is obvious from the context.
7.2 Label AI-generated or manipulated images, audio or video that resemble real
people, places or events, and follow the marking requirements set by
[Product/Legal] for synthetic content we publish.
8. PROHIBITED USES
Do not use AI tools, at work or with work data, to:
(a) deceive or manipulate people in ways that impair their ability to make an
informed decision, or exploit vulnerabilities due to age, disability or
circumstances;
(b) infer emotions of colleagues or candidates at work, or categorise people by
biometric data to deduce sensitive characteristics;
(c) create sexual or intimate imagery of any identifiable person, or any content
sexualising children;
(d) scrape facial images from the internet or CCTV to build recognition
databases;
(e) create deepfakes of real people without their consent and clear labelling;
(f) harass, discriminate, or produce unlawful content; or
(g) bypass security controls, licensing terms or rate limits.
9. BUILDING AND DEPLOYING AI SYSTEMS
9.1 Register every AI system we build or deploy in the AI Register before it
handles real data: owner, purpose, model and version, data sources,
affected people, and risk tier.
9.2 Assess risk before launch, including whether the system falls into a
regulated category (for example high-risk uses under the EU AI Act, such as
recruitment or credit scoring).
9.3 Evaluate the system before release and after material changes, against
criteria set in advance (accuracy, harmful output, bias, prompt injection),
and keep the results.
9.4 Personal data used for training, fine-tuning or retrieval needs a lawful
basis and must match the purposes in the relevant privacy notice.
10. INCIDENTS
Report to [security contact] immediately if you entered prohibited data into an
AI tool, received output containing someone else's personal or confidential
data, or saw an AI system behave in a harmful or unexpected way. Early reports
are treated as responsible, not disciplinary.
11. TRAINING
Everyone in scope completes AI awareness training on joining and [annually].
People who build or operate AI systems complete role-specific training.
12. COMPLIANCE
Breaches of this policy are handled under the [Disciplinary Policy]. Use of AI
tools may be monitored under the [Acceptable Use / Monitoring Policy].
APPENDIX A - AI REGISTER (EXTRACT)
Tool / system | Owner | Approved data classes | Contract excludes training (Y/N) | Review date
[ ] | [ ] | [ ] | [ ] | [ ]
Why each section is there
| Section | What it is for | Where it comes from |
|---|---|---|
| 4. Approved tools | Moves use from personal accounts to contracts that exclude training on your data. | Supplier controls in ISO/IEC 27001 Annex A 5.19–5.23 and ISO/IEC 42001. |
| 5. Data rules | The single biggest risk is pasting secrets or personal data into a tool that keeps it. | DPDP Act s.8(5) and GDPR Art. 32 security duties; your processor contracts. |
| 6. Using output | Makes a person accountable for AI-assisted work, and requires human review for decisions about people. | GDPR Art. 22 on solely automated decisions; ordinary professional duty. |
| 7. Transparency | Tells people when they are dealing with AI and labels synthetic media. | EU AI Act Art. 50, applying since 2 August 2026. |
| 8. Prohibited uses | Rules out the practices the law bans outright, plus plain misuse. | EU AI Act Art. 5, including the two prohibitions added by the Digital Omnibus from 2 December 2026. |
| 9. Building AI | Registers, assesses and evaluates systems you ship, so there is evidence of what they do. | ISO/IEC 42001; NIST AI RMF; EU AI Act high-risk duties for Annex III uses from 2 December 2027. |
| 10–11. Incidents and training | Early reporting and staff awareness. | EU AI Act Art. 4 on AI literacy; incident management in ISO/IEC 27001 Annex A 5.24–5.28. |
A summary for orientation, not legal advice. Check the AI Act text on EUR-Lex as amended by Regulation (EU) 2026/1744.
What does the EU AI Act prohibit in the workplace?
The EU AI Act's Article 5 bans, among other practices, inferring the emotions of people at work or in education (except for medical or safety reasons), biometric categorisation to deduce sensitive characteristics, untargeted scraping of facial images, and manipulative or exploitative techniques that cause significant harm. These have applied since 2 February 2025.
Section 8 of the template turns those into rules staff can follow, and adds the non-consensual intimate imagery and child sexual abuse material prohibitions that the Digital Omnibus adds from 2 December 2026. The EU AI Act guide has the full timetable, and the EU AI Act penalties guide explains why Article 5 carries the highest fines in the Act.
For the systems you build, a policy is where governance starts, not where it ends. AI governance in TryTrustable registers models, prompts and MCP servers, runs judge-scored evaluations, and evidences the results against ISO 42001, the NIST AI RMF and the EU AI Act.
More free templates: the full template library, including a 5×5 risk register, a record of processing activities, a vendor security questionnaire and a DPDP consent notice.
The things people ask us
What should an AI acceptable use policy include?
An AI acceptable use policy should list approved tools, say which classes of data may go into which tools, make people responsible for checking output, require transparency where the public interacts with AI, prohibit specific harmful uses, set rules for systems you build, and tell people how to report incidents. Keep it short enough that people read it.
Should we ban ChatGPT and other AI tools instead?
Bans tend to move use onto personal accounts, where you have no contract, no logs and no control over whether inputs train the vendor's model. Approving specific tools under enterprise terms, with clear rules on data classes, usually reduces risk more than prohibition. The template's approval route is there so staff have a legitimate way to ask.
Does the EU AI Act require an AI acceptable use policy?
Not by that name. It sets duties that a policy helps you meet: the Article 5 prohibited practices, the Article 50 transparency duties that apply from 2 August 2026, and Article 4 on supporting staff AI literacy. A written policy with training is the ordinary way to show those duties were taken seriously.
Can employees put customer personal data into an AI tool?
Only if the tool is approved for it, under a contract that makes the vendor your processor and excludes training on your inputs. Entering personal data into a tool is processing and, for many vendors, a transfer abroad. Under the DPDP Act and the GDPR it needs a purpose your notice covers and a processor contract behind it.
How does this policy relate to ISO 42001?
ISO/IEC 42001 asks for an AI policy and for controls over how AI systems are used and developed. An acceptable use policy covers the use side for staff. For certification you also need the management system around it: AI risk and impact assessments, objectives, an inventory, and evidence that controls run, which is what the ISO 42001 guide covers.
Who should own the AI acceptable use policy?
Usually security or a named AI governance lead, with legal and HR as reviewers, because it touches data protection, IP and discipline. What matters most is that one person owns the approved-tools register and answers new tool requests quickly; a slow approval route is the main reason policies are ignored.
Know which AI you actually run.
We register a model and a prompt with you live, run an evaluation, and show the evidence landing against ISO 42001 and the EU AI Act.