Drie decennia lang betekende het beschermen van persoonsgegevens het beheersen van waar gegevens werden opgeslagen en wie de database kon bereiken. AI-tools haalden dat model in ongeveer achttien maanden onderuit.
Dit is geen kritiek op AI. Het is een beschrijving van een structurele verschuiving — en die begrijpen is het verschil tussen gegevensbescherming die werkelijk werkt en gegevensbescherming die er bij een compliance-audit goed uitziet maar in de praktijk faalt op het moment dat een kenniswerker een chatvenster opent.
Het oude model — en waarom het werkte
Klassieke bescherming van persoonsgegevens was ontworpen voor gestructureerde data: CRM-records, EPD-systemen, HR-databases, financiële grootboeken. De dreiging was ongeautoriseerde toegang — een aanvaller of niet-bevoegde werknemer die gegevens bereikte die hij niet hoorde te bereiken.
Het antwoord was navenant gestructureerd:
- Tokenisatie en versleuteling op veldniveau in databases: vervang BSN's en rekeningnummers door ondoorzichtige tokens in rust. Alleen bevoegde diensten kunnen het token terugleiden naar het origineel.
- Op rollen gebaseerde toegangscontrole: beperk welke werknemers welke tabellen mogen bevragen. Log elke leesactie.
- Netwerk-DLP (Data Loss Prevention): scan uitgaand verkeer op gestructureerde PII-patronen — BSN-formaat, creditcardnummers, IBAN-patronen — en blokkeer exfiltratie voordat ze de bedrijfsgrens verlaat.
- Datamaskering in niet-productieomgevingen: test met data die er realistisch uitziet maar synthetisch is gegenereerd en geen echte identiteiten bevat.
Dit werkte omdat data op afgebakende, bekende plekken leefde. U kon de systemen die persoonsgegevens bevatten opsommen, de opslag- en netwerklagen omhullen met controles, en die controles hielden stand tegen het dreigingsmodel waarvoor ze waren gebouwd.
Wat AI-tools veranderden
Het dreigingsoppervlak verschoof — niet omdat AI-tools onveilig zijn, maar omdat ze een nieuwe, wrijvingsloze weg introduceerden van beheerste opslag naar externe verwerking.
Neem de workflow: een kenniswerker opent SharePoint, downloadt een contract-PDF, opent ChatGPT en plakt de inhoud. Hij was bevoegd om het document in te zien — geen toegangscontrole werd geschonden. Hij exfiltreerde geen data in technische zin — hij gebruikte een goedgekeurd apparaat op het bedrijfsnetwerk. Maar het document, met elke naam, elk adres en elk financieel cijfer erin, transiteerde zojuist naar commerciële cloudinfrastructuur waar de organisatie geen zicht op heeft, die door geen enkel contract wordt geregeld, en waarvan geen auditlog bestaat.
Het oude gereedschap heeft hier geen grip op:
- Netwerk-DLP detecteert gestructureerde patronen in bestandsuploads en uitgaande stromen, maar de meeste AI-interacties verlopen als HTTPS-POST-verzoeken naar een web-UI — de proxy ziet het bestemmingsdomein, niet de inhoud van de berichttekst.
- Tokenisatie in de database beschermt persoonsgegevens in rust. Tegen de tijd dat een gebruiker een PDF heeft gedownload en hem leest, zijn de gegevens al uit de tokenkluis gehaald, gereconstrueerd en weergegeven. Het tokensysteem deed precies wat het hoorde te doen — het was alleen niet ontworpen voor de volgende stap.
- Toegangscontroles werden voldaan op het moment dat de bevoegde gebruiker het bestand opende. Wat er stroomafwaarts van die toegang gebeurt, valt buiten hun bereik, door ontwerp.
Het oude model ging ervan uit dat de toegang tot data beheersen hetzelfde was als beheersen wat er met data gebeurde. AI-tools verbraken die aanname schoon. Bevoegde toegang plus een chatvenster staat gelijk aan data die de organisatie verlaat — in stilte, legaal (vanuit het oogpunt van toegangscontrole), en in volume.
Waarom filteren aan de cloudkant tekortschiet
Eén antwoord op dit gat is om al het AI-verkeer door een bedrijfsproxy te leiden die verzoeken onderschept, op persoonsgegevens scant, ze wegstreept en de geschoonde versie doorstuurt. Deze aanpak bestaat en is beter dan niets. Maar ze kent structurele grenzen:
- Ze vereist SSL-inspectie van HTTPS-verkeer — technisch ingrijpend, operationeel duur, en in toenemende mate aangevochten door de beveiligingsmodellen van browsers en door weerstand van werknemers op grond van privacy.
- Ze vereist configuratie per AI-tool. Naarmate de wildgroei aan AI-tools versnelt, groeit het te configureren oppervlak sneller dan welk securityteam dan ook kan bijbenen. Een nieuwe AI-tool wordt een gat op het moment dat een gebruiker hem ontdekt.
- Ze vangt gestructureerde PII-patronen (BSN-formaat, IBAN) maar worstelt met vrije namen, adressen en contextafhankelijke identificatiegegevens — die het merendeel van de persoonsgegevens in professionele documenten vormen.
- Ze kan niets tegen kopiëren-en-plakken vanuit applicaties buiten het bereik van de proxy — mobiele apparaten, persoonlijke machines, offline-dan-plakken-workflows.
Filteren aan de cloudkant behandelt AI als een kanaal om te bewaken in plaats van als een gedrag om te herstructureren. De onderliggende handeling — een gebruiker die gevoelige inhoud uit een beheerst systeem haalt en aan een externe dienst overhandigt — vindt nog steeds plaats. Het filteren voegt een drempel toe in het midden. Het pakt de wortel niet aan.
De vergelijking in heldere termen
Dimensie Klassieke DLP Anonimisering aan de clientkantDe juiste grens: vóór de AI, op het apparaat
De interventie moet plaatsvinden voordat de gegevens het apparaat van de gebruiker verlaten — niet aan de netwerkgrens, niet binnen de infrastructuur van de AI-aanbieder achteraf.
Dit vergt een ander denkmodel. In plaats van te vragen "hoe bewaken we wat gebruikers naar AI-tools sturen?", wordt de vraag: "hoe geven we gebruikers een versie van hun documenten die structureel veilig is om naar welke AI-tool dan ook te sturen?"
Het kerninzicht is dat AI geen identiteiten nodig heeft om zijn werk te doen. Het heeft structuur, taal en context nodig. "Alice Martin, geboren op 14 maart 1987, woonachtig aan de 14 rue des Acacias, Lyon, klantreferentie A-2091" vertelt een groot taalmodel niets extra's over de contractuele clausule die het moet analyseren. Haal de identiteit weg, behoud de clausule. De uitvoer van de AI is even bruikbaar — en de oorspronkelijke gegevens hebben nooit het apparaat verlaten.
Hoe promptShield dit uitvoert
promptShield draait volledig offline op het apparaat van de gebruiker — geen cloud-inferentie, geen netwerkaanroep tijdens de anonimisering. De detectiepijplijn draait drie lagen over elk document:
- Regex — gestructureerde patronen met hoge precisie: IBAN, BSN, e-mail, telefoon, paspoortnummer en andere documentidentificatieformaten in 7 Europese talen. Deze vuren als eerste, met hoge precisie, en vereisen geen modellading.
- Entiteitsdetectie — spaCy- en transformer-modellen die lokaal draaien en namen, adressen, organisaties en datums in context detecteren. Dezelfde entiteitsnaam die over pagina's terugkeert wordt gekoppeld, zodat anonimiseren op pagina 1 hem automatisch onderdrukt op pagina 4.
- Optionele LLM-passage — voor dubbelzinnige gevallen lost een lokaal draaiend GGUF-model grensgevallen op zonder ergens gegevens heen te sturen.
Elke gedetecteerde entiteit wordt vervangen door een stabiel, getypeerd token: [PERSON_1], [ADDRESS_2], [IBAN_1]. De koppeling tussen token en oorspronkelijke waarde wordt opgeslagen in een lokale SQLite-database — het tokenregister — die nooit het apparaat verlaat.
De gebruiker plakt het geanonimiseerde document in welke AI-tool dan ook. De AI levert zijn analyse op de tokens. Wanneer de gebruiker de uitvoer van de AI wil toepassen op het oorspronkelijke document, vervangt promptShield de echte waarden terug. De analytische workflow is ongewijzigd. De blootstelling is structureel uitgeschakeld.
Wat verandert, en wat niet
Anonimisering aan de clientkant pakt één specifiek gat aan: de wrijvingsloze weg van een beheerst document naar een externe AI-dienst. Ze vervangt geen toegangscontroles, vervangt geen auditlogging, en neemt niet de noodzaak weg om werknemers te trainen in passend AI-gebruik.
Wat ze wél verandert is het risicomodel voor specifiek het AI-gebruiksscenario. Zodra u anonimiseert vóór het plakken, heeft de vraag "wat gebeurt er als een werknemer ChatGPT op een cliëntdocument gebruikt?" een ander antwoord. De AI ontvangt gestructureerde inhoud — clausulelogica, financiële ratio's, contractarchitectuur — zonder enige identificatiegegevens eraan vast. Er is niets om bloot te leggen.
De oude grens was de documentopslag. De nieuwe grens moet het document zelf zijn — specifiek het moment waarop het overgaat van een afgebakend systeem naar vrije tekst in de handen van een gebruiker.
Die grens is degene die de klassieke DLP nooit was ontworpen om vast te houden. Het is degene die er nu toe doet.
