During a committee meeting, a councillor asks the portfolio holder: is all of our AI in the Algorithm Register? The privacy officer looks it up the next morning. Two entries, both models used in social services. That same morning she passes a colleague from communications rewriting a press release in ChatGPT, and she knows that the youth team uses a transcription tool nobody has ever asked her about.
So the answer to the councillor is: yes for the algorithms that affect residents, and no for the AI that staff use every day, because that does not belong there. There is a second register for that, and it is the one most municipalities do not have yet.
What does the Algorithm Register describe?
The Algorithm Register at algoritmes.overheid.nl is public. The Dutch government asks public bodies to describe high-impact algorithms there: models and AI that play a part in decisions about residents, or that noticeably affect how government deals with them. The aim is to let residents, councillors, regulators and journalists see which algorithms government uses and which safeguards go with them.
Whether publication will become a legal duty, and for exactly which algorithms, is still open; the site itself is the place to check. What is settled is the nature of the register: it covers applications with consequences for residents, and it is aimed at the outside world. A chatbot an adviser uses to rewrite a memo falls outside it. Not because that chatbot is unimportant, but because it decides nothing.
What belongs in the internal AI register?
Every AI service the municipality uses to get work done, including those that decide nothing: Microsoft 365 Copilot, ChatGPT, Perplexity, the youth team's transcription tool, the translation tool at the front desk, the service that rewrites council papers in plain language. For each row: who the vendor is, what it is used for, which department owns it, which data may and may not go in, what the municipality has decided and when that decision will be reviewed.
The fields are the same as for any organisation, and they are set out in our article on what an AI register is and what to record, with a completed example. For a municipality, two of them carry more weight. The field listing data that may not go in is long and specific: BSNs (citizen service numbers), benefits data, anything from youth care, confidential annexes. Then there is the cross-reference field: to the GDPR record of processing activities where personal data is involved, and to the Algorithm Register where the same application appears there too.
Why the AI Act does not prescribe one universal AI register for every organisation, and what does apply to public authorities that deploy high-risk systems, is explained in our article on whether an AI register is mandatory.
What belongs in which register?
| Algorithm Register | Internal AI register | |
|---|---|---|
| For whom | Residents, council, regulators, journalists | The municipality itself: data protection officer (DPO), CISO, IT, team leads |
| What is in it | High-impact algorithms and high-risk AI that affect decisions about residents | All AI services staff use, including those with no role in decisions |
| Unit | An application within a work process | An application of a tool, with the tool as a property |
| What it answers | Which algorithms does government deploy, with which safeguards | What do we use, what may go in, what have we decided |
| How it is filled | Per project, when a process is set up or changed | By self-reporting, and by looking at what is actually opened |
| When it changes | When an algorithm is new or changed | Every week, because tools arrive without anyone reporting them |
A few examples make the split clear. A model that determines which applications for a service get extra checks: the Algorithm Register, plus a row in the internal register with vendor and owner, plus the record of processing activities. ChatGPT in the communications team: the internal register only. The chatbot on the website that points residents in the right direction: the internal register in any case, with the AI Act's transparency obligation attached, and the Algorithm Register if the municipality judges that it noticeably affects residents. The youth team's transcription tool: the internal register, with a reference to the DPIA and the record of processing activities, because special categories of data go into it.
Why does the internal register fall behind?
Because it is filled in by people who know about a tool. Someone who does not realise their summariser is AI does not report it. Someone paying for it privately does not report it. Someone who started using it last week was not around for the survey.
Take a municipality that has allowed Copilot, with a restriction on documents from social services, and whose internal register has six rows. The first time it looks at which AI services are opened in the browser, it finds Perplexity and ChatGPT in use alongside Copilot, plus three specialist tools: a transcription tool for meetings, a plain-language rewriter and an image generator for communications. Two of them appear nowhere. That is not an incident, because nothing had been decided about those two. What it shows is that a survey is a snapshot of one moment. Why surveying more often does not fix that is explained in our piece on why an AI tool catalogue is out of date the moment you print it.
How does observed use feed the register?
By adding a second source alongside the register: which AI tools are actually opened in the organisation. Not who, not what is typed, only which tool and how often, at organisation level. The difference between that list and the register is the backlog, and every tool in it enters the register with the most honest status there is: no decision yet.
From then on the register has a rhythm. A new tool is noticed and gets a row with a date. The owner in the department that uses the tool answers the questions and the municipality takes a decision. At the review, the same owner checks whether the vendor's terms and the way data is used still hold. What those steps look like in practice is covered in our article on getting from shadow AI to a current AI register.
BeeSensible supplies that second source: the extension reports only the domain of an AI tool that is opened, at most once a day per device, with no user ID and no page content, and matches it against a catalogue of over 1,000 assessed tools. In the Inbox, an administrator sees which tools are new and still need a decision, and records that decision; every tool starts with the status "No decision yet". More on how that works is on the page about the AI register.
