The AI addendum to your DPIA: what a standard DPIA misses

On a Friday afternoon a privacy officer at a Dutch municipality gets a request from the information management team: "We are starting a pilot with an AI assistant. Can you fill in the DPIA? The template is in the usual place." The template is solid and every question gets an answer. The purpose becomes "supporting staff", the data become "the data staff already have access to", the recipient becomes "the vendor, as processor". The document is finished, and on every point that matters it is empty. The short answer to what is missing: with AI, a standard DPIA misses the chain, the three data flows, inaccurate output, purpose creep and the AI Act role, and an addendum of ten parts covers that.

That is not an invented risk. In its advice after prior consultation under Article 36 GDPR on Microsoft 365 Copilot at the municipality of Haarlemmermeer (case 2025-018225), the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) wrote about an almost identical purpose description: "Deze doelomschrijving is echter te vaag en te algemeen, waardoor deze niet kan kwalificeren als een welbepaald en uitdrukkelijk omschreven doel" (this purpose description is, however, too vague and too general, so that it cannot qualify as a specified and explicit purpose, our translation; section 6.2.1). What the case means for a Copilot DPIA at a municipality is set out in our piece on the Dutch DPA's advice. This article is about the broader lesson: a template that works well for a case management system does not ask the follow-up questions that matter for AI. You do not need a new template. You need an addendum.

When a DPIA is mandatory for AI is covered in our step-by-step guide to the DPIA obligation for AI systems; the relationship with the fundamental rights impact assessment under the AI Act in our comparison of the DPIA and the FRIA. This article assumes the DPIA is going ahead, and answers the question of what has to go into it that the template does not ask.

Why a standard DPIA template falls short for AI

Article 35(7) GDPR prescribes four elements: a systematic description of the processing operations and purposes, an assessment of necessity and proportionality, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged. Common templates are built around those four elements and ask their questions per processing operation. In our analysis, that works as long as three assumptions hold: the application does what it was designed to do, the data travel along known routes, and the result is a repetition or transformation of what went in. With AI, none of the three holds.

Whether AI crosses the threshold is rarely the question. Of the nine criteria in the Article 29 Working Party DPIA guidelines (WP248 rev.01, endorsed by the EDPB), AI usually meets several: evaluation or scoring, large-scale processing, matching or combining datasets, and innovative use of new technology. For municipalities and public agencies the criterion of vulnerable data subjects comes on top, which WP248 also applies where there is an imbalance of power; in our reading, the relationship between a citizen and the body deciding on their benefits is an example. The Dutch DPA's list of processing operations that require a DPIA also often catches AI, through profiling, employee monitoring and the observation and influencing of behaviour, among others. The problem is what goes into the document after that. The AP's Copilot advice offers three lessons that reach further than that one product.

The first lesson is about reuse. The municipality had its own DPIA and also relied on a reference DPIA commissioned by SLM Rijk, the strategic vendor management function of the Dutch central government. The AP states: "Alhoewel de referentie-DPIA van SLM Rijk niet voldoet aan de eisen van artikel 35 AVG, biedt deze referentie-DPIA wel waardevolle inzichten in de (technische) werking van Copilot" (although the SLM Rijk reference DPIA does not meet the requirements of Article 35 GDPR, it does offer valuable insight into the (technical) workings of Copilot, our translation; chapter 4). The reason is not a verdict on quality: a reference DPIA is meant to "verder in te kleuren" (further colour in, our translation) an organisation's own assessment (chapter 4, footnote 4). The municipality's own DPIA also fell short according to the AP, among other things because of the vague purpose description and the lack of information to citizens (sections 6.2.1 and 6.2.4). A reference DPIA or a vendor's documentation is input for your DPIA, not your DPIA.

The second lesson is about the direction of the test. "Noodzakelijkheid en proportionaliteit dienen nadrukkelijk niet te worden bekeken vanuit de ‘oplossing’, maar juist vanuit het doeleinde van de verwerking" (necessity and proportionality must expressly not be assessed from the perspective of the 'solution', but from the purpose of the processing, our translation; section 6.2.1). A template that starts with "describe the application" pushes you in the wrong direction.

The third lesson is about what the AP expressly left aside. The advice does not address the lawful basis, nor whether special categories of personal data are processed and which Article 9 GDPR exception would then apply, nor the question "of de (trainings)data rechtmatig is verkregen en of de verwerkte persoonsgegevens mogen worden gebruikt voor het verder trainen van een generatief AI-systeem" (whether the (training) data were lawfully obtained and whether the personal data processed may be used for further training of a generative AI system, our translation; chapter 6). That the AP did not advise on these points means your own DPIA has to.

The DPIA AI addendum in ten parts

The addendum is built as a module: ten parts, each with a question the template does not ask, the reason the question matters, and the evidence you collect. The evidence is the most important part. A DPIA that claims "the vendor does not use customer data for training" without the contract clause or product term on which that rests is a claim, not an assessment.

Below we work through the parts. The order is deliberate: the chain and the data flows come before the risks, because you cannot weigh a risk in a processing operation you cannot draw.

1. System and chain

An AI application is rarely one product. There is a model, often from a different party than the platform you use it in; there is a layer that enriches your question with context from your own environment; there are filters; sometimes an integrator or a plug-in sits in between. Record for each link who it is, what that party does and what role it has under the GDPR. The AP advice shows why that is not a formality: the municipality itself indicated it was unclear in what capacity the vendor acted, and the AP advises "voorafgaand aan de verwerking helder te krijgen welke rol elke betrokken partij heeft" (to establish clearly, before the processing, what role each party involved has, our translation; section 6.3.1). A role allocation in the contract is not decisive: what counts is who in fact determines the purposes and means.

Also record the model version and how you will notice when it changes: a contract can run for years while the model underneath is replaced.

2. Three data flows: training, context and interaction

The template asks about "the personal data". With AI, there are three flows, each with its own assessment.

Training data. Even if you do not train the model yourself, its origin is your question. In Opinion 28/2024 on AI models the EDPB states that a controller deploying a model should, as part of its accountability, conduct an appropriate assessment to ascertain that the model was not developed by unlawfully processing personal data. How deep that assessment goes depends on the risks. The same opinion makes clear that a model trained on personal data is not automatically anonymous; that is a case-by-case assessment.

Context data. This is the flow most templates miss and the one that is largest for assistants in office software: the documents, emails, chats and calendars the system can reach to "ground" an answer. The AP warns that a generative AI system given access to an organisation's systems can "reeds bestaande (nog niet ontdekte) problemen blootleggen en verergeren" (expose and aggravate existing (as yet undiscovered) problems, our translation; section 6.1). A forgotten shared folder of old case files used to be untidiness; with an assistant on top, it is a source.

Interaction data. Prompts, output, feedback, telemetry and logs. The AP finds that input and output are linked to individual users and are therefore personal data, and that it is "niet relevant [is] of het alleen persoonsgegevens betreft die de Gemeente reeds verwerkt" (not relevant whether it only concerns personal data the municipality already processes, our translation; chapter 5).

3. Purpose per use case and purpose creep

An ordinary application has a purpose built into the software. A generative assistant can do anything you type a question about. The AP writes: "Het inzetten van een generatief AI-systeem mag geen doel op zich zijn" (deploying a generative AI system must not be a goal in itself, our translation; section 6.2.1), and points out that users can also use the system for purposes that conflict with what the organisation had in mind.

The addendum therefore replaces the single purpose with a use case register: per use case, the task, the user group, the data sources and what is expressly excluded. For each use case, test whether reuse of existing data is compatible with the original purpose (Article 6(4) GDPR). Purpose creep also has an AI Act side here. In our reading, an organisation that starts using a general-purpose AI system for an Annex III purpose, for example assessing whether someone is eligible for public assistance benefits (Annex III, point 5(a)), can itself become the provider of a high-risk system under Article 25(1)(c). How that plays out with individual prompts from individual staff members has not yet crystallised; all the more reason to exclude such use in the register or to assess it deliberately.

4. Accuracy, bias and hallucination as a data protection risk

In the template, accuracy usually appears as a question about source data: is the data you enter correct? With generative AI a second category emerges: personal data the system creates itself. A summary of an objection that invents a fact, a draft letter with the wrong name. The AP names this risk explicitly and points to automation bias: people attach too much weight to the output of an automated system (section 6.2.2). On Copilot, the AP observes, based on the reference DPIA, that the chat interface reinforces that tendency and that usable source references are missing (section 6.3.4).

Record in the addendum how you measure accuracy (on real tasks, not on a demo), how staff must check output and how much time they get for it, and what happens when an error reaches a data subject. Also test whether errors are unevenly distributed across groups (bias).

5. Decisions, human intervention and explanation

Map the work process and mark every point where a decision is taken about a person. The AP is sharp here: "Als een generatief AI-systeem een beslissende rol heeft in de besluitvorming, is er sprake van uitsluitend geautomatiseerde besluitvorming" (if a generative AI system plays a decisive role in decision-making, there is solely automated decision-making, our translation; section 6.2.3, referring to the SCHUFA judgment, C-634/21). In the Copilot advice, the AP notes that the intended work processes, such as objection and appeal, are processes "waarin bij uitstek individuele besluitvorming plaatsvindt" (in which individual decision-making par excellence takes place, our translation). According to the AP, oversight must be meaningful ("zinvol"), "en niet slechts een symbolische handeling" (and not merely a symbolic act, our translation; section 6.2.3, referring to the guidelines on automated decision-making and the AP's guidance on meaningful human intervention). In our reading, in practice that means the reviewer has the authority, the knowledge, the information and the time to reach a different outcome.

Where an automated decision is taken, the explanation duty is added. In Dun & Bradstreet Austria (C-203/22) the Court of Justice held that Article 15(1)(h) GDPR requires an explanation of the procedure and principles actually applied, in a way the data subject understands; handing over an algorithm or formula is not enough, and trade secrets go to the supervisory authority or court where necessary rather than the explanation lapsing. For the full test, see our guide to AI agents and GDPR Article 22.

6. Retaining prompts, output and logs

The template asks for one retention period per processing operation. With AI you need several: for prompts and answers, for the files the system creates, for audit logs and for what the vendor itself retains. The AP endorses as a precondition "het centraal vaststellen van bewaartermijnen voor de inhoud van prompts en antwoorden" (setting retention periods centrally for the content of prompts and answers, our translation; section 6.3.2) and warns that retaining data merely because it is convenient ("handig") for the system's operation will quickly be unlawful ("snel onrechtmatig", our translation; section 6.2.1).

Logs have a second side. A log that shows per staff member what they asked and when is also an instrument for monitoring staff. Record who may view the audit logs and for what, and involve the works council: in the Netherlands, a scheme on the processing of staff data or on facilities capable of monitoring behaviour or performance falls under the works council's consent right in Article 27 of the Works Councils Act (Wet op de ondernemingsraden).

7. Data subject rights in a model context

An access request about an AI application concerns more than the case file: it also covers prompts and output in which the data subject appears, and metadata the vendor generates. Based on the reference DPIA, the AP found plausible the conclusion that public bodies using Copilot could not honour the right of access with respect to Diagnostic Data, the metadata Copilot generates, because of a lack of transparency at the vendor, and the AP states that the processor must assist the controller in this (section 6.3.3; Article 28(3)(e) GDPR).

Rectification and erasure are harder. You can correct a generated letter; you cannot always prevent the system from making the same error again. Describe what you can do, and run a test request before go-live: request access as a fictitious data subject and see what actually surfaces. Under the information duty (Articles 13 and 14 GDPR), the AP recommends that the municipality register Copilot in the Algoritmeregister (the Dutch government's public algorithm register), and calls informing citizens an important precondition for exercising their rights (section 6.2.4). Registration does not replace the privacy notice or the information owed to data subjects.

8. Security: permissions and prompt injection

An assistant that can read what the user can read exposes every excessive permission. The AP considers it necessary that an organisation first examines its authorisation policy and current permissions, and mentions labelling documents to exclude files (sections 6.1.2 and 6.1.3). Those are conditions before go-live, not improvements for later.

On top of that comes a risk missing from classic security sections: prompt injection. An instruction hidden in a document, an email or a web page can make the system do or reveal something the user did not ask for; OWASP puts it at the top of its list of risks for large language model applications. In our analysis, the risk grows with every connector and every action the system may take on its own. So inventory the connectors, limit what the system may do, and include prompt injection in the test brief.

9. Vendor, terms and transfers

The template's questions about the data processing agreement remain necessary, but the addendum adds four. May the vendor use your data for training or product improvement, and where does it say so? Which data does the vendor process as an independent controller, and for which purposes? If the vendor processes data as an independent controller, you need your own lawful basis for that disclosure (Article 6(1) GDPR), and if you know in advance that a processor will not follow your instructions, you must take measures or not engage it (Article 28(1) GDPR; AP advice section 6.3.1). Where are data processed and who has access from which country (Chapter V GDPR)? With an American vendor, transfers to the United States usually rest on the adequacy decision for the EU-US Data Privacy Framework, provided the vendor is certified. Remote access by staff in other third countries requires its own transfer tool under Article 46 GDPR and a transfer impact assessment; the reference DPIA lists access by hired staff in 30 third countries as a risk (AP advice chapter 5). And which filters does the vendor apply to input and output? The AP considers it necessary that the controller "zelf inzicht en invloed heeft op eventuele filters" (has insight into and influence over any filters itself, our translation; section 6.3.4).

On the relationship with the vendor, the advice is unambiguous: "Het enkele feit dat een onrechtmatigheid plaatsvindt bij een leverancier ontslaat de Gemeente immers niet van haar eigen verantwoordelijkheid om de AVG na te leven" (the mere fact that unlawful processing takes place at a vendor does not, after all, release the municipality from its own responsibility to comply with the GDPR, our translation; chapter 8). For two of the high residual risks, the AP concludes that not starting is the only mitigation as long as the vendor provides no clarity (sections 6.3.5 and 6.3.6). Note: the AP based these conclusions on the first version of the reference DPIA (17 December 2024); it did not assess the SLM Rijk update of September 2025 (chapter 4). So check for yourself what the vendor has since clarified about Required Service Data and retention periods.

10. AI Act role and classification

The DPIA is a GDPR instrument; the AI Act adds a second layer. Record in the addendum:

• Your role. Usually you are the deployer. If you develop the system yourself or have it developed for you, and put it into service under your own name, you are the provider (Article 3(3)). If you put your name or trademark on a high-risk system, modify it substantially, or change its intended purpose so that it becomes high-risk, you become its provider (Article 25(1)).
• The classification. If the use case falls under Annex III, the system is high-risk unless the Article 6(3) exception applies (never where it profiles people). That exception is the provider's assessment, which it documents and registers (Article 6(4)); request that documentation as evidence, or produce it yourself if a change of purpose makes you the provider. After the postponement by the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), the high-risk obligations for Annex III apply from 2 December 2027.
• Article 26. From 2 December 2027, deployers of high-risk systems must among other things ensure human oversight by competent people, monitor the system and keep logs, and under paragraph 9 use the information the provider supplies under Article 13 to carry out their DPIA. That information is therefore evidence for parts 1 and 2.
• Article 27. A body governed by public law that deploys an Annex III high-risk system (except point 2, critical infrastructure) also carries out a FRIA. Under Article 27(4) you can refer in it to the parts of the DPIA that already answer the question. For high-risk systems intended to be used by public authorities that were already placed on the market or put into service before 2 December 2027, the high-risk obligations under Article 111(2) only apply on a significant change in their design, and in any event by 2 August 2030.
• Article 4 and Article 50. Organisations using AI take measures to support the AI literacy of their staff and of others who use AI on their behalf, such as contractors (Article 4), tailored to their tasks and the context; a particular level per individual does not have to be guaranteed. Article 50 has applied since 2 August 2026: a deployer that uses AI to generate or manipulate text published to inform the public on matters of public interest discloses that the text has been artificially generated or manipulated, unless the text has undergone human review or editorial control and someone holds editorial responsibility for the publication (paragraph 4). For a chatbot for citizens, it must also be clear that people are talking to AI (paragraph 1, a provider obligation; that can be you if you put the chatbot into service under your own name).

How to add the AI addendum to your DPIA

DPIA for Copilot and other AI assistants

For Microsoft 365 Copilot we have worked the addendum out into a free Copilot DPIA pack: a checklist following the measures in the AP advice, a vendor questionnaire on roles, Required Service Data and retention periods, and text blocks for the DPIA that you adapt to your own situation. With the ten parts of this addendum alongside, you know where each piece belongs. The AP stresses that other organisations must assess for themselves whether their processing matches what the municipality described (chapter 1); the pack is therefore a starting point, not a ready-made conclusion. For other use cases, from a chatbot on the website to an agent in the case management system, the same module works; the DPIA template for AI systems is then the base you attach it to.

If you want a lawyer to review or carry out the addendum, with a reasoned opinion that carries a name, the signed assessment is designed for that: fixed scope and fixed price, agreed in advance. If you want to build the addendum into your privacy function structurally rather than once, you can hire me as an AI and privacy lawyer, directly or through your intermediary, or assign the role to an external DPO who also covers AI oversight.