Ito ay isang machine translation ng orihinal na dokumentong Ingles. Sa kaganapan ng anumang salungatan sa pagitan ng pagsasaling ito at ng orihinal na bersyong Ingles, ang bersyong Ingles ang mangingibabaw. Basahin ang orihinal na bersyong Ingles
On-device pseudonymizer: binuo at na-benchmark
2026-05-22 · Caiioo Team
Nais naming lutasin ang problema sa privacy ng mga AI system na nagsasanay at nagpapanatili ng tunay na personally identifiable information. Ang mga patakaran at kasunduan sa "Zero Data Retention" ay nagbabawas ng panganib, ngunit puno ang mga ito ng mga exception. Mahalaga nilang sinasabi: "Hindi namin itatago ang alinman sa iyong mga prompt o output maliban sa: (ilagay ang malaking listahan ng mga exception dito: mga layuning pangseguridad, pagsubaybay ng gobyerno, litigation holds, pagbuo ng produkto, error logs, pagpapabuti ng mga serbisyo...)"
Upang malutas ito, binuo namin ang isang personal data filter na tumatakbo sa sariling makina ng user, nakikita ang mensahe bago ito umalis sa device, at ibinabalik ang parehong sagot na matatanggap sana ng user kung ito ay na-type nang walang filter.
Kaya binuo namin ito. Kasama sa susunod na bersyon ng Caiioo ang Pseudonymizer. Maa-access sa pamamagitan ng shield icon sa agent chat pati na rin sa settings.
Binabalangkas ng white paper na ito ang katwiran, arkitektura, proseso ng pagsusuri, at mga prinsipyo ng disenyo sa likod ng aming privacy filtering system.
Ano ang aming layuning gawin
Pangkalahatang proteksyon sa privacy sa pamamagitan ng data minimization. Kapag ang isang user ay nakikipag-chat sa isang remote model, hindi kailangan ng model ang tunay na pangalan, address ng bahay, tunay na email, o numero ng telepono ng customer upang sagutin ang tanong ng user. Ang kailangan nito ay ang anyo ng tanong, at kailangang magmukha itong totoong tanong upang hindi balewalain ng LLM ang query bilang isang test lamang. Samakatuwid, tinatanggal ng filter ang mga tunay na identifier mula sa data na ipinapadala sa AI at ibinabalik ang mga tunay na halaga sa pagtugon nito. Ang nakikita ng model ay mga synthetic na pangalan at identifier; ang nakikita ng user ay ang totoong usapan.
Tulong sa HIPAA compliance. Ang ikalawang mode ay nakatuon sa 18 identifier sa HIPAA Safe Harbor rule (§164.514) at sa mas maluwag na Limited Data Set variant. Ang isang clinician, healthcare admin, o sinumang nagtatrabaho sa isang covered workflow ay maaaring makipag-usap sa isang general-purpose model tungkol sa mga totoong kaso nang hindi nagpapadala ng protected health information sa AI. Hindi kami ang compliance officer ng covered entity — ngunit maaari kaming magsilbing layer na pumipigil sa PHI na lumabas sa laptop sa simula pa lamang. Ang aming mga evaluation ay nagbibigay ng mga nasusukat na benchmark na magagamit ng mga organisasyon upang suriin ang kaangkupan ng filter para sa kanilang mga pamantayan sa compliance at privacy. Ang lahat ng hakbang sa privacy at seguridad ay mga pagpapasya na responsibilidad ng user o user entity.
Pinili namin ang dalawang ito dahil pareho ang engineering na ginagamit, at ang PHI use case ay mas madali sa teknikal na aspeto dahil sa paggamit nito ng mga natatanging named entities, na mas madaling i-redact kaysa sa mas pangkalahatang data sa kategoryang Personal Data. Nakakatulong din sa HIPAA filtering ang katotohanang ito ay karaniwang nasa English o Spanish. Nakikita namin ang mga identifier, pinapalitan ang mga ito ng mga stable na pseudonym at substituted identifier sa parehong format, ibinabalik ang mga ito sa pagtugon, at kailanman ay hindi nila-log ang mga tunay na halaga. Ang mapa sa pagitan ng synthetic na impormasyon at tunay na impormasyon ay nananatili lamang sa device ng user, upang mabasa ng user ang tunay na impormasyon sa mga tugon ng agent. Ang listahan ng kategorya at ang policy gate ang nagbabago sa pagitan ng mga mode.
Bakit regex at machine learning, at hindi isa lang sa kanila
Mayroong dalawang pangunahing teknolohiya ng filter sa aming pseudonymizer: isang deterministic pattern recognition language na tinatawag na regex, at mga trained na machine learning model.
Ang regex ay hindi matatalo pagdating sa surface formats. Ang isang email address ay may hugis ([email protected]). Ganoon din ang isang IP, credit card, IBAN, VIN, SSN (XXX-XX-XXXX), at API key. Kung ang format ay maaasahan, nahuhuli ito ng regex nang deterministic, sa bawat pagkakataon, nang walang model load at walang inference cost.
Gayunpaman, ang regex ay walang kakayahan pagdating sa context. Ang "Sarah's chart from last Tuesday" ay naglalaman ng isang tao at isang petsa, ngunit wala sa dalawang ito ang maaaring makilala sa pamamagitan ng format lamang. Ang "The patient at 14 Elm" ay naglalaman ng isang address na kamukha ng libu-libong non-addresses. Ang "Their MRN is 7741032" ay nangangailangan ng mga salita sa paligid ng numero upang magkaroon ng kahulugan.
Isang maliit na fine-tuned language model ang humahawak sa context — ang sa amin ay isang specially-trained na 110M-parameter encoder na distilled mula sa isang multilingual tiny language model — . Binabasa nito ang pangungusap, hindi lang ang substring, at sapat ang liit nito upang tumakbo nang napakabilis sa isang device, kahit sa isang mobile phone.
Ipinapakita ng mga benchmark ang magkakapares na lakas ng dalawang layer. Ni-benchmark namin ang dalawang layer nang magkahiwalay upang matiyak na ang bawat isa ay talagang nag-aambag. Sa 150-question PrivacyBench-PD question set kung saan ang mga tanong at sagot ay tahasang HINDI ginamit upang i-train ang model:
| Layer | PII caught | Caught rate |
|---|---|---|
| Regex only | 205 / 670 | 30.6 % |
| ML only | 516 / 670 | 77.0 % |
| Both (production) | 625 / 670 | 93.3 % |
Ang regex lamang ay nakakaligtaan ang tatlong kapat (3/4) ng mga identifier dahil karamihan sa mga identifier sa totoong prosa ay hindi structured. Ang ML lamang ay nakakaligtaan ang 16 percentage points na nahuli sana ng regex layer — ang mga bagay na nakadepende lamang sa kanilang hugis (ang credit card ay mukhang credit card; walang dagdag na signal ang model na maibibigay). Magkasama, sinasaklaw nila ang hindi kayang saklawin ng bawat isa nang mag-isa.
Sa mas malalim na pagsusuri kung saan nagiging mapagpasya ang bawat layer: sa parehong set na iyon, 16 na test values ang nahuli lamang ng regex (mga email, IP, financial accounts, structured IDs) at 327 ang nahuli lamang ng ML (mga pangalan, contextual identifiers, multilingual phrasings).
Maliit, matalino, mabilis — at tumatakbo kahit saan
Kailangan naming patakbuhin ang filter sa mismong device, na isang hamon sa engineering.
Dapat itong maging maliit dahil ang aming app ay tumatakbo sa device sa maraming system: sa loob ng isang browser extension, isang macOS app, isang iOS app, isang Android app, o Windows at Linux. Ang bundle ay humigit-kumulang 113 MB bawat model. Mayroong dalawang model — isa para sa pangkalahatang personal na data, isa para sa protektadong impormasyong pangkalusugan — at ang Safe Harbor mode ay pinapatakbo ang pareho nang sabay. Sa mga ito, ang isang low-end na Android device ang may pinakamababang performance, gayunpaman ang aming system ay gumagana nang maayos.
Dapat itong maging matalino dahil ang mga false negative ay naglalabas ng tunay na data sa isang remote na LLM at ang mga false positive ay sumisira sa pag-uusap. Ang mga pangalan ay dapat i-redact; ang mga panghalip ay hindi dapat. Ang email ng doktor sa isang forwarded thread ay dapat i-redact; ang [email protected] na footer ay malamang na hindi.
Dapat itong maging mabilis dahil direkta itong nakaharang sa bawat mensaheng ipinapadala o natatanggap ng user. Sinukat namin ang round-trip overhead sa ilalim ng 200 ms sa isang CPU thread, karamihan ay tokenization. Sa WebGPU at sa Neural Engine ng Apple, ito ay napakaliit kumpara sa network latency ng mismong LLM call.
Dapat itong tumakbo sa maraming runtime dahil ang Caiioo ay multi-platform. Ang parehong system ay tumatakbo sa mga Chrome extension, macOS at iOS, Android, at sa Windows at Linux. Isang detection model, isang regex library, isang merger, isang policy — magkaparehong gawi sa bawat surface kung saan tumatakbo ang Caiioo.
Ang mga score
Matapos ang ilang round ng testing at training, napili namin ang ika-16 na bersyon ng aming mga model. Sa ibaba ay ang tatlong benchmark, kung saan ang bawat isa ay may sinusukat na magkakaibang aspeto.
Ang sarili naming test set, 150 tanong na hindi pa nakikita ng model
Bago sumalang sa mga pampublikong benchmark, pinatakbo muna namin ang aming Personal Data filter laban sa isang internal test set na sadyang hindi isinama sa training data — kaya hindi pa kailanman nakikita ng detector ang alinman sa mga tanong na ito. Ang 150 tanong ay hinati sa apat na grupo (code snippets, document prose, mga sadyang hindi pamilyar na phrasing, at 10 wikang hindi Ingles), kasama ang isang "negative" group na walang anumang private data (isang sanity check upang matiyak na hindi kami sumosobra sa pag-redact). Pinagsamang regex + ML pipeline:
| Sub-bench | Nahuli | Rate |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Lahat ng 4 na positive bench | 625 / 670 | 93.3 % |
(Ang negative group ay walang private data na dapat mahanap. Isang bagay ang na-mask ng filter na hindi dapat — na tumutugma sa mga precision number sa ibaba.)
Mahigpit ang grader: bawat inaasahang piraso ng private data ay dapat ganap na mawala sa masked output para makakuha ng score ang tanong. Walang partial credit, walang "malapit na." Mas mahigpit ito kaysa sa mga benchmark na gumagamit ng isa pang LLM bilang judge (ang mga LLM judge ay madalas na mapagbigay). Para sa mga numerong direktang maihahambing sa ibang mga system, tingnan ang head-to-head section sa ibaba.
PrivacyBenchHIPAA — 40 healthcare questions
Bawat tanong ay naglilista ng protected health impormasyon na dapat i-redact (mga pangalan, medical record numbers, atbp.) AT mga signal na dapat panatilihin (mga petsa, heograpiya, edad kung wala pang 90 — ang HIPAA Limited Data Set rule). Sinusuri ng grader ang dalawang direksyon: inalis ba namin ang dapat alisin, at hinayaan ba namin ang dapat panatilihin?
| Mode | PHI redacted | Retained kept |
|---|---|---|
| Limited Data Set (panatilihin ang dates / geography / age ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (i-redact lahat pati ang dates) | 99 / 104 (95.2 %) | — |
Perpekto ang Limited Data Set submode sa benchmark na ito. Ang Safe Harbor — na mas maraming dapat i-redact kaya mas maraming pagkakataong magkamali — ay nakakuha ng 95.2%.
Resulta bawat kategorya sa sarili naming data, 200 sample bawat mode
Pinagsasama-sama ng mga pampublikong benchmark ang lahat. Ang aming internal test data ay hinihiwalay ang mga resulta bawat kategorya (mga pangalan, email, address, at iba pa) at pinapatakbo ang bawat isa sa tatlong paraan: regex lamang, ML lamang, at parehong magkasama. Ipinapakita nito sa amin kung aling teknolohiya ang nakakahuli sa anong uri ng identifier — at kung saan kailangan ng isa ang tulong ng isa pa. Pinakabagong run, 2026-05-20:
Buod sa lahat ng tatlong filter mode
| Mode | Combined recall | Precision | 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 |
Hindi kasama sa mga numerong ito ang mga URL, na sadyang hindi namin ginagalaw — ang pag-redact sa isang URL ay makakasira sa mga downstream action tulad ng "buksan ang link na ito" o "kunin ang page na iyon." Higit pa tungkol dito sa workflow section sa ibaba.
Ang pangkalahatang larawan bago ang mga per-category table: sa bawat mode, ang mga identifier na talagang tumutukoy sa isang tao ay nahuhuli nang malapit sa 100% ng pagkakataon. Mga pangalan, email, numero ng telepono, postal address, government ID, biometric ID, tumpak na geolocation, medical record number, petsa ng kapanganakan, social security number — nahuli sa bawat sample, bawat test. Ang mga kategorya kung saan bumababa kami sa 100% ay predictable: device ID (napakaraming format sa totoong text), iba't ibang institutional ID (loyalty numbers, employee ID — parehong problema), at mga larawan (hindi nakikita ng isang text-only filter ang nasa loob ng isang imahe). Wala sa mga iyon ang "pangalan sa chart" o "email sa draft" na identifier na talagang mahalaga para sa leakage. Ang mga high-stakes na kategorya ang mga maaasahan.
Personal Data filter
Naka-sort ayon sa combined recall (pinakamahusay muna), pagkatapos ay ayon sa risk tier (T1 = pinakasensitibo).
| Category | Tier | Regex recall | ML recall (raw) | Combined 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 |
Sa pagsusuri, nagbubunga ang two-layer design. Ang mga postal address, birth date, at person name ay nakakuha ng 0–13% sa ilalim ng regex lamang — walang pattern na maitutugma, kaya ang ML model lamang ang makakahuli sa kanila. Ang mga email, numero ng telepono, IP, government ID, biometric ID, at tumpak na geolocation ay nakakuha ng 100% sa ilalim ng regex lamang — mga surface format na madaling makuha ng ML model. Ang mga online handle, vehicle ID, at authentication secret ay halo-halo: nahuhuli ng regex ang mga standard form, at ang ML ang bahala sa iba pa. Ang combined recall ay tumutugma o lumalampas sa kung alinmang layer ang mas malakas, sa bawat kategorya.
Ang mga device ID at iba't ibang institutional ID ang mga kategoryang mababa sa 100%, at alam namin kung bakit: ang mga ito ang may pinakamalawak na uri ng format sa totoong text. Mas gusto naming maging tapat tungkol sa mga kategorya kung saan bumababa ang recall kaysa magpanggap na perpekto ang filter sa lahat ng dako.
HIPAA filter — Limited Data Set submode
Ang Limited Data Set submode ay pinapanatili ang mga petsa, heograpiya, at edad na 89 pababa ayon sa disenyo — ito ang mga signal na pinapayagan ng HIPAA na panatilihin ng isang organisasyon para sa lehitimong clinical research at operasyon.
| Category | Tier | Regex recall | ML recall (raw) | Combined 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 |
Ang mga larawan ay isang kilalang pagkukulang — hindi nakikita ng isang text-only filter ang nasa loob ng isang imahe. Ang Image-PHI ay isang hiwalay na problema na hindi pa namin inilalabas. Ang bawat iba pang kategorya sa mode na ito ay nasa 100%.
HIPAA filter — Safe Harbor submode
Tinatanggal ng Safe Harbor ang lahat ng pinanatili sana ng Limited Data Set submode — mga petsa, edad na higit sa 89, heograpiya. Upang makuha ang pinakamahigpit na coverage, pinapatakbo nito ang parehong filter model nang sabay: ang HIPAA-specific at ang pangkalahatang personal-data filter.
| Category | Tier | Regex recall | ML recall (raw) | Combined 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 |
Ang dalawang kawili-wiling row ay ang general dates (regex 100%, ML 30%) at ages over 89 (regex 100%, ML 0%). Sadyang hinayaan naming regex ang humawak sa dalawang ito sa Safe Harbor: ang mga petsa ay may pattern na laging nahuhuli ng regex, at ayaw naming hulaan pa ng isang probabilistic model ang isang numeric threshold tulad ng ">89". Ang isang deterministic rule ay mas maaasahan kaysa sa pag-utos sa ML model na matutunan ang parehong rule.
Pangkalahatang numero sa lahat ng kategorya
Sa kabuuan: paano maihahambing ang buong pipeline (regex + ML nang magkasama) sa alinmang layer lamang?
| Mode | Layers | Recall | Precision | F2 |
|---|---|---|---|---|
| Personal Data | regex only | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | ML only | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | pareho (full) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | regex only | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | ML only | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | pareho (full) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | regex only | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | ML only | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | pareho (full) | 92.4 % | 88.9 % | 91.7 % |
Ang "full" row ng Personal Data filter ay tinalo ang parehong single-layer na bersyon sa bawat metric — ang pagsasama ng regex (para sa surface formats) sa ML model (para sa konteksto) ay tunay na nagbibigay ng isang bagay na hindi kayang gawin ng alinmang layer lamang. Ang 97.3% na headline kanina sa post na ito ay ang numerong sumasalamin sa nakukuha ng isang tunay na user. Ang numero sa table sa itaas ay medyo mas mababa lamang dahil kasama rito ang kategoryang URL, na sadyang pinapanatili namin upang hindi masira ang mga link at tool call.
Head-to-head laban sa iba pang dedikadong privacy filter
Ang patas na paghahambing para sa isang on-device, halos instant na privacy filter tulad ng sa amin ay laban sa iba pang on-device, halos instant na privacy filter — hindi laban sa mga higanteng cloud-hosted LLM na tumatagal ng ilang segundo bawat mensahe at nangangailangan ng network round-trip. Pinatakbo namin ang bawat system sa class na ito laban sa parehong test set, gamit ang parehong matching rules. Parehong standard para sa lahat.
Ang peer class:
- openai/privacy-filter — Ang open-source na dedikadong privacy filter ng OpenAI. May humigit-kumulang 50 milyong parameter, sapat na maliit para tumakbo sa anumang modernong browser.
- piiranha-v1 — Isang 278M-parameter detector mula sa iiiorg. Ang lisensya nito ay limitado lamang sa research at evaluation (maaari naming sukatin ito, ngunit hindi maaaring i-ship nang komersyal).
- Microsoft Presidio — Ang pinakamalawak na ginagamit na open-source redactor, na pinagsasama ang tradisyonal na pattern matching sa isang maliit na language model para sa konteksto.
- GLiNER PII family — Isang pamilya ng maliliit at general-purpose na entity classifier. Ang Knowledgator ay naglalabas ng small (~44M), base (~86M), at large (~304M) na mga variant; naglabas ang NVIDIA ng 570M variant noong Oktubre 2025.
- Caiioo sa lahat ng tatlong mode (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall sa lahat ng limang test set, naka-sort na una ang Caiioo:
| System | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual 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) |
Nangunguna ang Caiioo sa dedicated-filter class sa dalawang pinakamalaking test (PD-200 at PHI-200), tabla o nangunguna sa mga pampublikong benchmark, at pangalawa sa multilingual. Sa pinakamaliit na test (PrivacyBench PD-25, 25 tanong lamang) nagtabla ang Caiioo at openai/privacy-filter sa 96.2%. Sa multilingual, nangunguna pa rin ang openai/privacy-filter sa 94.9% habang ang Caiioo ay nasa 92.6% — ang wika kung saan kami pinaka-nahuhuli ay Chinese; sa lahat ng iba pa ay nasa itaas kami o malapit dito. Kung ang multilingual coverage ay mission-critical, ang openai/privacy-filter ay isang makatwirang alternatibo. Para sa karamihan ng iba pang workload sa class na ito, Caiioo ang mainam.
Ang resulta sa HIPAA ang headline. Ang parehong Caiioo HIPAA mode ay nakakuha ng 100% recall sa bawat HIPAA test — bawat pangalan ng pasyente, bawat medical record number, bawat petsa ng kapanganakan, bawat account number ay nahuli. Ang pangalawang pinakamahusay na system ay ang openai/privacy-filter sa 93.7% sa PrivacyBenchHIPAA — isang 6.3-point na agwat, sa isang benchmark kung saan ang bawat pagkukulang ay isang real-world disclosure.
Isang pangalawang numero na dapat basahin: over-redaction — ang pag-mask sa mga bagay na hindi naman talaga private data. Ang over-redaction ay hindi panganib sa privacy, kundi isang usability cost. Kapag masyadong maraming bagay ang na-mask, sumasama ang reasoning ng LLM, at bumababa ang kalidad ng sagot. Ang Caiioo ay nag-mask nang hindi kinakailangan nang 1–24 beses sa mga test set. Presidio: 10–51. Ang GLiNER ng NVIDIA: 31–64 sa mga HIPAA test pa lamang. Mahalaga ang precision gaya ng recall kapag ang layunin ay ang pinakamahusay na posibleng sagot na may pinakamaliit na exposure.
Paano kung gumamit na lang ng isang frontier LLM bilang filter?
Kaya nila — at sa raw recall, sila ang nananalo. Ang malalaking general-purpose LLM (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B, at katulad nito), na tumatakbo sa cloud o locally, ay maaaring makakuha ng 95–100% sa bawat test kabilang ang multilingual. Isa itong tunay na opsyon para sa mga user na nangangailangan ng maximum recall at handang magbayad para dito.
Gayunpaman, may mga tunay na disbentaha:
- Mabagal ito. Segundo bawat mensahe sa halip na millisecond. Ang filter ay nasa harap ng bawat mensaheng ipinapadala ng user.
- Alinman sa mensahe ang aalis sa machine ng user, o ang model mismo. Para mag-filter sa cloud, kailangang umakyat doon ang mensahe — na sumisira sa layunin. Para mag-filter on-device, kailangang mag-download ng 1–17 GB na model.
- Maaari itong malinlang. Ang isang generative model ay maaaring mapaniwala, sa gitna ng mensahe, na huwag mag-redact (isang "prompt injection" attack). Ang isang maliit na classifier tulad ng sa amin ay hindi magagawa iyon.
- Parehong input, magkaibang output. Ang mga generative model ay hindi laging nagbibigay ng parehong sagot nang dalawang beses. Sinisira nito ang round-trip — ang pag-mask sa paglabas at pag-unmask sa pagbalik ay umaasa sa parehong real value na laging naka-map sa parehong fake.
Ang Caiioo ay binuo para sa kabilang panig ng tradeoff na iyon: isang napakaliit, predictable, sub-second filter na tumatakbo sa composer bago pindutin ng user ang send, at laging gumagawa ng parehong fake para sa parehong real value sa loob ng isang pag-uusap, upang manatiling maayos ang round-trip. Ang peer-class table sa itaas ay ang apples-to-apples na paghahambing para sa ganoong uri ng use case.
Ang patunay ay nasa resulta
Ang mga benchmark ay panimulang punto lamang, hindi ang dulo. Ang filter ay nakakabit sa bagong feature ng Caiioo: ang pseudonymizer — ang bahagi na aktwal na namamagitan sa composer at sa model.
Narito ang nangyayari kapag pinindot ng user ang send.
- Detect. Ang regex layer ang unang tatakbo — ito ay deterministic at mabilis sa loob ng microsecond. Ang ML model naman ang susunod na tatakbo sa anumang matitira. Kung mag-overlap ang dalawang layer sa parehong bahagi ng teksto, gumagamit kami ng simpleng panuntunan: regex ang mananaig sa mga surface format, ML naman sa konteksto.
- Tag self vs. other. Inihihiwalay ng Caiioo ang mga identifier na tumutukoy sa user mula sa mga identifier na tumutukoy sa ibang tao. Maaaring piliin ng user na i-redact ang isa lang, o pareho. Ang mga pangalang idinagdag ng user sa isang personal dictionary ay laging itinuturing na "self."
- Substitute. Ang bawat totoong value ay nakakakuha ng isang stable at style-matched na pseudonym. Ang "Sarah Goldberg" ay magiging "Maya Hartwell" — at mananatiling "Maya Hartwell" sa buong pag-uusap, upang ang pangangatwiran ng model tungkol sa taong iyon ay hindi magkawatak-watak sa bawat turn. Isang real-to-fake lookup table ang itinatago sa device ng user, na naka-encrypt gamit ang isang key mula sa keychain ng platform.
- Send. Ang model ay makakatanggap ng isang ganap na pekeng mensahe. Walang totoong identifier ang dadaan sa network, at ang aming audit log ay nagtatala lamang ng mga bilang — hinding-hindi ang mga mismong value.
- Restore. Ang streaming response ay ibinabalik sa dati habang dumarating ito. Ang "Maya Hartwell" sa tugon ng model ay magiging "Sarah Goldberg" bago ito makarating sa screen, na ipinapakita na may maliit na glow pill para makita ng user sa isang sulyap kung ano ang pinrotektahan.
- Ibalik din ang mga tool argument. Kung ang model ay tatawag ng isang tool — magpadala ng email, mag-file ng ticket, magsulat sa isang doc — at ang mga argument ay naglalaman ng mga peke, ibinabalik namin ang mga totoong value bago tumakbo ang tool. Ang model ay nangangatwiran sa mga peke; ang aksyon ay gumagamit ng totoong value.
Walang pakialam ang filter kung anong AI service ang ginagamit. Tumatakbo ito bago pa man makarating ang mensahe sa model, kaya ang OpenRouter, Anthropic, Google, OpenAI, at ang lokal na Ollama ay pawang makakatanggap ng parehong masked payload. Ang pagdaragdag ng bagong provider ay hindi muling magbubukas ng butas sa privacy.
Sino ang pinoprotektahan nito
Ang user. Ang pangalan, email, address, telepono, IP, at mga biometric identifier ng isang user — ang mga bagay na, kapag pinagsama-sama, ay tumutukoy sa isang tao sa isang aggregator — ay hindi kailanman umaalis sa device kapag naka-on ang filter.
Ang mga taong pinag-uusapan ng user. Karamihan sa mga tool sa privacy ay nakatuon sa taong nagta-type, ngunit ang binabalewala nila ay ang 'social contract' — ang katotohanan na lahat tayo ay may responsibilidad sa iba gayundin sa ating sarili. Ang pagsusumite ng "Pakisuri ang gawi ni Mr. Saunders para sa kawalan ng kakayahan" sa isang LLM, kung saan maaari itong maitala sa mga system log nang walang katiyakan, ay hindi responsable (at potensyal na mapanirang-puri). Ang paghingi ng tulong sa isang LLM para sa isang Google Sheet na naglalaman ng 1,000 business contact ay nagdedeposito sa kanilang lahat sa data-retention flypaper (sa iba't ibang antas, depende sa aktwal na 'zero data retention' na ipinapatupad). Saklaw din ng filter ng Caiioo ang mga third party: ang kliyente na ginagawan ng kontrata, ang pasyente na sinusuri ang record, ang kasamahan na ang email ay na-paste sa konteksto. Hindi sila pumayag na makita ng isang remote na LLM ang kanilang mga identifier. Iginagalang iyon ng filter sa pamamagitan ng default; maaaring lumipat ang user sa "sarili lang" o "iba lang" kung kinakailangan ng workflow.
Mga entity — mga negosyo, ospital, kumpanya. Mga account number, license number, medical record number, mga detalye ng financial routing, mga internal ID, API key, mga listahan ng customer. Ang isang negosyo ay may parehong interes sa data-minimization gaya ng isang tao. Ang isang clinician na gumagamit ng Caiioo upang gumawa ng discharge note ay hindi nagpapadala ng medical record number ng pasyente sa OpenAI. Ang isang abogado ay hindi nagpapadala ng account number ng kliyente sa Anthropic. Ang isang support engineer ay hindi nagpapadala ng API key mula sa log ng customer sa Google. Hindi tinatanong ng filter kung ang identifier ay pagmamay-ari ng isang tao o isang entity — pinapanatili lang nito ito sa device.
Pinakamataas na utility, pinakamababang exposure
Ang buong punto ay hindi dapat maramdaman ng user ang filter.
Karamihan sa mga tool sa privacy ay pinipilit ang isang pagpipilian: mag-redact nang agresibo at panoorin ang sagot ng model na lumala, o panatilihing magagamit ang prompt at panoorin ang pangako sa privacy na gumuho. Tinanggihan namin ang tradeoff na iyon. Ang model ay nakakakuha pa rin ng isang ganap na nabuong prompt — nakakakita ito ng pangalan, lugar, petsa, medical record number, lahat sa tamang gramatikal na posisyon. Nakakakita lang ito ng mga peke. Ang pangangatwiran nito ay magkapareho; ang mga string lang ang nilinis.
Ang stable substitution ang nagpapagana doon. Dahil ang parehong tunay na halaga ay palaging nakamapa sa parehong peke sa loob ng isang pag-uusap — sa buong mensahe ng user, ang resulta ng tool na bumabalik na tumutukoy sa pangalang iyon, ang naunang tugon ng model na nagbanggit nito — ang model ay may magkakaugnay na tao, lugar, o bagay na pag-iisipan. Ang mga multi-turn na pag-uusap ay hindi nagkakagulo. Ang mga tool call ay hindi nasisira. Ang mga sub-agent ay nagmamana ng mapa ng parent conversation at nananatiling pare-pareho sa buong gawain.
Ang output na nakikita ng user ay ang tunay na pag-uusap. Ang data na nakikita ng provider ay isang magkakaugnay na kathang-isip. Ang trabaho ay nangyayari sa pagitan ng dalawang pananaw na iyon, at ang layunin — ang tanging layunin — ay gawing hindi nakikita ang puwang na iyon.
Ang isang privacy filter na nakakaabala ay papatayin. Ang isang privacy filter na naglalaho sa workflow ang tanging uri na karapat-dapat ilabas.
Iyan ang pamantayang binuo namin.