On a Tuesday afternoon, a team leader at an insurer gets a question from someone in her team: can I use this transcription tool for a customer call? The AI policy was adopted last quarter: four pages, reviewed by legal. She looks it up, reads it twice and still does not know. It says something about handling data carefully and about Copilot being the preferred tool. It says nothing about this tool.
That is when an AI policy either works or does not. Not when it is adopted, but when a specific question comes up on an ordinary working day. So if you are writing an AI policy, do not start with the document. Start with the questions the document has to answer. If the answers are in there, the policy is usable. If they are not, the question gets answered in the corridor, and then it is not the policy that decides but whoever sounds most confident.
Why not start with the policy document?
Most AI policies begin life as a template. The template describes an attitude: responsible, transparent, in line with the GDPR. All of that is true and none of it helps, because an attitude does not tell you whether this particular tool may be used for this particular customer call.
There is a second problem with the template approach. A template describes the AI use its author had in mind, usually a chatbot someone types text into. The AI use that actually happens in the organisation looks different: a meeting tool that summarises, a PDF reader with an assistant, a browser extension that rewrites emails. No template takes a position on those, because a template cannot know which tools your people open. Our introduction to shadow AI describes what that use looks like.
So work the other way round. First the questions, then the answers, and only then the document that brings them together.
Which questions does an AI policy have to answer?
Eight. They sound simple, and that is the point: someone should be able to act on the answer without asking a second question.
| Question | What a usable answer looks like |
|---|---|
| Which tools do we allow? | A list of names with the account type, because ChatGPT on a business account is a different tool from ChatGPT on a free one |
| For what kind of work? | For each tool, the tasks that fit (translation, code, summarising public text) and the tasks that do not (customer correspondence, personnel files) |
| Under which conditions? | One sentence someone can follow: business account only, no personal data, internal use only |
| Which data may go in? | Categories with examples, from a national ID number and a diagnosis to a customer name in an email, plus a rule of thumb for borderline cases |
| Who assesses a new tool? | A role, a deadline and the questions the assessment covers |
| What does someone do with a tool that has no decision? | A procedure: where to request the assessment, and what may and may not go into the tool in the meantime |
| How do people hear about a change? | More than an email, which is forgotten within a week; the decision belongs where the tool is opened |
| How do we know whether policy and practice match? | A comparison of the list in the policy with the tools people actually open, in counts, without names |
The first four questions appear in almost every policy, even if the answers tend to be too general. The last four are usually missing, and those are exactly the questions that decide whether the policy still holds up six months later.
For the question of which data may go in, there is no need to invent anything new. Our article on what you can and cannot put in an AI prompt lists what never belongs in a prompt and what usually does. Adopt that list and add examples from your own work.
What do you write about a tool with no decision?
This is where the team leader got stuck. Her policy had only two options, allowed and not allowed, and the transcription tool fitted neither. At that point an employee guesses, and most people guess in favour of the work that has to get done.
A usable policy gives that situation a name of its own: "No decision yet". Every tool that has not been assessed goes there, including the ones nobody has ever asked about. The status comes with an instruction someone can follow immediately: public information only, and this is where you request the assessment. It is neither a ban nor an approval. It is the truth, written down, and it saves the team leader the conversation in the corridor.
The assessment itself is a fixed set of questions for the vendor: where does processing take place, what is retained, is input used for training, who are the sub-processors? Record the answers with a date, because AI services change their terms faster than any review cycle.
Why does a policy written for typing miss the file?
Almost every AI policy is written for the prompt: do not type customer names, do not paste account numbers. Almost none says anything about the report someone uploads in one go, even though a single attachment holds more personal data than a month of prompts. We explain why that gap is so large in a separate article.
The same applies to the meeting tool that records and summarises the call, and to the browser extension that reads the page to rewrite an email. Nobody types a prompt there, and yet text leaves the organisation. A policy written for typing misses that, and the person using the tool does not see it as AI use because there is no chat window.
So the question "for what kind of work?" in the table has to reach beyond the chat window. Uploading, recording, reading the page: name them separately, because people will not recognise them as the same decision unprompted.
How does a decision reach people while they work?
A policy document sits in a folder. The tool sits in the browser. An employee reads the policy once and opens the tool hundreds of times. That difference explains why a policy that is right on paper still does not get followed: not because people are unwilling, but because the document is not there at the moment it matters.
The decision works when it appears where the tool is opened. For an allowed tool, nothing happens. For a tool with no decision, a low-key notice appears: public information only, with a button to continue. For a tool that is not allowed, the approved alternative appears as the first button, with the option to continue anyway, or without that option if the organisation has set it up that way. For a tool marked "Limited use", the condition the organisation set appears, in one sentence.
BeeSensible does this in the browser: the organisation records a decision for each tool, and that decision appears when someone opens the tool, with the approved alternative as the first button. The extension blocks nothing of its own accord and decides nothing. People can continue unless the organisation has chosen "Employee cannot continue"; what happens next is counted without a user ID. The AI tools page explains how that works.
Here is the overview where those decisions are kept, alongside the observed use:
