Ask five people in your company what the rules are for using language models and image generators at work, and you will get five answers. The most common one is some version of "be sensible." That phrase has never stopped anyone from pasting a client contract into a chat window at 4:45 on a Friday. A usage policy is not a statement of values. It is a set of decisions made in advance, so that nobody has to guess under deadline pressure. Most drafts fail in the same handful of ways, and most of those failures are easy to spot once you know what to look for.
1. Describing the tool instead of the behavior
"Use AI responsibly" and "only approved tools may be used" sound authoritative. Neither tells a reader whether a specific action is allowed. That is the only test that matters: can someone check their own plan against your sentence and get a yes or a no?
Rules written as behaviors pass that test. "Customer contracts, personal data, and anything marked internal may not be entered into an external tool" is checkable. "Employees should be careful with sensitive information" is not. When you review a draft, read each line and ask what the violation would look like. If you cannot picture it, rewrite the line.
2. Treating a birthday message and a legal filing the same way
A single rule for every task forces people into one of two bad habits: over-asking for trivial things, or under-asking for serious ones. Use tiers instead. Three is plenty.
- Low risk: brainstorming, formatting, summarizing your own notes. Use freely, no sign-off.
- Medium risk: anything a client, candidate, or customer will see. A named human reviews and edits before it leaves the building.
- High risk: output that informs decisions about people, money, legal positions, or regulated data. Requires approval and a record of what was checked.
Fewer than three tiers is too blunt. More than five will not be remembered.
3. No owner, no inbox, no answer
If the policy says "get approval first" but never says from whom or how quickly, people will do the faster thing. Name a role, not just a person, plus a backup for holidays. Commit to a response window — two business days is a reasonable promise. Then publish the answers to common questions so the same request is not resolved five separate times by five separate managers.
4. Skipping the unglamorous clauses
The interesting half of a policy is the list of things people may do. The half that protects the company is duller, and it is usually missing.
- Data: which categories may be entered into which tools, and what never leaves the company under any circumstances.
- Retention: where outputs live, how long they stay, and who can find them later.
- Vendors: who checks the contract, the training-on-your-data settings, and the subprocessors before a tool is approved.
- Review: which outputs need a human read before they go out, and whose name goes on the sign-off.
- Disclosure: when clients, applicants, or readers need to be told a tool was involved.
- Accountability: what happens when someone ignores the rules. If the answer is "nothing," the rest is decoration.
Some of these clauses touch legal obligations that differ by industry and jurisdiction. Have a lawyer who knows your sector read the draft before it goes live. A policy explains how you work; it does not replace professional advice.
5. Naming products instead of categories
A policy that lists three approved products is out of date the moment a tool changes its name, pricing, or data terms. Describe categories of use in the policy itself, then keep the approved-tool register somewhere it can be edited by one accountable owner. Employees only need two things from that register: whether a tool is approved, and what data it may touch.
6. Publishing the policy and calling it done
A wiki page is not a control. New hires need this in their first week, not their fourth month. Teams need examples drawn from their own work — the examples that make sense to a marketer will not land with an engineer. A short session where people bring real tasks and check them against the policy teaches more than a slide deck ever will. Fifteen minutes a quarter is enough, provided it actually happens.
7. Never revisiting it
Put a review date on the cover page and honor it. Watch the questions that arrive in the approval inbox: anything asked repeatedly is a clause that needs rewriting, not a person who needs retraining. Keep a changelog so readers can see what moved and when. And when something does go wrong, treat it as information about the policy first and the individual second. Systems that punish questions teach people to stop asking them.
A practical path to a draft people will follow
You do not need a perfect policy to start. You need one that is written down, short enough to read aloud in five minutes, and specific enough to settle an argument.
- List the five tasks your teams most want help with. Write down what data each one involves.
- Sort those tasks into low, medium, and high risk. Most will land in the first two tiers.
- Draft each rule as a behavior with a clear yes or no.
- Name one owner, a backup, and a response window for approvals.
- Pilot with one team for two weeks. Note every question they ask.
- Revise, publish, and set a review date six months out.
A decent second version in a month beats a flawless first version next year. Keep the document honest about what it does not cover, tell people where to ask, and update it when the answers change.
Photo: chris_muschard / Pixabay
