An administrator at a Dutch municipality has assigned the Copilot licences to the policy departments and the customer contact centre. Two weeks later a colleague from social services asks whether Copilot can also summarise the action plan for a youth care case. The administrator does not know the answer, and the licence says nothing about it.
That is where the work beyond the licence begins. For a municipality it comes down to four things: the permission structure in SharePoint and Teams, the DPIA, the question of which data Copilot may reach and which an employee may paste, and the AI tools in use alongside Copilot. The general decisions are covered in our article on Microsoft Copilot governance; this piece is about what carries different weight in a municipality.
Which Copilot does the municipality actually have?
Three services are called Copilot. The consumer version at copilot.microsoft.com, without a work account, runs under consumer terms. Microsoft 365 Copilot Chat, signed in with the municipality's work account, runs under Microsoft's enterprise data protection but does not reach into mail and documents by itself. The paid Microsoft 365 Copilot does.
In a municipality this usually means that a small part of the organisation has a paid licence, the rest uses Copilot Chat and some staff know the consumer version from home. So the first decision is a status for each variant, with the consumer version named explicitly. The facts for each variant are set out in our article on the privacy risks of Copilot.
Why are permissions the first job in a municipality?
A municipal SharePoint environment has grown department by department and project by project: a site for a boundary reorganisation, a Teams channel for a neighbourhood team, a folder where the objections committee shares files. Some of it was once opened to "everyone in the organisation" because something had to be shared quickly, and was never locked down again. Council papers are public anyway; a folder of files on residents' objections or social services action plans is another matter.
Copilot does not break those permissions. It searches with the rights the employee already had and summarises what it finds. What was protected for years only because nobody knew where it was can now be found with one question. That mechanism is set out in our article on what happens when Copilot can reach SharePoint. Microsoft puts cleaning up over-broad permissions at the top of its own deployment guidance: start with a report on current permissions, then access reviews of the sites that are too open, then restricted access for the sites holding case files and only then licences.
What do you do with the DPIA?
In December 2024 SURF published a DPIA on Microsoft 365 Copilot together with SLM Rijk, which manages the Dutch central government's relationship with Microsoft. It listed four high privacy risks and advised against use for the time being. After Microsoft made changes, an update in September 2025 lowered the risks to amber, with two concerns remaining: inaccurate personal data generated about real people, and an 18-month retention period for pseudonymised metadata.
That DPIA describes the service. The municipality is the controller and describes its own use: which variant for whom, the state of the permissions with a date, which data ends up in prompts and within reach, which agents and connectors are switched on and which other AI tools are in use. What belongs in that part is covered in our article on a DPIA for Microsoft Copilot. The data protection officer reviews it; the administrator supplies the permissions report and the list of connectors.
Which data may Copilot reach, and which may someone paste?
These are two questions that often get treated as one. The first is about configuration: what Copilot retrieves by itself from mail, calendar and documents. That is everything the user may open, so the answer is the permission structure above. The second is about behaviour: what an employee pastes into the prompt.
For the second question, a municipality needs a short rule for each type of data. Data from social services, youth care, taxation and enforcement, often including a citizen service number, is classified as high under the BIO, the baseline information security standard for Dutch government. It does not belong in any prompt until the name, address and identifiers have been taken out, not even in a business environment with a data processing agreement. Rewriting a letter is usually fine once the identifying details are gone; our article on what you can and cannot share with AI sets out the categories. And letting Copilot summarise meetings with residents in Teams is a decision of its own: a transcript of a conversation about benefits is a new processing operation with its own purpose and retention period.
| Element | The question for a municipality | What you record |
|---|---|---|
| Variant | Who works with Copilot Chat, who with the paid variant, what applies to the consumer version | A status per variant, with an explanation |
| Permissions | Which social services, objections and staff sites are open to everyone | A dated permissions report; permissions cleaned up before licences are assigned |
| DPIA | What the sector DPIA covers, and what counts as the municipality's own use | The municipality's own DPIA, with the residual risks and local measures |
| Reach and prompt | Which data Copilot may retrieve, which someone may paste | A short rule per type of data |
| Meetings | May Copilot summarise conversations with residents? | A separate decision, recording who took it |
| Connectors and agents | Which agents are switched on, and who signed them off | A list with an owner per connector |
| Other AI tools | Which AI services are used alongside Copilot | A register with four statuses |
Which tools run alongside Copilot?
One municipality had allowed Copilot and commissioned an inventory. It turned out that Perplexity and ChatGPT were in use alongside Copilot, plus three specialist tools: a transcription tool for meetings, a translation tool at the front desk and a service that summarises policy memos. Two of the three appeared in no register. Nobody had broken any policy, because there was none for those two. The inventory was also out of date on the day it was delivered: a new tool had turned up that week.
That is not an incident. What it shows is that a Copilot decision says nothing about the tools alongside it, and that a one-off inventory dates quickly. The decision that follows: every tool in use gets a status, with Copilot as one row in that register and, where it fits, as the designated alternative to the tools that are not allowed.
BeeSensible links a catalogue of over 1,000 AI tools to the use it observes in the organisation: only the tool's domain, at most once a day per device, with no user ID and no content. In the Inbox, an administrator sees which tools have no decision yet and records that decision; anyone who opens such a tool afterwards sees the decision in the browser, with the allowed alternative as the first button. This is what that register looks like:
