A board secretary at a school group pulls up the AI policy for the annual planning cycle. The document was adopted a year earlier. It names a tool the vendor has since renamed, it says nothing about Copilot Chat even though it has been on for everyone since the Microsoft 365 rollout, and the transcription tool three teams rely on is not in it at all. Nobody broke the policy. The policy simply did not keep up.
So "how often should you review your AI policy" is the wrong question if you expect a number. You review when something prompts it, and at least once a year when nothing does. The rest of this piece is about what counts as a prompt, and which three numbers you bring to the table.
What does the law ask, and what does it not?
The GDPR sets no period for policy. Article 24 asks that an organisation's measures are reviewed and updated where necessary. Article 32 asks for a process for regularly testing, assessing and evaluating the effectiveness of measures. How regular is up to you, and you record why that rhythm fits the risk.
The AI Act adds no review period either. It does add a number of dates on which obligations start to apply, and anyone with a use case that falls under them has a trigger with a date attached. Which dates those are and what they mean for an employer is covered in the EU AI Act for employers.
For the rhythm this means: a fixed calendar is defensible, but a calendar alone is too little. Whoever looks once a year and otherwise not at all misses eleven months of change.
Which triggers weigh more than the calendar?
AI services change faster than policy. A chatbot gains memory, a meeting tool starts summarising, a vendor adds connectors or changes what happens to input. Each of those can make a status in your policy wrong without anything happening inside your organisation.
| Trigger | What you look at | What usually changes |
|---|---|---|
| A tool without a decision is used and growing | What the tool does, which data goes in, which account | A new line in the policy, with a status |
| The vendor changes features or terms | Whether the status and condition still fit the new version | The condition, sometimes the status |
| A new licence or preferred route | Which tools become redundant, and whether people agree | The preferred route and the statuses around it |
| An incident or near miss | Which agreement was missing or could not be followed | The agreement, and often the alternative |
| Reorganisation, acquisition, new department | Which use arrives that the policy does not know | The list of tools and their owners |
| A date in the AI Act or sector rules | Whether a use case falls under new obligations | The classification and what comes with it |
The first kind of trigger is the most common and the most often missed, because a policy document cannot see which tools are opened. To know that, you put the list from the policy next to actual use. How to do that without tracking people is described in measuring AI adoption.
Which three numbers do you look at in a review?
A review that only rereads the document finds only what is already in it. The numbers show what happens outside the document.
The share of AI use through allowed tools, with its trend. This is the number that ties policy to practice. If it rises, the decisions and the communication about them are doing their work. If it falls while total use grows, use is growing around the policy, and a review is no longer optional.
The tools without a decision that are actually used. Not the full list of everything opened once, but the tools with recurring use that the organisation has said nothing about. Every line in that list is a question employees are currently answering for themselves.
The notices and what happened next. When the decision appears at the moment someone opens a tool, you can count how often a notice was shown, how often the alternative was opened, and how often someone continued anyway. A notice that is dismissed most of the time rarely says something about the people and usually says something about the tool: the alternative does not do what they need, or the risk is smaller than the policy assumed.
All three numbers can be measured without a user id. BeeSensible counts which AI tools are opened (only the domain, at most once a day per device), shows the share through allowed tools with its trend and the tools without a decision that have use, and counts per status how often a notice was shown and what happened next. This is the register you make that comparison in:
