AI Acceptable Use Policy: A 2026 Template for Organizations

An AI acceptable use policy (AUP) is the written document that tells employees which AI tools are permitted, which data categories they may process in AI tools, what configurations are required, and what happens when the rules are broken. Without one, every employee makes their own judgment call — and those calls aggregate into audit findings, compliance violations, and data breaches. For a deeper look at how AI tool usage affects SOC 2 Trust Service Criteria and what evidence auditors actually request, see SOC 2 and AI.

This guide explains what an effective AI AUP needs to cover in 2026, walks through the key policy sections, and provides annotated model language you can adapt for your organization.

Why most existing AUPs don't cover AI

Most organizations have an acceptable-use policy that covers email, internet access, and company-owned devices. Those policies were written before generative AI was mainstream. They typically:

• Define "confidential information" but do not specify that sending it to AI tools is a disclosure to a third party.
• Prohibit "unauthorized software" but do not address cloud services accessed through a browser (which describes most AI tools).
• Reference "data loss prevention" systems designed for email and file transfer, not browser-based AI prompts.

The gap is not a failure of the original policy — it is a failure to update as the threat landscape changed. Retrofitting an existing AUP with AI-specific language is faster than writing from scratch; replacing vague "third-party services" language with AI-specific prohibitions is the minimum viable update.

Structure of an effective AI AUP

An AI AUP should address seven areas:

1. Scope — who is covered, which tools, which systems
2. Approved tools and tiers — the positive list
3. Prohibited data types — what must not enter AI tools
4. Required configurations — the settings that must be active
5. Incident response — what to do when the rules are broken
6. Training and acknowledgment — how employees learn the policy and confirm they understand it
7. Review and update schedule — how frequently the policy is revisited

Section 1: Scope

Model language:

This policy applies to all employees, contractors, and third parties ("personnel") who use generative AI tools, large language model interfaces, AI coding assistants, AI search tools, or AI content generation tools (collectively, "AI tools") in connection with their work for [Organization Name], whether on company-owned or personal devices.

It applies to all AI tools, including but not limited to ChatGPT, Claude, Gemini, Microsoft Copilot, GitHub Copilot, Cursor, Perplexity, Grok, and similar services, regardless of whether accessed through a browser, desktop application, API, or embedded in another product.

Why it matters: Scoping to "connection with their work" captures personal devices. Listing example tools by name prevents the "I didn't know that counted" defense.

Section 2: Approved tools and tiers

Model language:

The following AI tools are approved for use with company information subject to the conditions in this policy:

| Tool | Approved tier | Permitted data categories | Required configuration | | --- | --- | --- | --- | | ChatGPT | Enterprise only | Internal, Public | Training disabled, history off | | Claude | Claude for Work (Team/Enterprise) | Internal, Confidential (non-PHI) | Confirm with IT | | Microsoft 365 Copilot | M365 commercial license | Internal, Confidential | Commercial Data Protection on | | GitHub Copilot | Copilot Business | Source code (no secrets) | Privacy mode on, indexing off |

All other AI tools are unapproved for use with company information. Use of unapproved AI tools with company information is a violation of this policy.

Why it matters: A positive list ("approved") is more enforceable than a negative list ("prohibited") because it does not require anticipating every new tool. "Company information" is defined in your information classification policy; cross-reference it.

Section 3: Prohibited data types

This is the core of the policy. Be specific — vague language is unenforceable in practice.

Model language:

The following data types must not be entered into any AI tool, including approved tools, unless a specific exception is documented and approved by [Legal / Information Security]:

Regulated data:

• Protected health information (PHI) as defined by HIPAA (patient names, diagnoses, MRNs, dates of service, and any other individually identifiable health information)
• Personally identifiable information (PII) of customers, employees, or individuals (names combined with government IDs, financial account numbers, biometrics, or other identifying information)
• Payment card data: primary account numbers (PANs), CVVs, track data, PINs
• Nonpublic personal information regulated under GLBA, state privacy laws, or equivalent
• Education records protected under FERPA

Confidential business information:

• Unpublished financial results, projections, or forecasts
• M&A targets, deal terms, and due diligence materials
• Trade secrets, including proprietary algorithms, model weights, and internal tooling source code
• Attorney-client privileged communications
• Personnel records, compensation data, and HR investigation materials
• Customer contracts, pricing schedules, and contract terms marked confidential

Authentication material:

• Passwords, API keys, tokens, certificates, private keys, or any credential

When in doubt whether information falls into a prohibited category, treat it as prohibited and consult [Information Security / Legal] before proceeding.

Why it matters: Specificity reduces ambiguity and the "I didn't think that counted" defense. The "when in doubt" clause gives employees a safe default.

Section 4: Required configurations

Model language:

Personnel using approved AI tools must maintain the following configurations:

• Training/model improvement opt-out: Disable any settings that permit the AI provider to use your prompts to improve its models. For ChatGPT Enterprise, this is disabled by default; for other tools, confirm with IT.
• Chat history/conversation storage: Disable persistent conversation history for any session that involves confidential information. Where history cannot be disabled, do not enter confidential information.
• Codebase indexing / workspace context: For AI coding assistants, disable any feature that uploads the full codebase or repository to the AI provider's servers unless IT has reviewed and approved the specific repository for indexing.
• Memory / personalization features: Disable AI memory features that store information across sessions when using tools for work purposes. Review and delete any sensitive content already stored in AI memory.
• Connected apps and integrations: Do not connect AI tools to company systems (email, CRM, code repositories, cloud storage) without prior IT review and approval.

Configuration settings must be verified on each device where an AI tool is used. Configuration screenshots must be maintained and available for audit on request.

Why it matters: Configuration requirements convert a policy aspiration into a specific, auditable control. Screenshot documentation gives auditors evidence of operating effectiveness.

Section 5: Incident response

Model language:

If you believe you have sent prohibited data to an AI tool — whether through copy-paste, file upload, or an AI integration — take the following steps immediately:

1. Stop the session. Do not continue the conversation or add additional context.
2. Delete the conversation. Use the AI tool's conversation deletion feature to remove the session from visible history (note: this may not immediately delete from provider servers).
3. Report within 24 hours. Notify [Information Security / Compliance] using the incident reporting channel ([link/email/Slack channel]). Provide: the AI tool used, the approximate nature of the data involved, the date and time, and your best estimate of the scope.
4. Do not attempt to remediate alone. Do not contact the AI provider directly without [Information Security] involvement.

Failure to report a suspected incident is treated the same as the underlying policy violation.

Why it matters: A clear, low-friction incident response path increases the likelihood of voluntary reporting, which is critical for meeting breach notification deadlines.

Section 6: Training and acknowledgment

Model language:

All personnel must complete AI acceptable-use training before first use of any AI tool for work purposes, and annually thereafter. Training covers:

• This policy and the prohibited data categories
• How to identify confidential information in your work context
• Configuration requirements for approved tools
• The incident-reporting process

Personnel must acknowledge this policy in writing (electronic acknowledgment is acceptable) upon first receipt and annually. Acknowledgment records are maintained by [HR / IT] for the duration of employment plus three years.

Why it matters: Annual training acknowledgment is a standard audit evidence request. The three-year retention covers most statute-of-limitations periods for regulatory actions.

Section 7: Review and update schedule

Model language:

This policy is reviewed and updated at least annually, or when any of the following occur:

• A new AI tool is approved or removed from the approved list
• A significant change occurs in an approved tool's privacy terms or data handling
• A regulatory change introduces new requirements applicable to AI tool use
• An incident occurs that reveals a gap in the policy

The policy owner is [Chief Information Security Officer / General Counsel / CTO]. Questions about this policy may be directed to [email/Slack].

Common mistakes in AI AUPs

Mistake 1: Using "AI tools" to mean only consumer chatbots. AI capabilities are embedded in many products — Notion AI, Salesforce Einstein, Grammarly, Otter.ai, Microsoft Copilot in Word/Excel. A policy that only names standalone chatbots misses the majority of AI exposure.

Mistake 2: No positive list of approved tools. Without a positive list, employees have to guess whether a new tool is permitted. A positive list with an "all others require approval" default gives IT meaningful control over the tool inventory.

Mistake 3: Vague prohibited data categories. "Do not share confidential information" is not actionable. "Do not share customer names combined with account numbers, diagnoses, or government IDs" is.

Mistake 4: No enforcement mechanism. Policy violations require consequences, applied consistently. Document the consequence scale (coaching → warning → termination) and apply it. A policy that is never enforced is not an effective control.

Mistake 5: Set-and-forget. AI capabilities change monthly. A policy written in early 2026 may be materially incomplete by late 2026. Build the review cadence into the policy itself.

Communicating the policy to employees

Effective policy communication is not a one-time email. For AI AUPs, effective communication includes:

• Launch email from senior leadership (CEO or CISO) explaining why the policy exists and that it is not a ban on AI.
• Short explainer (1-2 pages or a 3-minute video) that translates the policy into plain-language examples for each role (developer, customer success, finance, HR).
• Embedded reminders in the tools themselves where possible: a browser bookmark that links to the approved-tool list, a Slack bot that answers "is [tool] approved?", a pinned Notion page for the engineering team.
• Annual refresh at the same time as other policy acknowledgments (security awareness, AUP, code of conduct).

Frequently asked questions

Should the AI AUP be a standalone document or part of the existing AUP?

Either approach works. A standalone AI AUP is easier to update and makes the AI-specific commitments explicit — useful when you need to show an auditor or regulator that you have addressed AI. Embedding it in the existing AUP keeps the document count manageable and ensures employees see it alongside other policies. Many organizations start with a standalone addendum and merge it into the main AUP at the next scheduled review.

How do we handle personal use of AI tools on company devices?

Many organizations permit personal use of AI tools on company devices during non-work hours, subject to the condition that company information is never involved. If you permit personal use, define it explicitly: "Personal AI tool use is permitted on company devices provided no Company Information (as defined in the Information Classification Policy) is included in any prompt or attachment." This allows flexibility while maintaining a clear line.

What if an employee's job requires using non-approved AI tools?

The policy should include an exception process: a documented request reviewed by IT and Legal, a risk assessment, and written approval from the appropriate authority (CISO, General Counsel, or department head). Track approved exceptions as part of your vendor inventory. Do not make the exception process so burdensome that employees ignore it and proceed without approval.

How do we enforce the policy for contractors and offshore teams?

The policy should cover contractors by scope (as drafted above). For offshore teams, include AI AUP compliance in your master service agreements and conduct-of-business requirements. For high-risk processing (PHI, financial data), require contractors to provide evidence of their own AI governance program.

Does the policy need to address AI tools the organization builds internally?

Yes, but in a different document. Internal AI systems — models trained on company data, AI features built into your product — are governed by your data governance and AI governance programs, not the employee AI AUP. The AUP covers employee use of external AI tools; internal AI development is a separate scope.

How do we keep the approved-tool list current as AI evolves rapidly?

Designate an owner (typically the CISO or CTO's office) responsible for maintaining the approved-tool list as a living document. Establish a lightweight review process (30-day intake for new tools, quarterly list review) that can keep pace with the speed of AI product launches without requiring a full policy revision for each addition.

The bottom line

An AI acceptable-use policy is not a ban on AI — it is the governance structure that lets your organization use AI confidently. The policy works when it is specific enough to be actionable, communicated to employees in plain language, enforced consistently, and updated as the AI landscape evolves. The organizations that get this right in 2026 will have a durable foundation for AI governance as the regulatory environment hardens; the organizations that do not will find themselves retrofitting governance after an incident makes it mandatory. For the case on pairing policy with technical controls, see Sonomos vs. staff training alone.