Dit is een machinevertaling van het originele Engelstalige document. In het geval van een conflict tussen deze vertaling en de originele Engelse versie, is de Engelse versie doorslaggevend. Lees de originele Engelse versie
On-device pseudonymizer: gebouwd en gebenchmarkt
2026-05-22 · Caiioo Team
We wilden het privacyprobleem oplossen van AI-systemen die trainen op en het bewaren van echte persoonlijk identificeerbare informatie. "Zero Data Retention"-beleid en overeenkomsten verminderen het risico, maar ze zitten vol uitzonderingen. Ze zeggen in feite: "We slaan geen van uw prompts of outputs op, behalve voor: (vul hier een lange lijst met uitzonderingen in: beveiligingsdoeleinden, overheidstoezicht, juridische bewaring, productontwikkeling, foutlogboeken, verbetering van de diensten...)"
Om dit op te lossen, hebben we een filter voor persoonlijke gegevens gebouwd dat op de eigen machine van de gebruiker draait, het bericht ziet voordat het het apparaat verlaat, en hetzelfde antwoord geeft dat de gebruiker zou hebben ontvangen als het zonder filter was getypt.
Dus hebben we er een gebouwd. De volgende versie van Caiioo zal de Pseudonymizer bevatten. Toegankelijk via het schild-icoon in de agent-chat en via de instellingen.
Dit witboek schetst de rationale, architectuur, het evaluatieproces en de ontwerpprincipes achter ons privacyfilteringsysteem.
Wat we willen bereiken
Algemene privacybescherming door dataminimalisatie. Wanneer een gebruiker chat met een extern model, heeft het model geen echte naam, woonadres, echt e-mailadres of telefoonnummer van een klant nodig om de vraag van de gebruiker te beantwoorden. Het heeft de vorm van de vraag nodig, en het moet eruitzien als een echte vraag zodat het LLM de query niet afwijst als een test. Het filter verwijdert daarom echte identificatiegegevens uit de gegevens die naar de AI worden verzonden en voegt de echte waarden weer samen op de terugweg. Het model ziet synthetische namen en identificatiegegevens; de gebruiker ziet de echte conversatie.
Ondersteuning bij HIPAA-naleving. Een tweede modus richt zich op de 18 identificatiegegevens in de HIPAA Safe Harbor-regel (§164.514) en de ruimere Limited Data Set-variant. Een clinicus, een zorgbeheerder of iedereen die werkt aan een gedekte workflow kan met een algemeen model over echte casussen praten zonder beschermde gezondheidsinformatie (PHI) naar de AI te sturen. Wij zijn niet de compliance officer van de gedekte entiteit — maar we kunnen de laag zijn die voorkomt dat PHI de laptop überhaupt verlaat. Onze evaluaties bieden meetbare benchmarks die organisaties kunnen gebruiken om de geschiktheid van het filter voor hun nalevings- en privacynormen te beoordelen. Alle privacy- en beveiligingsmaatregelen zijn discretionaire beslissingen die de verantwoordelijkheid zijn van de gebruiker of de gebruikersentiteit.
We hebben voor beide gekozen omdat de techniek hetzelfde is, en de PHI-use-case technisch gezien zelfs eenvoudiger is vanwege het gebruik van duidelijke benoemde entiteiten, die gemakkelijker te redigeren zijn dan de algemenere gegevens in de categorie Persoonsgegevens. HIPAA-filtering wordt ook geholpen door het feit dat dit over het algemeen in het Engels of Spaans is. We detecteren identificatiegegevens, vervangen deze door stabiele pseudoniemen en vervangende identificatiegegevens in hetzelfde formaat, herstellen deze op de terugweg en loggen nooit de echte waarden. De koppeling tussen de synthetische informatie en de echte informatie blijft alleen op het apparaat van de gebruiker staan, zodat de gebruiker echte informatie kan lezen in de antwoorden van de agent. De categorielijst en de beleidspoort zijn de zaken die veranderen tussen de modi.
Waarom regex plus machine learning, en niet slechts één van beide
Er zijn twee belangrijke filtertechnologieën in onze pseudonimiseerder: een deterministische taal voor patroonherkenning genaamd regex, en getrainde machine learning-modellen.
Regex is onverslaanbaar op oppervlakteformaten. Een e-mailadres heeft een vorm ([email protected]). Dat geldt ook voor een IP, een creditcard, een IBAN, een VIN, een SSN (XXX-XX-XXXX) of een API key. Als het formaat betrouwbaar is, vangt regex dit deterministisch op, elke keer weer, zonder modelbelasting en zonder inferentiekosten.
Regex is echter hopeloos wat betreft context. "Sarah's grafiek van afgelopen dinsdag" bevat een persoon en een datum, maar geen van beide kan worden onderscheiden op basis van het formaat alleen. "De patiënt op Elm 14" bevat een adres dat overeenkomt met duizend niet-adressen. "Hun MRN is 7741032" heeft de woorden rondom het getal nodig om betekenis te krijgen.
Een klein, fijnmazig taalmodel handelt de context af — het onze is een speciaal getrainde 110M-parameter encoder, gedistilleerd uit een meertalig tiny language model —. Het leest de zin, niet de substring, en is klein genoeg om extreem snel op een apparaat te draaien, zelfs op een mobiele telefoon.
De benchmarks illustreren de complementaire sterktes van de twee lagen. We hebben de twee lagen afzonderlijk getest om er zeker van te zijn dat elke laag daadwerkelijk bijdraagt. Op de PrivacyBench-PD vragenset van 150 vragen, waarbij de vragen en antwoorden expliciet NIET zijn gebruikt om het model te trainen:
| Laag | Gevangen PII | Percentage gevangen |
|---|---|---|
| Alleen Regex | 205 / 670 | 30,6 % |
| Alleen ML | 516 / 670 | 77,0 % |
| Beide (productie) | 625 / 670 | 93,3 % |
Regex alleen mist driekwart van de identifiers omdat de meeste identifiers in echt proza niet gestructureerd zijn. ML alleen mist 16 procentpunten die de regex-laag wel zou hebben gevangen — de zaken die puur hun vorm zijn (een creditcard ziet eruit als een creditcard; het model heeft geen extra signaal om toe te voegen). Samen dekken ze wat geen van beide alleen dekt.
Als we dieper kijken naar waar elke laag doorslaggevend is: over diezelfde set werden 16 testwaarden alleen door regex gevangen (e-mails, IP's, financiële rekeningen, gestructureerde ID's) en werden er 327 alleen door ML gevangen (namen, contextuele identifiers, meertalige formuleringen).
Klein, slim, snel — en draait overal
We moesten het filter op het apparaat zelf laten draaien, wat een technische uitdaging was.
Het moet klein zijn omdat onze app op veel systemen lokaal draait: in een browserextensie, een macOS-app, een iOS-app, een Android-app, of op Windows en Linux. De bundel is ongeveer 113 MB per model. Er zijn twee modellen — één voor algemene persoonsgegevens, één voor beschermde gezondheidsinformatie — en de Safe Harbor-modus draait beide parallel. Van deze is een low-end Android-toestel het minst krachtig, maar toch werkt ons systeem prima.
Het moet slim zijn omdat fout-negatieven echte gegevens lekken naar een externe LLM en fout-positieven het gesprek verpesten. Namen moeten worden geanonimiseerd; voornaamwoorden niet. Het e-mailadres van de arts in een doorgestuurd gesprek moet worden geanonimiseerd; de [email protected] voettekst waarschijnlijk niet.
Het moet snel zijn omdat het direct in de weg staat van elk bericht dat de gebruiker verzendt of ontvangt. We hebben de round-trip overhead gemeten op minder dan 200 ms op een enkele CPU-thread, voornamelijk tokenisatie. Op WebGPU en op Apple's Neural Engine is dit minuscuul vergeleken met de netwerklatentie van de LLM-aanroep zelf.
Het moet in meerdere omgevingen draaien omdat Caiioo multi-platform is. Hetzelfde systeem draait in Chrome-extensies, macOS en iOS, Android, en op Windows en Linux. Eén detectiemodel, één regex-bibliotheek, één merger, één beleid — identiek gedrag op elk platform waar Caiioo draait.
De scores
Na verschillende test- en trainingsrondes hebben we gekozen voor de 16e versie van onze modellen. Hieronder staan drie benchmarks die elk iets anders meten.
Onze eigen testset, 150 vragen die het model nooit eerder heeft gezien
Voordat we tegen publieke benchmarks testten, hebben we ons Personal Data filter losgelaten op een interne testset die we bewust buiten de trainingsdata hebben gehouden — de detector heeft deze vragen dus nooit eerder gezien. 150 vragen verdeeld over vier groepen (codefragmenten, documentproza, opzettelijk ongebruikelijke formuleringen en 10 niet-Engelse talen), plus een "negatieve" groep die helemaal geen privégegevens bevat (een controle om te zien of we niet overmatig redigeren). Gecombineerde regex + ML pipeline:
| Sub-bench | Gevonden | Score |
|---|---|---|
| code_bench | 69 / 74 | 93,2 % |
| doc_bench | 233 / 247 | 94,3 % |
| generalization_bench | 123 / 133 | 92,5 % |
| multilingual_bench | 200 / 216 | 92,6 % |
| Alle 4 positieve benches | 625 / 670 | 93,3 % |
(De negatieve groep bevatte geen privégegevens om te vinden. Het filter maskeerde één item dat niet gemaskeerd had mogen worden — consistent met de precisiecijfers verderop.)
De beoordelaar is streng: elk verwacht stukje privégegevens moet volledig verdwijnen uit de gemaskeerde output om de vraag te laten scoren. Geen gedeeltelijke punten, geen "bijna goed." Dat is strenger dan benchmarks die een andere LLM als jury gebruiken (LLM-jury's zijn vaak genereus). Zie de head-to-head sectie verderop voor cijfers die direct vergelijkbaar zijn met andere systemen.
PrivacyBenchHIPAA — 40 vragen uit de gezondheidszorg
Elke vraag bevat beschermde gezondheidsinformatie die moet worden geredigeerd (namen, medische dossiernummers, enz.) ÉN signalen die behouden moeten blijven (datums, geografie, leeftijd indien jonger dan 90 — de HIPAA Limited Data Set regel). De beoordelaar controleert beide kanten: hebben we verwijderd wat we hadden moeten verwijderen, en hebben we met rust gelaten wat we met rust hadden moeten laten?
| Modus | PHI geredigeerd | Retentie behouden |
|---|---|---|
| Limited Data Set (behoud datums / geografie / leeftijd ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (redigeer alles inclusief datums) | 99 / 104 (95,2 %) | — |
De Limited Data Set submodus is perfect op deze benchmark. Safe Harbor — waarbij meer geredigeerd moet worden en er dus meer kans is op missers — dekt 95,2%.
Resultaten per categorie op onze eigen data, 200 samples per modus
Publieke benchmarks gooien alles op één hoop. Onze interne testdata splitst resultaten uit per categorie (namen, e-mails, adressen, enzovoort) en voert elke categorie op drie manieren uit: alleen regex, alleen ML, en beide samen. Dat vertelt ons precies welke technologie welk type identificator vindt — en waar ze elkaar nodig hebben. Meest recente run, 2026-05-20:
Samenvatting over alle drie de filtermodi
| Modus | Gecombineerde recall | Precisie | F2 | Samples |
|---|---|---|---|---|
| Personal Data filter | 97,3 % | 97,8 % | 97,4 | 200 |
| HIPAA filter — Limited Data Set | 92,3 % | 92,3 % | 92,3 | 200 |
| HIPAA filter — Safe Harbor | 91,9 % | 91,5 % | 91,8 | 200 |
Deze cijfers zijn exclusief URLs, die we bewust ongemoeid laten — het maskeren van een URL zou vervolgacties zoals "open deze link" of "haal deze pagina op" onmogelijk maken. Meer hierover in de workflow-sectie hieronder.
Het grote geheel vóór de tabellen per categorie: in elke modus worden de identificatoren die daadwerkelijk een persoon identificeren in of nabij 100% van de gevallen gevonden. Namen, e-mails, telefoonnummers, postadressen, overheids-ID's, biometrische ID's, nauwkeurige geolocatie, medische dossiernummers, geboortedatums, burgerservicenummers — gevonden in elk sample, elke test. De categorieën waar we onder de 100% zakken zijn voorspelbaar: apparaat-ID's (enorme variëteit aan formaten in echte tekst), diverse institutionele ID's (loyaliteitsnummers, personeelsnummers — hetzelfde probleem), en foto's (een tekstfilter kan niet zien wat er in een afbeelding staat). Geen van deze is de "naam op een kaart" of "e-mail in een concept" identificator die er echt toe doet bij datalekken. De categorieën met een hoog risico zijn de betrouwbare categorieën.
Personal Data filter
Gesorteerd op gecombineerde recall (beste eerst), daarna op risiconiveau (T1 = meest gevoelig).
| Categorie | Tier | Regex recall | ML recall (raw) | Gecombineerde recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| email_address | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| government_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| person_name | T1 | 13,3 % (4/30) | 96,7 % (29/30) | 100,0 % | 30 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| postal_address | T1 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| precise_geolocation | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| birth_date | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| online_handle | T2 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 50,0 % (5/10) | 100,0 % (10/10) | 100,0 % | 10 |
| authentication_secret | T4 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| financial_account | T1 | 90,0 % (18/20) | 100,0 % (20/20) | 90,0 % | 20 |
| institutional_id | T3 | 80,0 % (8/10) | 90,0 % (9/10) | 90,0 % | 10 |
| device_id | T3 | 40,0 % (4/10) | 50,0 % (5/10) | 80,0 % | 10 |
Het ontwerp met twee lagen werpt zijn vruchten af. Postadressen, geboortedatums en persoonsnamen scoren 0–13% met alleen regex — er is geen vast patroon om te matchen, dus alleen het ML-model kan ze vinden. E-mails, telefoonnummers, IP's, overheids-ID's, biometrische ID's en nauwkeurige geolocatie scoren 100% met alleen regex — oppervlakteformaten die het ML-model "gratis" meekrijgt. Online handles, voertuig-ID's en authenticatiegeheimen zijn gemengd: regex vindt de standaardvormen, ML de rest. De gecombineerde recall is in elke categorie gelijk aan of hoger dan de sterkste individuele laag.
Apparaat-ID's en diverse institutionele ID's zijn de categorieën onder de 100%, en we weten waarom: deze hebben de grootste variëteit aan formaten in echte tekst. We zijn liever eerlijk over de categorieën waar de recall lager is, dan te doen alsof het filter overal perfect is.
HIPAA filter — Limited Data Set submodus
De Limited Data Set submodus behoudt datums, geografie en leeftijden van 89 jaar of jonger door ontwerp — dit zijn de signalen die HIPAA een organisatie toestaat te bewaren voor legitiem klinisch onderzoek en bedrijfsvoering.
| Categorie | Tier | Regex recall | ML recall (raw) | Gecombineerde recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| email_address | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| medical_record_number | T1 | 100,0 % (26/26) | 100,0 % (26/26) | 100,0 % | 26 |
| person_name | T1 | 15,4 % (4/26) | 100,0 % (26/26) | 100,0 % | 26 |
| phone_or_fax | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| social_security_number | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| account_number | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| health_plan_id | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| ip_address | T2 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| license_number | T2 | 0,0 % (0/12) | 100,0 % (12/12) | 100,0 % | 12 |
| vehicle_id | T2 | 25,0 % (3/12) | 100,0 % (12/12) | 100,0 % | 12 |
| device_id | T3 | 41,7 % (5/12) | 100,0 % (12/12) | 100,0 % | 12 |
| photo | T2 | 0,0 % (0/12) | 0,0 % (0/12) | 0,0 % | 12 |
Foto's zijn een bekende misser — een tekstfilter kan niet zien wat er in een afbeelding staat. Image-PHI is een apart probleem waar we nog geen oplossing voor hebben uitgebracht. Elke andere categorie in deze modus staat op 100%.
HIPAA filter — Safe Harbor submodus
Safe Harbor verwijdert alles wat de Limited Data Set submodus zou hebben behouden — datums, leeftijden boven de 89, geografie. Om de strengste dekking te krijgen, worden beide filtermodellen parallel uitgevoerd: het HIPAA-specifieke model en het algemene personal-data model.
| Categorie | Tier | Regex recall | ML recall (raw) | Gecombineerde recall | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100,0 % (18/18) | 0,0 % (0/18) | 100,0 % | 18 |
| biometric_id | T1 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| email_address | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| medical_record_number | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| person_name | T1 | 20,0 % (4/20) | 100,0 % (20/20) | 100,0 % | 20 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| social_security_number | T1 | 90,0 % (9/10) | 100,0 % (10/10) | 100,0 % | 10 |
| account_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| general_date | T2 | 100,0 % (27/27) | 29,6 % (8/27) | 100,0 % | 27 |
| health_plan_id | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| license_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 10,0 % (1/10) | 100,0 % (10/10) | 100,0 % | 10 |
| device_id | T3 | 22,2 % (2/9) | 88,9 % (8/9) | 77,8 % | 9 |
| photo | T2 | 0,0 % (0/9) | 0,0 % (0/9) | 0,0 % | 9 |
De twee interessante rijen zijn algemene datums (regex 100%, ML 30%) and leeftijden boven de 89 (regex 100%, ML 0%). We laten regex bewust beide afhandelen in Safe Harbor: datums hebben een vorm die regex altijd vindt, en we willen niet dat een probabilistisch model een numerieke drempel zoals ">89" in twijfel trekt. Een deterministische regel is betrouwbaarder dan het ML-model te vragen dezelfde regel te leren.
Algemene cijfers over alle categorieën
Alles bij elkaar opgeteld: hoe verhoudt de volledige pipeline (regex + ML samen) zich tot elke laag afzonderlijk?
| Modus | Lagen | Recall | Precisie | F2 |
|---|---|---|---|---|
| Personal Data | alleen regex | 65,8 % | 93,0 % | 69,9 % |
| Personal Data | alleen ML | 95,4 % | 92,4 % | 94,8 % |
| Personal Data | beide (vol) | 96,9 % | 98,0 % | 97,1 % |
| Limited Data Set | alleen regex | 55,9 % | 95,0 % | 60,9 % |
| Limited Data Set | alleen ML | 92,9 % | 84,5 % | 91,0 % |
| Limited Data Set | beide (vol) | 92,9 % | 89,3 % | 92,1 % |
| Safe Harbor | alleen regex | 58,9 % | 93,6 % | 63,6 % |
| Safe Harbor | alleen ML | 82,4 % | 88,3 % | 83,5 % |
| Safe Harbor | beide (vol) | 92,4 % | 88,9 % | 91,7 % |
De "volledige" rij van het Personal Data filter verslaat beide enkellaagse versies op elke metriek — het combineren van regex (voor oppervlakteformaten) met het ML-model (voor context) biedt echt iets wat geen van beide lagen alleen kan. De 97,3% kop boven dit bericht is het cijfer dat weerspiegelt wat een echte gebruiker krijgt. Het cijfer in de bovenstaande tabel is iets lager omdat het de URL-categorie bevat, die we bewust behouden zodat we links en tool calls niet verbreken.
Head-to-head tegen andere gespecialiseerde privacyfilters
De eerlijke vergelijking voor een on-device, vrijwel onmiddellijk privacyfilter zoals het onze is tegen andere on-device, vrijwel onmiddellijke privacyfilters — niet tegen gigantische cloud-hosted LLMs die seconden per bericht nodig hebben en een netwerkverbinding vereisen. We hebben elk systeem in deze klasse tegen dezelfde testsets uitgevoerd, met dezelfde matchingregels. Dezelfde standaard voor iedereen.
De vergelijkingsgroep:
- openai/privacy-filter — OpenAI's open-source gespecialiseerde privacyfilter. Ongeveer 50 miljoen parameters, klein genoeg om in elke moderne browser te draaien.
- piiranha-v1 — een detector met 278M parameters van iiiorg. De licentie beperkt het gebruik tot alleen onderzoek en evaluatie (we kunnen het meten, maar het mag niet commercieel worden geleverd).
- Microsoft Presidio — de meest gebruikte open-source redigeertool, die traditionele patroonherkenning combineert met een klein taalmodel voor context.
- GLiNER PII familie — een familie van kleine, algemene entiteitsclassificatoren. Knowledgator levert small (~44M), base (~86M) en large (~304M) varianten; NVIDIA bracht in oktober 2025 een 570M variant uit.
- Caiioo in alle drie de modi (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall over alle vijf testsets, gesorteerd met Caiioo bovenaan:
| Systeem | PrivacyBench PD-25 | Caiioo synthetisch PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetisch PHI-200 | Meertalig PD-40 (10 locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96,2 % (76/79) | 99,0 % (198/200) | — | — | 92,6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| openai/privacy-filter (50M) | 96,2 % (76/79) | 83,0 % (166/200) | 93,7 % (74/79) | 77,0 % (154/200) | 94,9 % (205/216) |
| gliner_pii_nvidia (570M) | 94,9 % (75/79) | 85,5 % (171/200) | 84,8 % (67/79) | 85,0 % (170/200) | 76,9 % (166/216) |
| gliner_pii_large (~304M) | 72,2 % (57/79) | 86,5 % (173/200) | 84,8 % (67/79) | 93,0 % (186/200) | 50,0 % (108/216) |
| gliner_pii_base (~86M) | 87,3 % (69/79) | 66,0 % (132/200) | 74,7 % (59/79) | 66,0 % (132/200) | 51,4 % (111/216) |
| gliner_pii_small (~44M) | 88,6 % (70/79) | 84,5 % (169/200) | 91,1 % (72/79) | 83,0 % (166/200) | 68,5 % (148/216) |
| Microsoft Presidio | 82,3 % (65/79) | 76,5 % (153/200) | 84,8 % (67/79) | 76,5 % (153/200) | 69,0 % (149/216) |
| piiranha-v1 (~278M) | 60,8 % (48/79) | 58,5 % (117/200) | 43,0 % (34/79) | 47,0 % (94/200) | 82,4 % (178/216) |
Caiioo loopt voorop in de klasse van gespecialiseerde filters op de twee grootste tests (PD-200 en PHI-200), staat gelijk of bovenaan bij de publieke benchmarks, en is tweede bij meertaligheid. Op de kleinste test (PrivacyBench PD-25, slechts 25 vragen) staan Caiioo en openai/privacy-filter gelijk op 96,2%. Bij meertaligheid leidt openai/privacy-filter nog steeds met 94,9%, met Caiioo op 92,6% — de taal waar we het meest achterblijven is Chinees; overal elders staan we aan of nabij de top. Als meertalige dekking bedrijfskritisch is, is openai/privacy-filter een redelijk alternatief. Voor de meeste andere workloads in deze klasse is Caiioo dat.
Het HIPAA-resultaat is het belangrijkste nieuws. Beide Caiioo HIPAA-modi behalen 100% recall op elke HIPAA-test — elke patiëntnaam, elk medisch dossiernummer, elke geboortedatum, elk rekeningnummer wordt gevonden. Het op één na beste systeem is openai/privacy-filter met 93,7% op PrivacyBenchHIPAA — een gat van 6,3 punten op een benchmark waar elke misser een openbaarmaking in de echte wereld betekent.
Een tweede getal dat de moeite waard is: over-redactie — het maskeren van zaken die eigenlijk geen privégegevens waren. Over-redactie is geen privacyschending, maar een bruikbaarheidskost. Maskeer te veel zaken en de redenering van de LLM verslechtert, waardoor het teruggestuurde antwoord minder waardevol is. Caiioo maskeert onnodig 1–24 keer over de testsets heen. Presidio: 10–51. NVIDIA's GLiNER: 31–64 op alleen de HIPAA-tests. Precisie is net zo belangrijk als recall wanneer het doel het best mogelijke antwoord is met de minst mogelijke blootstelling.
Hoe zit het met het gebruik van een frontier LLM als filter?
Dat kan — en op pure recall winnen ze. Grote algemene LLMs (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B en vergelijkbaar), die in de cloud of lokaal draaien, kunnen 95–100% scoren op elke test, inclusief meertaligheid. Dat is een reële optie voor gebruikers die maximale recall nodig hebben en bereid zijn daarvoor te betalen.
Er zijn echter duidelijke nadelen:
- Het is traag. Seconden per bericht in plaats van milliseconden. Het filter staat voor elk bericht dat de gebruiker verstuurt.
- Of het bericht verlaat de machine van de gebruiker, of het model doet dat. Om in de cloud te filteren, moet het bericht daarheen — wat het doel voorbijstreeft. Om on-device te filteren moet een model van 1–17 GB worden gedownload.
- Het kan worden misleid. Een generatief model kan midden in een bericht worden overgehaald om niet te redigeren (een "prompt injection" aanval). Een kleine classificator zoals de onze kan dat niet.
- Zelfde input, andere output. Generatieve modellen geven niet altijd twee keer hetzelfde antwoord. Dat verbreekt de round-trip — maskeren bij verzending en demaskeren bij ontvangst vertrouwt erop dat dezelfde echte waarde altijd naar dezelfde nepwaarde wordt gemapt.
Caiioo is gebouwd voor de andere kant van die afweging: een piepklein, voorspelbaar filter dat in minder dan een seconde draait in de composer voordat de gebruiker op verzenden drukt, en dat altijd dezelfde nepwaarde produceert voor dezelfde echte waarde binnen een gesprek, zodat de round-trip coherent blijft. De tabel met de vergelijkingsgroep hierboven is de eerlijke vergelijking voor dat soort gebruikssituaties.
De bewijslast ligt in de praktijk
Benchmarks zijn een startpunt, geen eindstation. Het filter is geïntegreerd in de nieuwe functie van Caiioo: de pseudonymizer — de component die zich daadwerkelijk tussen de composer en het model bevindt.
Dit is wat er gebeurt wanneer de gebruiker op verzenden drukt.
- Detecteren. De regex-laag wordt als eerste uitgevoerd — deze is deterministisch en razendsnel (microseconden). Het ML-model wordt vervolgens uitgevoerd op wat er overblijft. Als de twee lagen elkaar overlappen op hetzelfde stuk tekst, hanteren we een eenvoudige regel: regex wint bij oppervlakteformaten, ML wint bij context.
- Taggen van zelf vs. anderen. Caiioo scheidt identifiers die verwijzen naar de gebruiker van identifiers die verwijzen naar andere personen. De gebruiker kan ervoor kiezen om slechts één van beide, of beide te redigeren. Namen die de gebruiker aan een persoonlijk woordenboek heeft toegevoegd, tellen altijd als "zelf".
- Vervangen. Elke echte waarde krijgt een stabiel, qua stijl passend pseudoniem. "Sarah Goldberg" wordt "Maya Hartwell" — en blijft "Maya Hartwell" gedurende het hele gesprek, zodat de redenering van het model over die persoon niet versnipperd raakt over verschillende beurten. Een lookup-tabel van echt-naar-nep wordt op het apparaat van de gebruiker bewaard, versleuteld met een sleutel uit de keychain van het platform.
- Verzenden. Het model ontvangt een volledig fictief bericht. Geen enkele echte identifier gaat ooit over het netwerk, en ons audit log registreert alleen aantallen — nooit de waarden zelf.
- Herstellen. De streaming respons wordt bij binnenkomst direct terugvertaald. "Maya Hartwell" in het antwoord van het model wordt weer "Sarah Goldberg" voordat het het scherm bereikt, weergegeven met een kleine oplichtende 'pill' zodat de gebruiker in één oogopslag kan zien wat er beschermd is.
- Ook tool-argumenten herstellen. Als het model een tool aanroept — een e-mail verzenden, een ticket indienen, naar een document schrijven — en de argumenten bevatten fictieve gegevens, dan vervangen we deze weer door de echte waarden voordat de tool wordt uitgevoerd. Het model redeneert over de fictieve gegevens; de actie gebruikt de echte waarde.
Het filter maakt geen onderscheid tussen de gebruikte AI-service. Het wordt uitgevoerd voordat het bericht het model bereikt, dus OpenRouter, Anthropic, Google, OpenAI en een lokale Ollama ontvangen allemaal dezelfde gemaskeerde payload. Het toevoegen van een nieuwe provider opent het privacylek niet opnieuw.
Wie het beschermt
De gebruiker. De naam, het e-mailadres, het adres, het telefoonnummer, het IP-adres en de biometrische identificatiegegevens van een gebruiker — de zaken die, samen genomen, een persoon identificeren voor een aggregator — verlaten nooit het apparaat wanneer het filter is ingeschakeld.
De mensen over wie de gebruiker praat. De meeste privacytools richten zich op de persoon die typt, maar wat ze negeren is het 'sociaal contract' — het feit dat we allemaal een verantwoordelijkheid hebben tegenover anderen en onszelf. Het indienen van "Analyseer het gedrag van dhr. Saunders op incompetentie" bij een LLM, waar het voor onbepaalde tijd in systeemlogs kan worden opgeslagen, is onverantwoordelijk (en potentieel lasterlijk). Een LLM om hulp vragen bij een Google Sheet met 1.000 zakelijke contacten deponeert ze allemaal in de data-retentie-vliegenvanger (in verschillende mate, afhankelijk van de werkelijke 'zero data retention' die van kracht is). Het filter van Caiioo dekt ook derden: de klant voor wie een contract wordt opgesteld, de patiënt wiens dossier wordt geanalyseerd, de collega wiens e-mail in de context is geplakt. Zij hebben geen toestemming gegeven voor een externe LLM om hun identificatiegegevens te zien. Het filter respecteert dat standaard; de gebruiker kan overschakelen naar "alleen zelf" of "alleen anderen" als een workflow dat vereist.
Entiteiten — bedrijven, ziekenhuizen, firma's. Rekeningnummers, licentienummers, medische dossiernummers, financiële routeringsgegevens, interne ID's, API-sleutels, klantenlijsten. Een bedrijf heeft hetzelfde belang bij dataminimalisatie als een persoon. Een clinicus die Caiioo gebruikt om een ontslagbrief op te stellen, stuurt het medisch dossiernummer van de patiënt niet naar OpenAI. Een advocaat stuurt het rekeningnummer van de cliënt niet naar Anthropic. Een support engineer stuurt de API-sleutel uit het logboek van de klant niet naar Google. Het filter vraagt niet of de identificatie bij een persoon of een entiteit hoort — het houdt het gewoon op het apparaat.
Maximale bruikbaarheid, minimale blootstelling
Het hele punt is dat de gebruiker het filter niet zou moeten voelen.
De meeste privacytools dwingen tot een keuze: agressief anonimiseren en toezien hoe het antwoord van het model slechter wordt, of de prompt bruikbaar houden en toezien hoe de privacybelofte verwatert. Wij hebben die afweging afgewezen. Het model krijgt nog steeds een volledig gevormde prompt — het ziet een naam, een plaats, een datum, een medisch dossiernummer, allemaal op de juiste grammaticale posities. Het ziet alleen nepgegevens. De redenering is identiek; alleen de strings zijn geschoond.
Stabiele substitutie is wat dat mogelijk maakt. Omdat dezelfde echte waarde binnen een gesprek altijd naar dezelfde nepwaarde wordt vertaald — in het bericht van de gebruiker, het resultaat van de tool dat terugkomt met een verwijzing naar die naam, het eerdere antwoord van het model dat het noemde — heeft het model een samenhangend persoon, plaats of ding om over te redeneren. Gesprekken met meerdere beurten raken niet in de war. Tool-aanroepen gaan niet kapot. Sub-agenten erven de map van het hoofdgesprek en blijven consistent over de hele taak.
De output die de gebruiker ziet, is het echte gesprek. De gegevens die de provider ziet, zijn een samenhangende fictie. Het werk gebeurt in de kloof tussen die twee weergaven, en het doel — het enige doel — is om die kloof onzichtbaar te maken.
Een privacyfilter dat in de weg zit, wordt uitgeschakeld. Een privacyfilter dat opgaat in de workflow is het enige soort dat het waard is om uit te brengen.
Dat is de lat die we onszelf hebben gesteld.