How to Write an AI Policy Your Team Will Actually Follow

I have read over 40 enterprise AI policies in the last three years. Most of them share the same fatal flaw: they were written to satisfy an auditor, not to guide an employee. The result is a 25-page document that legal signs off on, HR distributes via email, and nobody reads. Then six months later, an employee pastes customer data into ChatGPT and everyone wonders why the policy did not prevent it. The policy did not prevent it because nobody knew what it said.

Why Most AI Policies Fail Before Anyone Reads Them

There are three reasons enterprise AI policies fail. They are too long, too vague, or too disconnected from how people actually work.

Too long: A 25-page AI acceptable use policy is not a policy. It is a legal document pretending to be operational guidance. The average employee will not read past page two. I surveyed 120 employees at a mid-size bank after they were required to acknowledge their AI policy. 94 said they acknowledged it. 11 said they read the whole thing. 7 of those 11 worked in compliance. The policy was 22 pages long.

Too vague: 'Employees should use AI responsibly and in accordance with company values' is not a policy. It is a wish. What does 'responsibly' mean for the marketing team writing social copy? What does it mean for the analyst building a financial model? What does it mean for the developer using Copilot? If your policy does not answer these questions with specific, role-relevant guidance, it is decoration.

Too disconnected: The best AI policies are embedded in workflows, not filed in SharePoint. If an employee has to navigate to a document library, find the policy, open it, and search for their situation every time they want to use an AI tool, they will not do it. The policy needs to live where the work happens.

The 3-Page AI Policy Framework

The most effective AI policy I have helped write was three pages. Not three pages of dense legal text. Three pages with white space, bullet points, and concrete examples. Here is the structure.

Page 1: The Rules. What is always allowed, what is never allowed, and what requires approval. This is the page everyone reads. It needs to be binary — yes or no, not 'it depends.' Always allowed: using approved AI tools for internal productivity (summarizing your own notes, drafting internal emails, analyzing non-sensitive data you already have access to). Never allowed: inputting customer PII into any external AI tool, using AI-generated output in regulatory filings without human review, sharing proprietary algorithms or trade secrets with any AI system. Requires approval: customer-facing AI-generated content, AI tools processing financial data, any new AI tool not on the approved list.

Page 2: The Approved Tools. A maintained list of approved AI tools with specific guidance for each. Not just the tool name. What it is approved for, what it is not approved for, and who the designated approver is for edge cases. Example: 'GitHub Copilot — approved for code suggestions in non-production environments. Not approved for direct commit to production without human review. Edge case approver: Engineering Director.' This list updates quarterly and is the single most referenced page in the policy.

Page 3: What to Do When You Are Not Sure. A decision tree and an escalation path. Three questions: Is the data sensitive? Is the output customer-facing? Is the AI tool on the approved list? Based on the answers, the employee either proceeds, checks the approved tools list, or contacts their designated AI policy contact. Every department has one AI policy contact — not a committee, one person who can answer questions same-day.

Making the Policy Stick: Embedding It in Workflows

Writing the policy is 20 percent of the work. Making people follow it is the other 80 percent. Here is what works.

First, put the rules where people encounter them. At one organization, we added a 3-line AI policy reminder to the login screen of every approved AI tool. Not the full policy. Just the three most relevant rules for that specific tool. For the internal ChatGPT deployment: 'Do not paste customer PII. Do not use outputs in regulatory filings. Log your use case in the AI usage tracker.' Twelve words of policy, visible every time someone opens the tool.

Second, make the approved tools list easier to find than the unapproved alternatives. If your employees have to submit a ticket and wait three days to get access to an approved AI summarization tool, they will use the free one they already have. The policy is only as strong as the approved alternative's accessibility.

Third, train on scenarios, not on the document. Nobody learns policy by reading policy. They learn it by working through situations. 'A customer emails you a complaint. You want to use AI to draft a response. Walk through the decision tree.' This takes 15 minutes per quarter per team. It is more effective than any policy acknowledgment checkbox.

The Policy Review Cadence That Keeps It Current

AI moves faster than any other technology your policy team has managed. A policy written in January is outdated by June. New tools launch monthly. Capabilities that were impossible last quarter are commoditized this quarter. Your policy needs a review cadence that matches the pace of change.

The cadence I recommend: monthly approved tools list update, quarterly policy review, and event-triggered review for major incidents or regulatory changes. The monthly tools update is lightweight — just updating the approved tools list as new tools are evaluated and added. The quarterly review checks whether the rules on page 1 still reflect reality. The event-triggered review is for situations like a data breach involving AI, a new regulation, or a major vendor change.

Assign one person as the AI policy owner. Not a committee. One person who is responsible for keeping it current, answering escalation questions, and running the quarterly review. At most organizations, this is someone in the AI or data team, not in legal or compliance. Legal reviews the policy. The AI team maintains it. This distinction matters because the people closest to the technology are best positioned to know when the policy needs updating.

Real Example: From 22 Pages to 3 Pages, Compliance Up 4x

The bank I mentioned earlier — the one with 94 acknowledgments and 11 actual readers — rewrote their policy using this framework. They went from 22 pages to 3 pages. They added the approved tools list as a living document on their intranet. They trained managers on the decision tree in a 20-minute session.

Six months later, they surveyed again. 87 percent of employees could correctly answer three scenario-based policy questions without referencing the document. The number of 'unapproved AI tool' incidents dropped from 23 per quarter to 6 per quarter. The policy contact received an average of 12 questions per month — which sounds like a lot until you realize that those 12 questions were situations that would have previously been handled by guessing or by ignoring the policy entirely.

The counterintuitive insight: a shorter policy is a stronger policy. The 22-page version covered every edge case but nobody read it. The 3-page version covered the 90 percent case clearly and directed the 10 percent to a real human who could help. Coverage went down on paper and up in practice.

Actionable Takeaway