The short answer
Most corporate AI Acceptable Use Policies (AUPs) fail because they are written as vague legal prohibitions (“Do not input confidential data into AI”) or unrealistic blanket bans. When policies fail to account for how engineers and business teams actually use AI, employees resort to unauthorized consumer accounts on personal hardware.
An effective AI AUP must be specific, data-tier aware, and role-based. It should explicitly define which data classifications may enter which specific AI tiers, provide concrete code-exclusion examples, and establish clear approval workflows.
The 4 Principles of a Workable AI Policy
1. Classify by Data Sensitivity, Not Hype
Categorize your company’s data into clear sensitivity tiers (e.g., Public, Internal, Confidential, Restricted/PII). Define explicitly which AI tools and subscription tiers are permitted for each data level:
- Public Data: Allowed on approved consumer and enterprise AI tools.
- Internal / Non-Sensitive Code: Allowed on enterprise workspace seats governed by a DPA.
- Confidential / Customer PII: Allowed only on zero-data-retention (ZDR) enterprise APIs or isolated self-hosted models.
- Restricted (Cardholder Data / Keys): Strictly prohibited on all external cloud AI tools.
2. Differentiate Consumer vs Enterprise Tiers
State explicitly in the policy that personal accounts and individual paid subscriptions ($20/month plans) are prohibited for corporate data. As explained in our guide on free vs paid AI tools terms, individual plans operate under consumer terms that reserve data rights.
3. Require Human Code Review for AI Output
Mandate that all code generated or assisted by AI must undergo standard peer review, automated security scanning, and unit testing prior to merging into production. Specify that AI tools cannot serve as peer reviewers for compliance purposes (such as SOC 2 change management).
4. Provide Concrete Examples
Instead of abstract rules (“Protect trade secrets”), include specific real-world do’s and don’ts:
- DON’T: Paste
.envconfiguration files, customer payment logs, or unannounced product specs into a web chat. - DO: Use repository ignore files to exclude sensitive paths from editor context buffers. Read our guide on what your IDE extension sends that you didn’t type.
Ready-to-Use AI Acceptable Use Policy Template
# Corporate AI Acceptable Use Policy
## 1. Purpose & Scope
This policy governs the use of Artificial Intelligence (AI) tools, Large Language Models (LLMs), and coding assistants by all employees, contractors, and third parties operating on company systems or client projects.
## 2. Approved vs Prohibited Tools
- **Approved Tools**: Only AI tools listed in the Corporate Software Catalog operating under Enterprise Workspace accounts are authorized for company data.
- **Prohibited Tools**: Personal AI accounts, free consumer tiers, and individual credit-card subscriptions are strictly prohibited for company source code or confidential data.
## 3. Data Classification & Permitted AI Usage
| Data Classification | Consumer Free Tier | Enterprise Workspace Seat | Isolated / ZDR API |
|---|---|---|---|
| **Public Information** | Permitted | Permitted | Permitted |
| **Internal Documentation** | Prohibited | Permitted | Permitted |
| **Proprietary Source Code** | Prohibited | Permitted (with Ignore Rules) | Permitted |
| **Customer PII / Financial Data**| Prohibited | Prohibited | Permitted (with DPA & ZDR) |
| **Credentials & API Keys** | **STRICTLY PROHIBITED** | **STRICTLY PROHIBITED** | **STRICTLY PROHIBITED** |
## 4. Engineering & Code Generation Rules
1. **Mandatory Peer Review**: All AI-assisted code must be reviewed and approved by a human engineer before merging to production.
2. **Path Exclusions**: Developers must maintain repository ignore files excluding `.env`, credential, and state files from AI context indexers.
3. **Secret Protection**: Developers must utilize local pre-commit secret scanners.
## 5. Intellectual Property & Client NDAs
Employees working on client repositories subject to Non-Disclosure Agreements (NDAs) must verify that client contracts permit third-party SaaS processing before enabling AI assistants.
## 6. Incident Reporting
If an employee suspects credentials or sensitive personal data were inadvertently transmitted to an unapproved AI tool, they must notify Security immediately.Why policies get ignored, and what fixes it
The template above is the easy part. Almost every organisation has a document like it, and shadow AI persists anyway. The reasons are consistent and they are not about wording.
The approved path is slower than the unapproved one. If requesting a tool takes six weeks and the consumer version takes ninety seconds, the policy is competing against convenience and losing. The single most effective change available to most organisations is not a better-drafted rule; it is a lightweight approval route with a stated turnaround — days for low-risk uses, the full review reserved for tools touching regulated data.
The approved tool is worse. If the sanctioned assistant is materially less capable than the consumer one, people will use the consumer one and not mention it. This is a procurement decision masquerading as a compliance problem.
Nobody can find the policy. A document in a wiki nobody has opened since onboarding is not a control. The rules need to appear where the decision is made — in the tool request form, in the repository template, in the onboarding checklist.
Reporting a mistake is punished. If the consequence of admitting that a credential went into a chat window is disciplinary, the consequence is silence, and you lose the ability to rotate the credential. A policy that wants incidents reported must say, in writing, that self-reported accidental disclosure is not a disciplinary matter. This single sentence changes reporting rates more than any other.
It bans a category rather than naming the risk. “No AI tools” is unenforceable and treated as advisory from the day it is published, which teaches staff that the whole document is advisory.
Make it survive new tools
A policy organised around vendor names is obsolete within a quarter. Products launch continuously, and existing vendors you already approved add AI features in updates without asking.
The durable structure is the one in Principle 1 above: rules attached to data classes and processing conditions, not to product names. “Customer personal data may be processed only under a signed DPA with training disabled and retention under 30 days” is a rule that automatically covers a tool that does not exist yet. “Do not use ChatGPT” does not.
Keep the tool list in a separate, living catalogue referenced by the policy rather than embedded in it, so adding a tool does not require re-approving a policy document. The policy changes annually; the catalogue changes weekly.
Add one clause most policies lack: AI features appearing inside already-approved software must be assessed before enablement. This is the largest uncovered surface in most organisations, because the vendor is already approved, the domain is already allowlisted, and nothing triggers a review.
Sections worth adding to the template
Beyond the six in the template, four additions repeatedly earn their place.
Output accountability. State plainly that the employee who submits AI-assisted work is responsible for it. This covers hallucinated citations, fabricated figures, insecure code and plagiarised text in one sentence, and it removes the “the tool produced it” defence before anyone tries it.
Disclosure expectations. Where AI assistance must be disclosed — to clients, in regulatory submissions, in published work, in code review — and where it need not be. Ambiguity here creates genuine anxiety, and people resolve it by either over-disclosing or hiding usage.
Client and contractual constraints. Section 5 of the template gestures at this and it deserves expansion: some client contracts prohibit third-party processing outright, and the obligation to check sits with the person doing the work. Can you use AI coding tools under an NDA? covers the analysis.
Automated decisions about people. A hard rule that AI output must not be the sole basis for a decision with legal or similarly significant effect on an individual — hiring, termination, credit, access to a service — without a documented human review step and a DPIA. This is where the regulatory exposure is concentrated and where a one-line policy statement does real work.
Measuring whether it is working
A policy without a feedback loop is an assertion. Four signals tell you whether the document reflects reality:
- Time from tool request to decision. The variable that most directly controls shadow AI. Track it and publish it.
- Percentage of AI tool spend running through SSO. Corporate-card subscriptions outside SSO are the population your offboarding process cannot reach.
- Self-reported incidents per quarter. Counter-intuitively, zero is a bad number — it usually means people are not reporting rather than not erring.
- Findings from periodic discovery sweeps. Shadow AI: finding unapproved tools covers the four technical vectors, and the trend between sweeps is more informative than any single run.
Review the policy on a fixed cadence — annually at minimum, and after any material change to the tools in use or the vendors’ terms. Name an owner in the document. An unowned policy decays into a historical artefact that nobody will update and everybody will cite.
To align your policy with SOC 2 requirements, see our guide on AI tools in a SOC 2 audit, and GDPR lawful basis for AI tools at work for the legal analysis that should sit behind the data classification table.