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 a single picture. The question is not 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 while the council paper or objection letter is sitting in the text box and whether the municipality can show afterwards that the policy was applied. For what AI governance means in general, see our introduction to AI governance.
Which AI is used in a municipality?
More than the municipal executive knows, and mostly for good reasons. In many municipalities Microsoft 365 Copilot is the tool that was procured and agreed on. Around it sits a second layer that rarely features 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 in plain language and a summariser for the pile of committee papers.
These tools save time in work where time is short. The point is that the second layer arrives without anyone choosing it, and that the data ending up in it is no less sensitive than in the first. Why it does not go away when you ban it is explained in our article on shadow AI.
Which data passes through?
A municipality processes data that few other organisations hold, and the work AI helps with is exactly the work that involves 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 (citizen service number), case number, the grounds for the objection | Everything that identifies 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 still works with placeholders in those places |
| 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 |
BSNs and benefits data are the most obvious, but youth care calls for the most caution: health and family data are special categories of personal data under the GDPR, and the notes from a "kitchen-table conversation" (the home visit where a family's support needs are discussed) are full of them. For a list of what never belongs in a prompt and what usually can go in, see what you can and cannot share with AI.
Which frameworks apply to a municipality?
Four, and they overlap without coinciding. How exactly they apply differs from one municipality to the next; this is the map, not the route.
The BIO (Baseline Informatiebeveiliging Overheid) is the baseline information security standard for Dutch government, with the VNG (the Association of Netherlands Municipalities) and the IBD (its information security service) as the expert bodies. The BIO does not mention AI, but it does call for data classification, supplier management and staff awareness, and all three apply to a chatbot with an objection letter pasted into it. What that means in practice is covered in our piece on AI under the BIO and NEN 7510.
The GDPR applies to every prompt that mentions a resident: purpose limitation, data minimisation, whether the vendor is a processor with a data processing 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 government asks public bodies to describe their high-impact algorithms in public. 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 explained in our article on the AI register for municipalities.
The AI Act affects a municipality in three places. Since 2 February 2025, Article 4 has required measures to support the AI literacy of people who work with AI. Since 2 August 2026, a chatbot that deals with 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, these include registering that use in the EU database. The council paper summariser falls outside all this, though the GDPR and Article 4 still apply to it. How that division works is explained in our guide to 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 actually used.
Take a municipality that has allowed Copilot and written that into its policy and training. When it looks for the first time 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 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 is out of date the moment it is finished.
Then comes the decision, per tool, taken by the municipality itself: allowed; limited use, with a condition the municipality writes down (business account only, no resident data); not allowed, with a named alternative; or, honestly, no decision yet. That last one is the status every new tool starts with. Which AI rules go with this in a municipality is covered in the article on AI policy for municipalities.
The decision only works once the employee at the front desk sees it when the tool opens, not just on the day of the training. For a tool without a decision, that means a calm notice: public information only, you can continue. For a tool that is not allowed, the approved alternative is the first button.
Then look, each quarter and at organisation level: what share of AI use goes through allowed tools, how many tools that are genuinely in use still have no decision and 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 the data protection officer.
BeeSensible links a catalogue of over 1,000 assessed AI tools to the use it observes in the municipality: only the domain of a tool that is opened, at most once a day per device, with no user ID and no page content. In the Inbox, an administrator sees which tools have no decision yet and records the decision. If the municipality has switched notices on, that decision appears in the browser when someone opens the tool. BeeSensible does not block anything by itself; for a tool that is not allowed, the municipality decides whether staff can continue after the notice.
