A team lead at an insurer gets a question from a colleague on a Tuesday afternoon: 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. About this tool it says nothing.
That is the moment an AI policy works or does not. Not when it is adopted, but when a concrete question lands 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 answer whether this one tool may be used for this one 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 exists in the organisation looks different: a meeting tool that summarises, a PDF reader with an assistant, a browser extension that rewrites emails. No template has a position on those, because the template does not know which tools your people open. What that use looks like is described in what shadow AI is.
So work the other way round. First the questions, then the answers, and only then the document that collects them.
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? | Per tool, the tasks that fit (translating, 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 the rule of thumb for doubtful cases |
| Who assesses a new tool? | A role, a deadline and the questions the assessment asks |
| What does someone do with a tool that has no decision? | A route: 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? | Not only an email, which is forgotten within a week; the decision belongs where the tool is opened |
| How do we see whether policy and practice match? | A comparison of the list in the policy with the tools that are actually opened, 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 six months later.
For the question of which data may go in, there is nothing new to invent. A list of what never belongs in a prompt and what usually does is in what you can and cannot put in an AI prompt. Adopt it, and add examples from your own work.
What do you write about a tool with no decision?
This is where the team lead got stuck. Her policy knew two flavours, allowed and not allowed, and the transcription tool fell into neither. What an employee does then is guess, 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 sits there, including the tool 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 lead the conversation in the corridor.
The assessment itself is a fixed set of questions for the vendor: where does processing run, 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. Why that gap is so large is covered in your AI policy covers what people type, what about the file they attach?.
The same applies to the meeting tool that records and summarises the call, and to the extension that reads along in the browser 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 past the chat window. Uploading, recording, reading along: name them separately, because people do not recognise them as the same decision on their own.
How does a decision reach the moment of 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 out of unwillingness, but because the document does not show up at the moment it matters.
The decision works when it appears where the tool is opened. For a tool that is allowed, nothing happens. For a tool with no decision, a calm 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. For a tool with limited use, the condition the organisation wrote itself appears, in one sentence.
BeeSensible does this in the browser: the organisation records a decision per tool, and that decision appears when someone opens the tool, with the approved alternative as the first button. The extension blocks nothing and decides nothing; continuing is always possible, and what happens next is counted without a user id. How that works is on the AI tools page.
This is the overview those decisions live in, next to the use that has been observed:
