A director at a housing association gets the AI policy back from legal: six pages, carefully drafted, and nobody reads it. At the team meeting she asks who knows what is in it. One of her five team leads has opened it, and that team lead 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 rules you can follow without having to ask a follow-up question. Below is such a page, with one sentence per rule 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 rules. Fill in the text in square brackets yourself.
1. We use AI through the tools on the list. The list is kept at [location] and gives every tool a status: allowed, limited use, no decision yet or not allowed. A tool marked "Limited use" comes with its condition, and a tool that is not allowed with its alternative. Why: a policy that names tools answers the question people actually ask. A stance such as "be 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 determines whether input is used for training, whether there is a data processing agreement and whether anyone can manage settings centrally.
3. This information never goes into any AI tool. 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 once it arrives. What goes in is your decision, and you only get to make it 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 rule everyone guesses, and most people guess in favour of getting the work 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: an assessment process without a deadline is a ban by another name.
6. Uploading a file, recording a meeting and letting a browser extension read your pages are covered by the same rules. Even when there is no chat window involved. Why: one attachment holds more personal data than a month of prompts, and people do not naturally see this as AI use.
7. A decision is shown 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 rules match the work. Why: without those figures the policy is an assumption. With names attached it would be monitoring people, and that is not the aim.
Below that: the date of adoption, who owns the document and when it will be reviewed. That is the whole page.
What is deliberately left out?
Everything the team lead does not need when she is looking for an answer. It belongs elsewhere, and the page says where.
| Not on the page | Where it belongs |
|---|---|
| The list itself, tool by tool | The register or list that rule 1 points to, because it changes more often than the policy |
| The reasoning and the risks | Training, and the discussion with the works council |
| The legal basis and the assessment for each processing activity | The DPIA and the record of processing activities |
| The questions the assessor puts to a vendor | A separate checklist for [role] |
| What happens when the rules are broken | The existing rules on information handling; 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 separate and you have a policy that stays readable, plus a set of appendices that is free to grow.
Why do people read this one?
Because every rule starts with what you do, not with what the organisation believes. The team lead looks up her meeting tool on the list (rule 1), sees it is not there (rule 4) and learns that recording counts too (rule 6). Three sentences and she has her answer: internal meetings only for now, nothing sensitive and ask for an assessment. She does not need to memorise which data falls under rule 3, because that list sits right there in the rule.
The second thing that helps is that there is only one version of the policy. Many organisations have a policy, an intranet page summarising it and an email from IT that says something slightly different. Here there is one page, and the list takes precedence. A separate piece explains why the four statuses in rule 1 work better than a simple "Allowed" or "Not allowed".
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, besides those six, people are using 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: rule 4 says exactly what status those tools have. It does show that a list built from a survey is out of date as soon as it is finished, and that rule 8 is what lets you notice.
BeeSensible links a catalogue of over 1,000 AI tools to the tools people open in the organisation, in counts and without a user ID. An administrator sees which tools have no decision yet and records the decision with its condition or alternative; the employee then sees that decision when they open the tool. This is what that overview looks like:
