Guide
An AI playbook somebody actually reads
Nine points, a three-basket model, and a list of what not to put in. The first version takes a day.
Contents (5)
In most organisations, AI use began without a decision. Somebody tried it, it worked, and within six months the tool was everywhere without anyone having set a policy. The first policy usually gets written only after something has happened.
A playbook is the cheap alternative. It is not a policy document and not an ethical declaration but a short answer to the questions people actually ask: may I use this, may I put this into it, who answers if it goes wrong. If it does not fit on two pages, nobody reads it, and then it steers nothing.
This article is a structure for one, written for an organisation that uses AI rather than building models.
The three-basket model
Start here, because it settles most everyday questions and needs no lawyer.
| Basket | Rule | Examples |
|---|---|---|
| Free | use it without asking | drafting, summarising, translating, brainstorming, a coding assistant, your own study |
| Considered | allowed, but a person answers for the result and the use is recorded | text going to a customer, analysis supporting a decision, classifying material, code going to production |
| Not without a decision | requires a separate decision | scoring or screening people, decisions about health or credit, inferring emotions, surveillance, putting confidential material into an external service |
Three baskets work because they answer the question a person has at the moment they are about to do something. A ten-page guideline does not answer it, because it never gets opened.
Note that the third basket is not the same as what the law forbids. Some of it is your own judgement, and some of it is the high-risk territory of the AI Act, where the use is permitted but takes considerably more than an experiment.
Nine points
1. What it may be used for. Three baskets and a few examples of each. The examples matter more than the definitions.
2. What may be put into it. Data classes stated plainly: public, internal, confidential, personal data, restricted. For each one, say whether it may go to an external service. This is the point people genuinely need every day.
3. Who decides on adoption. Tie the threshold to the consequence rather than the price: a tool for one person's own work is a different matter from a system that affects a customer or an employee. The latter is decided by a named person, not by the team itself.
4. Who answers for the result. Record it in one sentence: whoever publishes something answers for it, regardless of which tool made it. This removes most of the later arguments.
5. Transparency. When a customer is told they are dealing with a machine, and how artificial images or video are labelled. Since August 2026 these are also legal obligations, so this point can be written straight from the regulation.
6. Human oversight where it is required. Name the overseer by job title, say what they check, and give them the authority to reject. Record also that the number of rejections is monitored. If nobody ever rejects anything, the oversight is not working.
7. Handling an incident. What happens when there is an error, a data leak or a complaint: who is told, who investigates, within what time, and where it is recorded. One paragraph is enough, but it has to exist.
8. Induction. Who gets training, what it covers, and where it is recorded. Adequate AI literacy has been an obligation since February 2025, and recorded induction is the easiest way to show it.
9. Requirements on suppliers. What the contract has to contain before adoption:
- whether material you submit is used to train the model
- where the data is processed and stored
- how long logs are kept and who can see them
- whether subcontractors are used and where they are
- what happens to the data when the contract ends
- whether the supplier tells you in advance when the model changes
That last point catches people out. A service's model can change without notice, and then the results change too. If a process has been built on it, the change has to be noticed by some means other than a customer complaint.
What not to put in a playbook
- Model names. They go out of date in months and make the whole document look stale. Write about use cases and data classes instead.
- Technical detail. Interfaces and settings belong in an instruction manual, not in a policy.
- Prohibitions you cannot enforce. One of those only teaches people that the rules need not be followed. If you cannot enforce it, steer instead.
- An ethics declaration. "We use AI responsibly" steers nobody. Responsibility becomes visible through points 4, 6 and 7 or not at all.
- A blanket ban. It does not stop the use; it moves it out of sight, onto personal accounts and personal phones.
A first version in one day
Three steps that get you started without a project:
- Collect use cases, not tools. Ask the teams what they use AI for. The list is always longer than management expects, and it is the playbook's most important source material.
- Sort the list into three baskets. The disputed cases tell you what actually needs deciding. There are typically fewer than ten of them.
- Write two pages and set a review interval. Six months is a good one. The first version is not finished and does not need to be.
After that, measure one thing: does anybody use the playbook. If the same questions keep coming, the answer is either missing or written where nobody finds it.
In one sentence
A playbook is not a document you hide behind but a short answer to three questions people will ask anyway, and its value is measured by how many find the answer without asking anyone.
Harri Salomaa · Forty years in software, twenty of them in the United States and Germany: from collecting process data and analysing network data to immersive computing, and most recently AI.