AI Acceptable Use Policy: a plain, practical template for small teams
Most AI acceptable use policies are too long to read and too vague to follow. Here is a short one that fits a real team — plus the parts that actually prevent problems, and the trap that makes most of them useless.
Updated June 9, 2026 · 8 min read
If your team is using ChatGPT, Claude, Copilot, or any AI feature baked into the tools you already pay for, you probably need an acceptable use policy. Not because a regulator is knocking, but because people are pasting customer data into tools nobody approved, and right now the only rule is "use good judgment." That works until it doesn't.
The good news: a useful AI acceptable use policy for a small team is short. You do not need the 12-page enterprise document. You need something people will actually read once and remember. This guide gives you that, explains the parts that matter most, and names the mistake that turns a policy into shelfware.
What an AI acceptable use policy is actually for
A policy is not the goal. The goal is that a reasonable employee, on a busy Tuesday, knows the answer to three questions without asking:
- Which AI tools am I allowed to use for work?
- What information am I allowed to put into them?
- When does a human have to check the output before it goes out?
If your policy answers those three clearly, it is doing its job. Everything else is supporting detail.
The seven parts that matter
Across the better templates, the same core sections show up — scope, data rules, approved tools, prohibited uses, accountability, and review cadence (Centrexit, Lattice). Here they are, trimmed to what a small team needs.
1. Who and what it covers
State plainly that it applies to everyone — employees, contractors, anyone doing work for you — and to any AI tool used for company work, including ones accessed through personal accounts. The personal-account loophole is where most data leaks actually happen.
2. What data can go into AI tools
This is the most important section. Use a simple tiered rule instead of a wall of text:
Green — public info (your marketing copy, public research). Any reputable AI tool is fine.
Yellow — internal but not sensitive (general process notes, non-confidential drafts). Approved tools with company accounts only.
Red — customer data, employee personal info, financials, credentials, anything regulated. Never goes into a general AI tool. Full stop.
3. Which tools are approved
Name the specific tools you have blessed (e.g. "ChatGPT Team," "Claude for Work"), not vague categories. A named list is enforceable; "use reputable tools" is not. Keep the list short and review it quarterly.
4. What is off-limits
A few clear prohibitions beat a long list nobody remembers. The essentials: do not put Red-tier data into AI tools; do not let AI make a final decision about a customer or employee without a human checking it; do not pass off AI output as human-written when that would mislead someone; do not paste in proprietary code or secrets.
5. Who is accountable for AI output
The rule that prevents the most pain: the person who sends it owns it. AI output is a draft, not a decision. If an AI-drafted email to a customer is wrong, the employee who sent it is responsible for the error — the same as if they had written it themselves. Say this explicitly.
6. When a human must review
Most templates wave at "human review" without saying when. Be specific. A good default: a human must review before anything AI-generated goes to a customer, touches money or eligibility, or becomes an official record. (This is also where most teams quietly fail — see our guide on rubber-stamp reviews.)
7. How often you revisit it
AI tools change monthly. A policy written six months ago is probably already wrong about which tools exist. Put a quarterly review date in writing and name who owns it.
A short template you can adapt today
AI Acceptable Use Policy — [Company Name]
1. Scope. This applies to all employees, contractors, and third parties doing work for [Company], and to any AI tool used for company work — including tools accessed through personal accounts.
2. Data rules. Public info may be used with any reputable AI tool. Internal info may only be used with approved tools on company accounts. Customer data, personal data, financial data, credentials, and regulated information must never be entered into a general AI tool.
3. Approved tools. The current approved list is: [list]. Check the list before using a tool for work. The list is reviewed quarterly by [owner].
4. Prohibited. Do not enter restricted data; do not let AI make a final decision about a customer or employee without human review; do not misrepresent AI output as human-written; do not upload proprietary code or secrets.
5. Accountability. AI output is a draft. The person who uses or sends it is responsible for its accuracy.
6. Human review. A human must review any AI-generated content before it goes to a customer, affects money or eligibility, or becomes an official record.
7. Review. This policy is reviewed quarterly and updated as tools and rules change. Owner: [name].
Drop in your specifics and you have a policy a team can actually follow. Print it on one page.
The trap: a policy nobody operates
Here is the part the templates do not tell you. The most common failure is not a missing policy — it is a policy that exists on paper while the actual work happens a different way. The document says "a human reviews customer-facing AI output," but in practice one person is approving 200 items a day in nine seconds each. On paper you are governed. In reality you are not.
Writing the policy is the easy 20%. The hard 80% is making sure it matches how work is really done — that approved tools are the ones people actually reach for, that the review step has enough time to be real, and that someone owns it when the AI gets something wrong. A policy you do not operate is just a liability you have written down.
Want the policy without writing it from scratch?
Our AI Acceptable Use Pack gives you the full template, ready-made prohibited-use language, an ownership map, an exception log, and a quarterly review checklist — plus notes on where teams trip up. It is built to be adopted by a normal team, not filed by a compliance department.