At a housing association, a reminder pops up in the IT administrator's calendar: review AI register. He opens the spreadsheet. The last edit is eight months old, by a colleague who has since left. In the meantime the meeting tool has started summarising calls, and nobody added a row for it.
That is how a register goes stale: not on the day you write it, but on the day something changes at a vendor or on the work floor. Keeping it current therefore takes three things. Triggers that force a review, a rhythm as a safety net, and a second source that supplies the tools nobody reported. Which fields a row holds is covered in an AI register: what it is and what you record in it; this piece is about what comes after.
Which triggers force a review?
A review date in the row is a safety net. The real movement comes from outside the calendar, and it takes five forms.
| Trigger | What changes | What you check |
|---|---|---|
| New feature at the vendor | The tool can suddenly read documents, record meetings or search the web | Data use and purpose; whether the condition on "limited use" still holds |
| Acquisition or changed terms | New owner, new jurisdiction, new sub-processors, new training policy | Vendor, data processing agreement, where processing runs |
| Incident at the vendor | A data breach, a flaw in the sharing feature, a regulator stepping in | Whether the decision stands, and whether employees need to do anything |
| New use inside the organisation | Another department, another purpose, other data | Whether this is a new row, and who becomes its owner |
| Different account type | From free to business, or the reverse | Data processing agreement, training, administration; usually a separate row |
The first is the quietest. There is no request and no invoice; the vendor switches a feature on and the row in the register still describes the tool as it was two years ago. Why that is structural is explained in why an AI tool catalog ages the moment you print it. The fourth is the trigger most often missed, because the tool is already in the register. Copilot for internal memos and Copilot for interview notes in HR are one tool and two rows.
What rhythm actually works?
Not one annual round that takes six weeks. That produces a list that is already behind on delivery day, and the year after, nobody runs it again.
This works. Every row gets a review date set by its owner, according to risk: a translation tool for public texts can go a year, a transcription tool in HR closer to six months. On top of that, two fixed moments. Every quarter, the rows marked "no decision yet" and "limited use", the first because they are a backlog, the second because a condition goes stale faster than a plain yes or no. And once a year, everything.
Per row that is half an hour: do vendor, data use and purpose still hold, and is there a new date. If it stays that small, it keeps happening.
Why does an updated register still fall behind?
Because a register only knows what someone reported. Every row once began as a request, an invoice or a question to the service desk. Whatever starts without a request never gets in, and that is most of it. In the study by KPMG and the University of Melbourne among 48,000 workers in 47 countries (2025), 57 percent say they hide AI use from their employer. Not out of bad faith; the tool did the work and nobody had asked.
A vocational college keeps a register of nine rows, each with a review date. The first measurement of which AI services are opened in the browser shows fourteen. The five extra: Perplexity, a tool that generates test questions, a presentation tool with AI built in, a transcription tool one teacher pays for himself, and the free version of ChatGPT next to the business one. None of the five is an incident, because nothing had been decided about any of them. The register was current, for the nine rows it knew.
What is the difference between updating and being fed?
A register you update changes when someone remembers. A register that is fed gets new rows from what actually happens: an AI tool that is opened in the organisation and has no decision yet appears by itself, with the date it was first seen. The work shifts from finding to deciding.
That does not require watching people. To know whether a tool needs a decision, the service's domain is enough: that an AI tool was opened in the organisation, which one, and how often. Which methods do and do not see that is covered in how do you find out which AI tools employees actually use.
From the browser extension, BeeSensible reports only the domain of an opened AI tool, at most once per day per device, with no user id and no content. Newly discovered tools without a decision sit in the dashboard's inbox, where an administrator records the status, for several tools at once if needed. The catalogue of 865 tools is continuously curated; tools recently added to it carry a "New" label for thirty days. What the AI tools module shows per tool is below.
