AI Acceptable Use Policy: What to Include, With a One-Page Template
A usable AI acceptable use policy fits on one page: approved tools, data rules, human review and a route to ask. Here is what to include and a template to copy.
An AI acceptable use policy is a short document that tells staff which AI tools they may use, what data they may put into them, and who decides when the answer is unclear. A usable AI acceptable use policy fits on one page, reuses the data classes you already have, and names a person and a route for requesting new tools. The template below is written to be copied and edited.
Long policies tend to sit unread. Keep the staff-facing rules short and move the detail into linked standards that security, legal and HR own.
What is an AI acceptable use policy, and what is it not?
It is the part of AI governance that ordinary employees read. It answers three everyday questions: can I use this tool, can I paste this data, and what do I do if something goes wrong. It is not the full governance framework, which covers decision rights, risk registers and impact assessments.
Standards place the policy inside a wider system. ISO/IEC 42001:2023, published in December 2023, defines requirements for an AI management system, and ISO's own explainer lists "AI policy and objectives" among those requirements. The NIST AI Risk Management Framework 1.0, released on 26 January 2023, is voluntary and organises its guidance into four functions: Govern, Map, Measure and Manage. Neither document tells you what to write on your one page. Read together, they point to what the page needs around it: an owner, a review cycle and a link to risk management.
What do regulators and guidance say about staff use of AI?
In Saudi Arabia, SDAIA's Generative Artificial Intelligence Guidelines for Public (May 2025, version 1) is a guidance document, not a statute. On classified data breaches it says organisations should implement policies for generative AI use that prohibit users from entering classified information into third-party tools. Those policies should detail acceptable content generation practices, actions to prevent sensitive data leaks and steps to support ethical use. It also calls for oversight, regular reviews and employee training, and it states that users are responsible for verifying the content a tool generates.
The binding rules sit elsewhere. The Saudi Personal Data Protection Law (Royal Decree No. M/19 of 9/2/1443H, as amended) sets conditions on transferring personal data outside the Kingdom in Article 29, and Article 20 requires a controller to notify the competent authority of a leak or unauthorised access, as the implementing regulations specify. Pasting customers' personal data into a chatbot that processes it outside the Kingdom can therefore be a data protection question, not only a policy breach. Other countries in the region have their own data protection laws, and sector regulators (for example in banking, health and government) and cybersecurity or cloud rules can add limits on which tools and hosting locations are allowed. Check the ones that apply to you.
This is general information, not legal advice. Your obligations depend on your sector, the data you hold and where you operate.
What should a usable AI policy contain?
Ten elements cover what staff need. Each has a simple test: could an employee answer the question in under a minute without calling anyone?
| Element | What it says | Test |
|---|---|---|
| Scope | Who and what it covers: staff, contractors, personal accounts used for work, AI features inside existing software | Does it name browser extensions and meeting note-takers? |
| Approved tools | A list with a link, kept outside the policy so it can change weekly | Is there one place to look? |
| Data rules | What may be entered, by data class and by tool | Does it use your existing classification labels? |
| Prohibited uses | A short list of things never to do | Is each item concrete? |
| Human review | Which outputs a person must check before they leave the organisation | Is the checker named by role? |
| Disclosure | When to tell a client, colleague or regulator that AI helped | Is the trigger clear? |
| Accounts and devices | Work accounts only, or personal accounts with limits | Does it say what to do on a phone? |
| New tool requests | Who to ask, what to attach, how long the answer takes | Is there a target response time? |
| Incidents | What counts, who to tell, how fast, with no blame for honest reports | Does the reader know the contact? |
| Ownership and review | A named role, a version, a next review date | Is the date in the document? |
Here is a one-page AI acceptable use policy template
Copy this into your own format. Replace everything in square brackets, and delete any line you cannot enforce.
- Purpose. We use AI to [save time on drafting, analysis and research] while protecting customer, employee and company data.
- Who this covers. All [employees, contractors and interns], on any device, using any AI tool for work, including AI features inside software we already use.
- Approved tools. You may use the tools on [link to register]. For each tool the register states the data classes allowed. If a tool is not listed, ask before you use it.
- Data you may enter. [Public] and [Internal] data: in any approved tool. [Confidential] data: only in tools marked for it. [Restricted or personal data]: never, unless the register says the tool is approved for it.
- Never do. Enter passwords, keys or unreleased financial results. Use AI to make a final decision about a person, such as hiring or discipline. Upload client files to a tool that is not on the register.
- Check before you send. You are responsible for anything you send, with or without AI. [Role] must review [contracts, regulatory filings, customer-facing text, code going to production].
- Tell people when it matters. Say that AI helped when [a client asks, a contract requires it, or a regulator expects it].
- Accounts. Use your work account. Do not sign up to AI tools with a personal email for work tasks.
- Ask for a new tool. Send [form or address] with the task, the data involved and the vendor. We aim to reply within [number] working days.
- If something goes wrong. If you pasted data you should not have, or a tool behaves unexpectedly, tell [contact] straight away. Honest reports are not punished.
- Owner and review. Owned by [role]. Version [number], dated [date], reviewed by [date].
How do you set data rules people can follow?
Map the rules to the classification labels staff already know. Three bands are easier to remember than six: data that may go into any approved tool, data that may go only into tools marked for it, and data that never goes in. Public entities in Saudi Arabia work with the national data classification policy, and other organisations may have their own labels, so use whichever applies to you.
Take a regional bank as an illustration. It might allow staff to paste public product descriptions into an approved assistant, restrict customer correspondence to a tool its security team has reviewed, and forbid account numbers in any AI tool. The exact lines are yours to draw with your security and legal teams.
How do you roll the policy out so it gets used?
- Find out what staff already use. A short amnesty survey and a look at sign-in logs can show real behaviour, as described in our guide to shadow AI. Check that any log review is covered by your employee privacy notice.
- Draft with security, legal, HR and two business teams in one room, so the rules reflect real tasks.
- Publish the approved tools register before the policy. A policy that says no without saying what to use instead can push the same work to personal phones.
- Train with three real examples per team, including one where the correct answer is to ask first.
- Set a review date. Tools change faster than policies, so review the register monthly and the policy at least when your tool list or the applicable laws change.
What mistakes make an AI policy fail?
- A ban list without an approved alternative.
- A template copied from another country or sector without checking local law.
- No named owner, so nobody updates it.
- Rules that ignore AI features switched on inside email, CRM or meeting software.
- No fast route to ask for a new tool, so staff stop asking.
- Monitoring that staff were never told about.
How to start
If you do not know what your people already use, start with the AI Exposure Scan: a free 45-minute conversation that ends in a written next step. See the AI Exposure Scan (GB1). If you already know and want the policy, decision rights and registers written with you, read about AI Governance & Compliance Foundation (GB4) in our Governance Lab.
Frequently asked questions
What is an AI acceptable use policy?
It is a short document that tells employees which AI tools they may use, what data they may enter, which outputs a person must check, and who to ask or tell when something is unclear or goes wrong. It is written for everyday staff, not for auditors, and sits inside the wider AI governance framework.
How long should an AI acceptable use policy be?
Aim for one page of rules that staff can read in a few minutes. Put the changing detail, such as the approved tools list and data class tables, in linked documents. A short policy is easier to teach, easier to enforce and easier to update when tools or laws change.
Is an AI acceptable use policy required by law?
The sources we cite do not set a general legal requirement for a document with this name. Data protection and cybersecurity laws apply to AI use whether or not you have a policy, and some sectors have extra rules. ISO/IEC 42001 lists an AI policy among its requirements, but certification is voluntary. Ask counsel what applies to your sector and countries.
Should we ban ChatGPT and similar tools?
A ban is a choice, not a requirement. Without an approved alternative, work can move to personal devices where you cannot see it. Some organisations instead approve specific tools, set data rules per tool, and give staff a quick way to request others. Decide based on your data and regulators.
Get new insights by email
One email when we publish something useful. No spam; leave any time.
Services in this article
Related lab: Governance Lab ↗
