Writing an AI Use Policy for Your Team: A Practical Template and Examples

Most AI policies fail the same way: they’re either a one-line ban nobody respects or a ten-page document nobody reads. The teams that actually get value from AI tools land somewhere in between — a short, clear set of rules people can follow without asking permission for everything. This is a working template you can adapt, plus the examples and reasoning behind each piece.

Key takeaways

• A usable AI policy fits on one page and answers four questions: what tools are allowed, what data can’t go in, when to disclose, and who reviews the output.
• Write rules around how the work gets done, not around “did a tool touch this” — the second is unenforceable and breeds quiet workarounds.
• Don’t lean on AI detectors as a compliance gate. They report probabilities, not proof, and they misfire on non-native English writers.
• Tier your rules by risk: a brainstorm draft and a client-facing legal memo shouldn’t follow the same approval path.
• Ship a v1, tell people it’ll change, and schedule a review date. A living policy beats a perfect one that never launches.

Why most AI policies don’t work

Here’s the pattern. A manager reads a scary headline, fires off a Slack message banning ChatGPT, and three things happen. People who relied on it quietly keep using it on personal accounts. The honest folks who stopped fall behind. And nobody learns anything about doing AI work well, because the whole topic went underground.

The opposite failure is just as common: a policy written by committee, full of phrases like “employees shall exercise appropriate judgment when leveraging generative artificial intelligence solutions.” That tells no one what to actually do on a Tuesday afternoon.

A good policy is a decision aid. When someone is about to paste a customer email into a chatbot, the policy should answer “can I do this?” in a few seconds. If it can’t, it’s decoration.

The four questions every policy must answer

Forget the legalese. Your core document needs to answer four things clearly.

1. Which tools are approved?

Name them. Don’t say “approved AI tools” — list them. Be explicit about the difference between an enterprise account (where your contract says your inputs won’t train the vendor’s models) and a free consumer account (where the default terms may be very different).

Example wording:

> Approved for sensitive work: our company ChatGPT Enterprise workspace and our Microsoft Copilot license. Both have data agreements that keep our inputs out of model training. Approved for public/low-risk work only: free consumer chatbots. Not approved: any AI tool not on this list, until IT reviews it. Want something added? Post in #ai-tools and we’ll look within a week.

That last line matters. A request channel turns shadow usage into a conversation.

2. What data is off-limits?

This is the rule with real teeth, because the risk is concrete: data you put into the wrong tool can leak, persist, or end up training someone else’s model. Make a blunt list.

Example wording:

> Never paste into any AI tool: customer names or contact info, anything covered by an NDA, source code from private repos, unreleased financials, passwords or API keys, employee personal data. When in doubt, treat it as off-limits and ask.

Concrete beats clever. “Use good judgment with confidential information” sounds responsible and means nothing. A bulleted list of nouns gets followed.

3. When do people disclose?

Tie disclosure to stakes, not to whether a tool was used at all. Requiring a footnote on every internal email is the fast path to a rule everyone ignores.

Example wording:

> Disclose AI assistance on: client-facing deliverables, anything we publish under a person’s name, and any document that becomes a legal, medical, or financial record. You don’t need to disclose AI help on internal drafts, brainstorms, or routine email. If a reader would reasonably assume a human wrote every word and that assumption matters, say something.

4. Who reviews the output, and how?

AI output is a draft, never a finished product. The policy should name a human who owns accuracy. The reviewer’s job isn’t to catch “AI-ness” — it’s to catch wrong facts, fabricated citations, off-brand tone, and anything that could embarrass the company.

Example wording:

> Whoever’s name goes on the work owns its accuracy. Before anything ships externally, verify every factual claim, every quote, and every cited source against a primary reference. AI tools invent citations confidently. That’s on you to catch.

A mini-scenario: tier your rules by risk

Picture a marketing coordinator, Dana. On Monday she uses the company Copilot to rough out three subject-line options for a newsletter. On Wednesday she’s helping draft a contract amendment for a key account.

Those two tasks should not live under the same rule. The subject lines are low-stakes, reversible, and public-facing in a way that won’t sink the company if the tone is slightly off. The contract language touches a legal record and a named client.

So tier it:

• Tier 1 — low risk (brainstorms, internal drafts, formatting): Use approved tools freely. No disclosure, light review.
• Tier 2 — medium risk (published content, customer comms): Approved tools only, human review before it ships, disclose where a reader’s assumption matters.
• Tier 3 — high risk (legal, financial, medical, anything contractual): Approved enterprise tools only, named reviewer signs off, disclosure required, and a second set of eyes on facts.

One page, three tiers. Dana knows exactly which lane she’s in without filing a ticket.

The detector trap

A lot of draft policies include a line like “all content will be screened with an AI detector to ensure compliance.” Cut it.

AI detectors don’t tell you who wrote something — they estimate how statistically similar the text is to typical machine output. That score is a probability, not a confession. OpenAI pulled its own AI text classifier in July 2023 because the accuracy was too low to be useful. And a 2023 Stanford study (Liang and colleagues, published in Patterns) found that detectors flagged writing by non-native English speakers as AI far more often than native writing — in their tests, more than half of TOEFL essays by non-native writers got misclassified, while essays by native writers came through clean. The likely reason: plainer vocabulary and steadier sentence rhythm read as “machine-like” to the math. If you want the underlying reason, detectors only output a probability, not proof, and that probability swings with writing style.

Build enforcement on a detector and you get two predictable failures. You punish a careful ESL employee who wrote every word themselves, and you wave through a polished AI draft that happened to score low. Neither outcome is the one you wanted.

Use detection if you like — as a soft prompt to ask a colleague a friendly question, never as the verdict that ends the conversation. Make process the backbone of enforcement: approved tools, the data list, the review step. Those are things you can actually verify.

The one-page template

Drop your specifics into this skeleton and you’ve got a v1.

> [Company] AI Use Policy — v1.0, last reviewed [date] > > Why this exists: We want AI tools to make our work better and faster without leaking data or shipping sloppy output. These rules keep that simple. > > Approved tools: [list, with enterprise vs. consumer distinction] > Never put into AI tools: [the off-limits data list] > Disclose AI help when: [the stakes-based triggers] > Review before it ships: Whoever’s name is on it verifies all facts, quotes, and sources. > > Risk tiers: [Tier 1 / Tier 2 / Tier 3, one line each] > > Questions or new tool requests: #ai-tools > Next review date: [set one — quarterly to start]

Notice there’s no clause about “detecting” AI use, no productivity-killing approval queue for low-stakes tasks, and no vague appeals to judgment. Every line tells someone what to do.

Rolling it out without the eye-rolls

Announce it as a v1 and say out loud that it’ll change. People accept rules they helped shape, so open the #ai-tools channel before you publish and let folks flag the parts that won’t work in practice.

Pair the rules with a little craft, too. A policy that says “review before shipping” lands better when people know how to make a draft sound like a person actually wrote it — varied sentence length, specific detail, a real point of view. If your team wants the deeper background on writing well with these tools, point them to more on the ethics and detection side. The aim is better work, not just compliance.

Frequently asked questions

How long should a company AI use policy be? Short enough that people actually read it. One page for the core rules, with a linked appendix for the tool list and role-specific detail. Past three pages, most of your team will skim it once and never open it again.

Should our policy require disclosure on every document? No. Tie disclosure to stakes — client deliverables, published work, legal or financial records, anywhere a reader’s assumption that a human wrote it actually matters. A quick internal draft doesn’t need a footnote.

Can we use an AI detector to enforce the policy? Only as a soft signal. Detectors report a probability, not proof, OpenAI retired its own classifier over accuracy, and detectors over-flag non-native English writers. Build enforcement on process and review instead.

What’s the most important single rule? The data list. Naming exactly what can’t be pasted into a tool prevents the leaks that cause real, lasting damage. Disclosure and tone are recoverable; a leaked customer database isn’t.

How often should we update it? Set a review date when you publish — quarterly while tools change fast, then twice a year. Update it any time you approve a new tool or learn a lesson worth writing down.

Closing

A policy isn’t a wall, it’s a map. Give your team approved tools, a clear data line, stakes-based disclosure, and a real review step, and you’ll get the productivity without the quiet workarounds. When it’s time to make a draft read like a human actually wrote it — and to see how a detector reads it before it ships — you can run a draft through a humanizer and detection check and edit from there.