Het populairste advies over GDPR privacy by design is ook het minst nuttige: "bouw privacy vanaf het begin in." Artikel 25 vereist meer dan een vroege beleidsevaluatie of een privacyverklaring die aan een productlancering wordt gekoppeld. Het verplicht verwerkingsverantwoordelijken om verdedigbare technische en organisatorische keuzes te maken, bewijs van die keuzes te bewaren en deze opnieuw te bekijken zolang de verwerking doorloopt. Voor een engineering- of governanceteam is de praktische vraag daarom niet of een systeem "privacyvriendelijk" is. De vraag is of iemand de architectuur, standaardinstellingen, leveranciersafspraken, toegangsregels, risicobeoordeling en operationele logs kan inspecteren en vervolgens kan begrijpen waarom het systeem persoonsgegevens op die manier verwerkt.
Wat Privacy by Design daadwerkelijk betekent onder Artikel 25
Artikel 25 maakt van privacy by design een engineeringplicht gedurende de hele levenscyclus, waarbij de verantwoordelijkheid verdeeld is over de mensen die een systeem bouwen, leveren, configureren en bedienen. Onder Artikel 25(1) moeten verwerkingsverantwoordelijken passende technische en organisatorische maatregelen treffen bij het bepalen van de verwerkingsmiddelen en gedurende de verwerking zelf. De EDPB Guidelines 4/2019 benoemen maatregelen zoals dataminimalisatie, pseudonimisering en versleuteling als controles die in de architectuur moeten worden ingebouwd, en niet als aanvullingen na implementatie. Gepseudonimiseerde informatie blijft persoonsgegevens wanneer aanvullende informatie heridentificatie mogelijk kan maken, dus het resterende risico moet zichtbaar blijven in het ontwerp.
Een privacyverklaring legt de intentie vast. Het toont de implementatie niet aan. Inspecteerbaar bewijs omvat vereistendocumentatie, data-flow-diagrammen, instructies aan leveranciers, configuratiebeslissingen, testresultaten, bewaarregels, toegangsevaluaties en risicobeoordelingen. Bouwers kunnen de controle documenteren, leveranciers kunnen relevante instellingen en verwerkingsdetails zichtbaar maken, en implementatieteams kunnen bewijs bewaren dat de productieconfiguratie overeenkomt met het goedgekeurde ontwerp. De verwerkingsverantwoordelijke blijft aansprakelijk voor de verwerking, maar die aansprakelijkheid hangt af van artefacten die over die keten zijn verdeeld.
Ontwerp en standaard zijn afzonderlijke verplichtingen
Artikel 25(1) betreft waarborgen die in verwerkingsoperaties zijn ingebouwd. Artikel 25(2) betreft wat er standaard gebeurt. Het vereist dat standaard alleen de persoonsgegevens worden verwerkt die nodig zijn voor elk specifiek doel, waarbij de hoeveelheid verzamelde gegevens, de verwerkingsomvang, de bewaartermijn en de toegankelijkheid worden beperkt. Persoonsgegevens mogen zonder tussenkomst van de betrokkene niet toegankelijk zijn voor een onbeperkt aantal mensen. Article 25(2) GDPR
Een systeem kan sterke versleuteling gebruiken en toch niet voldoen aan de standaardverplichting als optionele velden zijn ingeschakeld, bewaring geen gedefinieerd doel heeft of gegevens meer mensen bereiken dan nodig is. Een restrictieve interface kan een architectuur niet corrigeren die duidelijke identificatiegegevens naar een externe dienst stuurt. Deze afwegingen moeten zichtbaar zijn in configuratiebasislijnen, implementatiecontroles en uitzonderingsgoedkeuringen.
Voor gevoelige supportworkflows laat privacy by design for customer support zien hoe deze verplichtingen zich vertalen naar operationele keuzes. In AI-ondersteund werk geldt dezelfde levenscycluslogica voor modellen, prompts, integraties en uitvoerpaden, zoals beschreven in GDPR responsibilities in a generative AI workflow.
Praktische regel: Behandel elke privacyclaim als een controle die inspecteerbaar bewijs moet opleveren.
De vier factoren die verwerkingsverantwoordelijken moeten afwegen
Artikel 25 vereist niet één architectuur voor elke verwerkingsverantwoordelijke. Het vereist een gedocumenteerde keuze op basis van vier factoren: de stand van de techniek, de implementatiekosten, de aard, omvang, context en doeleinden van de verwerking, en de risico's voor de rechten en vrijheden van mensen. De ICO presenteert deze factoren als de basis voor het selecteren van passende ontwerpmaatregelen. ICO guidance on data protection by design and by default
Lees de factoren als één beoordeling
Stand van de techniek betekent het identificeren van technische en organisatorische maatregelen die redelijkerwijs beschikbaar zijn voor de verwerking, in plaats van de nieuwste functie van een leverancier te accepteren. Versleuteling, tokenisatie, segmentatie, toegangsbeperkingen, privacytests en gecontroleerde verwijdering kunnen allemaal relevant zijn. Het ontwerpdossier moet uitleggen welke waarborgen zijn geselecteerd, waarom ze bij de verwerking passen en wat bouwers, leveranciers of implementatieteams moeten uitvoeren.
Kosten ondersteunen proportionaliteit, niet een algemene vrijstelling. De verwerkingsverantwoordelijke moet de implementatie-inspanning, operationele beperkingen, overwogen alternatieven en de reden voor de gekozen controle vastleggen. Een beperkt budget maakt een voorzienbaar risico met grote impact niet aanvaardbaar. De resulterende beslissing moet zichtbaar zijn in goedkeuringsdocumentatie, inkoopdocumenten of een uitzonderingslog.
Aard, omvang, context en doeleinden bepalen welk probleem de controles moeten aanpakken. Een vertrouwelijke juridische workflow, een systeem voor werknemersmonitoring en een openbaar contactformulier omvatten verschillende gegevens, betrokken personen, ontvangers, doeleinden en bedrijfsomstandigheden. Die details moeten verschijnen in de verwerkingsbeschrijving, het systeemontwerp, de data-flow-kaart en de leveranciersconfiguratie.
Risico's voor rechten en vrijheden hebben meer nodig dan een generiek dreigingslabel. De analyse moet mogelijke schade aan identificeerbare personen beschrijven, de waarschijnlijkheid en ernst beoordelen en elk risico koppelen aan een waarborg. Ze moet ook vastleggen wie een eventueel restrisico heeft aanvaard en wanneer die beslissing opnieuw moet worden bekeken.
Een verdedigbaar Artikel 25-dossier bevat daarom meer dan vier kopjes. Het verbindt elke factor met een beslissing, een verantwoordelijke eigenaar, een inspecteerbaar implementatieartefact en een reviewtrigger. Die structuur maakt verantwoordelijkheid toetsbaar over de verwerkingsverantwoordelijke, zijn bouwers, leveranciers en implementatieteams heen.
Dataminimalisatie en Privacy by Default in de praktijk
Artikel 25(2) wordt nuttig wanneer een team het vertaalt naar vier controlevlakken: verzameling, verwerkingsomvang, bewaring en toegankelijkheid. Dit zijn geen abstracte privacyprincipes. Het zijn de plekken waar productvereisten, code, configuratie en operationele review de blootstelling kunnen beperken of vergroten.
De vier controlevlakken
Bij het verzamelen moet een formulier of invoerinterface een onderbouwing van de noodzaak op veldniveau hebben. Als een veld geen vastgelegd doel heeft, moet de standaardkeuze zijn om het weg te laten en niet om het te verzamelen "voor het geval het nuttig wordt". Dit verhindert geen legitieme verzameling. Het dwingt het team om elk veld te koppelen aan een specifiek verwerkingsdoel.
Tijdens de verwerking moeten regels attributen verwijderen of onderdrukken die de volgende bewerking niet nodig heeft. Een samenvattingsdienst heeft mogelijk documenttekst nodig, maar geen directe identificatoren. Een analysepijplijn heeft mogelijk een gebeurteniscategorie nodig zonder de onderliggende inhoud te bewaren. De maatregel is inspecteerbaar wanneer de transformatieregel, de testcase en de resulterende payload kunnen worden beoordeeld.
Bewaring vereist een afdwingbaar schema, niet alleen een verklaring dat gegevens niet langer dan nodig worden bewaard. Logica voor verwijdering of archivering moet het doel identificeren, de gebeurtenis die de bewaartermijn start, het verantwoordelijke systeem en het bewijs dat de regel is uitgevoerd. Waar langere bewaring een afzonderlijk doel dient, moet dat doel worden beoordeeld in plaats van te worden overgenomen van de oorspronkelijke workflow.
Toegankelijkheid betreft zowel interne gebruikers als verdere verspreiding. Op rollen gebaseerde scopes, tenant-isolatie, goedkeuringspoorten en beperkte exports kunnen voorkomen dat persoonsgegevens voor een onbepaald publiek beschikbaar komen. De richtlijnen van de ICO benadrukken ook dat pseudonimisering, encryptie en andere maatregelen moeten worden geselecteerd in het licht van de verwerkingscontext en het risico, en niet moeten worden behandeld als vervanging voor minimalisering. ICO pseudonymisation guidance
- Hoeveelheid verzamelde gegevens — Inspecteerbare maatregel: beslissingen over noodzaak op veldniveau, beperkte formulieren en invoerfilters
- Omvang van de verwerking — Inspecteerbare maatregel: payloadregels, attribuutonderdrukking en doelspecifieke verwerkingspaden
- Bewaartermijn — Inspecteerbare maatregel: afgedwongen bewaarschema's, verwijderingstaken en uitvoeringsrecords
- Toegankelijkheid — Inspecteerbare maatregel: rolscopes, exportbeperkingen, goedkeuringspoorten en toegangslogs
De afweging is meestal zichtbaar in analyses. Meer velden langer bewaren kan rijkere analyse ondersteunen, maar het vergroot ook de informatie die beschikbaar is voor later gebruik, toegang en openbaarmaking. Een privacy-by-default-ontwerp maakt die afweging expliciet en vereist een actieve beslissing voordat verzameling of zichtbaarheid wordt uitgebreid.
Voor AI-workflows biedt dataminimalisering in een generatieve AI-workflow een nuttig perspectief om te onderzoeken wat een model bereikt, wat in logs achterblijft en wat de gebruiker kan exporteren.
Pseudonimisering als gelaagde ontwerpmaatregel
Pseudonimisering is een architectuur voor risicovermindering, geen omzetting van persoonsgegevens in anonieme gegevens. De bescherming ervan hangt af van het beheersen van de informatie die omkering mogelijk maakt. Onder Article 25 is pseudonimisering een voorbeeld van een passende maatregel, terwijl gepseudonimiseerde gegevens persoonsgegevens blijven wanneer afzonderlijk bewaarde informatie heridentificatie kan ondersteunen.
Vier lagen vereisen vier soorten bewijs
Vervanging van identificatoren vervangt directe identificatoren door tokens of andere pseudoniemen. Het implementatierecord moet specificeren wat wordt vervangen, hoe botsingen worden afgehandeld en of de transformatie koppelbaarheid tussen gebeurtenissen behoudt.
Geïsoleerde mappinggegevens scheiden omkeringsinformatie van de operationele dataset. De ICO beveelt afzonderlijke fysieke of logische opslag aan, met netwerksegmentatie waar passend, in plaats van de mapping naast gepseudonimiseerde records te plaatsen.
Toegangscontroles op heridentificatie stellen een afzonderlijke rechtengrens in. Medewerkers of diensten die de mapping kunnen gebruiken, moeten beperkte, geauthenticeerde toegang hebben, met monitoring die losstaat van de gewone toegang tot operationele gegevens.
Heridentificatielimieten vereisen gedocumenteerde tests en beslissingen. Een DPIA of gelijkwaardig verwerkingsrecord moet vermelden wanneer omkering is toegestaan, wie dit autoriseert, welke logging vereist is en hoe het koppelingsrisico opnieuw wordt beoordeeld na systeemwijzigingen.
Encryptie beschermt mappingmateriaal, maar bepaalt niet wie het mag ontsleutelen of onder welke voorwaarden. Hashing kan directe blootstelling verminderen en toch koppeling of gevolgtrekking toelaten, afhankelijk van de implementatie en beschikbare aanvullende informatie.
Een verdedigbaar ontwerp behoudt vier inspecteerbare artefacten: vervangingslogica, opslagtopologie, toegangsreviews en resultaten van heridentificatietests. De organisatie moet ook vastleggen of pseudoniemen stabiel zijn, worden geroteerd, doelgebonden zijn of tussen systemen worden gedeeld. Die records verdelen de verantwoordelijkheid over de teams die de maatregel bouwen, de leveranciers die componenten exploiteren en de implementatieteams die toegang en uitzonderingen configureren.
Restrisico telt: Pseudonimisering vermindert het koppelingsrisico. Het ontneemt de verwerkingsverantwoordelijke niet de verantwoordelijkheid om te beoordelen of personen nog steeds kunnen worden geïdentificeerd.
Het onderscheid tussen pseudonimisering en anonimisering, in het bijzonder in AI-workflows, wordt verder uitgewerkt in pseudonimisering versus anonimisering in AI-workflows.
De volgende visualisatie toont het gelaagde model in werking:
Article 25 koppelen aan een vertrouwelijke documentworkflow
Denk aan een vertrouwelijke juridische-documentworkflow die contracten inleest, geselecteerde context naar een large language model stuurt voor samenvatting en bevindingen terugstuurt naar de raadsman. De privacyvraag is niet of de modelaanbieder beveiligingsfuncties biedt. Het team moet beslissen wat de klantomgeving verlaat, welke identificatoren nodig zijn, hoe het systeem onbedoelde openbaarmaking blokkeert en wat aantoont dat die maatregelen hebben gewerkt.
Een maatregel-voor-maatregel-koppeling
Een semantische privacylaag kan gevoelige entiteitstypen detecteren zoals namen, adressen, financiële identificatoren en contractbepalingen, en deze vervolgens hashen of vervangen vóór een modelaanroep. Dat implementeert een minimaliserings- en pseudonimiseringsbeslissing op de uitgaande grens. De workflow moet nog steeds de detectieregels, bekende beperkingen en behandeling documenteren van inhoud die niet overeenkomt met een geconfigureerd entiteitstype.
Lokale pseudonimisering houdt de mapping aan de klantkant in plaats van duidelijke identificatoren naar de modelaanbieder te sturen. De mappingopslag moet eigen toegangscontroles, encryptie, operationeel eigenaarschap en een heridentificatiebeleid hebben. Zonder die grenzen kan het vervangen van een naam in de prompt het risico alleen maar naar een ander systeem verplaatsen.
Een fail-closed uitgaande controle kan een prompt of antwoord blokkeren wanneer niet-geredigeerde persoonsgegevens worden gedetecteerd. Het testen van het beleid met synthetische adversariële invoer levert bewijs dat de poort is beproefd tegen bewuste storingen, in plaats van alleen in de configuratie te zijn ingeschakeld.
Wat een onderzoeker zou kunnen inspecteren
Voor deze workflow omvatten nuttige artefacten:
- Redactieverslagen: Welke entiteitsklassen werden gedetecteerd, getransformeerd of onopgelost gelaten.
- Rapporten over uitgaand beleid: Of de prompt is geslaagd, mislukt of ingrijpen vereiste.
- Vastleggingen van modelprompts: De exacte beschermde context die ter verwerking is verzonden, onderworpen aan passende toegangsbeperkingen.
- Herstelverslagen: Wanneer en hoe lokale pseudoniemen werden teruggekoppeld naar het klantdocument.
- Configuratiesnapshots: De beleidsversie, modelroute en implementatie-instellingen die op dat moment actief waren.
De vier factoren uit artikel 25 bepalen het ontwerp. De wettekst creëert een context waarin vertrouwelijkheid en individuele impact aanzienlijk kunnen zijn. De stand van de techniek informeert de beschikbare filter- en isolatiemaatregelen. Kosten spelen een rol bij de selectie van maatregelen, maar deze moeten worden afgewogen tegen het risico en de haalbaarheid van alternatieven. Het resultaat is geen bewering van automatische naleving. Het is een traceerbare keten van risicobeoordeling naar waarborg naar waargenomen werking.
Die functies kunnen het verzamelen van bewijs ondersteunen, maar ze vervangen niet de juridische beoordeling van de verwerkingsverantwoordelijke, de due diligence van leveranciers of het professionele oordeel.
Verdeelde verantwoordelijkheid over bouwers, leveranciers en AI
Artikel 25 wordt vaak omschreven als een verplichting voor de verwerkingsverantwoordelijke, maar moderne verwerking bevindt zich zelden binnen de architectuur van één organisatie. Softwarebouwers creëren de applicatie, SaaS-leveranciers beheren componenten, modelaanbieders verzorgen inferentie of logging, en implementatieteams configureren integraties. De verwerkingsverantwoordelijke blijft verantwoordelijk voor zijn verwerkingsbeslissingen, maar beheert mogelijk niet elke technische laag die het resultaat beïnvloedt.
Waar de keten breekt
Een leverancier kan privacy-instellingen aanbieden zonder restrictieve standaardinstellingen configureerbaar of persistent te maken. Een AI-aanbieder kan prompts of outputs bewaren in operationele logs onder voorwaarden die het implementatieteam niet heeft onderzocht. Een integratielaag kan volledige records doorgeven aan een downstream-dienst omdat er geen lokale filtering plaatsvindt vóór de API-aanroep.
Elke leemte kan artikel 25(2) ondermijnen. Een verwerkingsverantwoordelijke kan denken dat gegevensminimalisatie aanwezig is, terwijl de connector extra velden verzendt. Een productteam kan beperkte zichtbaarheid configureren, terwijl een leveranciersupdate de instelling reset. Een contract kan verantwoordelijkheid op papier toewijzen, terwijl niemand de configuratie exporteert of het auditspoor controleert.
- Geminimaliseerde invoer — Verantwoordelijkheid verwerkingsverantwoordelijke: Definieer noodzakelijke gegevens en keur payloadregels goed; Verantwoordelijkheid leverancier / bouwer: Bied filtering en stabiele configuratiecontroles; Verantwoordelijkheid AI-aanbieder: Verwerk alleen overeengekomen invoer en documenteer de verwerking
- Beschermende standaardinstellingen — Verantwoordelijkheid verwerkingsverantwoordelijke: Stel doelspecifieke standaardinstellingen in en test ze; Verantwoordelijkheid leverancier / bouwer: Behoud restrictieve instellingen door updates heen; Verantwoordelijkheid AI-aanbieder: Bied duidelijke controles voor bewaring, logging en toegang
- Pseudonimisering — Verantwoordelijkheid verwerkingsverantwoordelijke: Beslis wanneer omkering is toegestaan en beheer de mapping; Verantwoordelijkheid leverancier / bouwer: Ondersteun tokenisatie, isolatie en toegangsgrenzen; Verantwoordelijkheid AI-aanbieder: Vermijd het ontvangen van duidelijke identificatoren waar deze niet nodig zijn
- Bewijs en beoordeling — Verantwoordelijkheid verwerkingsverantwoordelijke: Onderhoud DPIA, beslissingen en verificatieverslagen; Verantwoordelijkheid leverancier / bouwer: Lever wijzigingsmeldingen, logs en configuratie-exporten; Verantwoordelijkheid AI-aanbieder: Lever relevant verwerkings- en operationeel bewijs
Een praktische controlematrix moet elke waarborg aan een eigenaar toewijzen en het bewijs benoemen dat met de implementatie meereist. Dat bewijs kan geëxporteerde beleidsregels, configuratiesnapshots, leveranciersvoorwaarden, toegangslogs en testresultaten omvatten.
Teams die bredere governanceprogramma's opbouwen, kunnen deze toeleveringsketenbenadering vergelijken met een compliancekader voor Canadese mkb-bedrijven, terwijl ze de juridische analyse jurisdictiespecifiek houden. Canadees governancemateriaal kan het procesontwerp informeren, maar het vervangt niet de GDPR-verplichtingen die van toepassing zijn op EU-verwerking.
Het tegendraadse punt: In een gedeelde architectuur is documentatie geen administratief residu. Het is de manier waarop de verwerkingsverantwoordelijke aantoont welke partij elke privacyrelevante beslissing heeft genomen.
Waarom ontwerpfouten een vastgestelde boetebandbreedte met zich meebrengen
Artikel 25 is geen vrijblijvende ontwerpvoorkeur. Een tekortkoming kan binnen een vastgestelde handhavingscategorie van de GDPR vallen. De richtsnoeren van de EDPB voor boeteberekening plaatsen inbreuken op gegevensbescherming door ontwerp en door standaardinstellingen binnen de lagere categorie administratieve boetes, tot 10 miljoen euro of 2% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. De hogere categorie reikt tot 20 miljoen euro of 4% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is, voor verplichtingen die onder die categorie vallen. EDPB fine-calculation guidelines
Die cijfers zijn geen prijsmodel voor niet-naleving. Ze bepalen de mogelijke blootstelling, terwijl het ontwerpverslag helpt verklaren hoe een autoriteit de tekortkoming kan beoordelen. Na een incident of klacht kunnen onderzoekers nagaan wat de verwerkingsverantwoordelijke wist over de verwerking, welke waarborgen beschikbaar waren, welke standaardinstellingen werden meegeleverd, hoe leveranciers waren geconfigureerd en of de organisatie haar risicobeoordeling heeft herzien.
Waarom de tabel hier niet eerlijk zaken kan benoemen
Een vergelijking van zaken van toezichthoudende autoriteiten vereist zaakspecifieke primaire beslissingen. Het geverifieerde materiaal stelt de boetebandbreedtes en de classificatie van inbreuken op artikel 25 vast, maar het levert geen geverifieerde zaaknamen, autoriteitsspecifieke beslissingen of gedocumenteerde ontwerpfouten voor Duitsland, Frankrijk, Ierland of Nederland. Het vullen van die cellen met plausibel klinkende voorbeelden zou een bewijstabel in speculatie veranderen.
- EU GDPR framework — Maximale boete categorie 4: Tot €10 miljoen of 2% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is; Opvallende zaak onder artikel 25: Zaakspecifieke primaire beslissing vereist bevestiging; Aangehaalde ontwerpfout: Zaakspecifieke bevinding vereist bevestiging
- Nationale toezichthoudende autoriteiten — Maximale boete categorie 4: Toegepast binnen het boetekader van de GDPR; Opvallende zaak onder artikel 25: Zaakspecifieke primaire beslissing vereist bevestiging; Aangehaalde ontwerpfout: Zaakspecifieke bevinding vereist bevestiging
De bruikbare operationele conclusie is dat inspecteerbaar ontwerpbewijs de onzekerheid tijdens de beoordeling vermindert. Een verwerkingsverantwoordelijke die het verwerkingsdoel, de beoordeling op vier factoren, de standaardinstellingen, het pseudonimisatieontwerp, de leverancierstoewijzing, de testresultaten en latere herbeoordelingen kan tonen, kan aantonen dat er een actief beheersingsproces is. Dat bewijs verdeelt ook de verantwoordelijkheid: bouwers kunnen de implementatie onderbouwen, leveranciers kunnen hun geconfigureerde dienst onderbouwen, en implementatieteams kunnen aantonen dat restrictieve instellingen de release hebben doorstaan. Een beleidsverklaring alleen geeft de verwerkingsverantwoordelijke minder basis om uit te leggen waarom het opgeleverde systeem passend was.
De huidige leidraad van de ICO weerspiegelt de veranderende reikwijdte van privacy-by-design-werk. De update voegt een subsectie toe over de hogere beschermingsplichten voor kinderen onder de UK GDPR na de Data (Use and Access) Act 2025. De wijziging illustreert waarom ontwerpverplichtingen monitoring gedurende de hele levenscyclus vereisen, vooral waar sectorspecifieke plichten van invloed zijn op standaardinstellingen, tests of herbeoordelingstriggers.
Meer artikelen over dit onderwerp zijn verzameld in het overzicht AI-privacy en AVG.
Bronnen en referenties
Bronnen: Kernclaims op juridisch vlak worden toegeschreven aan Art. 25 GDPR (gdpr-info.eu), de EDPB Guidelines 4/2019 en ICO-richtlijnen over data protection by design, pseudonimisering en boeteberekening, waarbij ontwerpkoppelingen als redactionele analyse worden gepresenteerd.