A policy adviser has to turn a council proposal on waste collection into one readable page for the councillors by Thursday morning. She pastes the draft into a chatbot and has a summary in two minutes. Two floors down, a colleague at the citizen contact centre uses the same tool to summarise an objection letter, with the resident's name, address and benefits case number in it.
That is AI governance in a municipality in one picture. Not the question whether the organisation may use AI, because it already does. The question is which tools are in use, what the municipality has decided about them, whether the employee knows that decision at the moment the council paper or the objection letter sits in the text box, and whether the municipality can show afterwards that the policy was applied. What AI governance means in general is set out in what is AI governance.
Which AI is used in a municipality?
More than the executive board knows, and mostly for good reasons. Microsoft 365 Copilot is, in many municipalities, the tool that was procured and agreed on. Around it sits a second layer that rarely appears in any decision: ChatGPT for letters and memos, a transcription tool that writes up council and team meetings, a translation tool for the front desk and the neighbourhood teams, a service that rewrites policy documents into plain language, and a summariser for the pile of committee papers.
They save time in work where time is short. The point is that the second layer appears without anyone choosing it, and that the data landing in it is no less sensitive than in the first. Why it does not disappear when you ban it is in what is shadow AI.
Which data passes through?
A municipality processes data that few other organisations hold, and the work where AI helps is exactly the work that carries it.
| Task | What can be in the text | What can come out before you paste |
|---|---|---|
| Summarise a council proposal | Usually public; sometimes a confidential annex or the names of people involved | The confidential annex and the residents' names |
| Summarise an objection letter | Name, address, BSN, case number, the grounds for the objection | Everything that leads to the person; the substance of the objection stays usable |
| Rewrite a letter about a benefit | BSN, income, household situation, the amount of the benefit | Rewriting works with placeholders in those spots |
| Write up a youth team conversation | The child's name, health, home situation | This does not belong in a tool without a decision, even with the names removed |
| Transcribe a meeting | Who said what, including about residents and colleagues | Decide beforehand whether the tool is allowed, rather than deleting the recording afterwards |
The BSNs and benefits data stand out most, but youth care asks for the most caution: health and family data are special categories of personal data under the GDPR, and a note from a kitchen-table conversation is full of them. A list of what never belongs in a prompt and what usually does is in what you can and cannot share with AI.
Which frameworks apply to a municipality?
Four, and they overlap without coinciding. The exact application differs per municipality; this is the map, not the route.
The BIO, the Baseline Informatiebeveiliging Overheid, is the security baseline Dutch government bodies work under, with the VNG (the association of municipalities) and the IBD (its information security service) as knowledge organisations. The BIO does not mention AI, but it asks for data classification, supplier management and staff awareness, and all three touch a chatbot with an objection letter pasted into it. What that means in practice is in BIO and NEN 7510: AI and privacy in government and healthcare.
The GDPR applies to every prompt a resident appears in: purpose limitation, data minimisation, whether the vendor is a processor with an agreement in place, and in youth and care work the extra protection for special categories of data.
The Algorithm Register at algoritmes.overheid.nl is where the Dutch national government asks public bodies to publicly describe impactful algorithms. That covers algorithms that affect decisions about residents, not the chatbot an adviser uses to rewrite a memo. The difference between that public register and the internal overview of AI services in daily use is in an AI register for municipalities.
The AI Act touches a municipality at three points. Since 2 February 2025, Article 4 asks for measures supporting the AI literacy of people who work with AI. Since 2 August 2026, a chatbot facing residents must make clear that it is AI (Article 50). And for AI that assesses whether someone is entitled to a benefit or a service, a use listed in Annex III, the deployer obligations apply from 2 December 2027, for public authorities including registration of that use in the EU database. The council paper summariser is outside that; the GDPR and Article 4 still apply to it. How that division works is in the EU AI Act for employers.
How do you approach it without a year-long project?
Do not start with the policy document. Start with what is used.
A municipality has allowed Copilot and put that in policy and training. When it looks for the first time at which AI services are opened from the browser, Perplexity and ChatGPT turn out to be in use next to Copilot, plus three specialised tools: a transcription tool for meetings, a plain-language rewriter and a summariser. Two of them appear in no register at all. Nobody did anything wrong, because nothing had been decided about those two. What it does show is that a quarterly inventory falls behind the moment it is finished.
Then comes the decision, per tool and by the municipality itself: allowed, limited use with a condition the municipality writes down (business account only, no resident data), not allowed with an alternative named, or honestly no decision yet. That last one is the status every new tool starts on. Which agreements belong with that for a municipality is in an AI policy for municipalities.
The decision only works once the front desk employee sees it when the tool opens, not on the day of the training. For a tool without a decision, a calm notice: public information only, you can continue. For a tool that is not allowed, the approved alternative as the first button.
And then look, each quarter and at organisation level: what share of AI use runs through allowed tools, how many tools with real use still have no decision, how often someone chose the alternative after a notice. Those are figures about tools, not about staff. A municipality that measures this per person has started a different conversation, with the works council and with the DPO.
BeeSensible links a catalog of 865 assessed AI tools to the use observed in the municipality: only the domain of an opened tool, at most once per day per device, with no user id and no page content. An administrator sees which tools have no decision yet and records the decision in the AI Tools module. If the municipality has switched notices on, that decision appears in the browser when someone opens the tool, never as a block.
