Detta är en maskinöversättning av det engelska originaldokumentet. Vid eventuella avvikelser mellan denna översättning och den engelska originalversionen ska den engelska versionen ha företräde. Läs den engelska originalversionen
Pseudonymisering direkt på enheten: byggd och benchmarkad
2026-05-22 · Caiioo Team
Vi ville lösa integritetsproblemet med AI-system som tränas på och sparar verklig personidentifierbar information. Policyer och avtal om "Zero Data Retention" minskar risken, men de är fyllda med undantag. De säger i princip: "Vi kommer inte att lagra någon av dina instruktioner eller utdata förutom för: (infoga lång lista med undantag här: säkerhetsändamål, statlig övervakning, rättsliga krav, produktutveckling, felloggar, förbättring av tjänsterna...)"
För att lösa detta byggde vi ett personuppgiftsfilter som körs på användarens egen maskin, ser meddelandet innan det lämnar enheten och returnerar samma svar som användaren skulle ha fått om det hade skrivits helt utan filter.
Så vi byggde ett. Caiioos nästa version kommer att innehålla denna Pseudonymizer. Tillgänglig via sköldikonen i agentchatten samt i inställningarna.
Detta white paper beskriver logiken, arkitekturen, utvärderingsprocessen och designprinciperna bakom vårt system för integritetsfiltrering.
Vad vi föresatte oss att göra
Allmänt integritetsskydd genom dataminimering. När en användare chattar med en fjärrmodell behöver modellen inte ett riktigt namn, en hemadress, en riktig e-postadress eller en kunds telefonnummer för att svara på användarens fråga. Den behöver frågans form, och den behöver se ut som en riktig fråga så att LLM inte avfärdar förfrågan som ett test. Filtret rensar därför bort verkliga identifierare från den data som skickas till AI:n och infogar de verkliga värdena igen på vägen tillbaka. Modellen ser syntetiska namn och identifierare; användaren ser det verkliga samtalet.
Stöd för HIPAA-efterlevnad. Ett andra läge riktar sig mot de 18 identifierarna i HIPAA Safe Harbor-regeln (§164.514) och den lösare varianten Limited Data Set. En kliniker, en administratör inom hälso- och sjukvård eller vem som helst som arbetar i ett omfattat arbetsflöde kan prata med en generell modell om verkliga fall utan att skicka skyddad hälsoinformation till AI:n. Vi är inte den omfattade enhetens efterlevnadsansvariga — men vi kan vara det lager som förhindrar att PHI överhuvudtaget lämnar den bärbara datorn. Våra utvärderingar ger mätbara riktmärken som organisationer kan använda för att bedöma filtrets lämplighet för deras standarder gällande efterlevnad och integritet. Alla integritets- och säkerhetsåtgärder är bedömningsfrågor som vilar på användarens eller användarenhetens ansvar.
Vi valde båda eftersom det tekniska utförandet är detsamma, och användningsfallet för PHI är faktiskt tekniskt enklare på grund av dess användning av distinkta namngivna entiteter, vilka är lättare att maskera än den mer generella datan i kategorin personuppgifter. HIPAA-filtrering underlättas också av det faktum att det i allmänhet sker på engelska eller spanska. Vi upptäcker identifierare, ersätter dem med stabila pseudonymer och ersättningsidentifierare i samma format, återställer dem på vägen tillbaka och loggar aldrig de verkliga värdena. Kopplingen mellan den syntetiska informationen och den verkliga informationen stannar enbart på användarens enhet, så att användaren kan läsa verklig information i agentens svar. Det är kategorilistan och policygrinden som ändras mellan lägena.
Varför regex plus maskininlärning, och inte bara en av dem
Det finns två huvudsakliga filterteknologier i vår pseudonymiserare: ett deterministiskt språk för mönsterigenkänning som kallas regex, och tränade maskininlärningsmodeller.
Regex är oslagbart på ytliga format. En e-postadress har en form ([email protected]). Det har även en IP, ett kreditkort, ett IBAN, ett VIN, ett SSN (XXX-XX-XXXX), en API-nyckel. Om formatet är tillförlitligt fångar regex det deterministiskt, varje gång, utan modellbelastning och utan inferenskostnad.
Regex är dock hopplöst på kontext. "Sarahs journal från förra tisdagen" innehåller en person och ett datum, men inget av dem kan särskiljas enbart genom sitt format. "Patienten på 14 Elm" innehåller en adress som överlappar tusen icke-adresser. "Deras MRN är 7741032" behöver orden runt numret för att betyda något.
En liten finjusterad språkmodell hanterar kontext — vår är en specialtränad 110M-parameter encoder destillerad från en flerspråkig tiny language model — . Den läser meningen, inte delsträngen, och är tillräckligt liten för att köras extremt snabbt på en enhet, till och med en mobiltelefon.
Benchmarks illustrerar de kompletterande styrkorna hos de två lagren. Vi har benchmarkat de två lagren isolerat för att säkerställa att båda faktiskt bidrar. På PrivacyBench-PD-frågepaketet med 150 frågor, där frågorna och svaren uttryckligen INTE användes för att träna modellen:
| Lager | PII fångade | Fångstfrekvens |
|---|---|---|
| Endast Regex | 205 / 670 | 30,6 % |
| Endast ML | 516 / 670 | 77,0 % |
| Båda (produktion) | 625 / 670 | 93,3 % |
Regex ensamt missar tre fjärdedelar av identifierarna eftersom de flesta identifierare i verklig prosa inte är strukturerade. ML ensamt missar 16 procentenheter som regex-lagret skulle ha fångat — de saker som är enbart sin form (ett kreditkort ser ut som ett kreditkort; modellen har ingen extra signal att tillföra). Tillsammans täcker de vad ingen av dem täcker ensam.
Om man tittar djupare på var varje lager är avgörande: i samma testset fångades 16 testvärden endast av regex (e-post, IP-adresser, finansiella konton, strukturerade ID:n) och 327 fångades endast av ML (namn, kontextuella identifierare, flerspråkiga formuleringar).
Liten, smart, snabb — och körs överallt
Vi var tvungna att få filtret att köras direkt på enheten, vilket var en teknisk utmaning.
Det måste vara litet eftersom vår app körs lokalt på många system: i ett webbläsartillägg, en macOS-app, en iOS-app, en Android-app eller Windows och Linux. Paketet är cirka 113 MB per modell. Det finns två modeller — en för allmänna personuppgifter, en för skyddad hälsoinformation — och Safe Harbor-läget kör båda parallellt. Bland dessa är en enklare Android-enhet den minst kraftfulla, men vårt system fungerar utmärkt.
Det måste vara smart eftersom falska negativa resultat läcker verklig data till en fjärrstyrd LLM och falska positiva resultat förstör konversationen. Namn måste maskeras; pronomen får inte maskeras. Läkarens e-post i en vidarebefordrad tråd bör maskeras; sidfoten [email protected] bör förmodligen inte göras det.
Det måste vara snabbt eftersom det sitter direkt i vägen för varje meddelande användaren skickar eller tar emot. Vi mätte fördröjningen till under 200 ms på en enda CPU-tråd, mestadels tokenisering. På WebGPU och på Apples Neural Engine är det försumbart jämfört med nätverkslatensen för själva LLM-anropet.
Det måste fungera i flera miljöer eftersom Caiioo är plattformsoberoende. Samma system körs i Chrome-tillägg, macOS och iOS, Android samt på Windows och Linux. En detekteringsmodell, ett regex-bibliotek, en sammanfogare, en policy — identiskt beteende på varje yta där Caiioo körs.
Resultaten
Efter flera omgångar av tester och träning landade vi på den 16:e versionen av våra modeller. Nedan visas tre benchmarks som var och en mäter olika saker.
Vårt eget testset, 150 frågor som modellen aldrig sett
Innan vi testade mot publika benchmarks körde vi vårt Personal Data-filter mot ett internt testset som vi medvetet höll utanför träningsdatan — så detektorn har aldrig sett någon av dessa frågor tidigare. 150 frågor uppdelade i fyra grupper (kodsnuttar, dokumentprosa, avsiktligt ovanliga formuleringar och 10 icke-engelska språk), plus en "negativ" grupp som inte innehåller någon privat data alls (en säkerhetskontroll för att se till att vi inte maskerar för mycket). Kombinerad regex + ML-pipeline:
| Sub-bench | Fångade | Andel |
|---|---|---|
| code_bench | 69 / 74 | 93,2 % |
| doc_bench | 233 / 247 | 94,3 % |
| generalization_bench | 123 / 133 | 92,5 % |
| multilingual_bench | 200 / 216 | 92,6 % |
| Alla 4 positiva benches | 625 / 670 | 93,3 % |
(Den negativa gruppen hade ingen privat data att hitta. Filtret maskerade en sak som det inte borde ha gjort — vilket stämmer överens med precisionssiffrorna längre ner.)
Bedömningen är strikt: varje förväntad del av privat data måste försvinna helt från den maskerade utdatan för att frågan ska få poäng. Ingen delpoäng, inget "nära nog". Det är hårdare än benchmarks som ber en annan LLM att vara domare (LLM-domare tenderar att vara generösa). För direkt jämförbara siffror mot andra system, se head-to-head-sektionen längre ner.
PrivacyBenchHIPAA — 40 hälso- och sjukvårdsfrågor
Varje fråga listar skyddad hälsoinformation som måste maskeras (namn, journalnummer, etc.) OCH signaler som måste behållas (datum, geografi, ålder om under 90 — regeln för HIPAA Limited Data Set). Bedömaren kontrollerar båda hållen: tog vi bort det vi borde ha tagit bort, och lät vi bli det vi borde ha låtit bli?
| Läge | PHI maskerat | Behållna kvar |
|---|---|---|
| Limited Data Set (bevara datum / geografi / ålder ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (maskera allt inklusive datum) | 99 / 104 (95,2 %) | — |
Sub-läget Limited Data Set är perfekt i detta benchmark. Safe Harbor — som har mer att maskera och därmed fler möjligheter att missa — täcker 95,2 %.
Kategori-för-kategori-resultat på vår egen data, 200 prover per läge
Publika benchmarks klumpar ihop allt. Vår interna testdata delar upp resultaten per kategori (namn, e-post, adresser och så vidare) och kör varje kategori på tre sätt: endast regex, endast ML, och båda tillsammans. Det visar oss exakt vilken teknik som fångar vilken typ av identifierare — och var de behöver varandra. Senaste körningen, 2026-05-20:
Sammanfattning över alla tre filterlägen
| Läge | Kombinerad recall | Precision | F2 | Prover |
|---|---|---|---|---|
| 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 |
Dessa siffror exkluderar URLer, som vi medvetet låter bli — att förstöra en URL skulle bryta nedströmsåtgärder som "öppna denna länk" eller "hämta den här sidan". Mer om det i workflow-sektionen nedan.
Helhetsbilden före tabellerna per kategori: i varje läge fångas de identifierare som faktiskt identifierar en person i nästan 100 % av fallen. Namn, e-post, telefonnummer, postadresser, statliga ID-handlingar, biometriska ID:n, exakt geolokalisering, journalnummer, födelsedatum, personnummer — fångas i varje prov, varje test. De kategorier där vi hamnar under 100 % är förutsägbara: enhets-ID:n (enorm variation av format i verklig text), diverse institutionella ID:n (lojalitetsnummer, anställnings-ID — samma problem) och foton (ett filter för enbart text kan inte se vad som finns i en bild). Inget av dessa är den typ av identifierare som "namn i ett diagram" eller "e-post i ett utkast" som faktiskt spelar roll för läckage. Kategorierna med höga insatser är de pålitliga.
Personal Data filter
Sorterat efter kombinerad recall (bäst först), sedan efter risknivå (T1 = mest känslig).
| Kategori | Nivå | Regex recall | ML recall (rå) | Kombinerad 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 |
När man läser tabellen ser man att designen med två lager lönar sig. Postadresser, födelsedatum och personnamn får 0–13 % med enbart regex — det finns inget mönster att matcha, så endast ML-modellen kan fånga dem. E-post, telefonnummer, IP-adresser, statliga ID:n, biometriska ID:n och exakt geolokalisering får 100 % med enbart regex — ytliga format som ML-modellen får "gratis". Online-alias, fordons-ID:n och autentiseringshemligheter är blandade: regex fångar standardformerna, ML fångar resten. Den kombinerade recall-nivån matchar eller överträffar det enskilda lager som är starkast i varje kategori.
Enhets-ID:n och diverse institutionella ID:n är de kategorier som ligger under 100 %, och vi vet varför: dessa har den största variationen av format i verklig text. Vi vill hellre vara ärliga med de kategorier där recall brister än att låtsas att filtret är perfekt överallt.
HIPAA filter — Limited Data Set submode
Sub-läget Limited Data Set bevarar datum, geografi och åldrar 89 år eller yngre genom design — det är de signaler som HIPAA tillåter en organisation att behålla för legitim klinisk forskning och verksamhet.
| Kategori | Nivå | Regex recall | ML recall (rå) | Kombinerad 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 |
Foton är en känd miss — ett filter för enbart text kan inte se vad som finns i en bild. Bild-PHI är ett separat problem som vi inte har lanserat ännu. Alla andra kategorier i detta läge ligger på 100 %.
HIPAA filter — Safe Harbor submode
Safe Harbor rensar bort allt som sub-läget Limited Data Set skulle ha behållit — datum, åldrar över 89, geografi. För att få den striktaste täckningen körs båda filtermodellerna parallellt: den HIPAA-specifika och den generella för personuppgifter.
| Kategori | Nivå | Regex recall | ML recall (rå) | Kombinerad 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 två intressanta raderna är generella datum (regex 100 %, ML 30 %) och åldrar över 89 (regex 100 %, ML 0 %). Vi låter avsiktligt regex hantera båda i Safe Harbor: datum har en form som regex fångar varje gång, och vi vill inte att en probabilistisk modell ska ifrågasätta ett numeriskt tröskelvärde som ">89". En deterministisk regel är mer pålitlig än att be ML-modellen lära sig samma regel.
Övergripande siffror för alla kategorier
När vi lägger ihop allt: hur står sig den fullständiga pipelinen (regex + ML tillsammans) mot något av lagren ensamt?
| Läge | Lager | Recall | Precision | F2 |
|---|---|---|---|---|
| Personal Data | endast regex | 65,8 % | 93,0 % | 69,9 % |
| Personal Data | endast ML | 95,4 % | 92,4 % | 94,8 % |
| Personal Data | båda (full) | 96,9 % | 98,0 % | 97,1 % |
| Limited Data Set | endast regex | 55,9 % | 95,0 % | 60,9 % |
| Limited Data Set | endast ML | 92,9 % | 84,5 % | 91,0 % |
| Limited Data Set | båda (full) | 92,9 % | 89,3 % | 92,1 % |
| Safe Harbor | endast regex | 58,9 % | 93,6 % | 63,6 % |
| Safe Harbor | endast ML | 82,4 % | 88,3 % | 83,5 % |
| Safe Harbor | båda (full) | 92,4 % | 88,9 % | 91,7 % |
Raden "full" för Personal Data-filtret slår båda versionerna med enstaka lager på varje mätvärde — att kombinera regex (för ytliga format) med ML-modellen (för kontext) ger verkligen något som inget av lagren kan erbjuda ensamt. Siffran 97,3 % som nämndes tidigare i detta inlägg är den siffra som speglar vad en verklig användare får. Siffran i tabellen ovan är något lägre endast för att den inkluderar kategorin URL, som vi medvetet bevarar för att inte bryta länkar och verktygsanrop.
Head-to-head mot andra dedikerade integritetsfilter
Den rättvisa jämförelsen för ett integritetsfilter som körs på enheten och är nästan omedelbart, som vårt, är mot andra integritetsfilter som körs på enheten och är nästan omedelbara — inte mot gigantiska molnbaserade LLMs som tar sekunder per meddelande och kräver en nätverksresa. Vi körde alla system i denna klass mot samma testset och använde samma matchningsregler. Samma standard för alla.
Klassen av likvärdiga system:
- openai/privacy-filter — OpenAI:s dedikerade integritetsfilter med öppen källkod. Cirka 50 miljoner parametrar, tillräckligt litet för att köras i vilken modern webbläsare som helst.
- piiranha-v1 — en detektor med 278 miljoner parametrar från iiiorg. Dess licens begränsar den till endast forskning och utvärdering (vi kan mäta den, men den kan inte levereras kommersiellt).
- Microsoft Presidio — det mest använda verktyget för maskering med öppen källkod, som kombinerar traditionell mönstermatchning med en liten språkmodell för kontext.
- GLiNER PII family — en familj av små, generella entitetsklassificerare. Knowledgator levererar varianterna small (~44M), base (~86M) och large (~304M); NVIDIA släppte en variant på 570M i oktober 2025.
- Caiioo i alla tre lägen (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall över alla fem testset, sorterat med Caiioo först:
| System | PrivacyBench PD-25 | Caiioo syntetisk PD-200 | PrivacyBenchHIPAA-40 | Caiioo syntetisk PHI-200 | Flerspråkig PD-40 (10 språk) |
|---|---|---|---|---|---|
| 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 leder klassen för dedikerade filter på de två största testerna (PD-200 och PHI-200), ligger lika med eller leder på publika benchmarks, och är tvåa på flerspråkighet. På det minsta testet (PrivacyBench PD-25, endast 25 frågor) ligger Caiioo och openai/privacy-filter lika på 96,2 %. På flerspråkighet leder openai/privacy-filter fortfarande med 94,9 % medan Caiioo ligger på 92,6 % — det språk där vi ligger efter mest är kinesiska; överallt annars ligger vi i eller nära toppen. Om flerspråkig täckning är verksamhetskritisk är openai/privacy-filter ett rimligt alternativ. För de flesta andra arbetsbelastningar i denna klass är Caiioo det.
HIPAA-resultatet är den stora nyheten. Båda Caiioo HIPAA-lägena nådde 100 % recall på varje HIPAA-test — varje patientnamn, varje journalnummer, varje födelsedatum, varje kontonummer fångas. Det näst bästa systemet är openai/privacy-filter med 93,7 % på PrivacyBenchHIPAA — ett gap på 6,3 punkter, i ett benchmark där varje miss är ett avslöjande i verkligheten.
En annan siffra värd att notera: övermaskering — att maskera saker som faktiskt inte var privat data. Övermaskering är inte en integritetsskada, det är en användbarhetskostnad. Maskera för många saker och LLM:ens resonemang blir sämre, och det returnerade svaret försämras. Caiioo maskerar i onödan 1–24 gånger över testseten. Presidio: 10–51. NVIDIA:s GLiNER: 31–64 enbart på HIPAA-testerna. Precision är lika viktigt som recall när målet är bästa möjliga svar med minsta möjliga exponering.
Vad sägs om att bara använda en frontier LLM som filter?
De kan göra det — och på rå recall vinner de. Stora generella LLMs (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B och liknande), som körs antingen i molnet eller lokalt, kan få 95–100 % på varje test inklusive flerspråkighet. Det är ett reellt alternativ för användare som behöver maximal recall och är villiga att betala för det.
Nackdelarna är dock påtagliga:
- Det är långsamt. Sekunder per meddelande istället för millisekunder. Filtret ligger framför varje meddelande användaren skickar.
- Antingen lämnar meddelandet användarens maskin, eller så gör modellen det. För att filtrera i molnet måste meddelandet skickas dit — vilket motverkar syftet. Att filtrera på enheten kräver nedladdning av en modell på 1–17 GB.
- Det kan luras. En generativ modell kan mitt i ett meddelande övertalas att inte maskera (en "prompt injection"-attack). En liten klassificerare som vår kan inte det.
- Samma indata, olika utdata. Generativa modeller ger inte alltid samma svar två gånger. Det bryter tur-och-retur-processen — maskering på vägen ut och avmaskering på vägen tillbaka bygger på att samma verkliga värde alltid mappas till samma falska värde.
Caiioo är byggt för den andra sidan av den avvägningen: ett pyttelitet, förutsägbart filter på under en sekund som körs i skrivfönstret innan användaren trycker på skicka, och som alltid producerar samma falska värde för samma verkliga värde inom en konversation, så att tur-och-retur-processen förblir sammanhängande. Tabellen för likvärdiga system ovan är jämförelsen mellan äpplen och äpplen för den typen av användningsfall.
Beviset ligger i resultatet
Benchmarks är en startpunkt, inte en mållinje. Filtret är inbyggt i Caiioos nya funktion: pseudonymizer — den komponent som faktiskt sitter mellan kompositören och modellen.
Här är vad som händer när användaren trycker på skicka.
- Detektera. Regex-lagret körs först — det är deterministiskt och går på mikrosekunder. ML-modellen körs därefter på det som återstår. Om de två lagren överlappar på samma textstycke använder vi en enkel regel: regex vinner på ytformat, ML vinner på kontext.
- Tagga själv vs. andra. Caiioo separerar identifierare som refererar till användaren från identifierare som refererar till andra personer. Användaren kan välja att maskera endast den ena, eller båda. Namn som användaren har lagt till i en personlig ordbok räknas alltid som "själv".
- Ersätta. Varje verkligt värde får en stabil, stilmatchad pseudonym. "Sarah Goldberg" blir "Maya Hartwell" — och förblir "Maya Hartwell" under hela konversationen, så att modellens resonemang kring den personen inte fragmenteras mellan olika turer. En uppslagstabell för verkligt-till-falskt sparas på användarens enhet, krypterad med en nyckel från plattformens keychain.
- Skicka. Modellen tar emot ett helt falskt meddelande. Ingen verklig identifierare skickas någonsin över nätverket, och vår granskningslogg registrerar endast antal — aldrig själva värdena.
- Återställa. Det strömmande svaret mappas tillbaka allt eftersom det anländer. "Maya Hartwell" i modellens svar blir "Sarah Goldberg" innan det når skärmen, renderat med en liten lysande markering så att användaren med ett ögonkast kan se vad som skyddades.
- Återställa även verktygsargument. Om modellen anropar ett verktyg — skickar ett e-postmeddelande, skapar ett ärende, skriver i ett dokument — och argumenten innehåller falska värden, ersätter vi dem med de verkliga värdena innan verktyget körs. Modellen resonerar kring det falska; åtgärden använder det verkliga värdet.
Filtret bryr sig inte om vilken AI-tjänst som används. Det körs innan meddelandet ens når modellen, så OpenRouter, Anthropic, Google, OpenAI och en lokal Ollama får alla samma maskerade data. Att lägga till en ny leverantör öppnar inte integritetshålet på nytt.
Vem det skyddar
Användaren. En användares namn, e-post, adress, telefon, IP och biometriska identifierare — de saker som tillsammans identifierar en person för en datainsamlare — lämnar aldrig enheten när filtret är på.
Människorna användaren pratar om. De flesta integritetsverktyg fokuserar på personen som skriver, men vad de ignorerar är det "sociala kontraktet" — det faktum att vi alla har ett ansvar gentemot andra såväl som oss själva. Att skicka in "Vänligen analysera herr Saunders beteende för inkompetens" till en LLM, där det kan registreras i systemloggar på obestämd tid, är oansvarigt (och potentiellt ärekränkande). Att be en LLM om hjälp med ett Google Workspace-ark som innehåller 1 000 affärskontakter deponerar alla dessa i datalagringens flugpapper. Caiioos filter täcker även tredje part: klienten ett kontrakt skrivs för, patienten vars journal analyseras, kollegan vars e-post klistrades in som sammanhang. De har inte samtyckt till att en fjärrstyrd LLM ser deras identifierare. Filtret respekterar det som standard; användaren kan byta till "endast mig själv" eller "endast andra" om ett arbetsflöde kräver det.
Enheter — företag, sjukhus, firmor. Kontonummer, licensnummer, journalnummer, finansiella routingdetaljer, interna ID:n, API-nycklar, kundlistor. Ett företag har samma intresse av dataminimering som en person. En kliniker som använder Caiioo för att skriva ett utskrivningsmeddelande skickar inte patientens journalnummer till OpenAI. En advokat skickar inte klientens kontonummer till Anthropic. En supportingenjör skickar inte API-nyckeln från kundens logg till Google. Filtret frågar inte om identifieraren tillhör en person eller en enhet — det behåller den helt enkelt på enheten.
Maximal nytta, minimal exponering
Hela poängen är att användaren inte ska känna av filtret.
De flesta integritetsverktyg tvingar fram ett val: maskera aggressivt och se modellens svar bli sämre, eller behåll instruktionen användbar och se integritetslöftet urholkas. Vi förkastade den kompromissen. Modellen får fortfarande en fullständig instruktion — den ser ett namn, en plats, ett datum, ett journalnummer, allt i rätt grammatiska positioner. Den ser bara falska sådana. Dess resonemang är identiskt; endast strängarna är rensade.
Stabil substitution är det som får det att fungera. Eftersom samma verkliga värde alltid mappas till samma falska inom en konversation — i användarens meddelande, verktygsresultatet som kommer tillbaka och refererar till namnet, modellens tidigare svar som nämnde det — har modellen en sammanhängande person, plats eller sak att resonera kring. Konversationer med flera turer blir inte röriga. Verktygsanrop går inte sönder. Underagenter ärver huvudkonversationens mappning och förblir konsekventa genom hela uppgiften.
Utdata som användaren ser är den verkliga konversationen. Data som leverantören ser är en sammanhängande fiktion. Arbetet sker i glappet mellan dessa två vyer, och målet — det enda målet — är att göra det glappet osynligt.
Ett integritetsfilter som är i vägen kommer att stängas av. Ett integritetsfilter som försvinner in i arbetsflödet är den enda sorten som är värd att leverera.
Det är den ribban vi har lagt.