Hoe bescherm je persoonsgegevens in AI-systemen?
Persoonsgegevens in AI beschermen draait om minder data, tokenisatie, afspraken met verwerkers en toegangscontrole. Een praktische aanpak voor B2B.
Je beschermt persoonsgegevens in AI-systemen door zo weinig mogelijk persoonsgegevens naar het AI-model te sturen, de rest te vervangen door tokens, toegang per gebruiker in de data zelf af te dwingen, verwerking vast te leggen in een verwerkersovereenkomst en te weten waar de data geografisch terechtkomt. De AVG vraagt daarbij niets nieuws: doelbinding, dataminimalisatie en passende beveiliging gelden voor AI net zo als voor elk ander systeem. Het verschil is dat AI de verleiding groot maakt om alles mee te sturen.
Waarom AI het risico vergroot
Een B2B-bedrijf denkt bij persoonsgegevens vaak aan HR of consumenten. Maar een CRM en een administratie staan er vol mee: contactpersonen, e-mailadressen, telefoonnummers, notities over gesprekken, soms privéadressen van eenmanszaken. Bij een vof of eenmanszaak is zelfs het bedrijf herleidbaar tot een persoon.
AI verandert drie dingen:
- Volume. Een analyse die vroeger op een export van vijf kolommen draaide, krijgt nu het hele klantrecord, inclusief vrije tekst, omdat het model "alles kan lezen".
- Bestemming. De data verlaat je systemen en gaat naar een model bij een externe aanbieder, soms buiten de EU.
- Vrije tekst. Notities, mails en tickets worden ineens bruikbaar voor analyse. Juist daar staan gegevens die niemand ooit bewust heeft vastgelegd: een ziekmelding, een privésituatie, een conflict.
Wat de AVG vraagt, toegepast op AI
De AVG kent een aantal beginselen die direct vertaalbaar zijn naar AI.
Doelbinding. Je verwerkt persoonsgegevens voor een omschreven doel. "AI-analyse" is geen doel. "Controleren of gefactureerde bedragen overeenkomen met contractafspraken" wel. Uit dat doel volgt welke gegevens nodig zijn.
Dataminimalisatie. Niet meer gegevens dan nodig voor het doel. Voor omzetcontrole zijn bedragen, datums, contractvoorwaarden en klantnummers nodig. Namen van contactpersonen zelden.
Integriteit en vertrouwelijkheid. Passende technische en organisatorische maatregelen. Pseudonimisering wordt in de AVG uitdrukkelijk genoemd als voorbeeld van zo'n maatregel.
Verwerkers. Een partij die namens jou persoonsgegevens verwerkt, zoals een AI-aanbieder of een softwareleverancier die AI inzet, is een verwerker. Daarvoor is een verwerkersovereenkomst verplicht, met daarin onder meer welke subverwerkers worden ingezet.
Doorgifte buiten de EU. Gaat data naar een land buiten de EER, dan gelden aanvullende eisen. Dat speelt bij veel AI-modellen, omdat de grote aanbieders vaak buiten de EU zitten of daar ook verwerken.
Geautomatiseerde besluitvorming. Besluiten die uitsluitend geautomatiseerd worden genomen en iemand in aanmerkelijke mate treffen, zijn aan strikte regels gebonden. In B2B-omzetcontrole speelt dat minder, omdat het meestal over bedrijven gaat en een mens de beslissing neemt, maar het is een reden te meer om AI te laten aanbevelen en niet te laten beslissen.
Dit is geen juridisch advies. Voor je eigen situatie is overleg met je privacyverantwoordelijke of jurist verstandig, zeker als je twijfelt of een verwerking een hoog risico vormt. In dat geval kan een gegevensbeschermingseffectbeoordeling (DPIA) verplicht zijn.
Zes maatregelen die werken
1. Minder data naar het model
De effectiefste bescherming is data die het model nooit ontvangt. Maak per AI-toepassing een lijst van de velden die nodig zijn. Alles daarbuiten gaat niet mee. Vrije tekstvelden alleen als de taak ze aantoonbaar nodig heeft.
2. Tokenisatie voor wat wel meegaat
Herleidbare gegevens die wel nodig zijn voor de samenhang, zoals welke facturen bij dezelfde contactpersoon horen, worden vervangen door tokens. Het model ziet PERSOON_0412, niet de naam. De vertaaltabel blijft in je eigen omgeving. Uitgewerkt in hoe tokenisatie van bedrijfsdata werkt.
3. Toegang in de data, niet alleen in het scherm
Een accountmanager die in het CRM alleen zijn eigen klanten ziet, moet via een AI-assistent ook alleen zijn eigen klanten kunnen opvragen. Dat lukt alleen als de toegangsregels in de database zelf zitten, row-level security, en niet alleen in de gebruikersinterface. Anders kan een slimme vraag aan de AI om de interface heen.
4. Eigen accounts met smalle rechten
Een AI-toepassing krijgt een eigen account per systeem, met alleen leesrechten op de benodigde gegevens. Zie hoe je AI toegang geeft tot bedrijfsdata.
5. Afspraken met elke verwerker
Leg vast: waar de data wordt verwerkt, welke subverwerkers betrokken zijn, of invoer wordt bewaard of gebruikt voor het trainen van modellen, en hoe lang. Consumentenversies van AI-tools hebben vaak andere voorwaarden dan zakelijke versies.
6. Logging en bewaartermijnen
Leg vast welke gegevens door welke toepassing zijn ingezien. En let op de logbestanden zelf: als de prompts en antwoorden van een AI-systeem worden gelogd, staan de persoonsgegevens daar ook in. Een logbestand is ook een verwerking, met een bewaartermijn.
Waar het misgaat in de praktijk
De geplakte export. Een medewerker plakt een klantexport in een gratis chattool om snel een analyse te doen. Namen, mailadressen en omzet per klant staan nu bij een aanbieder waarmee geen verwerkersovereenkomst is gesloten. Het is de meest voorkomende en meest onderschatte route.
Notities die niemand las. Een AI-toepassing die CRM-notities samenvat, brengt ineens informatie naar boven die jaren ongezien in vrije tekstvelden stond. Soms gevoelig, soms onjuist, soms beide.
Prompts in logbestanden. Het AI-systeem zelf is goed afgeschermd, maar de volledige prompts, met klantgegevens, worden gelogd in een monitoringtool die de halve IT-afdeling kan inzien.
Subverwerkers die veranderen. Een leverancier wisselt van AI-model of voegt er een toe. De data gaat nu naar een andere partij, misschien in een ander land, zonder dat iemand het merkte.
Gegevens die blijven. Na afloop van een proef of een contract staan klantgegevens nog bij de leverancier, omdat niemand heeft gevraagd ze te verwijderen.
Rekenvoorbeeld: hoeveel persoonsgegevens heeft een omzetanalyse nodig?
Rekenvoorbeeld: stel, je wilt nagaan of alle meerwerk uit projecten ook gefactureerd is. Je hebt per project een CRM-record met 40 velden, waaronder 12 met persoonsgegevens: projectleider klant, contactpersoon facturatie, telefoonnummers, e-mailadressen, en een notitieveld.
Voor de analyse zijn nodig: projectnummer, klantnummer, oorspronkelijke opdrachtwaarde, geregistreerde meerwerkopdrachten met bedrag en datum, en gefactureerde bedragen. Dat zijn 6 velden, waarvan geen enkele een persoonsgegeven bevat.
- Zonder selectie gaan 40 velden per project mee, waarvan 12 met persoonsgegevens.
- Met selectie gaan 6 velden mee, zonder persoonsgegevens.
- Alleen als je meerwerk wilt vinden dat alleen in notities staat, heb je het notitieveld nodig. Dan tokeniseer je de namen erin.
Het resultaat van de analyse is hetzelfde. Het risico is een fractie. Hoe je het lek zelf vindt, staat in hoe je vergeten facturen ontdekt.
Controlelijst voor elke AI-toepassing
- Is het doel in één zin beschreven?
- Welke velden zijn nodig voor dat doel, en welke daarvan bevatten persoonsgegevens?
- Worden herleidbare gegevens getokeniseerd voordat ze naar het model gaan?
- Waar draait het model, en waar wordt data opgeslagen?
- Is er een verwerkersovereenkomst, met een lijst van subverwerkers?
- Wordt invoer gebruikt voor training? Zo ja, kan dat uit?
- Worden prompts en antwoorden gelogd, en wie kan die logs inzien?
- Wat gebeurt er met de data na afloop van het contract?
- Wordt de toegang per gebruiker in de data zelf afgedwongen?
- Is beoordeeld of een DPIA nodig is?
Hoe RiOS hiermee omgaat
RiOS wordt gebouwd met een aantal vaste ontwerpregels die hier direct op aansluiten: een tokenisatielaag die persoons- en identificerende gegevens verwijdert voordat iets een AI-model bereikt, row-level security in de database, verwerking op infrastructuur binnen de EU, en een verwerkersovereenkomst met alle subverwerkers bij naam voordat er iets gekoppeld wordt. De details staan op de pagina beveiliging. Hoe privacy past in de rest van de AI-architectuur voor omzetcontrole, lees je in hoe AI binnen Revenue Intelligence werkt.
Veelgestelde vragen
Is het gebruik van AI op klantdata toegestaan onder de AVG?
Ja, als je aan de gewone eisen voldoet: een doel en een grondslag, niet meer gegevens dan nodig, passende beveiliging en afspraken met verwerkers. AI is geen uitzondering, maar maakt het wel makkelijker om per ongeluk te veel te verwerken.
Zijn zakelijke contactgegevens ook persoonsgegevens?
Ja. Een naam met een zakelijk e-mailadres is herleidbaar tot een persoon en valt onder de AVG. Bedrijfsgegevens van een BV zijn dat niet, maar die van een eenmanszaak kunnen het wel zijn.
Is een AI-model binnen de EU voldoende?
Het lost het vraagstuk van doorgifte op, niet dat van dataminimalisatie. Ook een model binnen de EU hoeft de namen van je klanten meestal niet te zien.
Wat is de snelste verbetering die ik morgen kan doorvoeren?
Afspreken dat er geen klantexports in chattools zonder verwerkersovereenkomst worden geplakt, en een zakelijke omgeving beschikbaar stellen voor wie AI wil gebruiken.
Meer in dit cluster
- Hoe werkt AI binnen Revenue Intelligence?Begin hier
- Hoe geef je AI toegang tot bedrijfsdata?
- Hoe werkt tokenisatie van bedrijfsdata?
- Wat gebeurt er als AI verkeerde bedrijfsdata gebruikt?
- AI architecture voor Revenue Intelligence
- Wat is anomaly detection?
- Wat is predictive analytics?
- Predictive AI vs generative AI