Every company over 50 employees has an AI usage problem they haven't fully named yet. Engineering is using Copilot or Cursor. Marketing is drafting in ChatGPT. Sales is generating proposals with Claude. Legal is asking GPT to summarize contracts. HR is running candidate communications through it.
Most of this happens without a written policy. The first time leadership notices is usually when something goes wrong — customer data ends up in a free-tier consumer LLM, a hallucinated statistic makes it into a board memo, an engineer commits AI-generated code that violates an open-source license.
The companies handling this well wrote AI policies before the incidents. Here's the framework I use with them.
Why "ban AI" doesn't work
The reflex at risk-averse companies: ban consumer AI tools, allow only enterprise-licensed ones. This fails for three reasons:
- Productivity gap. Teams using AI are 15–30% more productive on relevant tasks. Banning it puts your team at competitive disadvantage.
- Shadow IT. People will use the tools anyway, just outside the visible workflow. Your policy creates no actual control, just plausible deniability.
- Talent loss. Engineers especially won't accept companies that ban modern productivity tools. You'll lose hiring battles.
The right framework is structured permission — clear rules for what's allowed, what's restricted, and what's prohibited, paired with sanctioned tools that meet the rules.
Three-tier data classification
The foundation of any AI policy: classify your data by sensitivity, and apply different AI usage rules to each tier.
Tier 1: Public data
Marketing materials, public website content, published research, publicly available company information.
Allowed AI usage: any tool, including consumer (free-tier) LLMs. No data leakage risk because it's already public.
Tier 2: Internal data
Internal strategy documents, financial data not yet disclosed, employee information that's not PII, customer aggregate analytics.
Allowed AI usage: only enterprise-licensed AI tools with contractual data-handling guarantees (no training on inputs, data deletion timelines, regional data residency).
Tier 3: Sensitive data
Customer PII, financial account information, source code with IP, M&A discussions, employee health data, anything subject to GDPR/ HIPAA/SOC 2.
Allowed AI usage: only AI tools deployed in your private cloud environment (e.g., Azure OpenAI in your tenant) OR explicitly approved enterprise tools with appropriate certifications.
The policy says: never paste tier-3 data into a tool that hasn't been explicitly approved for it. The classification is the foundation; the tooling decisions follow.
Approved tool list
A specific, written list of which AI tools are approved for which tiers:
- Tier 1: ChatGPT (free or paid), Claude (free or paid), Google Gemini.
- Tier 2: ChatGPT Enterprise, Claude for Work, GitHub Copilot Business, Microsoft 365 Copilot.
- Tier 3: Azure OpenAI in dedicated tenant, AWS Bedrock, Google Vertex AI, custom in-house deployment.
Maintain the list centrally. Update quarterly. The list serves two purposes: tells employees what's approved, and makes the shadow-IT problem visible (if everyone's using a tool not on the list, either approve it or fix the policy gap).
Usage rules
The policy needs explicit rules for common situations.
For engineering
- Copilot/Cursor approved for code generation in approved IDEs.
- Generated code must be reviewed before commit. AI-generated code is treated like junior-engineer code — useful, requires oversight.
- Open-source license attribution must be checked (Copilot can occasionally surface GPL-licensed code).
- Never paste production secrets, API keys, or customer data into any AI tool.
For marketing and content
- Approved AI tools allowed for first drafts.
- All AI-generated content must be reviewed by a human before publication.
- Facts and statistics generated by AI must be independently verified.
- Author bylines remain human; AI assistance doesn't get author credit but should be disclosed where the publication requires.
For sales
- AI tools allowed for proposal drafting, email composition, research summarization.
- Customer-specific data shared with AI tools must be in approved tier-appropriate tools only.
- Final outbound communications reviewed by the human sender; AI doesn't send.
For legal, HR, finance
- Approved tier-2 or tier-3 AI tools allowed for document review and summarization.
- AI-generated legal analysis or HR communications require human expert review.
- Tier-3 data restrictions strictly enforced — never use consumer AI tools for employee or candidate data.
Vendor approval process
For new AI tools entering the approved list, a written approval process:
- Use case — what problem does this tool solve that existing tools don't?
- Data handling — what does the vendor do with input data? Training opt-out? Deletion timelines? Data residency?
- Security certifications — SOC 2 Type II, ISO 27001, GDPR compliance, HIPAA if relevant.
- Cost vs alternatives — is this differentiated enough to justify another tool in the stack?
- Pilot results — 30-day pilot with measured outcomes before full approval.
The process should be efficient (2–4 weeks for approval) but mandatory. Bypassing it for "urgent" needs creates the shadow IT problem the policy was meant to prevent.
Training and education
A written policy that nobody reads doesn't work. The companies running AI policy well pair the document with mandatory training:
- Annual AI literacy training (60 minutes) for all employees. What AI is, what the risks are, what the company's policy is.
- Role-specific training (30 minutes) for high-AI-usage functions — engineering, marketing, sales — covering specific tools and their appropriate use.
- Refresher when policy changes — anytime the approved tool list or data tiers change, distribute an update.
Total time investment: 1–2 hours per employee per year. Worth it to prevent the incidents that would otherwise consume weeks of recovery.
Incident response for AI-related issues
The policy should specify what happens when something goes wrong:
- Suspected data leak to an unapproved AI tool: immediate notification to security, assessment of what data was exposed, vendor contact to request deletion where possible.
- AI-generated content with errors published: standard content correction process; document for training improvement.
- AI-generated code in production causing incidents: standard incident response; review whether the AI generation contributed.
- Bias or discrimination from AI tools (especially HR contexts): immediate halt of the affected workflow; legal review; tool evaluation.
The patterns aren't unique to AI — they're standard incident response with AI-specific causes. The point of including them in the policy is making clear that AI incidents are treated as real incidents, not as novelties.
Reviewing the policy
AI capabilities are evolving quarterly. The policy needs ongoing maintenance:
- Quarterly review of the approved tool list. New tools added; outdated ones removed.
- Annual policy refresh with data-tier reclassification as business changes.
- Continuous monitoring of vendor terms of service changes — AI vendors update their data policies regularly, and your approved-tool status should follow.
The companies running AI policy well treat it as a living document, not as a 2024 artifact still on the wiki.
A starter template
For companies that need to move fast:
AI USAGE POLICY (Vx.y)
1. PURPOSE: enable productive AI use while protecting data and quality.
2. CLASSIFICATION:
Tier 1 (Public): [examples]. Approved tools: [list].
Tier 2 (Internal): [examples]. Approved tools: [list].
Tier 3 (Sensitive): [examples]. Approved tools: [list].
3. PROHIBITED USES:
- Pasting tier-3 data into non-approved tools.
- Using AI-generated facts without verification.
- Publishing AI-generated content without human review.
- Submitting AI-generated work as fully human-authored where prohibited (e.g., academic, regulatory).
4. APPROVED VENDORS: [maintained list, updated quarterly]
5. INCIDENT RESPONSE: [contacts, process]
6. POLICY OWNER: [name, role]. Reviewed quarterly.
That's the structure. Customize to your industry, your data sensitivity profile, and your existing security framework.
AI usage in companies is already widespread. The question isn't whether your team will use AI — they already are. The question is whether they're using it inside a framework that protects your data, quality, and IP, or whether they're using it in the gap your policy doesn't fill. Write the policy now; the alternative is writing it after an incident.
For broader AI strategy beyond internal usage policy, see AI Strategy for Non-Technical CEOs.
