Hoe werkt tokenisatie van bedrijfsdata?

Tokenisatie van bedrijfsdata betekent dat herleidbare gegevens, zoals namen, e-mailadressen, telefoonnummers en IBAN's, worden vervangen door neutrale plaatsvervangers, tokens, voordat de data naar een AI-model gaat. Het model werkt met de tokens, en pas wanneer het resultaat terugkomt in je eigen omgeving worden ze weer vertaald naar de echte gegevens. Zo kan AI patronen in je omzetdata analyseren zonder ooit te zien over wie het gaat.

Twee betekenissen van het woord token

Eerst een spraakverwarring. In AI betekent "token" ook iets anders: het stukje tekst waarin een taalmodel invoer opknipt, ongeveer een woorddeel. Als een aanbieder prijzen per duizend tokens noemt, gaat het over die betekenis.

In dit artikel gaat het over de privacybetekenis: een plaatsvervanger voor een gevoelig gegeven. "Jan de Vries, [email protected]" wordt bijvoorbeeld "PERSOON_0412, EMAIL_0412". Het begrip komt uit de betaalwereld, waar creditcardnummers al lang op deze manier worden vervangen.

Hoe tokenisatie werkt

Het proces heeft vier stappen.

1. Herkennen. Een verwerkingsstap loopt de data door en herkent wat herleidbaar is. In gestructureerde velden is dat eenvoudig: de kolom "contactpersoon" bevat namen, de kolom "e-mail" e-mailadressen. In vrije tekst, zoals een CRM-notitie of een mail, is het lastiger. Daar zijn patroonherkenning en taalherkenning voor nodig.

2. Vervangen. Elk herkend gegeven wordt vervangen door een token. Belangrijk: hetzelfde gegeven krijgt steeds hetzelfde token. Als Jan de Vries in tien facturen voorkomt, is hij in alle tien PERSOON_0412. Daardoor blijven patronen zichtbaar: het model ziet dat dezelfde persoon tien keer terugkomt, zonder te weten wie het is.

3. Verwerken. Het AI-model krijgt alleen de getokeniseerde versie. Het analyseert, vergelijkt, vat samen en schrijft een antwoord met tokens erin.

4. Terugvertalen. De vertaaltabel, welk token bij welk echt gegeven hoort, blijft in je eigen beveiligde omgeving. Het antwoord van het model wordt daar teruggezet naar leesbare gegevens voor de gebruiker die ze mag zien.

Een voorbeeld van wat er naar het model gaat:

De bedragen, datums en afspraken blijven staan. Die heeft het model nodig om lekkage te vinden. Wie het zijn, heeft het niet nodig.

Wat je wel en niet tokeniseert

De afweging is steeds: heeft het model dit gegeven nodig om de taak uit te voeren?

Bijna altijd tokeniseren:

• Namen van personen
• E-mailadressen en telefoonnummers
• Adressen van personen
• IBAN's en andere rekeningnummers
• Burgerservicenummers en andere identificatienummers (die horen in de regel niet eens in je CRM of administratie thuis)

Afhankelijk van de taak:

• Bedrijfsnamen. Een bedrijfsnaam is meestal geen persoonsgegeven, maar bij een eenmanszaak of vof kan hij direct naar een persoon wijzen. Commercieel kan hij ook gevoelig zijn.
• Productnamen en projectnamen, als ze naar een klant herleidbaar zijn.

Meestal niet tokeniseren:

• Bedragen, aantallen, prijzen, percentages
• Datums en termijnen
• Productcategorieën en contracttypen
• Statusvelden

Deze laatste groep is precies waar omzetcontrole om draait. Tokeniseer je die ook, dan kan het model niets meer.

Tokenisatie, pseudonimisering en anonimisering

Drie begrippen die vaak door elkaar worden gebruikt, met juridisch verschillende gevolgen.

Anonimisering betekent dat gegevens onomkeerbaar niet meer naar een persoon te herleiden zijn, ook niet in combinatie met andere informatie. Echt geanonimiseerde gegevens vallen buiten de AVG. In de praktijk is echte anonimisering lastig, zeker bij kleine datasets.

Pseudonimisering betekent dat gegevens alleen met aanvullende informatie, zoals een vertaaltabel, weer te herleiden zijn, en dat die informatie apart en beveiligd wordt bewaard. Gepseudonimiseerde gegevens blijven onder de AVG vallen, maar het risico is kleiner en de AVG noemt pseudonimisering uitdrukkelijk als passende beveiligingsmaatregel.

Tokenisatie met een vertaaltabel is een techniek voor pseudonimisering. Voor het AI-model zelf, dat de vertaaltabel nooit ziet, zijn de gegevens niet herleidbaar. Voor jouw organisatie, die de tabel beheert, wel.

Het praktische gevolg: tokenisatie vermindert het risico sterk, maar ontslaat je niet van de AVG-verplichtingen. Dat werkt het artikel over persoonsgegevens beschermen in AI-systemen verder uit.

Waar het misgaat

Vrije tekst. Gestructureerde velden zijn betrouwbaar te tokeniseren. Een CRM-notitie als "gesproken met de vrouw van de eigenaar, ze heeft net een operatie gehad, bellen na de zomer" bevat gevoelige informatie zonder één naam. Geen herkenner vangt alles. Daarom is het verstandig vrije tekst alleen mee te sturen als de taak het echt nodig heeft.

Herleidbaarheid via combinaties. Een token verbergt de naam, maar de combinatie van gegevens kan iemand alsnog herkenbaar maken. "De enige klant in Zeeland met een contract boven EUR 500.000" is herleidbaar zonder naam. Bij kleine klantenbestanden weegt dit zwaarder.

Inconsistente tokens. Als "J. de Vries", "Jan de Vries" en "[email protected]" drie verschillende tokens krijgen, ziet het model drie personen. Analyses op klantniveau worden dan onbetrouwbaar. Goede tokenisatie normaliseert eerst.

De vertaaltabel op de verkeerde plek. Als de tabel in dezelfde omgeving staat als het model, of in een logbestand belandt, is de bescherming weg.

Tokenisatie als excuus. "Het is getokeniseerd, dus we kunnen alles sturen" is de verkeerde reflex. Dataminimalisatie blijft het uitgangspunt: stuur alleen wat nodig is, en tokeniseer daarvan wat herleidbaar is.

Rekenvoorbeeld: werkt lekdetectie nog na tokenisatie?

Rekenvoorbeeld: stel, je wilt controleren of klanten met een kortingsafspraak na afloop van die afspraak weer het volle tarief betalen. Je hebt 1.200 factuurregels en 85 CRM-notities met kortingsafspraken.

Na tokenisatie ziet het model per klant een token, per afspraak een percentage en een einddatum, en per factuur een bedrag en een datum. Het vindt bijvoorbeeld dat KLANT_0087 een korting van 5 procent had tot en met december, en in januari tot en met maart nog steeds met korting is gefactureerd, op een maandbedrag van EUR 5.300.

• Gemiste omzet: 5 procent van EUR 5.300 is EUR 265 per maand, over drie maanden EUR 795.
• Voor de medewerker wordt KLANT_0087 teruggezet naar Voorbeeld Techniek BV, zodat de factuur kan worden gecorrigeerd.

Het model heeft de afwijking gevonden zonder te weten om welke klant het ging. Dat is de kern: voor lekdetectie zijn bedragen, datums en afspraken nodig, geen namen. Meer over dit type lek in revenue leakage door verkeerde prijzen.

Controlelijst: vragen aan je leverancier

1. Wordt er getokeniseerd voordat data naar een AI-model gaat? Voor alle modellen, of alleen voor sommige?
2. Welke gegevens worden herkend? Alleen gestructureerde velden, of ook vrije tekst?
3. Waar staat de vertaaltabel, en wie kan erbij?
4. Krijgt hetzelfde gegeven steeds hetzelfde token?
5. Wat gaat er ongetokeniseerd mee, en waarom?
6. Is de tokenisatie getest, bijvoorbeeld door steekproeven van wat het model ontvangt?

Tokenisatie binnen RiOS

RiOS wordt gebouwd met een tokenisatielaag als vaste ontwerpregel: een verwerkingsstap haalt namen, e-mailadressen en andere herleidbare gegevens eruit en vervangt ze door tokens voordat iets een AI-model bereikt. Dat geldt voor elk model, ongeacht waar het draait. De uitleg van de datastromen staat op de pagina beveiliging. Hoe tokenisatie samenhangt met toegangsrechten en koppelingen, lees je in hoe je AI toegang geeft tot bedrijfsdata, en het bredere plaatje in hoe AI binnen Revenue Intelligence werkt.

Veelgestelde vragen

Maakt tokenisatie data anoniem?

Niet in juridische zin. Zolang er een vertaaltabel bestaat, is het pseudonimisering. Voor het AI-model zijn de gegevens niet herleidbaar, maar de AVG blijft van toepassing op je eigen verwerking.

Wordt de AI er minder slim van?

Voor omzetanalyse nauwelijks, omdat bedragen, datums en afspraken blijven staan. Voor taken waarbij de naam zelf ertoe doet, zoals een gepersonaliseerde mail schrijven, wordt de naam pas na het model weer ingevoegd.

Is tokenisatie hetzelfde als versleuteling?

Nee. Versleutelde data is onleesbaar tot je haar ontsleutelt, en een model kan er niets mee. Getokeniseerde data is leesbaar en bruikbaar, alleen de herleidbare delen zijn vervangen.

Moet ik tokeniseren als het AI-model in de EU draait?

Waar het model draait, verandert niets aan het feit dat het model de namen van je klanten niet nodig heeft voor de meeste analyses. Dataminimalisatie geldt overal.