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 in Microsoft Copilot governance; this piece is about what weighs differently 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 a small part of the organisation has a paid licence, the rest works with Copilot Chat, and a share of staff know the consumer version from home. The first decision is therefore a status per variant, with the consumer version named explicitly. The facts per variant are in the privacy risks of Copilot.
Why are permissions the first job in a municipality?
A municipal SharePoint environment has grown by department and by project: a site for a boundary reorganisation, a Teams channel for a neighbourhood team, a folder where the objections committee shares files. Part of it was once opened to "everyone in the organisation" because something had to be shared quickly, and never reverted. Council papers are public anyway; a folder of objection files or action plans from social services 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 by nobody knowing where it was becomes findable in one question. That mechanism is set out in what happens when Copilot can reach SharePoint, and Microsoft puts the clean-up of over-broad permissions first in its own deployment guidance: a report of the permission state first, then access reviews on the sites that are too open, then restricted access on 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, the Dutch central government's vendor management for Microsoft, listing four high privacy risks and advising against use for the time being. After changes by Microsoft, a September 2025 update lowered the risks to amber, with two remaining concerns: 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 on, and which AI tools are in use alongside. What belongs in that part is in a DPIA for Microsoft Copilot. The data protection officer reads along; the administrator supplies the permissions report and the list of connectors.
Which data may Copilot reach, and which may someone paste?
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 that second question a municipality needs a short rule per type of data. Data from social services, youth care, taxation and enforcement, often carrying a citizen service number, is classified high under the BIO baseline and belongs in no prompt until name, address and identifiers are out, not even in a business environment with a data processing agreement. Rewriting a letter is usually fine once the identifying details are gone; what you can and cannot share with AI gives 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, cleaned up before the licences |
| DPIA | What the sector DPIA describes, and what is the municipality's own use | Its own DPIA with the residual risks and the 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, with who took it |
| Connectors and agents | Which agents are on, and who signed off | A list with an owner per connector |
| Tools alongside | Which AI services are used next to Copilot | A register with four statuses |
Which tools run alongside Copilot?
A municipality had allowed Copilot and commissioned an inventory. Alongside Copilot, Perplexity and ChatGPT turned out to be in use, 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 were in no register. Nobody had broken policy, because none existed for those two, and the inventory was out of date on the day it was delivered, because a new tool had arrived that week.
That is not an incident. It shows that a Copilot decision says nothing about the tools alongside it, and that a one-off inventory ages quickly. The decision that follows is that every tool in use gets a status, with Copilot as one row in that register and, where it fits, as the designated alternative for the tools that are not allowed.
BeeSensible links a catalogue of 865 AI tools to the use observed in the organisation: only the tool's domain, at most once per day per device, with no user id and no content. An administrator sees which tools have no decision yet and records that decision in the AI Tools module; whoever 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:
