Key takeaways
- If it cannot be read in three minutes and applied without asking, it is decoration.
- Name tasks, not principles. "Use judgement with confidential data" is not a rule anyone can follow.
- Traffic lights beat prose: green tasks, amber tasks needing a check, red tasks that are off limits.
- A policy without a configured tool is a request to keep doing the risky thing more quietly.
Most AI usage policies are written to satisfy a risk register rather than to guide a person at their desk. They open with definitions, run to nine pages, and conclude that employees should exercise appropriate care. Everyone acknowledges receipt. Nobody's behaviour changes, because nothing in the document told anyone what to do differently on Tuesday.
A policy that works has a different job. It has to answer, quickly and specifically, the question a person actually has: can I put this thing into that tool for this purpose?
The eight decisions your policy has to make
Before drafting a word, settle these. A policy is really just the written form of eight decisions, and most drafts fail because two or three of them were never actually made.
- Which tools are approved. Named, specifically. Not "enterprise-grade AI tools" but the actual product and tier.
- What information may go in. Framed in your own categories, so people can classify what is in front of them.
- Which tasks are encouraged. The most commonly missed section, and the one that drives adoption.
- Which tasks are prohibited. Short and absolute, with no interpretation required.
- When AI involvement must be disclosed. To clients, in published work, or internally.
- Who checks the output. The answer is always a person, and the policy should say which one.
- What happens with personal accounts. Whether they are permitted for anything work-related, and the answer is usually no.
- Who to ask. A named role for the cases the policy does not cover, because there will always be some.
The traffic light method
The single most effective structural choice is to classify tasks rather than describe principles. Three lists, in your own vocabulary, using your own work.
| Category | Meaning | Example entries |
|---|---|---|
| Green | Go ahead, no approval needed, no disclosure needed | Drafting internal emails, summarising your own meeting notes, rewriting text for clarity, brainstorming, explaining an unfamiliar concept, formatting or restructuring documents you already have. |
| Amber | Allowed in the approved tool, with a named check before it goes anywhere | Client-facing drafts, anything containing figures, summarising a contract, first drafts of published content, anything where being wrong would be visible externally. |
| Red | Not permitted, in any tool | Personal or health information about staff or customers, credentials, material covered by client contracts that forbid third-party processing, and final decisions about people such as hiring or discipline. |
Write these lists using tasks your people genuinely do. A generic list gets skimmed; a list containing "the Thursday client update" gets read, because it is obviously about them.
The green list is not a courtesy. It is the part that produces adoption. A policy that only prohibits reads as a warning, and warnings suppress the safe uses as effectively as the unsafe ones. Explicit permission is what gives a cautious employee confidence to start.
Write for the person, not the auditor
Two versions can coexist. A one-page operational policy that staff read and follow, and a longer control document for audit, insurance and client due diligence. Problems start when the second is handed to staff as though it were the first.
Some concrete language tests for the staff-facing version:
- Replace "exercise appropriate judgement" with the actual judgement. If you cannot state it, you have not made the decision yet.
- Replace "sensitive information" with your own categories, named. People cannot apply a classification scheme they have never seen.
- Replace "AI systems" with the product names. Vagueness here is read as permission to use anything.
- Replace "should ensure" with "must", or delete the line. Soft verbs signal that the rule is optional.
- If a sentence would not change anyone's behaviour, cut it. Length is the main reason policies go unread.
The accountability clause
One principle deserves its own line, in plain words: the person who sends it owns it. AI assistance does not transfer responsibility for accuracy, tone, confidentiality or professional obligations. If a figure is wrong in a client report, the accountability sits exactly where it always did.
This is worth stating explicitly because it resolves most edge cases without further rules. It also reframes checking from bureaucratic overhead into ordinary professional practice, which is a much easier sell than a compliance step.
Disclosure, handled proportionately
Disclosure rules go wrong in both directions. Requiring a declaration on every email that touched an assistant is unworkable and will simply be ignored. Requiring none at all can breach client expectations or professional standards.
A proportionate default: disclosure is not required for drafting assistance where a person has reviewed and taken ownership of the output, and is required where a client contract demands it, where a professional body requires it, or where the output is presented as independent analysis. Then check whether your specific sector has stricter rules, because several do.
Rollout matters as much as drafting
A policy emailed as an attachment achieves compliance theatre. A policy introduced alongside a working, configured tool achieves behaviour change. The sequence that works:
- Configure the approved tool first, so the policy describes a reality rather than an intention.
- Run a short session per team where the traffic lights are applied to that team's actual work.
- Put the one-pager where the work happens, in the intranet or wiki people already open, not only in a document management system.
- Include it in induction from day one, so new starters never form unofficial habits.
- Review it every six months. This category moves, and a policy that names a tool you no longer use is worse than none.
A reliable signal that your policy is working: people start asking specific amber questions, such as whether a particular client's material is in scope. Silence usually means it was never read.
Frequently asked questions
How long should an AI usage policy be?
One page for staff, readable in three minutes and applicable without asking anyone. Keep longer detail in a separate control document for audit and client due diligence.
What should it cover?
Approved tools by name, what information may go into them, encouraged tasks, prohibited tasks, when disclosure is required, who is accountable for the output, whether personal accounts are permitted, and who to ask when the policy is silent.
Do small businesses need one?
Yes, and short is fine. If you handle client information under contract, obligations about where that information is processed apply regardless of headcount, and a one-pager plus a properly configured tool covers most of it.
Should the policy name specific tools?
Yes. Generic wording is read as permission to use anything. Name the approved product and tier, and commit to reviewing the list every six months.
Policy plus the setup that makes it real
The Implementation Package includes an organisation rollout plan and a plain-English how-to guide for staff, alongside the provider configuration, admin controls and spending limits that make a policy enforceable rather than aspirational.