Toestemming en het recht om vergeten te worden

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 5 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Privacywetten bepalen het ontwerp · Volgende: Beschermen, bewaren en bewijzen

De vraag die deze module beantwoordt: Hoe ontwerp je voor toestemming, en voor het wissen van een persoon?

Steve Trucking heeft het telefoonnummer van een ontvanger. Eenvoudige vraag: mogen we hem een sms sturen? Misschien. Over de levering van vandaag? Die van morgen? Mogen we het nummer gebruiken voor een aanbieding? Wat als hij nee zei tegen sms’jes, of ja tegen leveringsupdates maar nee tegen marketing, en toen van gedachten veranderde?

Nu de andere kant op. De ontvanger zegt: verwijder mijn persoonlijke informatie. Waar staat die? In Salesforce, waarschijnlijk, maar we hebben geleerd dat dat niet het hele antwoord is. Ze kwam van een retailpartner. Ze kan in een customer data platform staan, in veldhistorie, een archief, een leveringsnotitie, een export, een integratielog, een gesprek met een agent. Toestemming en verwijdering klinken als beleidsvragen, maar uiteindelijk moet het systeem ze beantwoorden. Dat is architectuur.

Toestemming is data

Het eerste principe: toestemming is data. Breng haar niet terug tot Has_Opted_In__c = true. De echte vraag is nooit alleen “heeft hij toestemming gegeven?” Het is toestemming waarvoor, via welk kanaal, op welk adres of nummer, voor welk doel, wanneer, is het veranderd, en kunnen we het bewijzen? Als het bedrijf op die antwoorden beslissingen neemt, moeten ze als gestructureerde data opgeslagen worden. Een alinea in een privacybeleid is niet genoeg, en een vinkje op een webformulier ook niet: het vinkje legt een gebeurtenis vast; de architectuur moet bewaren wat die gebeurtenis betekent.

Gebruik het model dat Salesforce al gebouwd heeft

Mijn standpunt: gebruik het standaardmodel voor toestemming waar je kunt, in plaats van hetzelfde opnieuw te bouwen in aangepaste velden. Het toestemmingsdatamodel van Salesforce beheert toestemming op vier niveaus, elk een specifiekere vraag (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Globale toestemming, op het Individual: wie is deze persoon, en heeft hij nee gezegd tegen alles?
• Toestemming per kanaaltype (Contact Point Type Consent): mogen we dit soort kanaal gebruiken, zoals sms of e-mail?
• Toestemming per contactpunt: hoe zit het met dit specifieke telefoonnummer of e-mailadres?
• Doel van datagebruik (Data Use Purpose): om welke reden: leveringsmeldingen, service, marketing?

Samen kan de architectuur antwoorden op “mogen we de informatie van deze persoon gebruiken, via dit contactpunt, voor dit doel?”, wat veel nuttiger is dan “toestemming = ja”. Elk record dat bij een individu hoort kan meedoen: leads, contactpersonen, persoonsaccounts, gebruikers.

Click to enlarge

Vier vragen, elk smaller dan de vorige. Eén opt-invlag beantwoordt er geen enkele goed.

Het doel doet ertoe

Een retailpartner stuurt Steve Trucking het nummer van een ontvanger zodat de ploeg de levering kan afstemmen. Dat maakt de ontvanger geen marketinglead. Dezelfde data kan verschillende toegestane toepassingen hebben: leveringsafstemming, opvolging door service, marketing, personalisatie met AI. Als beleid of wet ze verschillend behandelt, moet het model ze uit elkaar houden. De vraag is niet hebben we het telefoonnummer? Het is wat mogen we ermee doen?

En toestemming is niet altijd de rechtsgrond. Sommig gebruik rust op andere gronden die de wet biedt, en dat bepaalt Legal. Bouw geen architectuur die aanneemt dat elke privacybeslissing een opt-in-vinkje is. Ondersteun wat het beleid ook zegt: als een gebruik van toestemming afhangt, modelleer en handhaaf toestemming; als een andere grond van toepassing is, sla dan nog steeds op wat nodig is om te beslissen of het gebruik toegestaan is.

Toestemming heeft een levenscyclus en een zeggenschap

Mensen geven toestemming, trekken haar in, veranderen voorkeuren, veranderen van nummer. Het bedrijf voegt nieuwe doelen toe; wetten veranderen. Ontwerp dus de levenscyclus: wat gekozen werd, wanneer, hoe, voor welk doel, en wat er gebeurt bij intrekking. En hier wordt het interessant: als een ontvanger zijn toestemming intrekt, weet Salesforce dat. Weet het messagingplatform het? De analytics? De agent? Toestemming die in één systeem staat terwijl andere op verouderde toestemming handelen, is niet veel van een controle.

Dat betekent vragen welk systeem gezaghebbend is voor toestemming. Salesforce, een voorkeurenplatform, iets anders? Wat het antwoord ook is, laat niet vijf systemen onafhankelijk beslissen of dezelfde persoon met hetzelfde gebruik instemde. Toestemming heeft nodig wat alle bestuurde data nodig heeft: een eigenaar, een gezaghebbend record, een manier om te synchroniseren, en handhaving.

Nu zegt de persoon: vergeet me

Het eerste instinct is de contactpersoon verwijderen en het afgerond noemen. Maar de data van de persoon kan op een contactpersoon staan, een levering, een leveringsnotitie, een case, een foto, in veldhistorie, in Snowflake, in een archief, een integratielog, een zoekindex of de gespreksgeschiedenis van een agent. Daarom begint mijn standpunt over verwijdering eerder: verwijderen is in de praktijk zeldzaam en moeilijk, dus controleer eerst waar persoonsgegevens heen gaan. Ontwerp zo dat ze op zo weinig mogelijk plekken terechtkomen. Als er dan een verzoek komt, verhul of ontkoppel ze waar dat aan het beleid voldoet, en spoor elke kopie op: veldhistorie, archieven, Data 360, en nu ook zoekindexen en gesprekken met agents.

Begin de zoektocht niet als het verzoek binnenkomt. Dan is het te laat om het landschap te gaan begrijpen. Het woordenboek, de herkomst en de classificatie uit module 3 waren geen papierwerk; ze maken dit mogelijk. Je weet al welke velden persoonsgegevens bevatten en waar de kopieën heen gingen.

Click to enlarge

Een vergeet-mij-verzoek is een beslissing voor elke kopie.

De klok loopt

Deze verzoeken komen met termijnen. Onder de AVG moet de organisatie zonder onnodige vertraging en binnen een maand na ontvangst op het verzoek van een persoon reageren; bij complexe of talrijke verzoeken kan dat met nog twee maanden verlengd worden, maar de persoon moet binnen de eerste maand ingelicht worden, met de redenen (artikel 12, lid 3, Verordening (EU) 2016/679 (opens in a new tab)). Andere wetten stellen hun eigen termijnen; Legal vertelt je welke van toepassing zijn. Hoe dan ook, een maand is niet lang genoeg om het landschap te ontdekken. Dat is de termijn die de kaart van kopieën moet verslaan.

Verwijderen, de-identificeren of bewaren?

Een verzoek betekent niet per se dat alles overal verdwijnt. Sommige records moeten of mogen bewaard blijven; sommige operationele records kunnen blijven maar de persoon niet meer identificeren; sommige data kan gede-identificeerd worden. Het geldende beleid en de wet beslissen; de architectuur ondersteunt elke uitkomst, plek voor plek: verwijder het, de-identificeer het, of bewaar het onder een goedgekeurde eis (en wie mag het dan zien, hoe lang, waarom?).

Denk aan het onderscheid uit module 4. Ontkoppelen telt alleen als vergeten als de persoon redelijkerwijs niet opnieuw geïdentificeerd kan worden. Gepseudonimiseerde gegevens zijn nog steeds persoonsgegevens. Gebruik verhulling niet als sluiproute om een wettelijke eis heen.

Je kunt niet verwijderen wat je niet kunt vinden

Voordat je iemand kunt wissen, moet je hem vinden. Het verzoek komt van een e-mailadres. De ene retailpartner stuurde “Jane Smith”, een andere “J. Smith”, en het telefoonnummer is veranderd. De ontvanger is helemaal geen contactpersoon; zijn gegevens staan op elke levering. Dezelfde persoon kreeg leveringen voor twee verschillende partners. Het ene systeem kent hem op e-mail, een ander op een externe ID. Wissen hangt af van identiteit, en je wilt niet de data van iemand anders verwijderen omdat je matching te agressief was. Identiteitsarchitectuur is deel van privacyarchitectuur.

Steve Trucking maakt het nog moeilijker. De ene retailpartner mag nooit de leveringen of ontvangers van een andere zien. Als dezelfde persoon leveringen voor twee partners kreeg, moet operations die relaties gescheiden houden, terwijl privacy de persoon misschien toch over beide heen moet vinden. Los privacy niet op door de beveiligingsgrens te breken, en bescherm de grens niet door privacyverzoeken onmogelijk te maken. De architectuur moet allebei doen.

Foto’s en vrije tekst zijn ook data

Het is makkelijk om privacy als velden te zien: naam, e-mail, telefoon, adres. Maar Steve Trucking maakt miljoenen leveringsfoto’s per jaar, en sommige laten mensen of de binnenkant van een huis zien. Een bewaar- of wisbeleid dat alleen naar gestructureerde velden kijkt, is onvolledig; net als een beleid dat bestanden, documenten, transcripties, logs en AI-prompts en -antwoorden negeert.

En vrije tekst is gevaarlijk. Je verwijdert de naam, de telefoon en het adres, en vindt dan deze leveringsnotitie: “Bel Jane op 602-555-0198. Poortcode 4821. Hond loopt in de tuin.” Daar is het. Leveringsnotities als gevoelig classificeren vertelt je dat er misschien een probleem is; het vindt en verwijdert de persoonsgegevens in de tekst niet. Soms is het beste antwoord voorkomen dat onnodige persoonlijke details daar überhaupt terechtkomen. Controleer eerst waar persoonsgegevens heen gaan.

Privacy Center is een tool, niet de hele architectuur

Salesforce Privacy Center helpt deze processen te draaien. Het beleid voor het recht om vergeten te worden wordt per object gebouwd, om alles vast te leggen wat je verwijderd wilt hebben, en draait tegen een specifiek klantrecord (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Dat is nuttig. Maar “we hebben Privacy Center gekocht, dus we zijn klaar” is geen architectuur. De data van de persoon kan buiten het bereik van één tool staan: Data 360, het datawarehouse, partnersystemen, archieven, logs, zoeken, bestanden, gesprekken met agents. De enterprise heeft nog steeds een antwoord op enterpriseniveau nodig, en je moet nagaan wat elke tool echt dekt voordat je erop vertrouwt.

Overdraagbaarheid en bewijs

Sommige wetten geven mensen ook het recht om een kopie van hun data te krijgen. Merk op dat het hetzelfde zoekprobleem is: verwijderen vraagt waar staat de data van deze persoon, zodat we erop kunnen handelen? Overdraagbaarheid vraagt waar staat ze, zodat we haar kunnen leveren? Allebei rusten ze op identiteit, classificatie, herkomst, de systeeminventaris en eigenaarschap.

En dan: hoe bewijs je dat je het gedaan hebt? Verzoek ontvangen, identiteit geverifieerd, systemen doorzocht, acties ondernomen, uitzonderingen vastgelegd, bewaarde data gerechtvaardigd, afronding gelogd. Er zit hier een echte spanning: je verwijdert iemands persoonsgegevens terwijl je genoeg bewijs bewaart om te laten zien dat je het verzoek goed afgehandeld hebt. Precies daarom moeten architecten niet zelf bewaarregels verzinnen. Juridische zaken en compliance beslissen welk bewijs moet blijven; de architectuur bewaart het zonder de data te bewaren die verwijderd moest worden.

Voorbij het examen: wat AI verandert. AI maakt nieuwe doelen en nieuwe kopieën. Toestemming om data te gebruiken voor het leveren van een dienst dekt niet automatisch het voeden van een agent (grounding), personalisatie of training; Data Use Purpose is de natuurlijke plek om die uit elkaar te houden. En persoonsgegevens kunnen overleven in prompts, groundingcontext, gesprekken, samenvattingen, zoek- en vectorindexen, en logs. “We hebben het bronrecord verwijderd” is geen volledig antwoord als de AI-laag het nog onthoudt.

Wat een architect hier beslist

• Hoe toestemming en toegestaan gebruik gemodelleerd worden, zodat systemen kunnen antwoorden op wie, welk kanaal, welk contactpunt en welk doel.
• Welk systeem gezaghebbend is voor toestemming, en hoe intrekkingen elk systeem bereiken dat erop handelt.
• Waar persoonsgegevens zich kunnen verspreiden: velden, vrije tekst, bestanden, historie, analytics, archieven, integraties, zoeken en AI.
• Hoe een verzoek de juiste persoon vindt en op elke plek verwijderen, de-identificeren of goedgekeurd bewaren in gang zet.
• Welk bewijs er blijft om aan te tonen dat toestemming en privacyverzoeken afgehandeld zijn.

Toestemming en wissen lijken tegenpolen (mogen we deze data gebruiken? kunnen we stoppen en haar verwijderen?), maar ze rusten op dezelfde fundamenten: identiteit, doel, classificatie, herkomst, eigenaarschap, handhaving en bewijs. Gebruik het standaardmodel voor toestemming, controleer waar persoonsgegevens heen gaan, weet waar de kopieën zijn, en ontwerp het wisproces voordat het eerste verzoek binnenkomt. Als iemand vraagt “kun je me vergeten?”, heeft de architectuur een beter antwoord nodig dan “we denken het wel.”

Verder lezen

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Verordening (EU) 2016/679 (AVG, in het Engels GDPR) (opens in a new tab), artikel 12, lid 3, de termijn om op een verzoek te reageren, gecontroleerd op 2026-10-14.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, Engels, gecontroleerd op 2026-10-14).