Een privacy officer krijgt op vrijdagmiddag een verzoek van de afdeling informatievoorziening: "We starten met een pilot met een AI-assistent. Kun je de DPIA invullen? Het sjabloon staat op de gebruikelijke plek." Het sjabloon is degelijk en elke vraag krijgt een antwoord. Het doel wordt "ondersteuning van medewerkers", de gegevens zijn "de gegevens waar medewerkers al bij kunnen", de ontvanger is "de leverancier, als verwerker". Het document is af, en het is op de punten die ertoe doen leeg. Het korte antwoord op de vraag wat er ontbreekt: een gewone DPIA mist bij AI de keten, de drie gegevensstromen, onjuiste output, doelverschuiving en de AI Act-rol, en een aanvulling van tien onderdelen vangt dat op.
Dat is geen verzonnen risico. In het advies na voorafgaande raadpleging over Microsoft 365 Copilot bij de gemeente Haarlemmermeer (zaak 2025-018225) schrijft de Autoriteit Persoonsgegevens over een vrijwel identieke doelomschrijving: "Deze doelomschrijving is echter te vaag en te algemeen, waardoor deze niet kan kwalificeren als een welbepaald en uitdrukkelijk omschreven doel" (paragraaf 6.2.1). Wat de casus betekent voor een Copilot-DPIA bij een gemeente, staat in ons stuk over het AP-advies. Dit artikel gaat over de bredere les: een sjabloon dat goed werkt voor een zaaksysteem stelt bij AI niet de vervolgvragen die ertoe doen. U hebt geen nieuw sjabloon nodig, wel een aanvulling.
Wat een gewone DPIA mist bij AI, in het kort
Een gewone DPIA beschrijft een verwerking met een bekende applicatie, vaste gegevensstromen en een afgebakend doel. Bij AI vallen daar vijf dingen tussendoor. Ten eerste is het systeem een keten: een modelaanbieder, een platform, soms een integrator en uw eigen configuratie, elk met een eigen rol onder de AVG en de AI Act. Ten tweede hebben de gegevens drie levens: training, context (de documenten en mails waar het systeem bij kan) en prompts, output en logs. Ten derde maakt het systeem zelf nieuwe persoonsgegevens, die onjuist kunnen zijn (artikel 5 lid 1 punt d AVG). Ten vierde is het doel bij generatieve AI open van opzet, zodat doelverschuiving de norm is en niet de uitzondering. Ten vijfde hangt de AI Act er rolgebonden plichten aan. De DPIA-AI-aanvulling is een module van tien onderdelen die u aan uw bestaande DPIA hangt. Ze vervangt de vier minimumonderdelen van artikel 35 lid 7 AVG niet, maar zorgt dat die bij AI werkelijk worden ingevuld.
Wanneer een DPIA verplicht is bij AI, staat in het stappenplan over de DPIA-plicht bij AI-systemen; de verhouding tot de grondrechtenbeoordeling van de AI Act in onze vergelijking van DPIA en FRIA. Dit artikel gaat ervan uit dat de DPIA er komt, en beantwoordt de vraag wat erin moet dat het sjabloon niet vraagt.
Waarom een standaard DPIA-sjabloon bij AI tekortschiet
Artikel 35 lid 7 AVG schrijft vier onderdelen voor: een systematische beschrijving van de verwerkingen en doeleinden, een beoordeling van noodzaak en evenredigheid, een beoordeling van de risico's voor de rechten en vrijheden van betrokkenen, en de beoogde maatregelen. Gangbare sjablonen zijn rond die vier onderdelen gebouwd en stellen hun vragen per verwerking. Naar onze analyse werkt dat zolang drie aannames kloppen: de applicatie doet wat ze is ontworpen te doen, de gegevens gaan langs bekende routes, en de uitkomst is een herhaling of bewerking van wat erin ging. Bij AI klopt geen van de drie.
Dat AI boven de drempel komt, is zelden de vraag. Van de negen criteria uit de DPIA-richtsnoeren van de Artikel 29-werkgroep (WP248 rev.01, door de EDPB overgenomen) raakt AI er doorgaans meerdere: evaluatie of scoring, grootschalige verwerking, het combineren van datasets en innovatief gebruik van nieuwe technologie. Voor gemeenten en uitvoeringsorganisaties komt het criterium van kwetsbare betrokkenen erbij, dat WP248 ook toepast bij een onevenwichtige machtsverhouding; naar onze lezing is de verhouding tussen een burger en de organisatie die over zijn uitkering besluit daar een voorbeeld van. Ook de lijst van de AP met verplichte DPIA's raakt AI vaak, via onder meer profilering, controle werknemers en observatie en beïnvloeding van gedrag. Het probleem is wat er daarna in het document komt. Het AP-advies over Copilot geeft daar drie lessen voor die verder reiken dan dat ene product.
De eerste les gaat over hergebruik. De gemeente had een eigen DPIA en baseerde zich daarnaast op een referentie-DPIA die in opdracht van SLM Rijk, het strategisch leveranciersmanagement van de Rijksoverheid, was opgesteld. De AP stelt: "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" (hoofdstuk 4). De reden is geen oordeel over de kwaliteit: een referentie-DPIA is bedoeld om de eigen afweging van een organisatie "verder in te kleuren" (hoofdstuk 4, voetnoot 4). Ook de eigen DPIA van de gemeente schoot volgens de AP tekort, onder meer door de te vage doelomschrijving en het ontbreken van informatie aan burgers (paragrafen 6.2.1 en 6.2.4). Een referentie-DPIA of de documentatie van een leverancier is invoer voor uw DPIA, niet uw DPIA.
De tweede les gaat over de richting van de toets. "Noodzakelijkheid en proportionaliteit dienen nadrukkelijk niet te worden bekeken vanuit de 'oplossing', maar juist vanuit het doeleinde van de verwerking" (paragraaf 6.2.1). Een sjabloon dat begint met "beschrijf de applicatie" duwt u de verkeerde kant op.
De derde les gaat over wat de AP uitdrukkelijk liet liggen. Het advies gaat niet in op de grondslag, niet op de vraag of bijzondere persoonsgegevens worden verwerkt en welke uitzondering van artikel 9 AVG dan geldt, en ook niet op de vraag "of de (trainings)data rechtmatig is verkregen en of de verwerkte persoonsgegevens mogen worden gebruikt voor het verder trainen van een generatief AI-systeem" (hoofdstuk 6). Dat de AP er niet over adviseerde, betekent dat uw eigen DPIA het moet doen.
De DPIA-AI-aanvulling in tien onderdelen
De aanvulling is opgebouwd als een module: tien onderdelen, elk met een vraag die het sjabloon niet stelt, de reden waarom de vraag ertoe doet, en het bewijs dat u verzamelt. Het bewijs is het belangrijkste deel. Een DPIA die beweert dat "de leverancier geen klantgegevens gebruikt voor training" zonder de contractclausule of productvoorwaarde waarop dat rust, is een bewering en geen beoordeling.
| Onderdeel | Kernvraag | Waarom | Bewijs om te verzamelen |
|---|---|---|---|
| 1. Systeem en keten | Welk model, welk platform, welke integrator, welke eigen configuratie, en wie is wat? | Rollen onder AVG en AI Act volgen de keten, niet het contract | Architectuurschets, lijst van (sub)verwerkers, modelversie, instructies van de aanbieder |
| 2. Drie gegevensstromen | Wat gebeurt er met trainingsdata, contextdata en prompts, output en logs? | Elke stroom heeft een eigen doel, bewaartermijn en ontvanger | Gegevensstroomschema per stroom, voorwaarde over training, bewaarinstellingen |
| 3. Doel per toepassing | Voor welke concrete taken, door wie, en wat is uitgesloten? | "Ondersteuning" is geen welbepaald doel; open systemen schuiven op | Register van toepassingen, gebruiksbeleid, technische blokkades |
| 4. Juistheid en bias | Hoe vaak is de output fout, voor wie, en wat gebeurt er dan? | Gegenereerde onjuiste persoonsgegevens raken artikel 5 lid 1 punt d en artikel 16 | Testresultaten op echte taken, controle-instructie, foutprocedure |
| 5. Besluiten, menselijke tussenkomst en uitleg | Waar in het proces wordt over mensen besloten, en wie beslist werkelijk? | Artikel 22 AVG en de uitlegplicht uit Dun & Bradstreet | Processchema met beslispunten, werkinstructie, steekproef van beoordelingen |
| 6. Prompts, output en logs bewaren | Wat wordt gelogd, hoe lang, wie kan erbij, en wordt er meegekeken naar medewerkers? | Opslagbeperking en het risico van een volgsysteem voor personeel | Bewaarbeleid, instellingen, toegangsrechten op auditlogs, standpunt ondernemingsraad |
| 7. Rechten van betrokkenen | Kunt u inzage, rectificatie en verwijdering waarmaken over de hele keten? | De verwerkingsverantwoordelijke blijft aan de lat, ook als alleen de leverancier de gegevens ziet | Procedure voor verzoeken, contractuele bijstand van de verwerker, proefverzoek |
| 8. Beveiliging | Wat kan het systeem lezen, wat kan het doen, en hoe is het te misleiden? | Te ruime autorisaties en promptinjectie zijn de nieuwe lekroutes | Autorisatiereview, labeling, inventaris van koppelingen, test op promptinjectie |
| 9. Leverancier, voorwaarden en doorgifte | Wat mag de leverancier zelf met de gegevens, waar gaan ze heen, en welke filters gelden? | Een onrechtmatigheid bij de leverancier ontslaat u niet | Verwerkersovereenkomst, productvoorwaarden, doorgiftemechanisme en doorgiftetoets per land, antwoorden op uw vragenlijst |
| 10. AI Act-rol en classificatie | Bent u aanbieder of gebruiksverantwoordelijke, is de toepassing hoog risico, en welke plichten gelden nu al (AI-geletterdheid, transparantie)? | De AI Act hangt plichten aan rol en doel, bovenop de AVG | Classificatienotitie, documentatie van de artikel 6 lid 3-beoordeling van de aanbieder, maatregelen AI-geletterdheid, transparantiecheck artikel 50, eventueel de FRIA |
Hieronder werken we de onderdelen uit. De volgorde is bewust: de keten en de gegevensstromen komen vóór de risico's, omdat u een risico niet kunt wegen in een verwerking die u niet kunt tekenen.
1. Systeem en keten
Een AI-toepassing is zelden één product. Er is een model, vaak van een andere partij dan het platform waarin u het gebruikt; er is een laag die uw vraag aanvult met context uit uw eigen omgeving; er zijn filters; soms zit er een integrator of een plug-in tussen. Leg per schakel vast wie het is, wat die partij doet en welke rol ze onder de AVG heeft. Het AP-advies laat zien waarom dat geen formaliteit is: de gemeente gaf zelf aan dat niet duidelijk was in welke hoedanigheid de leverancier handelde, en de AP adviseert om "voorafgaand aan de verwerking helder te krijgen welke rol elke betrokken partij heeft" (paragraaf 6.3.1). Een rolverdeling in het contract is daarbij niet doorslaggevend: het gaat om wie feitelijk doel en middelen bepaalt.
Noteer ook de modelversie en hoe u merkt dat die verandert: een contract kan jaren meegaan terwijl het model eronder wordt vervangen.
2. Drie gegevensstromen: training, context en interactie
Het sjabloon vraagt naar "de persoonsgegevens". Bij AI zijn dat drie stromen met elk een eigen beoordeling.
Trainingsdata. Ook als u het model niet zelf traint, is de herkomst ervan uw vraag. De EDPB stelt in Advies 28/2024 over AI-modellen dat een verwerkingsverantwoordelijke die een model inzet, als onderdeel van zijn verantwoordingsplicht passend moet beoordelen of het model niet is ontwikkeld met onrechtmatige verwerking van persoonsgegevens. Hoe diep die beoordeling gaat, hangt af van de risico's. Hetzelfde advies maakt duidelijk dat een model dat op persoonsgegevens is getraind niet automatisch anoniem is; dat is een beoordeling per geval.
Contextdata. Dit is de stroom die de meeste sjablonen missen en die bij assistenten in kantoorsoftware het grootst is: de documenten, mails, chats en agenda's waar het systeem bij kan om een antwoord te "gronden". De AP waarschuwt dat een generatief AI-systeem dat toegang krijgt tot de systemen van een organisatie "reeds bestaande (nog niet ontdekte) problemen blootleggen en verergeren" kan (paragraaf 6.1). Een vergeten gedeelde map met oude dossiers was een slordigheid; met een assistent erboven is het een bron.
Interactiedata. Prompts, output, feedback, telemetrie en logs. De AP stelt vast dat in- en output aan individuele gebruikers worden gekoppeld en daarom persoonsgegevens zijn, en dat het "niet relevant [is] of het alleen persoonsgegevens betreft die de Gemeente reeds verwerkt" (hoofdstuk 5).
3. Doel per toepassing en doelverschuiving
Een gewone applicatie heeft een doel dat in de software zit. Een generatieve assistent kan alles waar u een vraag over typt. De AP schrijft: "Het inzetten van een generatief AI-systeem mag geen doel op zich zijn" (paragraaf 6.2.1), en wijst erop dat gebruikers het systeem ook kunnen inzetten voor doelen die in strijd zijn met wat de organisatie voor ogen had.
De aanvulling vervangt daarom het ene doel door een register van toepassingen: per toepassing de taak, de gebruikersgroep, de gegevensbronnen en wat uitdrukkelijk is uitgesloten. Toets voor elke toepassing of hergebruik van bestaande gegevens verenigbaar is met het oorspronkelijke doel (artikel 6 lid 4 AVG). Doelverschuiving heeft hier ook een AI Act-kant. Naar onze lezing kan een organisatie die een AI-systeem voor algemene doeleinden gaat gebruiken voor een doel uit bijlage III, bijvoorbeeld het beoordelen of iemand in aanmerking komt voor een uitkering (bijlage III punt 5 onder a), onder artikel 25 lid 1 punt c zelf aanbieder van een hoog-risicosysteem worden. Hoe dat uitpakt bij losse prompts van individuele medewerkers, is nog niet uitgekristalliseerd; des te meer reden om zulk gebruik in het register uit te sluiten of bewust te beoordelen.
4. Juistheid, bias en hallucinatie als gegevensbeschermingsrisico
In het sjabloon staat juistheid meestal als vraag over brongegevens: kloppen de gegevens die u invoert? Bij generatieve AI ontstaat een tweede categorie: persoonsgegevens die het systeem zelf maakt. Een samenvatting van een bezwaarschrift die een feit verzint, een conceptbrief met de verkeerde naam. De AP noemt dit risico bij naam en wijst op automation bias: mensen hechten te veel waarde aan de output van een geautomatiseerd systeem (paragraaf 6.2.2). Over Copilot merkt de AP, op basis van de referentie-DPIA, op dat de chatinterface die neiging versterkt en dat bruikbare bronverwijzingen ontbreken (paragraaf 6.3.4).
Leg in de aanvulling vast hoe u juistheid meet (op echte taken, niet op een demo), hoe medewerkers output moeten controleren en hoeveel tijd ze daarvoor krijgen, en wat er gebeurt als een fout een betrokkene bereikt. Toets ook of fouten ongelijk verdeeld zijn over groepen (bias).
5. Besluiten, menselijke tussenkomst en uitleg
Teken het werkproces en markeer elk punt waar over een persoon wordt besloten. De AP is hier scherp: "Als een generatief AI-systeem een beslissende rol heeft in de besluitvorming, is er sprake van uitsluitend geautomatiseerde besluitvorming" (paragraaf 6.2.3, met een verwijzing naar het SCHUFA-arrest, C-634/21). In het Copilot-advies constateert de AP dat de beoogde werkprocessen, zoals bezwaar en beroep, processen zijn "waarin bij uitstek individuele besluitvorming plaatsvindt". Het toezicht moet volgens de AP "zinvol" zijn, "en niet slechts een symbolische handeling" (paragraaf 6.2.3, met verwijzing naar de richtsnoeren over geautomatiseerde besluitvorming en de handvatten van de AP voor betekenisvolle menselijke tussenkomst). Naar onze lezing betekent dat in de praktijk dat de beoordelaar het mandaat, de kennis, de informatie en de tijd heeft om tot een andere uitkomst te komen.
Waar wel een geautomatiseerd besluit valt, komt de uitlegplicht erbij. Het Hof van Justitie oordeelde in Dun & Bradstreet Austria (C-203/22) dat artikel 15 lid 1 punt h AVG een uitleg vraagt van de procedure en de beginselen die feitelijk zijn toegepast, op een manier die de betrokkene begrijpt; een algoritme of formule overhandigen is niet genoeg, en bedrijfsgeheimen gaan zo nodig naar de toezichthouder of de rechter in plaats van dat de uitleg vervalt. Voor de volledige toets verwijzen we naar ons stuk over AI-agents en artikel 22 AVG.
6. Prompts, output en logs bewaren
Het sjabloon vraagt één bewaartermijn per verwerking. Bij AI hebt u er meerdere nodig: voor prompts en antwoorden, voor de bestanden die het systeem maakt, voor auditlogs en voor wat de leverancier zelf bewaart. De AP onderschrijft als randvoorwaarde "het centraal vaststellen van bewaartermijnen voor de inhoud van prompts en antwoorden" (paragraaf 6.3.2) en waarschuwt dat bewaren omdat het "handig" is voor de werking van het systeem "snel onrechtmatig" zal zijn (paragraaf 6.2.1).
Logs hebben een tweede kant. Een log die per medewerker laat zien wat die vroeg en wanneer, is ook een instrument om medewerkers te volgen. Leg vast wie de auditlogs mag inzien en waarvoor, en betrek de ondernemingsraad: een regeling over de verwerking van personeelsgegevens of over voorzieningen die geschikt zijn om gedrag of prestaties te controleren, valt onder het instemmingsrecht van artikel 27 van de Wet op de ondernemingsraden.
7. Rechten van betrokkenen in modelcontext
Een inzageverzoek over een AI-toepassing gaat over meer dan het zaakdossier: ook over prompts en output waarin de betrokkene voorkomt, en over metadata die de leverancier genereert. Op basis van de referentie-DPIA vond de AP de conclusie aannemelijk dat overheidsorganisaties bij Copilot het inzagerecht ten aanzien van Diagnostic Data, de metadata die Copilot genereert, niet konden waarmaken door gebrek aan transparantie bij de leverancier, en stelt de AP dat de verwerker de verwerkingsverantwoordelijke daarbij moet bijstaan (paragraaf 6.3.3; artikel 28 lid 3 punt e AVG).
Rectificatie en verwijdering zijn lastiger. U kunt een gegenereerde brief corrigeren; u kunt niet altijd voorkomen dat het systeem dezelfde fout opnieuw maakt. Beschrijf wat u wel kunt, en doe vóór de start een proefverzoek: vraag als fictieve betrokkene inzage en kijk wat er werkelijk boven water komt. In het kader van de informatieplicht (artikelen 13 en 14 AVG) beveelt de AP de gemeente aan Copilot te registreren in het Algoritmeregister, en noemt ze het informeren van burgers een belangrijke randvoorwaarde om rechten te kunnen uitoefenen (paragraaf 6.2.4). Registratie vervangt de privacyverklaring en de informatie aan betrokkenen niet.
8. Beveiliging: autorisaties en promptinjectie
Een assistent die kan lezen wat de gebruiker kan lezen, maakt elke te ruime autorisatie zichtbaar. De AP acht het noodzakelijk dat een organisatie eerst haar autorisatiebeleid en lopende autorisaties onderzoekt, en noemt het labelen van documenten om bestanden uit te sluiten (paragrafen 6.1.2 en 6.1.3). Dat zijn voorwaarden vóór de start, geen verbeterpunten voor later.
Daarbovenop komt een risico dat in klassieke beveiligingsparagrafen ontbreekt: promptinjectie. Een instructie verstopt in een document, een mail of een webpagina kan het systeem iets laten doen of prijsgeven wat de gebruiker niet vroeg; OWASP zet dit bovenaan zijn lijst van risico's voor toepassingen met grote taalmodellen. Naar onze analyse groeit het risico met elke koppeling en elke handeling die het systeem zelfstandig mag uitvoeren. Inventariseer daarom de koppelingen, beperk wat het systeem mag doen, en neem promptinjectie op in de testopdracht.
9. Leverancier, voorwaarden en doorgifte
De vragen die het sjabloon stelt over de verwerkersovereenkomst blijven nodig, maar de aanvulling voegt er vier aan toe. Mag de leverancier uw gegevens gebruiken voor training of productverbetering, en waar staat dat? Welke gegevens verwerkt de leverancier als zelfstandige verwerkingsverantwoordelijke, en voor welke doelen? Verwerkt de leverancier gegevens als zelfstandige verwerkingsverantwoordelijke, dan hebt u voor die verstrekking een eigen grondslag nodig (artikel 6 lid 1 AVG), en weet u vooraf dat een verwerker zich niet aan uw instructies zal houden, dan moet u maatregelen treffen of hem niet inschakelen (artikel 28 lid 1 AVG; AP-advies paragraaf 6.3.1). Waar worden gegevens verwerkt en wie heeft vanuit welk land toegang (hoofdstuk V AVG)? Bij een Amerikaanse leverancier rust doorgifte naar de Verenigde Staten meestal op het adequaatheidsbesluit voor het EU-US Data Privacy Framework, mits de leverancier gecertificeerd is. Toegang op afstand door personeel in andere derde landen vraagt een eigen doorgifte-instrument uit artikel 46 AVG en een doorgiftetoets; de referentie-DPIA noemt toegang door ingehuurd personeel in 30 derde landen als risico (AP-advies hoofdstuk 5). En welke filters past de leverancier toe op invoer en uitvoer? De AP acht het noodzakelijk dat de verwerkingsverantwoordelijke "zelf inzicht en invloed heeft op eventuele filters" (paragraaf 6.3.4).
Over de verhouding met de leverancier is het advies ondubbelzinnig: "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" (hoofdstuk 8). Voor twee van de hoge restrisico's concludeert de AP dat niet starten de enige mitigatie is zolang de leverancier geen duidelijkheid geeft (paragrafen 6.3.5 en 6.3.6). Let op: de AP baseerde deze conclusies op de eerste versie van de referentie-DPIA (17 december 2024); de update van SLM Rijk van september 2025 heeft de AP niet beoordeeld (hoofdstuk 4). Controleer dus zelf wat de leverancier sindsdien over Required Service Data en bewaartermijnen heeft verduidelijkt.
10. AI Act-rol en classificatie
De DPIA is een AVG-instrument; de AI Act legt er een tweede laag naast. Leg in de aanvulling vast:
- Uw rol. Meestal bent u gebruiksverantwoordelijke. Ontwikkelt u het systeem zelf of laat u het voor u ontwikkelen, en stelt u het onder eigen naam in gebruik, dan bent u aanbieder (artikel 3 punt 3). Zet u uw naam of merk op een hoog-risicosysteem, wijzigt u het substantieel of wijzigt u het doel zo dat het hoog risico wordt, dan wordt u het (artikel 25 lid 1).
- De classificatie. Valt de toepassing onder bijlage III, dan is het systeem hoog risico, tenzij de uitzondering van artikel 6 lid 3 geldt (nooit bij profilering). Die uitzondering is een beoordeling van de aanbieder, die hij documenteert en registreert (artikel 6 lid 4); vraag die documentatie op als bewijs, of maak haar zelf als u door een doelwijziging aanbieder wordt. Na het uitstel door de Digital Omnibus (Verordening (EU) 2026/1744, in werking sinds 27 juli 2026) gelden de hoog-risicoplichten voor bijlage III vanaf 2 december 2027.
- Artikel 26. Voor gebruiksverantwoordelijken van hoog-risicosystemen gelden vanaf 2 december 2027 onder meer menselijk toezicht door bekwame mensen, monitoring en het bewaren van logs, en lid 9: gebruik de informatie die de aanbieder onder artikel 13 verstrekt voor uw DPIA. Die informatie is dus bewijs voor onderdeel 1 en 2.
- Artikel 27. Een publiekrechtelijke organisatie die een hoog-risicosysteem uit bijlage III inzet (met uitzondering van punt 2, kritieke infrastructuur), doet ook een FRIA. Volgens artikel 27 lid 4 kunt u daarin verwijzen naar de delen van de DPIA die de vraag al beantwoorden. Voor hoog-risicosystemen bedoeld voor gebruik door overheidsinstanties die al vóór 2 december 2027 in de handel zijn gebracht of in gebruik zijn gesteld, gelden de hoog-risicoplichten volgens artikel 111 lid 2 pas bij een aanzienlijke wijziging in hun ontwerp, en in ieder geval uiterlijk op 2 augustus 2030.
- Artikel 4 en artikel 50. Organisaties die AI gebruiken nemen maatregelen die de AI-geletterdheid ondersteunen van hun personeel en van anderen die namens hen AI gebruiken, zoals ingehuurde krachten (artikel 4), afgestemd op hun taken en de context; een bepaald niveau per persoon hoeft niet te worden gegarandeerd. Sinds 2 augustus 2026 geldt artikel 50: wie AI gebruikt voor tekst die wordt gepubliceerd om het publiek te informeren over zaken van algemeen belang, maakt bekend dat de tekst kunstmatig is gegenereerd of bewerkt, tenzij de tekst een proces van menselijke toetsing of redactionele controle heeft ondergaan en iemand de redactionele verantwoordelijkheid voor de publicatie draagt (lid 4). Bij een chatbot voor burgers moet bovendien duidelijk zijn dat men met AI praat (lid 1, een plicht van de aanbieder; dat kunt u zelf zijn als u de chatbot onder eigen naam in gebruik stelt).
Zo voegt u de AI-aanvulling aan uw DPIA toe
Begin bij de DPIA die u al hebt
Kopieer het sjabloon niet opnieuw. Vul het bestaande document in zoals gebruikelijk en hang de tien onderdelen eraan als bijlage, met verwijzingen naar de plekken in het hoofddocument die erdoor worden aangevuld. Zo blijft de DPIA herkenbaar voor de FG en het bestuur, en is zichtbaar wat AI eraan toevoegt. Waar de aanvulling past in de bredere route van AI-intake, register en toezicht door de FG, leest u in AI-governance via de privacyfunctie.
Teken de keten en de drie stromen vóór de risico's
Onderdeel 1 en 2 zijn het fundament. Zolang niet duidelijk is wie welke rol heeft en welke gegevens via training, context en interactie bewegen, is elke risicobeoordeling een schatting. Vraag de leverancier om de stukken die u nodig hebt; wat niet komt, noteert u als open punt.
Vervang het algemene doel door een register van toepassingen
Schrijf per toepassing op wat de taak is, wie het systeem gebruikt, welke bronnen het mag raadplegen en wat uitgesloten is. Begin klein: de AP noemt het positief dat de gemeente met een kleinschalige pilot wilde beginnen (hoofdstuk 5) en wijst op toepassingen waarbij vooraf het kleinste risico wordt verwacht, met de kanttekening dat ook een pilot aan de AVG moet voldoen (hoofdstuk 8).
Vul de bewijskolom, en maak van gaten startvoorwaarden
Elke bewering in de aanvulling krijgt een bron: een contractclausule, een instelling, een testresultaat, een besluit. Wat u niet kunt onderbouwen, wordt een voorwaarde waaraan voldaan moet zijn vóór ingebruikname. Blijft na alle maatregelen een hoog restrisico over, dan volgt een voorafgaande raadpleging van de AP (artikel 36 AVG).
Plan de herbeoordeling en de koppeling met de FRIA
Leg vast bij welke wijzigingen u de DPIA opnieuw beoordeelt: een nieuw model, een nieuwe koppeling, een nieuwe toepassing in het register, gewijzigde voorwaarden (artikel 35 lid 11 AVG). De AP wijst erop dat u bij een wezenlijk andere verwerking moet beoordelen of een nieuwe DPIA en eventueel een nieuwe voorafgaande raadpleging nodig is (hoofdstuk 9). Valt de toepassing onder artikel 27 AI Act, bouw de FRIA dan op deze aanvulling.
DPIA voor Copilot en andere AI-assistenten
Voor Microsoft 365 Copilot hebben we de aanvulling uitgewerkt tot een gratis Copilot-DPIA-pakket: een checklist langs de maatregelen uit het AP-advies, een vragenlijst voor de leverancier over rollen, Required Service Data en bewaartermijnen, en tekstblokken voor de DPIA die u op uw eigen situatie aanpast. Met de tien onderdelen van deze aanvulling ernaast weet u waar elk stuk thuishoort. De AP benadrukt dat andere organisaties zelf moeten beoordelen of hun verwerking overeenkomt met wat de gemeente beschreef (hoofdstuk 1); het pakket is daarom een startpunt en geen kant-en-klare conclusie. Voor andere toepassingen, van een chatbot op de website tot een agent in het zaaksysteem, werkt dezelfde module; het DPIA-template voor AI-systemen is dan de basis waaraan u haar hangt.
Wilt u dat een jurist de aanvulling toetst of uitvoert, met een onderbouwd oordeel waar een naam onder staat, dan is de beoordeling met handtekening daarvoor bedoeld: vaste scope en vaste prijs, vooraf afgesproken. Wilt u de aanvulling niet eenmalig, maar structureel in uw privacyfunctie inbouwen, dan kunt u mij inhuren als AI- en privacyjurist, rechtstreeks of via uw bemiddelaar, of de rol beleggen bij een externe FG die ook AI-toezicht doet.
Veelgestelde vragen over de DPIA voor AI
Bronnen
Nieuwsbrief
Elke dinsdag de AI Act-week vooruit in 5 minuten
Praktische duiding van deadlines, richtsnoeren en toezicht, zodat u weet wat er deze week toe doet. Geen spam en u schrijft zich met één klik weer uit.
Praktisch en kort · Geen spam · Met één klik uitschrijven