# Writing an AI Acceptable Use Policy Your Whole Organization Can Follow

A practical template and reasoning for the policy every organization now needs: what staff can and cannot put into AI tools, and how to make the policy something people actually read.

Staff are already using AI tools at work, whether or not a policy tells them how. An **acceptable use policy** (AUP) is the short document that says what is allowed, what is not, and why. One that nobody reads is worthless, and one written as a bare list of bans gets worked around within a week. This guide shows how to write one people will actually follow, in terms that work for public bodies, businesses, and schools alike.

## Start with the "why", not the "no"

Most AI policy failures come from treating staff as the threat rather than as people trying to work faster. Open with the reasoning. For example: "Some AI tools keep what you type and may use it to improve future models, so anything you paste in could leave our control for good." That sentence persuades more people than a page of prohibitions.

## Core sections every AI acceptable use policy needs

### 1. What counts as an "AI tool"

Be explicit. The list should include public chatbots, AI browser extensions, AI features built into everyday software (email suggestions, meeting summarizers, coding assistants), and AI agents that can take actions on a user's behalf. Ambiguity is where most violations happen: people do not think of an AI-powered spreadsheet add-on as "AI" until it is pointed out.

### 2. Data tiers and what is allowed where

| Tier | Examples | Rule |
| --- | --- | --- |
| Public | Published web content, press releases, public documentation | Safe to use with most AI tools |
| Internal | Draft plans, internal procedures, non-sensitive business data | Only approved tools covered by a data-processing agreement |
| Confidential or regulated | Citizen or customer personal data, health or financial records, credentials, proprietary source code | Never entered without written approval from your data protection or legal lead, and only through vetted, contractually governed tools |

### 3. Human review

AI output that is customer-facing, legally binding, or safety-relevant needs a **named human reviewer** before it goes out. Say who reviews which categories. This prevents the common failure of AI-drafted content going out unchecked because "it is usually right". Remember that AI can state false things confidently (often called a hallucination), so the reviewer's job is to verify, not just skim.

### 4. Approved tools and how to request a new one

Keep a living list of vetted tools with a named owner, and give staff a simple way to ask for a new one. If approval feels impossible, **shadow AI** (people quietly using unapproved tools) becomes the norm.

### 5. Incident reporting

Say what to do if confidential data was entered into an AI tool by mistake, and make it a "report it, no blame" process. Punishing reports only means incidents stop being reported.

## A worked example

A caseworker pastes a resident's letter, including name and address, into a public chatbot to get a tidy reply. Under a good policy, three things help: the caseworker knows personal data is in the top tier and should not go there, an approved internal tool exists as an alternative, and a mistake can be reported without fear. Without those, the caseworker would not have known, and nobody would have found out.

## Governance beyond the document

A policy is a snapshot, and AI changes fast enough that a yearly review is not enough. Pair it with a small cross-functional group (IT, legal, and a business representative) that meets quarterly to review new tool requests, incidents, and whether existing tools are still rated correctly. This matters more as AI agents move from answering questions to taking actions on internal systems. Published frameworks, such as the NIST AI Risk Management[↗](/risk-management) Framework, can help structure this work.

## Checklist for your first draft

- The policy fits on one or two pages and opens with the reasons.

- It defines "AI tool" broadly, including built-in features and agents.

- Data tiers are clear, with examples staff recognize from their own work.

- High-stakes outputs have a named reviewer.

- There is an approved-tools list, an owner, and a request route.

- Reporting a mistake is safe, and the policy has a review date.

## Related reading

[AI Governance: Building Responsible AI PoliciesAs AI tools spread across organizations, governance policy, not just technical controls, determines whether adoption is safe, compliant, and trustworthy.](/ai-governance-building-responsible-ai-policies) [AI Safety for Employees: What You Need to KnowAI safety for employees means knowing what can go wrong when you use AI tools at work, misplaced trust in outputs, manipulation of the AI itself, and data exposure, and how to use them without creating risk for yourself or your employer.](/understanding-ai-safety-risks-beyond-cybersecurity) [Prompt Injection: The New Frontier of AI AttacksWhen an AI assistant reads a webpage, email, or document, hidden instructions inside that content can hijack its behavior. Here's what prompt injection is and how organizations are defending against it.](/prompt-injection-the-new-frontier-of-ai-attacks)