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 switched 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 covers what counts as a trigger and which three numbers to bring to the table.
What does the law ask, and what does it not?
The GDPR sets no review period for policies. 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 regularly is up to you; you record why that frequency 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 how often you review, this means a fixed calendar is defensible, but a calendar alone is not enough. If you look once a year and never in between, you miss eleven months of change.
Which triggers matter 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 tool | Which tools become redundant, and whether people are on board | The preferred tool and the statuses around it |
| An incident or near miss | Which rule was missing or could not be followed | The rule, and often the alternative |
| Reorganisation, acquisition, new department | What new use arrives that the policy does not cover | 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 compare the list in the policy with actual use. Our article on measuring AI adoption describes how to do that without tracking people.
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 much 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 are being used, and counts per status how often a notice was shown and what happened next. This is the register where you make that comparison:
