AI Acceptable Use Policy Template: What to Put in Each Section
A one-page AI acceptable use policy beats a forty-page one nobody reads. Section by section, what to write, with examples for a thirty-person company, and where to get the template.
September 7, 2026 8 min read
Most organizations we meet are in one of two states. Either there is no AI policy and everyone is quietly pasting customer data into whatever chatbot they like, or there is a policy so long and so cautious that nobody has read it and everyone is quietly doing the same thing.
The fix is a short policy that answers the questions people actually have. This post walks through each section of the template we publish and what to write in it. The whole thing should fit on one page, two at most.
Start with what the policy is for
An acceptable use policy does three jobs. It tells people which tools they may use. It tells them what they may and may not put into those tools. And it tells them who is accountable for what comes out. Everything else, the ethics statements and the vision paragraphs, can live somewhere else.
Section by section
1. Scope
Who the policy covers and what counts as an AI tool. Keep the definition practical: any software that generates text, images, code, or decisions from a prompt, including features built into tools you already use, such as the assistant inside your email or your CRM. People forget those.
Example: "This policy applies to all staff and contractors, and to any tool that generates content or recommendations from a prompt, including AI features inside Microsoft 365, Google Workspace, and HubSpot."
2. Approved tools
Name them. A short list of tools that have been reviewed, with the account type people should use. The important distinction is between consumer accounts, where your prompts may be used to train the vendor's models, and business accounts under contract terms that prohibit it.
Example: "Approved: ChatGPT Team, Claude for Work, Microsoft Copilot under our tenant. Personal accounts on any AI service may not be used for work."
3. What you may put in, by data class
This is the section that matters most and the one most policies get wrong by being vague. Define three or four classes of data and say plainly which tools may receive each.
- Public. Anything already on your website or in your marketing. Any approved tool.
- Internal. Drafts, plans, meeting notes without personal details. Approved business-tier tools only.
- Confidential. Customer or client records, employee information, financials, anything under a contract or a regulation (HIPAA, CUI, attorney-client). Only tools explicitly cleared for that class, or none.
- Regulated. If you hold data under a specific regime, name it and name the rule. For a defense supplier, "no CUI in any AI tool" is one sentence and it is the sentence that matters.
4. Review of output
AI output is a draft until a person has checked it. Say so, and say who. The person who sends the email, publishes the post, or ships the code owns it, regardless of what wrote the first version.
Example: "AI-generated content is reviewed by the person who uses it before it leaves the organization. Facts, figures, quotations, and legal or medical statements are verified against a source."
5. Disclosure
When do you tell people AI was involved? Most organizations land on: disclose when the output is presented as someone's original work or analysis, and when a customer would reasonably want to know. A drafted email does not need a label. A report to a board might.
6. Procurement and vendors
New AI tools get reviewed before they are adopted. The review can be short, but it should ask: where does the data go, is it used for training, who can access it, and can we delete it. Put the "no training on our data" requirement in writing as a condition of purchase.
7. Incidents
What to do when someone pastes something they should not have. Tell someone, quickly, without punishment for reporting. The policy should name the person or inbox and promise a response. A rule people are afraid to invoke is not a rule.
8. Ownership and review
Who owns the policy and when it is revisited. Quarterly is right for now; the tools change too fast for annual.
If a new hire cannot read the policy in five minutes and answer "can I paste this customer's email into the tool?" without asking anyone, the policy is too long or too vague. Rewrite until they can.
Filling it in for a thirty-person company
A professional services firm with thirty people might land on: two approved tools on business accounts; public and internal data allowed in both; client files only in the one tool whose contract has been reviewed; every client deliverable checked by the engagement lead; disclosure to clients in the engagement letter; new tools reviewed by the operations manager with a one-page checklist; incidents to the operations manager within the day; policy reviewed every quarter at the leadership meeting.
That is the whole policy. It takes an afternoon to write and an hour to roll out.
Rolling it out
Do not email it. Walk through it in a room, take questions, and collect a signature or an acknowledgment. The questions you hear are the sections you need to sharpen. We do this as part of every cohort, where the portal's policy generator produces a first draft from a few questions and the group edits it together. It is also one of the most common things we cover in a free Lunch & Learn.
Get the template
The template, with these sections and example language, is in our policy and governance downloads, alongside a vendor evaluation checklist and a governance framework for organizations that need more structure. Take it, edit it, make it yours. A policy people follow is worth more than a policy that is complete.