Most corporate AI policies fail at the same point: they are written by people who have to protect the organisation, for people who just want to know whether they can paste a client email into ChatGPT.
The document is thorough, legally sound, eleven pages long, and nobody reads it. Meanwhile half the team is already using AI on personal accounts, which is the exact situation the policy was meant to prevent.
Here is the version that works, and the reasoning behind each part.
The traffic light model
Almost everything people need to know fits into three categories they can hold in their head.
Green: use freely. Public information, general knowledge, your own drafting and thinking, anything that could appear in a public blog post without consequence. No approval needed. Most work is green, and saying so explicitly matters, because a policy that sounds uniformly restrictive gets ignored in all categories.
Amber: approved tools only. Internal information that is not public but is not sensitive. Internal documents, project plans, non-identifiable data, draft materials. Fine to use, but only in the accounts the company pays for, never in a personal login.
Red: never, in any tool. The list that depends on your sector and contracts. Typically customer personal data, financial records tied to identifiable people, credentials and keys, unreleased financials, privileged legal matters, and anything under a client NDA.
People remember three colours. They do not remember eleven pages.
The one page template
Copy this, fill in the bracketed parts, and have whoever owns risk at your company check the red list against your actual contracts and sector obligations.
[Company name] AI Usage Policy Last updated: [date]. Owner: [name, role]. Questions: [name or channel].
The short version. You are encouraged to use AI tools for your work. Use company accounts, not personal ones. Never put the red list into any AI tool. Check anything before it goes to a customer.
Approved tools. [List them. Include the account type, for example "ChatGPT Business, company SSO login".] Anything not on this list needs a quick word with [owner] before use on work material.
Green, use freely. Public information, general research, your own drafting, brainstorming, code you would be comfortable making public, anything that could appear publicly without consequence.
Amber, approved tools only. Internal documents, project plans, meeting notes, non-identifiable operational data, draft materials, internal code. Company accounts only, never personal logins.
Red, never in any AI tool. [Customer personal data. Financial records tied to identifiable individuals. Credentials, API keys, passwords. Unreleased financial results. Matters under legal privilege. Anything covered by a client NDA. Add your sector specific items.]
Before anything leaves the building. AI output going to a customer, a regulator, or the public gets reviewed by a human who is accountable for it. The reviewer is responsible for the content, the same as if they had written it.
Disclosure. [State your position. For example: we do not require disclosure for AI assisted internal drafting. We do require it for [specific cases].]
If something goes wrong. Tell [owner or channel] immediately. Nobody is in trouble for reporting a mistake quickly. This matters more than the rest of this document.
Why the last line matters most
Teams that have no rules do not become careful. They become quiet.
If an employee pastes something they should not have into a public tool, the outcome you want is that you hear about it within the hour. That only happens if reporting is genuinely consequence free, and if leadership has said so out loud rather than just written it.
Every policy I have seen work has had a version of that line, and the companies where it is credible are the ones where the first reported incident was handled well and visibly.
Five mistakes to avoid
Writing it after the training. Rules introduced before anyone has touched a tool land as sensible guardrails. The same rules at the end of a build day land as a legal afterthought.
Blocking instead of governing. Blocking produces identical usage on personal phones with zero visibility. You have not removed the risk, you have removed your view of it.
Making everything amber. If the policy makes routine work feel restricted, people stop consulting it entirely, including for the red items. Be generous with green.
No named owner. A policy with no name on it has nobody to ask, so people guess.
Never updating it. The tools change fast. Put a review date on it, quarterly is sensible, and change the approved tool list as your stack changes.
Where this sits in a rollout
The policy conversation belongs in the first 90 minutes of a training day, right after the shared foundation and before anyone opens a tool. Fifteen minutes is usually enough if the document is one page.
Doing it there has a useful side effect. People ask the awkward questions in a room with a facilitator and their colleagues, which surfaces the genuine edge cases in your business far better than a review cycle over email ever will. In several sessions the red list has been materially improved by someone in finance or legal raising a case nobody had thought about.
Then at the end of the day, once everyone has built something real, you agree the final version and it goes out. Written by the people who have to follow it, which is the only version anybody follows.