Lesson 4 of 8 · 9 min read · last verified 2026-10-15
Write the rules down
In this lesson you will:
- Write a one-page acceptable-use note that people will actually read
- Avoid a ban that drives use out of sight
Once more than one person uses a tool, you need agreement about how. Left unwritten, the rules are whatever each person guesses, and the guesses differ.
The aim is a page short enough that people read it, specific enough that they can follow it, and honest enough that they trust it.
Why not a ban
The reflex, when something feels risky, is to prohibit it.
A flat ban on using AI tools at work is common, and it tends to produce the situation it fears. People who find the tools useful keep using them, on personal accounts, from phones, without telling anyone. This is shadow use, and it has every risk of the sanctioned version plus an additional one: you cannot see it, advise on it, or protect anyone from it.
A ban also removes the one thing a policy can do, which is to steer. Someone who knows what is acceptable can stay inside it. Someone told “never” has nothing to steer by.
That is not an argument for permitting everything. It is an argument for being specific about what is and is not fine.
A page, with five parts
Aim for one page. If it needs two, the second is probably unread.
1. What is approved
Name the tools and, as P8·L4 explained, the plan. It matters whether a tool is the business version or a free personal account, because the data terms can differ sharply. “Use the company account, not a personal one” can be the most protective line on the page.
If you have not chosen, say so and say how to ask.
2. What may go in, and what may not
Concrete, with examples from your own data.
Fine: public information, your own drafts, anonymised or invented examples, published documents.
Not without checking first: anything with a customer’s name, a colleague’s details, unreleased figures.
Never: passwords or keys, personal data of the kind in the HR folder, anything under an agreement that forbids sharing.
Short lists of examples beat principles. P8·L3 covers why: what is sent leaves your control.
3. What needs a person
Say which outputs must be checked by someone before they go further. A message to a customer. A number in a report. Anything legal, medical or financial. Anything that affects a person’s job, pay or access.
State it as a rule about the work and not about the tool: “A human reads every message before it is sent” holds whatever the tool is.
4. Who is accountable
The person who uses the tool and sends the result is accountable for it.
“The tool wrote it” is not an answer to a customer, a colleague or a regulator. Saying so plainly, in advance, protects people more than it threatens them, because it removes the ambiguity about who owns a mistake.
5. Where to ask
A named person or channel for questions, and a promise not to punish good-faith asking. If people cannot ask safely, they will guess, and the guesses are where the problems start.
Disclosure
Decide and state whether work needs to say it was made with a tool.
There is no universal answer. Some contexts require it, such as a course that forbids undisclosed assistance or a publisher with a policy. Others do not. Explorer E8·L2 covers the reasoning. What matters for the page is that people are not left to work it out under pressure. State what is expected, and for what kinds of work.
Make it findable and short-lived
Put it where people will see it. In the tool, in the team space, in the onboarding pack. A policy in a folder is a policy nobody has read.
Date it, and say when it will be reviewed. Rules about a fast-moving subject age. A review date, three or six months out, signals that it is expected to change and gives people a reason to look again.
Change it in public. When the rules change, say what changed and why. P9·L7 returns to this.
Lrnon’s version
The project publishes its principles openly, and several are in the form this lesson recommends: specific, with the mechanism behind each.
The brand guide lists, among the things Lrnon never does, accepting payment for coverage, ranking tools by anything but stated criteria, and quietly amending a claim that turned out to be wrong. Each is a rule about the work and not about a tool, each is checkable, and there is a stated escalation: content corrections are fixed and published, anything touching neutrality or funding is decided by the founder and recorded.
It is a small project and the format scales down well. A short page with specific rules and a named person to ask is within reach of a team of three.
Try it now (25 minutes)
Draft the page for your team. Five headings, a few lines each. Use real examples from your own data in the “may go in” section.
Then hand it to someone who was not involved and ask them to tell you, in their own words, what they would do in three situations: pasting a customer email, using a personal account, and sending a drafted message. Where their answer differs from your intent, the page is unclear.
Check your understanding
Recap
Write one page that people will read. Avoid a flat ban, which drives use out of sight. Cover five things: which tools and plans are approved, what may and may not go in with real examples, what a person must check, who is accountable, and where to ask without being punished. Decide what disclosure is expected, put the page where people see it, date it and review it. Rules about a fast-moving subject age, so say when they will be looked at again.
🗂 3 flashcards from this lesson join your daily review.
Previous: Teach judgement, not buttons · Next: Fear, status and fair objections