A neighbourhood team worker has held three kitchen-table conversations on a Friday afternoon and wants to turn her notes into reports before the weekend. She knows a tool that does it in a minute. The municipality's AI policy was adopted by the executive board last year: six pages, with the words careful and responsible in it, and Copilot as the preferred tool. About this tool, and about a note from a conversation in a family's home, it says nothing.
That is the moment an AI policy works or does not. A policy for a municipality need not be long, but it has to answer that question: may I use this tool, with this note, and if not, what then. The general structure of such a policy is in writing an AI policy. This piece is about what is different for a municipality.
Which questions must a municipality's policy answer?
The same questions as anywhere else, with answers that fit municipal work.
| Question | What a municipality writes down |
|---|---|
| Which tools are allowed, with which account? | A list of names with the account type attached; Copilot inside the municipality's own tenant is a different thing from a free chatbot on a private account |
| Which data never goes in? | BSN, benefits and income data, everything from youth care and social care, objection and enforcement files, papers under confidentiality |
| What applies in contact with residents? | A chatbot says it is AI; a letter or a formal decision remains a decision of the municipality, taken and signed by an employee |
| Who assesses a new tool, and how fast? | An owner in the line organisation answers the questions, the DPO and the CISO review, and there is a deadline |
| What do you do with a tool without a decision? | Public information only, and this is where you request the assessment |
| How do the front desk and the neighbourhood teams hear about a change? | Where the tool is opened, not in an email from three weeks ago |
| How do we see whether the policy is followed? | The list from the policy next to the tools actually opened, in numbers, without names |
The second row is longer at a municipality than at most companies, and that is no reason to shorten it. A front desk employee has to see at a glance that a benefits case number sits in the same category as a BSN. A general list is in what you can and cannot share with AI; add examples from your own work, because nobody recognises "social services data" in an objection letter about a parking fine.
What do you write down about contact with residents?
Three things, all short.
A chatbot on the website or on the phone makes clear that it is AI. Article 50 of the AI Act has required that since 2 August 2026, and it is also plain decency towards a resident asking about their application.
A letter rewritten with the help of AI remains a letter from the municipality. Whoever sends it reads it and stands behind it. For a formal decision, an objection or a service that applies twice over: the decision belongs to the municipality and is taken by an employee, and AI helps with the wording at most. How a municipality handles AI that assesses or prioritises applications is a separate chapter, with the AI Act and the Algorithm Register attached; that is in AI governance for municipalities.
And residents' data does not go into a tool without a decision, not even to tidy up a letter. Rewriting works with placeholders. The task still gets done; the resident does not leave the municipality.
What is the role of the DPO and the CISO?
A different one from the role they often get. In many municipalities the AI policy lands with the DPO, because it is about personal data. That clashes with the DPO's position: the DPO reviews and advises, and has to be able to do that independently. A DPO who adopts the policy and approves the tools cannot later say independently that something is wrong.
This division works better. The DPO reviews a new tool against the GDPR: legal basis, purpose limitation, processing agreement, whether a DPIA is needed. The CISO reviews against the BIO baseline: classification of the data, the vendor, where processing takes place. The decision itself belongs to the municipality, in practice the directors or the management team, and each tool has an owner in the line organisation: the team lead of the contact centre for the translation tool, the manager of the youth team for the transcription tool. That owner answers the questions and drives the review. And the works council belongs at the table early, certainly once the policy says anything about how the municipality will measure use.
The register those decisions land in, and how it relates to the Algorithm Register, is in an AI register for municipalities.
How does the policy reach the front desk and the neighbourhood teams?
Not through the document. A six-page policy is read once, on the day of the training, and the tool is opened hundreds of times afterwards. What does stick is one line per situation, at the moment the situation arises. How to write that without burying people in rules is in how do you communicate AI policy.
Back to the neighbourhood team worker. She opens the tool and sees a short notice: no decision has been taken on this tool yet, enter public information only, and this is where you request an assessment. She writes up the reports in Copilot that afternoon, without the families' names, and requests the assessment. Two weeks later the municipality has decided: limited use, for internal meetings without case material only, with Copilot as the route for anything residents appear in. From that moment, everyone who opens the tool sees that one sentence.
That is not a complicated set-up. It is the list from the first row of the table, with one of four statuses per tool, visible where the work happens.
BeeSensible does this in the browser: the municipality records a decision per tool in the AI Tools module, and that decision appears when someone opens the tool, with the approved alternative as the first button. The extension blocks nothing and decides nothing; continuing is always possible, and what happens next is counted without a user id.
