Copilot in Dutch municipalities: the DPIA after the Dutch DPA's advice in 10 steps

A mid-sized Dutch municipality, an ordinary Tuesday morning. The customer contact centre wants Copilot to draft answers to frequently asked questions faster. Legal Affairs wants it to summarise objections (the Dutch administrative "bezwaarschriften" that precede an appeal to the courts). Communications has already tried it in a test environment and loves it. The CIO has forty licences in the budget and asks the privacy officer for a green light before Christmas: "It stays inside our tenant, and central government already did a DPIA on it, right?"

Since the advice of the Autoriteit Persoonsgegevens (AP, the Dutch Data Protection Authority) on Microsoft 365 Copilot at the municipality of Haarlemmermeer, that question can no longer be answered by signing a standard form. The AP concluded that the intended processing "inbreuk zou maken op de AVG" ("would infringe the GDPR") and closed with a clear piece of advice: "Niet starten met de voorgenomen verwerking dan nadat de bovengenoemde maatregelen zijn genomen" ("Do not start the intended processing until the measures set out above have been taken"). Quotes from the advice are given in the original Dutch; the English renderings in italics are our translation, not an official one. The advice does not mean Copilot is banned at municipalities. It does mean that the municipality's own DPIA has to do the work, and that the reference DPIA commissioned by SLM Rijk (Strategic Vendor Management Microsoft for the Dutch central government) cannot take its place. This article sets out what the AP actually asks, what it means for your organisation, and how to build the DPIA in ten steps.

What the Dutch DPA advised on Copilot at Haarlemmermeer

On 11 June 2025 the municipality of Haarlemmermeer submitted a request for prior consultation for a small-scale pilot with Microsoft 365 Copilot. According to annex 1 of the advice, the pilot involved 15 to 20 employees, with use cases not yet defined, within a scope limited to the customer contact centre, efficiency gains in the objection and appeal process, and communications and external relations. The municipality relied on the reference DPIA carried out for SLM Rijk, dated 17 December 2024. The advice was published on the AP's website in July 2026.

One early point deserves attention, because many public bodies reason the same way. The municipality expected the pilot not to create any new processing of personal data. The AP disagreed (chapter 5): input and output are linked to individual users, the content can contain personal data, and through Microsoft Graph Copilot has access to files and metadata. That the municipality already processes those data makes no difference. The AP welcomes a pilot, but adds that "ook een pilot aan de AVG moet voldoen" ("a pilot, too, must comply with the GDPR").

The AP does not address the legal basis (Article 6 GDPR), the exceptions for special categories of personal data (Article 9) or the lawfulness of the training data (chapter 6). That is not a free pass: you answer those questions in your own DPIA. The advice itself has three parts.

A. Getting the basics in order

Before an organisation puts a generative AI system into use, its information security and data management must be in order, according to the AP (section 6.1). The reasoning: once a generative AI system gets access to the organisation's systems, it can expose and aggravate existing problems nobody had noticed yet. The AP names four preconditions.

• Record of processing activities (6.1.1). An up-to-date record that shows, at least broadly, which processing operations the AI system touches, and that is kept up to date during and after implementation.
• Overview and labelling of documents (6.1.2). Knowing which personal data sit in which documents, cleaning up or excluding outdated files, and labelling files that must not end up in the AI system. According to the VNG (Association of Netherlands Municipalities), which the AP cites via a note from the IBD (the municipalities' Information Security Service), most municipalities do not label documents. And pointedly: "Het is uitdrukkelijk niet de bedoeling dat hier pas mee wordt gestart zodra het generatieve AI-systeem al in gebruik is genomen" ("It is expressly not the intention that this work only starts once the generative AI system is already in use").
• Permissions (6.1.3). "Copilot heeft volgens de Gemeente toegang tot alle gegevens waar de gebruiker ook toegang toe heeft" ("According to the Municipality, Copilot has access to all data the user also has access to"). The AP therefore considers it necessary for the organisation to review its access policy and existing permissions first (Article 32 GDPR and the BIO, the Baseline Information Security for Dutch government), and flags features that grant access automatically through a shared link.
• Cloud environment (6.1.4). Insight into the processing in the existing cloud environment, tested against the GDPR and the Dutch central government cloud policy of 2022. Already being a customer of a vendor does not release you from the duty to look at alternatives; where the risk is high, a self-hosted system may be necessary according to the AP.

B. Generative AI in the public sector

The second part (section 6.2) applies to any generative AI system, not only to Copilot.

Purpose limitation, data minimisation and storage limitation (6.2.1). "Het inzetten van een generatief AI-systeem mag geen doel op zich zijn" ("Deploying a generative AI system must not be an end in itself"). The municipality described the purpose as "het ondersteunen van de medewerker" ("supporting the employee"); the AP found that too vague and too general to qualify as a specified and explicit purpose. Necessity and proportionality are assessed from the purpose, not from the solution. For data minimisation, it must be settled in advance which data and applications the system can reach; access to email requires a separate justification. If the vendor does not offer those settings, the system cannot be put into use, according to the AP.

Inaccurate or unwanted answers (6.2.2). A generative AI system does not always give the right answer, and incorrect output usually sounds plausible. Combined with automation bias, that turns the accuracy principle of Article 5(1)(d) GDPR into a real problem. Users need the knowledge and the time to check the output.

Automated decision-making (6.2.3). Given the public task and the work processes described, including objection and appeal, the AP considers it very likely that individual decisions with legal effects can be taken there; the DPIA did not show that the municipality had assessed this. Where a generative AI system plays a decisive role, the decision is based solely on automated processing (Article 22 GDPR). The municipality must periodically check that the human remains decisive, and staff need sufficient knowledge of how the system works and what its risks are.

Data subject rights (6.2.4). The municipality's DPIA did not mention the right to information. The AP requires residents to be informed about new and affected processing, and recommends registering Copilot in the Algoritmeregister (the Dutch government's Algorithm Register) once it is in use.

C. The specific risks of Copilot

The third part (section 6.3) follows the four high residual risks from the original SLM Rijk reference DPIA, which the AP assumed the municipality endorsed: data subjects cannot exercise their rights; inaccurate generated personal data can have negative consequences; there is a loss of control because of a lack of transparency about Required Service Data (RSD); and pseudonymised data can be re-identified because the retention periods of RSD are unknown. In its summary (chapter 2) the AP states: "Een gebrek aan transparantie vanuit Microsoft ontslaat de Gemeente echter niet van de verplichting om de AVG na te leven" ("A lack of transparency on Microsoft's part does not, however, release the Municipality from its obligation to comply with the GDPR"). It also points out that the lead supervisory authority for Microsoft is not the AP but the Irish Data Protection Commission.

The concrete points:

• Microsoft's role (6.3.1). The municipality itself did not know in which capacity Microsoft acts, and according to the reference DPIA Microsoft is a controller for some processing. If the vendor will not cooperate on additional arrangements, it cannot be engaged where the municipality knows that doing so would breach the GDPR.
• Preconditions from the reference DPIA (6.3.2). Information management in order, Bing blocked, the free consumer versions and the public feedback forum blocked, pre-ticked marketing emails switched off, and retention periods for prompts and responses set centrally. All before go-live.
• Right of access (6.3.3). The AP considers it plausible that public bodies cannot meet the right of access because of Microsoft's lack of transparency, in particular for Diagnostic Data.
• Inaccurate personal data and filters (6.3.4). The chat interface reinforces automation bias, source references are incomplete or sometimes point to files that do not exist, and Microsoft's Responsible AI filter cannot be adjusted. The AP considers it necessary for the municipality to have insight into and influence over those filters.
• Required Service Data and retention (6.3.5 and 6.3.6). As long as Microsoft does not make sufficiently clear what RSD contains, what it is used for and how long it is kept, "is de enige manier voor de Gemeente om dit risico te mitigeren het niet gebruiken van Copilot" ("the only way for the Municipality to mitigate this risk is not to use Copilot").

The conclusion: two lists of measures

Chapter 8 sets out the measures in two lists. The first applies before the municipality puts any generative AI system into use, whichever system it is: the points from parts A and B above. The second comes on top when the choice falls on Copilot: the points from part C, with a hard condition that you do not start without sufficient transparency about RSD and retention periods. The AP's measures come on top of all the measures in the reference DPIA, which the AP assumes the municipality will also implement before use. If a vendor does not cooperate, that cooperation must still be secured, or the vendor cannot be engaged. Without these measures, the AP says, the processing will "waarschijnlijk als onrechtmatig" qualify ("likely qualify as unlawful"). A small-scale pilot with the lowest-risk use cases may be needed to verify that the measures actually work.

Legally this is written advice under Article 36(2) and Article 58(3)(a) GDPR, not a binding decision. The AP does keep its ordinary powers: according to chapter 9, complaints or other information about the processing can still lead it to request further information or open an investigation.

Can your organisation use Copilot? What the advice means

The advice is addressed to one municipality. In its introduction the AP writes that other municipalities or public bodies wishing to rely on the advice must assess for themselves whether their processing corresponds to Haarlemmermeer's, weighing all the circumstances of their own processing. In our reading, four practical conclusions follow.

First: the reference DPIA is input, not a DPIA. The AP writes that the SLM Rijk reference DPIA "niet voldoet aan de eisen van artikel 35 AVG" ("does not meet the requirements of Article 35 GDPR"), because it is a reference DPIA that individual controllers use to inform their own assessment. At the same time the AP calls it valuable for understanding how Copilot works technically. If you adopt the conclusions of the 2024 version, you also adopt its four high residual risks, as the AP assumed at Haarlemmermeer: because the municipality relied on the reference DPIA, the AP took it that the municipality also endorsed those four high residual risks.

Second: the AP has not assessed the SLM Rijk updates. SLM Rijk published a first update of the reference DPIA on 11 September 2025. In it, Microsoft's measures helped mitigate two of the four high risks, and the other two dropped to medium: possibly inaccurate and incomplete personal data in generated answers, and the coarse 18-month retention period for pseudonymised Required Service Data and telemetry data. A second update of 27 May 2026 arrives at two medium and nine low risks, and places on public bodies the responsibility for deciding which tasks they allow Copilot to be used for. The AP left the first update out of its advice (chapter 4): the municipality had not taken that version into account, the time limit in Article 36(2) GDPR left too little time to assess it, and part of the measures is confidential in the public version. The second update does not appear in the advice at all; the AP relied only on the first version of the reference DPIA and the municipality's own DPIA. Whether the measures reduce the risks sufficiently for your processing is therefore a question for your own DPIA, using the current position at Microsoft and SLM Rijk as a source. In our reading the AP advice is not the last word on this, but neither are the updates.

Third: the first list applies to every generative AI system. A municipality that switches to a different generative AI system does not escape the basics or the public sector test. In our reading the advice is therefore broader than its title suggests, and relevant well beyond the Netherlands for any public body planning a generative AI assistant on top of its document estate.

Fourth: this is more than a privacy project. Permissions, labels and tenant settings sit with information management and IT, arrangements with Microsoft with procurement, and decision-making with the business. The DPIA is where those pieces come together.

The Copilot DPIA in ten steps

The steps below follow the structure of Article 35(7) GDPR (description, necessity and proportionality, risks, measures) and are built around the points the AP raised at Haarlemmermeer. They are our translation of the advice into a working order, not a requirement set by the AP. When a DPIA is mandatory for AI and how to scope it is covered in our guide to DPIAs for AI systems; the legal text is on our page on Article 35 GDPR. What an ordinary DPIA misses for AI is covered in the AI addendum to your DPIA.

Two remarks on that last step. The AP gives its advice within eight weeks, a period that can be extended by six weeks, and the clock stops while the AP waits for information it has requested (Article 36(2) GDPR). At Haarlemmermeer the AP asked for additional information and held a meeting with the DPO and a privacy officer; build such rounds into your planning. And according to chapter 9, a municipality must assess, when the processing changes substantially, whether it needs to be reassessed under Article 35 and possibly submitted to the AP again. Scaling up to the whole organisation is such a moment in our reading; the AP itself calls scaling up "geen doel op zich" ("not an end in itself", footnote 133). The legal text is on our page on Article 36 GDPR.

Copilot and the AI Act: Article 4, Article 50 and high risk

The AP itself notes in the advice that the AI Act may apply alongside the GDPR. For Copilot at a municipality, that means three things in practice.

Article 4 already applies. The AI literacy duty has applied since 2 February 2025, and since 27 July 2026 in the wording of the Digital Omnibus (Regulation (EU) 2026/1744): providers and deployers take measures that support the development of AI literacy, without having to guarantee a specific individual level. The AP advice still refers to the original wording. The core remains: show per role which measures you took, because the AP links that knowledge directly to meaningful human intervention.

Article 50 has applied since 2 August 2026, largely on the provider's side. The duties to disclose AI interaction (paragraph 1) and to mark generated content in a machine-readable way (paragraph 2) rest on the provider, which for Copilot is Microsoft. For systems already on the market before 2 August 2026, such as Copilot, paragraph 2 applies from 2 December 2026 (Article 111(4)). If the municipality builds its own assistant for residents on Copilot Studio and puts it into service under its own name, in our analysis it can itself be the provider of that system, and paragraph 1 then applies to it too. As a deployer, a municipality mainly deals with paragraph 4. If Communications uses AI to create realistic images, audio or video that constitute a deep fake, it must disclose that the content has been artificially generated or manipulated. And anyone who publishes AI-generated text to inform the public on matters of public interest must disclose that, unless the text has undergone human review or editorial control and someone holds editorial responsibility. A communications department that edits Copilot texts and publishes them under its own responsibility will usually, in our reading, fall under that exception; do record the editorial control.

Copilot is not a high-risk system in ordinary office use, but the use can change that. The task determines the classification, not the tool. If the municipality structurally uses Copilot for a purpose listed in Annex III, for example to assess whether someone is eligible for a benefit or service (point 5(a)) or to select candidates (point 4), the high-risk obligations apply from 2 December 2027. That is different if Copilot only performs a preparatory or narrow procedural task there, does not materially influence the outcome and does not perform profiling (Article 6(3)); the provider, possibly the municipality itself here, must then document that assessment in advance (Article 6(4)). Where the high risk does apply, the municipality as deployer has the obligations of Article 26, such as human oversight by competent persons, keeping logs and informing workers' representatives, workers and affected persons in advance, and as a body governed by public law it must carry out a fundamental rights impact assessment (FRIA) under Article 27. Anyone who changes the intended purpose of a general-purpose AI system so that it becomes high-risk also becomes the provider of that high-risk system (Article 25(1)(c)), with the provider obligations that come with it. The transitional rule of Article 111(2) (by 2 August 2030 at the latest for systems intended to be used by public authorities) helps little here: it only covers a high-risk system that was already in use for that Annex III purpose before 2 December 2027, and it falls away on a significant change in design. With a cloud service the vendor updates continuously, in our analysis you cannot build on it. Watch two applications this article itself mentions. Objection and appeal concerning benefits or services sits close to Annex III point 5(a) in our analysis, and using Copilot logs to evaluate staff performance or behaviour sits close to point 4(b). So exclude Annex III purposes expressly in the DPIA, or make the Article 6(3) assessment visible. More in our comparison of the DPIA and the FRIA, the FRIA for municipalities and our piece on the AI register.

A working pack for the Copilot DPIA

So that the steps above do not start from a blank document, we have put together a Copilot DPIA pack: a checklist along the measures in the AP advice, a vendor questionnaire on roles, Required Service Data and retention, and text blocks for the DPIA that you adapt to your own situation. For a first structured check of a concrete use case under the GDPR and the AI Act, you can also use the case check.

Back to the municipality from the opening. The honest answer to the CIO is not no, but a sequence. First the permissions, the record of processing and the labels, because they have value without Copilot too. Then a few well-defined use cases with a concrete purpose, outside objection and appeal as long as human review is not in place. Then the tenant settings, the arrangements with Microsoft and an honest assessment of what is still unknown about Required Service Data. And only then a small pilot, with a DPIA that weighs every point in the AP advice, or with your own prior consultation of the AP. If you want the next AI application to follow the same route, from intake to the DPO's advice, AI governance through the privacy function describes how to make that route permanent. If you want someone to work through that DPIA with your privacy officer and DPO, or to carry out the legal assessment, you can hire Zahed Ashkara as a legal adviser on AI and privacy. If your organisation has no DPO or an overloaded one, that is also possible as an external DPO with AI oversight; if you want an independent, signed opinion on your Copilot DPIA, look at the assessment.