Overview

Your senior database engineer sent an email to the whole team: "I just fed our entire schema and production query logs to ChatGPT to help with query optimization. Got some great suggestions. Turns out the bot gave me some really helpful query rewrites. Should've asked first?"

The gut reaction: panic. Your reply probably involved the word "incident."

But here's what actually happened: Someone needed help optimizing queries. They didn't know whether it was allowed. They didn't know which tool was approved. They didn't know what data was sensitive. So they guessed wrong.

The real failure wasn't the engineer; it was your policy. You either didn't have one, or you had one and didn't communicate it.

An enterprise AI acceptable use policy (AUP) solves this. It's not a rulebook that makes work impossible. It's a guide that tells teams exactly what they can do, why, and with what guardrails.

Purpose

An enterprise AI AUP answers a simple question that your teams are asking right now whether they know it or not: "Can I use this AI tool, and if so, how?"

Without a clear policy, teams either:

• Don't use AI at all (and fall behind)
• Use AI but hide it (shadow AI)
• Use AI openly and incur compliance/security risk

A good AUP creates a third path: teams use AI confidently within understood boundaries.

An AUP is not a ban list. It's a framework that says, "Here are the categories of work. Here are the approved tools for each category. Here are the guardrails. Here's how to request an exception."

Why This Matters

For IT operations, an AUP is essential because:

• 
  Reduces liability. If an employee leaks customer data through an unapproved AI tool, and you had no policy, you share liability. If you had a policy and they violated it knowingly, your liability is clearer and potentially lower.
• 
  Clarifies what's approved. Teams stop guessing. They know they can use ChatGPT for brainstorming (approved), but not for production credentials (prohibited). That clarity prevents 80% of the incidents you'd otherwise have.
• 
  Enables compliance reporting. When an auditor asks "What's your policy on AI tool usage?" you have a document. When they ask "How do you enforce it?" you have an answer.
• 
  Scales governance without growing headcount. A clear, principle-based policy scales to hundreds or thousands of employees without requiring a team of people to manage exceptions.
• 
  Supports innovation. A well-designed AUP doesn't block AI; it enables it. It says "here's how to use AI safely and effectively," not "no."

Core Concepts

Key Insight: Principle-Based vs. Tool-Based Policies

The biggest mistake organizations make is writing tool-based policies:

>
"Approved tools: ChatGPT Plus, GitHub Copilot

Prohibited tools: Claude, Gemini, local LLMs

Requires approval: Everything else"

This policy will be outdated in 3 months. A new tool emerges that's better than your approved tools. Teams need it. What happens? They use it anyway, violating your policy.

A principle-based policy works differently:

>
"Generative AI tools can be used for brainstorming, documentation, and code analysis if:

• No customer data is sent to the tool
• No production credentials or secrets are sent to the tool
• No proprietary algorithms or confidential business logic is sent to the tool
• A human reviews and validates all AI-generated output before use

Specific tool choices are left to teams, provided they meet the above requirements."

This policy survives the release of new tools. It explains the principle (protect sensitive data, maintain human judgment) rather than mandating specific tools.

Key Insight: Data Classification is Your Foundation

Before you write an AUP, you need to know what data your organization has and how sensitive it is. A data classification framework is essential.

Typical data classes:

Class
Definition
Examples
AI Handling

Public
Can be openly shared
Blog posts, marketing materials, documentation
Can be sent to any AI tool

Internal
For company use but not confidential
General process documentation, internal announcements
Can be sent to most AI tools, caution with cloud-based services

Confidential
Sensitive business information
Financial data, business plans, customer lists
Cannot be sent to external AI tools without encryption or anonymization

Restricted
Highly sensitive; regulatory or legal constraints
Customer PII, payment card data, health information, production credentials
Cannot be sent to external AI tools under any circumstances

Once you have this framework, your AUP becomes much simpler: "AI tools can handle Public and Internal data. Confidential data requires case-by-case approval. Restricted data cannot be sent to external AI tools."

Your teams can then apply this rule themselves without needing to memorize your policy.

Key Insight: Use Case Categories

Rather than writing separate policies for each team, categorize use cases. IT operations teams probably fall into a few common categories:

Use Case 1: Code and Documentation

• Code analysis and generation
• Documentation writing and improvement
• Brainstorming solutions to technical problems
• Guardrails: All generated code must be reviewed. Do not send production code or proprietary algorithms. Do not send credentials.

Use Case 2: Data Analysis and Optimization

• Analyzing logs, metrics, and performance data
• Helping optimize queries or system configurations
• Identifying anomalies in operational data
• Guardrails: Do not send customer data, production credentials, or data that could identify a customer. Anonymize data before sending if possible.

Use Case 3: Learning and Skill Development

• Using AI to learn new technologies or languages
• Getting explanations of technical concepts
• Practicing problem-solving
• Guardrails: This is a low-risk category. Minimal restrictions beyond "don't share proprietary IP."

Use Case 4: Routine Task Automation

• Drafting standard reports or runbooks
• Organizing information
• Creating templates or checklists
• Guardrails: Moderate guardrails. Don't send data that identifies customers or contains credentials.

For each use case, you can be specific about approved tools, data handling, review requirements, and escalation paths.

Key Insight: The Approval Exception Process

Your policy will have gaps. Someone will need to do something that's not explicitly covered. That's where your exception process comes in.

A good exception process:

• Is lightweight for low-risk exceptions (email approval, 1-2 days)
• Is thorough for high-risk exceptions (security review, compliance review, CIO sign-off)
• Provides a clear path rather than a black hole
• Includes criteria for what can and can't be approved

Example exception request:

>
"Our ops team wants to feed our last 30 days of anonymized alert logs into an AI tool to help identify patterns we're missing. The tool is [Vendor]. The data is [describe it]. We'll review all findings and validate them before acting on them. What do we need to do to approve this?"

Decision framework:

• Is this data truly anonymized? (verify)
• Does the vendor meet our security requirements? (security team)
• Is this a one-time analysis or ongoing? (affects approval)
• Have we evaluated alternatives? (is AI the right approach?)
• What's the timeline? (affects thoroughness of review)

Decision: "Approved for 30-day pilot. Monthly review required. If you want to extend beyond 30 days, formal vendor security assessment required."

Key Insight: Communication Strategy

A policy sitting in a document that nobody reads is useless. You need a communication and training strategy.

Phase 1: Announcement (Week 1)

• Executive leadership communicates the new policy
• Message: "We're enabling AI usage safely. Here's what you can do."
• Tone: Enabling, not restricting

Phase 2: Training (Weeks 2-3)

• Role-specific training (IT operations teams, data teams, administrative teams)
• Hands-on examples: "Here's a request that's approved. Here's why. Here's one that's not. Here's why."
• Q&A: "What if I want to do X?"

Phase 3: Support (Ongoing)

• Help desk training on the policy
• Quick reference guide (1-page policy summary)
• Exception request form (easy to find and use)
• Regular FAQs in team meetings

Phase 4: Enforcement (Ongoing)

• DLP tools catch violations and generate alerts (not blocking, initially)
• Violations are treated as coaching opportunities, not punishments
• Quarterly reviews of violations teach you where the policy is unclear

Practical Use Cases

Use Case 1: The Right Way to Approve Code Generation

Scenario: Your infrastructure team wants to use GitHub Copilot for infrastructure-as-code development.

Policy application:

• Use case: Code generation (approved)
• Data concern: Are they sending production configurations? (Yes, but infrastructure definitions, not secrets)
• Decision: Approved, with guardrails.

The approval:

"GitHub Copilot is approved for infrastructure-as-code development. Guardrails:

1. Remove all actual IP addresses, domain names, and resource IDs before sending
2. Never send actual database passwords, API keys, or certificate content
3. All generated code must be reviewed in code review (which you're already doing)
4. Document the use of AI in your pull request comments
5. We'll audit first month of usage to ensure guidelines are being followed"

What the team gets: Clear permission. No surprises. They know exactly what they can do.

What IT gets: A record of approval. Confidence that risk is managed. A way to audit usage and catch problems.

Use Case 2: When to Reject a Request

Scenario: Your database team wants to use an AI tool to help optimize queries against production data. They want to send actual production SQL statements and query execution plans (which might contain real data examples).

Policy application:

• Use case: Data analysis and optimization (approved in principle)
• Data concern: Production query logs might contain customer data or reveal business logic
• Decision: Not approved as requested.

The response:

"We like this idea, but we need to modify the approach. You can't send actual production queries to an external tool because they might contain customer data. Here's what we can do instead:

• Generate synthetic query patterns that mimic your production queries but with fake data
  - Use an internal tool (if you have one) that doesn't leave your network
  - Work with the database vendor's optimization tool (if available) which has stronger data privacy guarantees
  - For specific production optimization problems, submit a formal exception request that includes a security and compliance review

Which approach works for you?"

This response doesn't block the team; it redirects them to a safer path.

Use Case 3: The Shadow AI Conversation

Scenario: You discover through a DLP alert that someone has been sending internal documentation to ChatGPT to help write runbooks.

Old approach (reactive):

"You violated policy. Stop immediately. Meeting with your manager and the security team."

New approach (proactive):

First conversation with the engineer:

"I noticed you've been using ChatGPT to help write runbooks. Is that something you find helpful?"

"Yeah, actually, it's great at helping me structure information and catch things I missed."

"That makes sense. Here's the thing: we need to be careful about what internal documentation goes to external AI tools because it might contain sensitive info. But we like the idea of using AI for documentation. Let's get you set up properly.

First, let's look at what you're sending to make sure it's actually safe. Second, we'll make sure your tool choice meets our security requirements. Third, we'll make sure your team knows it's approved so everyone can use it safely."

The outcome: The team gets the tool they need. Governance actually works. You've converted a violation into an improvement to your policy.

Examples

Example 1: A Complete AI Acceptable Use Policy

Title: Enterprise AI Acceptable Use Policy

Scope: All employees, contractors, and partners using AI tools in work-related contexts.

Definitions:

• Generative AI tools: ChatGPT, Claude, Copilot, Gemini, and similar systems that generate text, code, or other content
• Data classification (see classification framework above)
• Approved tools: Tools that have passed security and compliance review
• Sensitive data: Anything classified as Confidential or Restricted

Approved Use Cases:

Use Case
Description
Approved?
Guardrails

Brainstorming
Ideation on technical problems, design, or approach
✅ Yes
Generic concepts only, no specific systems

Documentation
Writing or improving documentation, guides, runbooks
✅ Yes
Don't send production details without anonymization

Code Analysis
Understanding code, identifying issues, suggestions
✅ Yes
Don't send proprietary algorithms or credentials

Code Generation
Generating code, scripts, or configuration
✅ Yes
All output must be reviewed; don't send secrets

Learning
Learning new technologies, languages, frameworks
✅ Yes
Low-risk category; minimal guardrails

Data Analysis
Analyzing logs, metrics, performance data
⚠️ With Approval
Data must be anonymized; no PII or credentials

Routine Tasks
Drafting reports, creating templates
✅ Yes
Standard guardrails; no sensitive data

Decision Making
Using AI output as primary input for decisions
❌ No
Human judgment must validate before action

Production Automation
Running AI systems in production without human review
❌ No
Requires formal governance process

Prohibited Practices:

• Sending customer personal information (names, emails, phone numbers, account IDs)
  - Sending production credentials, API keys, certificates, or secrets
  - Sending proprietary algorithms, business logic, or confidential strategies
  - Asking AI to make autonomous decisions about infrastructure or security
  - Using AI tools from unapproved vendors without exception approval
  - Storing output from AI tools in unauthorized locations

Data Handling Rules:

• Public data: Can be sent to any approved AI tool
  - Internal data: Can be sent to approved tools with reasonable data privacy policies (US or EU-based preferred)
  - Confidential data: Cannot be sent to external AI tools without formal exception (requires security and compliance approval)
  - Restricted data: Cannot be sent to external AI tools under any circumstances

Tool Approval and Use:

• Teams may use any approved tool that fits their use case
  - A list of pre-approved tools is maintained (see appendix)
  - To request approval for a new tool, submit an exception request (see process below)
  - Tool vendors may be re-evaluated quarterly

Current Approved Tools:

• ChatGPT Plus (OpenAI)
• GitHub Copilot (GitHub)
• Claude (Anthropic)
• Google Gemini (Google)
• [others as appropriate]

Exception Request Process:

• For low-risk exceptions (using an approved tool in a different way, or one-time analysis):
  - Submit request form: what you want to do, why, what data, what tool
  - Approval from your manager + IT governance team
  -
  Timeline: 2-5 business days
• 
  For high-risk exceptions (new tool, sensitive data handling, ongoing use):
• Security review: Does the tool meet our security requirements?
  - Compliance review: Does it meet our data privacy obligations?
  - CIO/CISO approval required
  - Timeline: 2-3 weeks

Governance and Monitoring:

• IT monitors AI tool usage and data flows
  - Violations trigger coaching conversations, not punishment
  - Quarterly policy review incorporates learnings from violations
  - Annual training refresh required

Questions?

• See the FAQ (attached)
  - Contact [email protected]
  - Bring questions to your manager

Example 2: An Exception Request Form

AI Tool Exception Request Form

Requestor Information

• Name: *_***
• Department: *_***
• Manager: *_***
• Date: *_***

Request Details

• What tool do you want to use? (name, vendor)
• What use case? (code generation, data analysis, learning, other)
• What data will it handle? (describe, classify by sensitivity level)
• Why this tool? (what are you trying to accomplish, and why is this tool the right choice?)
• Timeline: One-time, or ongoing? How long?

Data Handling Plan

• How will you ensure sensitive data is not sent? (describe your process)
• Who reviews the output?
• Where will results be stored?
• What's your incident response plan if something goes wrong?

Approval Pathway

• Manager approval: *_***
• Security review (if required): *_***
• Compliance review (if required): *_***
• Final approval: *_***

Terms

• I understand the risks and have a plan to mitigate them
• I will notify IT of any issues or violations
• I understand this approval may be revoked if misused

Example 3: A 1-Page Quick Reference Guide

AI Policy Quick Reference

Can I use AI for...?

• ✅ Brainstorming and ideation
• ✅ Writing documentation or runbooks
• ✅ Code analysis and generation (if reviewed)
• ✅ Learning and skill development
• ⚠️ Data analysis (if anonymized)
• ❌ Handling customer data
• ❌ Managing production credentials
• ❌ Autonomous decision-making

Before you use an AI tool:

1. Is it on the approved list? (See tools list)
2. What data are you sending? (Check classification)
3. Will you review the output? (Always)
4. Have you told your manager? (Yes)

If you need something that's not approved:

1. Fill out the exception form ([email protected])
2. Include: what tool, what data, what you're doing
3. Wait for approval (2-3 weeks for new tools)
4. Don't use it until approved

Questions?

Email [email protected] or ask in #ai-policy Slack channel

Example 4: A Communication Template for Rollout

Subject: New AI Acceptable Use Policy - Here's What You Need to Know

Hi team,

We're excited to formally enable responsible AI usage across IT. Many of you are already using tools like ChatGPT and GitHub Copilot. Our new policy makes clear which tools are approved and how to use them safely.

The good news:

• Brainstorming, documentation, and code generation are approved
• You can use the tools your team finds most helpful
• We're not banning AI; we're enabling it responsibly

The important details:

• Don't send customer data, credentials, or proprietary business logic to external AI tools
• Review all AI-generated output before using it
• If you want to use a tool not on our approved list, there's a simple exception process

What's next:

1. Read the policy (linked below)
2. Attend the training session for your team (schedule linked)
3. Start using AI confidently, and let us know if you have questions

We built this policy with your input, and we're committed to updating it as our needs evolve. If you think something should be approved or prohibited differently, the feedback process is in the policy.

Let's make IT operations smarter with AI.

[Policy link] [FAQ link] [Exception form link]

Anti-Patterns

Anti-Pattern 1: Writing a Policy Nobody Can Understand

The trap: Your policy is 30 pages long, full of legal language, and discusses edge cases nobody cares about. Teams read the first page, don't understand it, and make their best guess (which is usually wrong).

Why it fails: Communication fails. You have a policy but no adoption.

Fix: Write a principle-based policy (2-3 pages), not a comprehensive legal document. Put the detailed rules in appendices. Create a 1-page quick reference. Invest in communication and training.

Anti-Pattern 2: A Policy That's All "No"

The trap: Your policy says "ChatGPT is prohibited. This tool requires approval. That tool is banned." Nothing is approved except a few obscure tools nobody's heard of.

Why it fails: Teams work around the policy. The moment there's demand for something, it goes underground.

Fix: Your policy should answer "yes" to most common use cases. "No" should be the exception, not the default. "Brainstorming, documentation, and code generation are approved" is a strong policy. The specific tool is less important than the use case.

Anti-Pattern 3: No Exception Process

The trap: Your policy covers the 80% case but not the 20%. Someone needs to do something slightly unusual. There's no way to get approval. So they either skip approval or violate policy.

Why it fails: Policies without escape hatches get violated because they're too rigid.

Fix: Build an exception process that's lightweight for low-risk exceptions (2-5 days) and more thorough for high-risk ones (2-3 weeks). Make it easy to ask.

Anti-Pattern 4: Enforcement Without Understanding

The trap: Your DLP tool catches someone sending data to ChatGPT. You immediately escalate it as a violation without understanding why they did it.

Why it fails: Teams see enforcement as punishment, not guidance. They hide future violations rather than asking for permission.

Fix: When you catch a violation, first understand. "I see you sent X to Y tool. What were you trying to accomplish? Let's figure out the right way to do that." Most violations are people trying to solve a problem, not being malicious.

Human Judgment Checkpoints

• Can your team articulate the policy without reading it? If engineers can't tell you what's approved and why, your communication failed. Rewrite the quick reference.
  - Are you catching violations or enabling compliance? If your monitoring is finding lots of violations, your policy is either unclear or too restrictive. Investigate why.
  - Is the exception process actually used? If you set up an exception process and nobody uses it, it's either too heavy, too invisible, or not needed. Adjust.
  - Does leadership understand the policy? Your manager, your CISO, your CIO should be able to explain the policy and defend it. If they can't, you haven't communicated it well.

Key Takeaways

• 
  Write principle-based policies, not tool-based ones. "AI can handle X, Y, Z but not A, B, C" survives new tools. "ChatGPT is approved" becomes obsolete.
• 
  Start with data classification. If you know what data you have and how sensitive it is, your policy becomes much simpler: "AI tools can handle public and internal data, but not confidential or restricted data."
• 
  Organize around use cases, not tools or departments. Every team has brainstorming, documentation, and data analysis. One set of use-case rules applies to everyone.
• 
  Make approval lightweight for low-risk cases. If your exception process takes 3 weeks for a simple request, teams will work around the system. Risk-based approval takes 2-5 days for simple cases, 2-3 weeks for complex ones.
• 
  Invest in communication as much as in the policy. A great policy that nobody understands is useless. A simple policy that everyone knows is powerful.
• 
  Treat violations as learning opportunities. When you catch shadow AI, ask "why?" Usually the answer is that your policy didn't cover something teams needed. Fix the policy, don't just punish the team.
• 
  Plan to update the policy quarterly. New tools emerge. New use cases are discovered. Your policy evolves, or it becomes irrelevant.