How to Build an AI Acceptable Use Policy That Employees Actually Follow
Build an AI Acceptable Use Policy that works — with data classification, approved tool lists, plain language, worked examples, and a review cadence that keeps pace with AI.

Every week, another organisation publishes an AI Acceptable Use Policy. Most of them look the same: a list of prohibitions, a few definitions lifted from a vendor's terms of service, a signature line, and a filing cabinet where it will live indefinitely. Employees sign it. Nobody reads it. Nothing changes.
If your AI AUP isn't shaping behaviour, it isn't working. And in a regulatory environment where AI governance is increasingly scrutinised, "we have a policy" is no longer enough. You need one people actually understand and follow.
Here's how to build one.
Why Most AI AUPs Fail
The root problem is simple: most AI AUPs are written by legal or compliance teams for legal or compliance purposes — to create a paper trail, not to guide decision-making.
The result is policies that are too abstract ("do not use AI tools to process confidential data" sounds clear until an employee wonders whether their project notes count, or whether summarising a client email in ChatGPT is covered), too broad (blanket prohibitions push employees to ignore the policy entirely or work around it quietly), not maintained (a policy written in January is often obsolete by June), and not connected to consequences (if there's no clear answer to "what happens if I break this rule?", the rule has no teeth).
Step 1: Start With Use Cases, Not Prohibitions
Effective AI AUPs are built around what people are actually doing — or want to do — with AI tools. Before writing a single policy line, audit your organisation's AI usage and map out the most common scenarios: drafting emails and documents, summarising meetings or calls, writing or reviewing code, analysing data, customer-facing communications, research and competitive intelligence.
For each use case, answer one question: is this permitted, permitted with conditions, or prohibited? Build your policy around that taxonomy.
The practical benefit is significant: employees can look up their specific situation and get a clear answer, rather than trying to interpret vague language under pressure.
Step 2: Classify Your Data, Then Map It to AI Tools
The biggest risk from AI tool usage isn't the tools themselves — it's what data gets fed into them. Your AUP needs to connect your existing data classification framework to specific AI tool permissions.
A simple mapping looks like this:
Data Classification | Approved AI Tools | Conditions |
|---|---|---|
Public / Internal | Any approved tool | None |
Confidential | Enterprise-tier tools only (e.g., Claude for Enterprise, Microsoft 365 Copilot) | Must be covered by DPA / BAA |
Restricted / Personal Data | Not permitted in external AI tools | Internal/self-hosted models only, if available |
The distinction between a consumer-tier AI tool and an enterprise-tier tool with a data processing agreement in place is crucial — and should be explicitly called out in your policy.
Step 3: Define the Approved Tool List
Your AUP should reference a living approved tool list — a document or intranet page that gets updated as tools are reviewed and approved, rather than baking specific tool names into the policy itself, which will go out of date.
For each tool, the list should include the tool name and vendor, approved use cases, the maximum data classification permitted, whether a data processing agreement is in place, and any conditions such as "enterprise licence only" or "not for customer data."
This decouples the policy — which changes infrequently — from the tool list, which changes often. Both become much easier to maintain.
Step 4: Write It in Plain Language
This cannot be overstated. Your AI AUP will be read — if it's read at all — by people who are not lawyers.
Avoid: "The use of generative artificial intelligence systems to process, transmit, or store information classified as Confidential or above is prohibited except where the relevant data controller has obtained appropriate contractual assurances from the processor..."
Prefer: "Don't paste confidential documents or customer data into AI tools unless the tool is on our approved list for that data type. If you're unsure, ask IT before you share."
Test your draft with a sample of employees from different departments. If they can't tell you in their own words what the policy requires of them, rewrite it.
Step 5: Make It Actionable with Worked Examples
Abstract rules are hard to apply to real situations. A short section of worked examples does more than three pages of policy prose.
✅ Using Claude to draft a first version of an internal report from your own notes: permitted.
✅ Using Microsoft 365 Copilot to summarise a Teams meeting with a client: permitted, as it processes data within your Microsoft 365 tenant.
❌ Uploading a client contract to a public AI chatbot to extract key terms: not permitted. Use an approved enterprise tool or ask the legal team.
⚠️ Using an AI coding assistant to review code that includes API keys or connection strings: permitted only if the tool is on the approved list and secrets have been removed first.
Step 6: Define Accountability and Consequences
A policy without consequences is a suggestion. Your AUP should clearly state who is responsible for compliance, what employees should do if they're unsure (a named team or email address, not just "contact IT"), how to report a suspected breach, and what the consequences of a breach are — proportionate and clearly linked to your existing disciplinary framework.
Accountability also means leadership setting an example. If senior leaders are visibly using unapproved AI tools, no policy will change behaviour at the team level.
Step 7: Build in a Review Cadence
A policy with no review date is already out of date. Build in a minimum six-month review cycle with a named owner responsible for keeping it current.
Reviews should cover new AI tools that have become widely used, changes to relevant regulations (GDPR, AI Act, sector-specific requirements), incidents or near-misses that revealed gaps, and feedback from employees on what's unclear or unworkable.
Getting Buy-In: The Human Side
The best-written policy will still fail without buy-in.
Involve employees in the process — people are more likely to follow rules they helped shape. Frame the policy as enabling, not restricting: lead with what's permitted, not what's prohibited. Pair it with training — a 20-minute awareness session with real examples relevant to each team's work will do more than an email attachment. And make it easy to find — on your intranet, accessible from search, not buried in a SharePoint folder nobody knows about.
The Bottom Line
An AI Acceptable Use Policy is only as valuable as the behaviour it produces. The organisations getting this right aren't writing longer policies — they're writing clearer ones, and backing them up with training, tooling, and a culture where employees feel comfortable asking questions rather than quietly taking risks.