Writing an AI policy your team will actually follow

why most AI policies fail

The failure modes are consistent, and each points at its own fix. Policies are too long: a twelve-page document covering every edge case reads like a legal contract, so people sign it and forget it, and nobody consults a twelve-page document before pasting a paragraph into a chat window. They are vague: "use AI responsibly" and "do not share sensitive information" push the hard decision back onto the employee at the exact moment they cannot make it well, because a vague policy decides nothing. They are built on fear: a tone that is mostly warning teaches that AI is dangerous and you will get in trouble for using it, which is a poor lesson because the tools are genuinely useful and people know it. And they are ban-first: blocking the consumer tools does not make them less useful, so people keep using them and stop telling you, and you lose the visibility you would have needed to govern. The pattern underneath all four is the same: the policy is written to protect the company from its own people rather than to help its people work safely. A policy that works inverts each of these: short instead of long, specific instead of vague, enabling instead of fearful, tool-naming instead of ban-first.

the principles of a workable policy

Five principles sit under a policy people follow. Enable within guardrails: start from the assumption that AI use is good and that the job is to make it safe, so the policy opens with permission, then sets the rails. Classify data, so the rules are about data, not mood: replace "use good judgment about sensitive data" with a small, named set of data classes and a clear rule for each, because specificity is what makes a policy followable, and this is the heart of the whole document. Name approved tools and give a fast way to request new ones: list the tools, the plan tier where it matters, and the path to request one not on the list, because requests that vanish into a queue are exactly what drive people to skip the process. Make the rules memorable: the data rules in particular should be short enough that a person carries them in their head, because a rule nobody can recall at the keyboard is not a control. And set realistic enforcement: a large share of AI use happens on personal accounts that leave no trace your tooling can pick up, so the policy plus sensible guardrails plus a short literacy effort are what carry the channels you cannot monitor, and the control is a rule people understand and a sanctioned tool they would rather use, not a wall you imagine you can build.

the structure of a good AI policy, section by section

This is the part you can write from directly. Eight sections, each short. A good policy of this kind fits comfortably on two to three pages, and if a section grows past a few short paragraphs, you are probably writing a reference document rather than a policy people will follow.

1. Purpose and scope. Two or three sentences. State why the policy exists and who it covers. Say plainly that the company supports the use of AI for work and that this policy sets out how to do it safely. Define scope: who it applies to, such as all employees and contractors, and what it covers, such as all AI tools used for company work, whether company-provided or not. That last line closes the gap where someone assumes their personal account is outside the rules.

2. The core principle. One short paragraph that sets the tone for everything after it. Something close to: AI tools can help us work faster and better, and we want people to use them; the rules below exist so that we get that benefit without putting customer data, confidential information, or the company at risk. This single paragraph frames every rule that follows as a condition on a permission rather than a prohibition.

3. Data classification rules for AI. This is the heart of the policy. Define a small set of data classes and state, for each, what kind of tool it may go into. A workable scheme has four. Public: information already published or cleared for release, marketing copy, public web content, may go into any AI tool. Internal: day-to-day work that is not secret but not public, internal drafts and non-sensitive project material, may go into approved AI tools on the company's approved plans. Confidential: material that would cause harm if it leaked, unreleased financials, strategy and roadmaps, source code, anything under an NDA, only approved enterprise-tier tools with training disabled and a data processing agreement in place, named specifically. Regulated: personal data under GDPR and any data carrying specific legal handling requirements, customer records, employee data, health or financial data about individuals, into a tool only where a DPA is in place and the use has been reviewed, with the safe default for most teams being that regulated data does not go into general AI tools at all. Write the rule for each class in one line with one or two concrete examples, because "do not paste customer email addresses or support tickets containing personal data into a consumer AI tool" lands in a way that "handle regulated data appropriately" never will. If you keep one thing tight in the whole policy, keep this.

4. Approved tools and the request path. List the AI tools approved for work, noting the plan tier where it changes the data rules, since an enterprise plan with training switched off and a DPA available handles more than a free consumer account that trains on inputs. Then name the request path for tools not on the list: who receives the request, how someone submits it, and how fast they will get an answer, with a real number on the turnaround. A path that promises a response within a few working days is one people will use. Treat the list as living, reviewed on a cadence, with the current version in a named place people can find.

5. Clear do's and don'ts in plain language. A short, scannable list, the section people actually glance at in the moment. The do's read like permissions: use approved tools for drafting, summarizing, and research; check AI output before you rely on it; ask if you are unsure which data class something falls into. The don'ts read like bright lines: do not paste regulated or confidential data into tools not approved for it; do not connect AI tools to company systems without review; do not assume a tool keeps your data private because it feels private. Keep the whole list short enough to read in under a minute.

6. Connectors and access. One line, but an important one. State that AI tools requesting access to company systems go through review before anyone grants them. This covers the case the data-classification rules miss: an employee clicks "approve" on an OAuth screen and an AI tool gains standing read access to mail, files, or calendars, a grant that persists long after the trial ends and is a data path whether or not anyone is using the tool today. Name who runs that review. This is the rule that keeps connectors from becoming the quiet back door around everything else in the policy.

7. Roles, ownership, and review cadence. A policy with no owner drifts out of date within a quarter, because AI tools and their terms change quickly. Name one owner for the policy, the approved-tools list, and the request path, usually the Head of IT or the CTO directly. State the review cadence: quarterly is a practical rhythm for active teams, annual is the floor, and vendor term changes and new tools are reviewed at each cycle.

8. Consequences, stated calmly. Say what happens if the rules are not followed, in a measured tone, without threat. State that the policy is a condition of working with company data, that breaches are handled through the normal channels, and that the focus is on getting things right rather than catching people out. A calm consequences section reinforces the enabling tone; a heavy one undoes it and pushes people back toward hiding their AI use. Encourage people to report a mistake early, because a team that tells you when something went into the wrong tool is worth far more than one that stays quiet.

how to roll it out so it sticks

A written policy that lands in an inbox and is never mentioned again has the same effect as no policy. Three things turn a document into a practice. A short training, not a course but a fifteen-minute session or a short written briefing that walks through the four data classes and the reasons behind them, because people follow a rule they understand far better than one they only obey; "do not paste personal data into consumer AI tools" sticks when it comes with the reason that the data ends up somewhere you cannot retrieve it from and the company carries the legal exposure. A one-page summary, the four data classes with examples, the approved-tools list, the do's and don'ts, and the request link, pinned where people work; this one page is the policy as far as daily behavior is concerned, and the rest is reference. And a request path that is genuinely fast, the part most often neglected and most important, because if asking for a new tool is slow or silent, people stop asking and go around you, and the whole policy quietly fails. The briefing is also the documented literacy measure the EU AI Act expects.

a note on the EU AI Act

This is context, not the reason to write a policy. The EU AI Act places an AI-literacy duty on deployers, meaning organizations that use AI in a professional context, under Article 4, which has applied since 2 February 2025. A written acceptable-use policy combined with a short training or briefing is a practical part of meeting that duty, and it is the kind of documented measure a proportionate response for a mid-market company looks like. You are writing the policy because it makes AI use safer and faster; meeting part of the Article 4 obligation is a useful side effect.