Most mid-size companies wrote an AI acceptable use policy in the last two years because a board member, a cyber insurance questionnaire, or a customer security review demanded one. Ask who has read it since and the answer is usually the person who wrote it and the auditor who asked for it. It lists approved tools, forbids pasting customer data into chatbots, points at a training module, and then sits in the policy repository next to the clean desk policy.
The full template is at the bottom, ungated. First, what it should contain and what has to sit around it for the rules to hold.
What acceptable AI usage means
An AI acceptable use policy (AUP) tells employees which AI tools they may use, what data may go into them, what they may do with the output, and what happens when they break the rules. It is the employee-facing slice of a broader corporate AI policy. Vendors also call it an AI usage policy or a generative AI policy; a search for an AI usage policy template or a sample AI policy turns up the same seven elements under different headings.
Acceptable AI usage comes down to three questions any employee can answer at their desk. Is this an approved tool? Is this data allowed to leave the company through it? Will a person check the output before it matters? A policy works when someone can answer all three in under a minute without calling legal.
Why a written policy matters, and why it is rarely enough
Three things go wrong without one.
Data leaks. Free-tier chat tools retain prompts by default, and many train on them. A sales rep who pastes a contract into one has shared it with a third party on terms nobody read. Prompt injection turns the tool itself into an exfiltration channel: a webpage carries hidden instructions, and the assistant summarizing it obliges. Agents that act rather than answer make the same mistakes at speed.
Outputs diverge. Two analysts produce contradictory forecasts from two different tools, and nobody notices until a customer does.
Accountability disappears. When a regulator, customer, or plaintiff asks how a decision was made, "someone used ChatGPT" is the answer nobody wants in the record.
A written policy addresses all three by setting expectations. What it cannot do is see a prompt. It names the approved tools and the forbidden data classes with no way of knowing which tool an employee opened or what they typed. Most companies bridge that gap with annual training and a hope. We wrote about why AI compliance training falls short on its own; the short version is that awareness changes what people know, not what they do at 4:45 on a Friday with a deadline.
What should be in an AI acceptable use policy
Every workable AUP we have reviewed contains the same seven elements. The order varies more than the substance.
- Purpose. Why the policy exists, limited to the risks the company actually faces.
- Scope. Who is covered, which systems, and whether personal devices and AI features embedded in software you already own count. The summarizer in your CRM is AI.
- Definitions. AI system, generative AI, AI agent, approved tool, confidential data.
- Permitted uses. Concrete examples by role rather than abstractions.
- Prohibited uses. Same treatment. Name what has gone wrong or will.
- Data handling rules. A classification table tied to what may enter a prompt.
- Enforcement. Who monitors, what happens on violation, and how to report an incident.
Approved tools and the path to a new one
List the approved tools by name and edition, including which login to use. Write "ChatGPT Enterprise through company SSO" rather than "ChatGPT," because that difference decides whether prompts are retained and used for training.
Then give people a fast way to ask for something new. A five-day turnaround from a named owner beats a 90-day procurement cycle because the unsanctioned tool is one browser tab away, and if the sanctioned route takes longer than the workaround, the workaround wins. Most shadow AI is a failed request that nobody ever submitted. We cover how to detect shadow AI separately.
Data classification tied to the prompt
The AUP maps each existing data class to a plain answer about AI tools. Four classes cover nearly every case: public, internal, confidential, and regulated (PII, PHI, payment card data, material non-public information, and anything a customer contract forbids sharing). Nobody opens a classification standard mid-task, but the four-row table in the template below, placed on the screen where people type, gets read.
Permitted and prohibited uses, by role
Abstract rules fail at the point of use because they require judgment about which category a task falls into; examples remove it. Acceptable uses of AI at most companies include drafting text the author will review, summarizing documents the employee may already read, writing code that goes through code review, and answering questions against an approved internal knowledge base.
Role-specific examples land harder than generic ones. In finance, drafting variance commentary is a normal use, while feeding unreleased earnings into a tool that trains on inputs is a reportable incident. A support rep can draft a reply with AI and should never send it unread.
Human review before an output leaves the building
Nothing AI-generated leaves the company until a named person has read it and would sign their name to it. A reviewer who approves forty AI-written emails in ten minutes is a rubber stamp, and a regulator will treat it as one, so the template requires the reviewer to be able to explain the output rather than merely to have seen it.
Enforcement, monitoring, and incidents
State what the company monitors and be honest about it. Most companies can see which SaaS domains employees visit, some can see uploads, and almost none can see prompt content. A policy that implies surveillance the company cannot perform undermines the rest of it.
Violation handling should scale with intent and impact: an honest mistake reported within the hour is a training moment, while concealing it is a disciplinary matter. Most data leaks through AI tools are discovered by the person who caused them, and the policy decides whether they speak up.
How to draft, roll out, and maintain it
Drafting takes a small group rather than a committee: one owner from security or IT, one from legal or compliance, and two or three daily users who will tell you which rules they would ignore. Circulate the draft to department heads for a week with one question: what in your team's work does this get wrong?
Send the final policy with the tool list and the data table on top, and hold a 20-minute session per department on their role-specific examples. Require acknowledgment, but treat the signature as the start of the record rather than proof of compliance. Review quarterly for the first year, since the tool list will change monthly, and keep a version history so an auditor can see which policy was in force on a given date.
Policy defines, the point of use enforces
A written AUP sets expectations and creates a record that the company set them. It does nothing about the moment an employee opens a browser tab. Rules about which tool, which data class, and which review step only become real where a system can see all three at once: who is asking, which tool, and what class of data is in the request.
The AUP holds when paired with two things. First, a sanctioned path that is easier than the unsanctioned one: enterprise accounts through SSO and a fast request process. Second, a point of use where the policy gets applied rather than remembered. An identity-aware AI gateway sits at that point. It knows the person from your directory, the tool from the request, and the data class from the prompt, and applies the rules the policy already wrote: allow, redact, route to an approved model, or block and explain why.
That pairing is the difference between an AUP that produces evidence and one that produces acknowledgment forms. The broader case is in our governance offering. Swept Access is our version of the gateway; if the policy below describes rules you have no way to apply, see how Swept Access works or talk to us.
AI acceptable use policy template
Copy this, replace the bracketed placeholders, and delete what does not apply. If legal needs to add terms, put them in a separate section rather than rewriting the rules employees read.
[Company] AI Acceptable Use Policy
Version [1.0] | Effective [date] | Owner: [Role, e.g., Head of Information Security]
1. Purpose
This policy sets the rules for using artificial intelligence tools at [Company]. It exists to keep [Company] and customer data out of systems we do not govern, to keep people responsible for decisions, and to give every employee a clear answer about what they can use.
2. Scope
This policy applies to all employees, contractors, interns, and temporary staff. It covers AI tools [Company] provides, AI features built into software [Company] already uses, personal accounts or devices used for [Company] work, and AI agents that act on [Company] systems or data.
3. Definitions
- AI system: Software that generates content, makes predictions, or takes actions based on a machine learning model.
- Generative AI: An AI system that produces new text, code, images, audio, or video from a prompt.
- AI agent: An AI system that takes actions on its own, such as sending messages, editing records, or calling other systems.
- Approved tool: An AI system listed in Section 4, accessed through the login method named there.
- Confidential data: Information classified as Confidential or Regulated under Section 5.
4. Approved tools and how to request a new one
You may use the following tools for [Company] work, only through the login method listed:
| Tool | Access method | Approved for data up to |
|---|---|---|
| [ChatGPT Enterprise] | [Company SSO] | [Confidential] |
| [GitHub Copilot Business] | [Company GitHub org] | [Confidential (source code)] |
| [Internal assistant name] | [Internal URL] | [Regulated, per Section 5] |
Using a personal account for any of these tools, or a tool not on this list, for [Company] work is not permitted. To request a new tool, submit [form/link] to [Role]. You will get a decision within [5] business days, and approved tools are added to this table and announced in [channel].
5. Data you may and may not enter
Before you put anything into an AI tool, decide which class it belongs to. If you are not sure, treat it as the higher class.
| Data class | Examples | May it enter an approved tool? |
|---|---|---|
| Public | Published marketing content, public web pages, press releases | Yes, any approved tool |
| Internal | Meeting notes, internal process docs, unshared drafts | Yes, approved tools with company login only |
| Confidential | Contracts, financials, source code, unreleased plans, customer lists, employee data | Only in tools marked "Confidential" in Section 4, and only for permitted uses |
| Regulated | Personal data (PII), health data (PHI), payment card data, material non-public information, data under contractual restriction | No, except in [Internal assistant name] or another tool explicitly approved for that class |
Never enter passwords, API keys, or credentials of any kind into an AI tool.
6. Permitted uses
With an approved tool and data within the limits in Section 5, you may:
- Draft, edit, summarize, and translate text you will review before using
- Write, explain, and test code that goes through [Company]'s normal code review
- Summarize or answer questions about documents you are already authorized to read
- [Role-specific permitted uses, e.g., "Support: draft customer replies for review before sending"]
7. Prohibited uses
You may not use AI tools to:
- Enter Regulated data into any tool not explicitly approved for it
- Make or recommend a decision about hiring, firing, pay, credit, insurance coverage, or benefits without a named person reviewing and owning the decision
- Generate content that impersonates a real person or misrepresents who created it
- Send AI-generated communications to customers, regulators, or the public without the review required in Section 8
- Find or exploit vulnerabilities in [Company] or third-party systems without written authorization from [Role]
- [Role-specific prohibited uses]
8. Human review requirements for outputs
Any AI-generated content that leaves [Company], including customer communications, contracts, filings, and production code, must be reviewed by a person who is qualified to judge it, has read it in full, can explain why it is right, and takes responsibility for it as if they had written it. The reviewer's name is recorded in [system or process].
9. Transparency and disclosure
- Customers and the public: Disclose that AI was used when it materially shaped the content or decision, when the customer asks, or when law or contract requires it. [Company]'s standard disclosure language is: "[text]."
- Colleagues: Mark AI-generated drafts as such when sharing internally.
- Never: Present AI output as the independent work of a person where that distinction matters, such as expert opinions, references, or attestations.
10. Agents and automation
An AI agent that takes actions, not just produces text, requires written approval from [Role] naming the agent, the systems it may access, and the actions it may take. Scope its permissions to the minimum required: an agent that drafts emails does not need send permission. A person must be able to stop it, and every action it takes is logged in [system].
11. Monitoring and enforcement
[Company] monitors AI tool usage on company networks, devices, and accounts, including [which tools are accessed, what data classes are submitted, and which actions agents take]. [Company] does not monitor [describe the limits honestly].
Violations are handled under [Company]'s [disciplinary policy name]. Consequences depend on intent, impact, and whether the violation was self-reported. Accidental violations reported promptly are treated as training matters. Concealed or repeated violations, or intentional misuse of Regulated data, may result in termination.
12. Reporting incidents
If you enter data you should not have, see an AI tool or agent behave unexpectedly, or become aware of anyone violating this policy, report it to [address/form/channel] within [24 hours]. Self-reporting an accidental disclosure will not by itself result in disciplinary action. Reporting fast lets [Company] request deletion, rotate credentials, and notify anyone affected.
13. Training
Everyone covered by this policy completes AI acceptable use training [within 30 days of hire], [annually], and when this policy changes materially. [Role] tracks completion.
14. Policy review and version history
[Role] reviews this policy [quarterly] during its first year and [annually] thereafter, and whenever a regulation changes or an incident reveals a gap. The tool table in Section 4 may be updated between reviews by [Role] with notice in [channel].
| Version | Date | Change | Approved by |
|---|---|---|---|
| 1.0 | [date] | Initial policy | [Name, Role] |
15. Acknowledgment
I have read [Company]'s AI Acceptable Use Policy, version [1.0]. I understand which tools I may use, what data I may enter, when review is required, and how to report an incident.
Name: ______________________ Date: ____________ Signature: ______________________
Where to start
Write the tool table and the data table first. They are what employees will screenshot and keep. Then ask whether anything in your environment can see a request and apply those tables to it. If the honest answer is no, you have written rules that nobody enforces. Closing that gap separates an AI policy for companies that reads well from one that holds.