A director at a housing association gets the AI policy back from legal: six pages, careful, and nobody reads it. At the team meeting she asks who knows what is in it. One of five team leads has opened it, and she still does not know whether the meeting tool her team uses is covered.
An AI policy people read fits on one page and consists of agreements you can follow without asking a second question. Below is such a page, with one sentence per agreement on why it is there. It is an example to copy from, not a legal template: a lawyer or the data protection officer reviews it before it is adopted.
What does a one-page policy look like?
Eight agreements. The text in brackets is yours to fill in.
1. We use AI through the tools on the list. The list lives at [location] and gives every tool a status: allowed, limited use, no decision yet, or not allowed. A limited tool comes with its condition, a rejected tool with its alternative. Why: a policy that names tools answers the question people ask. An attitude such as "careful" does not.
2. You use AI only through the account [organisation] has set up. A free or personal account is not a work environment, not even for an allowed tool. Why: the account type decides whether input is used for training, whether a data processing agreement exists, and whether anyone can set anything centrally.
3. These data go into no AI tool at all. National identification numbers, medical information, passwords and keys, tenant and applicant data, contracts and anything under a confidentiality obligation. Not even in an allowed tool with the right account. Why: the account governs what happens to data after it arrives. What you put in is up to you, and that moment happens only once.
4. If a tool is not on the list, its status is no decision yet. You put only public information into it and request an assessment from [role]. Why: without this agreement everyone guesses, and most people guess in favour of the work that has to get done.
5. [Role] assesses a new tool within [ten working days]. The assessment puts a fixed set of questions to the vendor and records the decision on the list with a date. The department that wants the tool owns it. Why: a route without a deadline is a ban with a detour.
6. Uploading a file, recording a meeting and letting an extension read along fall under the same agreements. Even when no chat window is involved. Why: one attachment holds more personal data than a month of prompts, and people do not recognise this as AI use on their own.
7. A decision lives where the tool is opened. When something changes, it changes there. The list takes precedence over this document. Why: an email about a changed decision is forgotten within a week. The tool is opened hundreds of times.
8. We look at which tools are opened, in counts, never at who typed what. That is how we see whether these agreements match the work. Why: without those figures the policy is an assumption. With a name attached it would be monitoring of people, and that is not the point.
Below that: the date of adoption, who owns the document, and when it is reviewed. That is the page.
What is deliberately left out?
Everything the team lead does not need at the moment she is looking for an answer. It belongs elsewhere, and you say where.
| Not on the page | Where it belongs |
|---|---|
| The list itself, tool by tool | The register or list agreement 1 points to, because it changes more often than the policy |
| Explanation of intent and of the risks | Training, and the conversation with the works council |
| The legal basis and the assessment per processing activity | The DPIA and the processing register |
| The questions the assessor puts to a vendor | A checklist of its own for [role] |
| What happens after a breach of the rules | The existing rules on handling information; an AI policy needs no sanctions of its own |
Put all of this on the page and you get legal's six pages back. Keep it apart and you are left with a policy that stays readable and a set of appendices that may grow.
Why does anyone read this one?
Because every agreement starts with what you do, not with what the organisation believes. The team lead looks up her meeting tool on the list (agreement 1), sees it is not there (agreement 4), and learns that recording counts too (agreement 6). Three sentences and she has an answer: internal meetings only for now, nothing sensitive, and request an assessment. She does not need to know by heart which data fall under agreement 3, because that list sits with the agreement.
The second thing that helps is that the policy has no second version of itself. Many organisations have a policy, an intranet page that summarises it, and an email from IT that says something slightly different. One page, and the list wins. Why the four statuses in agreement 1 work better than allowed and not allowed is explained separately.
What happens when the list falls behind?
A care organisation adopts this policy with a list of six tools. Four months later an inventory shows that, next to those six, people use a transcription tool, two translation tools and an AI feature inside the existing rostering software. None of the four is on the list. That is not a breach of the policy: agreement 4 says exactly what the status of those tools is. It does show that a list built from a survey falls behind as soon as it is finished, and that agreement 8 is what lets you notice.
BeeSensible links a catalogue of 865 AI tools to the tools that are opened in the organisation, in counts and without a user id. An admin sees which tools have no decision yet, records the decision with its condition or alternative, and that decision appears for the employee at the moment they open the tool. This is what that overview looks like:
