aiagentrank.io
⚙️Ops5 min read

How to write an AI policy for your team: the 2026 template

Practical AI policy template — what to allow, what to forbid, how to handle data + IP + customer-facing AI, and how to avoid the two common policy failure modes.

AI Agent Rank EditorsPublished May 23, 2026

An AI policy is the document that tells your team what they can + can't do with AI tools — and the document that protects the company when something goes wrong. Most companies don't have one in 2026. The ones that do are quieter about it.

TLDR — the structure

A working AI policy has 5 sections:

  1. Allowed uses — what's encouraged
  2. Forbidden uses — what's prohibited and why
  3. Data classification — what data can go into which AI tool
  4. Customer-facing AI — disclosure + accuracy requirements
  5. Incident response — what to do when AI does something wrong

Plus a one-page "TL;DR for everyone" at the top. The full policy is 3-5 pages; the TL;DR is what gets read.

Section 1: Allowed uses (be explicit + permissive)

Most teams default-deny in AI policy. This is wrong. Default-deny pushes employees to use AI without telling you.

Default-allow common productivity uses, then specify the exceptions:

Examples of allowed:

  • Drafting + editing internal documents (memos, emails, plans)
  • Research + summarization of public information
  • Code generation for personal productivity (with review)
  • Meeting summaries from notes you took
  • Brainstorming + ideation

If your policy doesn't allow these, employees will ignore it. Better to allow + guide than forbid + lose visibility.

Section 2: Forbidden uses (specific + justified)

For each prohibition, give the reason — not "because we said so" but "because of risk X."

Common prohibitions:

  • Customer PII into public AI tools. Reason: data residency + breach risk. Use the approved tools (see Section 3).
  • Source code into public AI tools without IP review. Reason: IP leakage + license compatibility. Use approved tools.
  • Decisions about employees (hire/fire/promote) based on AI without human review. Reason: discrimination liability + fairness.
  • Generated content presented as human-authored externally without disclosure. Reason: deception + customer trust.
  • AI-generated code shipped without human review. Reason: quality + security.
  • Using AI to circumvent existing policies (e.g., generating fake invoices). Reason: it's still fraud regardless of who/what created it.

Note the absence of "no ChatGPT, period." That doesn't work.

Section 3: Data classification

This is the section that does the most work. Tie AI-tool usage to data classification levels.

Sample classification:

TierExamplesAllowed AI tools
PublicMarketing copy, public blog postsAny AI tool
InternalInternal docs, meeting notes, codeApproved AI tools (list)
ConfidentialCustomer PII, employee data, financial detailsEnterprise-tier approved tools only (e.g., Claude Enterprise, ChatGPT Enterprise, your self-hosted setup)
RestrictedTrade secrets, security incidents, M&ANO AI tools — human-only

The "approved AI tools" list belongs in an appendix that you can update without rewriting the policy. Refresh quarterly.

Section 4: Customer-facing AI

Special rules for AI that interacts with customers.

Required practices:

  • Disclosure. If a customer is talking to an AI (chatbot, voice agent, email auto-reply), disclose it. Required by EU AI Act and California AB-1047; recommended everywhere.
  • Escalation paths. Customer can always reach a human within the same channel. No infinite-loop AI traps.
  • Accuracy review. Customer-facing AI outputs (refund decisions, billing actions, advice) reviewed regularly for accuracy + bias.
  • Restricted topics. Don't deploy AI to handle medical/legal/financial advice unless you've engineered for it specifically.
  • Audit logging. Every customer-facing AI conversation logged + reviewable.

Section 5: Incident response

When AI does something wrong, what's the process?

The 5-step incident pattern:

  1. Detect — How was the issue surfaced? (User complaint, automated monitoring, employee report?)
  2. Contain — Disable the misbehaving agent or scope it to dry-run mode immediately
  3. Assess — Scope: how many users/transactions/outputs affected?
  4. Communicate — Internal team + affected users + (if material) external comms
  5. Fix + post-mortem — Root cause analysis + policy/configuration update + share learnings

Most incidents will be small. The process scales down for small incidents. Having the framework matters when you need it.

The one-page TL;DR

Put this at the top of the policy. It's what employees actually read.

AI POLICY — TL;DR

DO use AI for:
- Drafting + editing internal docs
- Research + summarization
- Code generation (with review)
- Brainstorming
- Meeting notes

DON'T put into AI:
- Customer PII (unless using [Approved Tool X])
- Source code (unless using [Approved Tool Y])
- Trade secrets / M&A info — never

DON'T use AI to:
- Make hire/fire decisions without human review
- Ship code unreviewed
- Generate customer-facing content without disclosure

When in doubt: ask [policy owner]. We'd rather you ask than guess.

Full policy: [link]

Two common policy failure modes

Mode 1: Too restrictive

"No AI tools allowed without approval." Result: employees use AI tools anyway, just without telling you. You lose visibility + control. Worse than having no policy.

Mode 2: Too vague

"Use AI responsibly." Result: every employee makes their own call. You have a policy in name but no enforcement.

The middle path: be specific about the rules that matter, generous about the rules that don't.

How to roll out the policy

  1. Draft internally (Ops + Legal + Engineering owners)
  2. Pilot with one team for 2-4 weeks; collect questions; refine
  3. All-hands announce with the TL;DR + 30-min Q&A
  4. Train managers to handle the gray-zone cases their team brings them
  5. Review quarterly — the AI landscape shifts every 3 months; static policies decay

Who owns the policy?

Typically:

  • Drafting: Cross-functional (Ops/IT/Legal/Engineering)
  • Approval: CTO or CISO + Legal
  • Ongoing ownership: A specific person (often in IT or Ops) whose job includes "AI governance"
  • Day-to-day enforcement: Managers + a central queue for escalations

The biggest risk is no owner — the policy gets written, posted, and forgotten.

Bottom line

A working AI policy is short, specific, and revisited quarterly. It's permissive by default + restrictive where stakes are high. It has an owner. It survives contact with employees who actually use AI tools daily. If your policy is none of these, rewrite it.

Browse the glossary for governance terms →

Keep exploring

Compares, definitions and shortlists tied to what you just read.

More from the blog

How to write an AI policy for your team: the 2026 template · AI Agent Rank