Writing an AI Acceptable Use Policy That Does Not Kill Innovation

Most AI Acceptable Use Policies (AUPs) in circulation today fall into one of two failure modes.

The first: a blanket prohibition drafted by a legal team in 2023 that bans all generative AI tools, was ignored by every department within 60 days, and has not been updated since. This policy provides the illusion of governance while shadow AI usage grows unchecked underneath it.

The second: a vague aspirational document that instructs employees to "use AI responsibly" without defining what responsible means, what tools are approved, or what data can be shared with which tools. This policy provides no actual protection because nobody knows what it requires.

A policy that works has to be specific enough to be actionable and flexible enough that employees do not route around it.

Start With the Business Context, Not the Legal Template

The instinct to open a legal template and fill in the blanks produces generic policies. Start with your actual business context:

• What AI tools are employees already using? (Discovery informs the policy.)
• What sensitive data categories does your organization handle? (Shapes data-sharing rules.)
• What workflows benefit most from AI assistance? (Shapes the approved-use section.)
• What regulatory requirements apply? (HIPAA, SOC 2, GDPR, FINRA — each has implications.)
• What is your risk tolerance for AI-generated content in customer-facing communications? (Shapes review requirements.)

A policy written from these answers will be specific to your organization. A policy written from a template will be generic — and employees will sense that it was not written for them.

The Core Policy Structure

Section 1: Scope and Definitions

Define what the policy covers. "AI tools" is too vague — it encompasses everything from Excel's autocorrect to autonomous agents. Be specific:

• Generative AI tools — tools that produce text, code, images, or other content in response to prompts (ChatGPT, Claude, Copilot, Gemini, image generators)
• Automated decision systems — tools that make or recommend business decisions using AI models
• AI-enhanced features in approved software — AI capabilities built into existing approved tools (email AI assist, coding autocomplete, document summarization)

Each category may have different rules.

Section 2: Tiered Access Model

A binary "allowed / not allowed" model does not match organizational reality. A tiered model is more useful:

Tier 1 — Approved for all employees: AI features within existing approved enterprise software (Microsoft Copilot on M365, Salesforce Einstein, etc.). These tools operate under existing data processing agreements.

Tier 2 — Approved with data classification restrictions: Specific approved external AI tools (e.g., Claude Pro with enterprise privacy mode, or approved OpenAI API integrations). Employees may use these for public or internal-classification data only. Confidential or restricted data may not be input.

Tier 3 — Requires IT/security approval: Tools not on the approved list but requested for a specific legitimate use case. Approval requires review of the tool's data handling practices.

Not permitted: Tools with training-data rights in consumer tiers, tools that cannot provide data processing agreements, tools that process regulated data without appropriate controls.

Section 3: Data Classification Rules for AI Input

This is the most operationally critical section. Employees need clear rules about what data can go into what tools.

Public data (marketing copy, publicly available information): May be input into Tier 1 and Tier 2 tools.

Internal data (internal processes, non-sensitive business information): Tier 1 tools only (with enterprise data protection agreements in place).

Confidential data (customer PII, financial records, trade secrets, legal matters): Enterprise-tier tools only, where specific data processing agreements and privacy controls are confirmed. Input into consumer-tier tools is prohibited.

Restricted data (PHI, PCI data, credentials, regulated technical data): May not be input into any external AI tool without explicit security team approval and a documented DPA.

Section 4: Approved Use Cases

List specific workflows where AI use is encouraged:

• Drafting internal communications (with human review before sending)
• Summarizing meeting notes
• Writing first drafts of non-customer-facing content
• Code generation and debugging in development environments
• Research and competitive intelligence synthesis

And workflows where AI use requires explicit review:

• Customer-facing written communications (must be reviewed by a human before sending)
• Legal documents and contracts (must be reviewed by legal or an attorney)
• Financial projections and reports (all AI-generated numbers must be independently verified)
• Medical or safety-relevant decisions

Section 5: Transparency Requirements

Employees should disclose AI assistance where it is material. The threshold varies by context:

• Code commits using AI assistance: disclosure in the commit message or PR description
• Published content: follow the organization's publication disclosure policy
• Customer communications: disclosure is not typically required for AI-assisted drafting reviewed by a human, but is required if content is sent without human review

Section 6: Prohibited Uses

Be explicit:

• Using AI tools to generate misleading, defamatory, or harassing content
• Inputting data in violation of the data classification rules above
• Using AI to attempt to circumvent security controls or access unauthorized systems
• Representing AI-generated content as original human analysis without disclosure (in contexts where that distinction is material)

Making the Policy Stick

A policy that is not enforced is not a policy — it is a document. Enforcement requires:

Training. Policy release must be accompanied by practical training that explains why each rule exists and how to apply it to common workflows. Employees who understand the reasoning behind a rule follow it more reliably than those who received only a compliance checkbox.

An approved tool list. Maintain a current list of approved AI tools, with their permitted data classification tiers. Update it when tools are added or removed from the enterprise portfolio.

A request process. Employees who want to use a tool not on the approved list need a clear path to request approval — otherwise they route around the policy. Make the request process simple enough that using it is easier than ignoring it.

Annual review. The AI tool landscape changes faster than most policy revision cycles. Commit to annual review at minimum, with triggered review when a significant tool or capability change occurs.

If you want a policy that actually governs AI in your organization — rather than just existing on paper — Talk to JP Stratton.