Questa è una traduzione automatica del documento originale in inglese. In caso di discrepanze tra la presente traduzione e la versione originale in inglese, prevarrà la versione inglese. Leggi la versione originale in inglese
Pseudonimizzatore on-device: creato e testato
2026-05-22 · Caiioo Team
Volevamo risolvere il problema della privacy dei sistemi AI che si addestrano e conservano informazioni reali di identificazione personale. Le politiche e gli accordi di "Zero Data Retention" riducono il rischio, ma sono pieni di eccezioni. In sostanza dicono: "Non memorizzeremo nessuno dei tuoi prompt o output eccetto per: (inserire qui una lunga lista di eccezioni: scopi di sicurezza, sorveglianza governativa, conservazione per controversie legali, sviluppo del prodotto, log di errore, miglioramento dei servizi...)"
Per risolvere questo problema, abbiamo costruito un filtro per i dati personali che gira sulla macchina dell'utente, vede il messaggio prima che lasci il dispositivo e restituisce la stessa risposta che l'utente avrebbe ricevuto se avesse digitato senza alcun filtro.
Quindi ne abbiamo creato uno. La prossima versione di Caiioo includerà lo Pseudonimizzatore. Accessibile tramite l'icona dello scudo nella chat dell'agente e nelle impostazioni.
Questo white paper delinea la logica, l'architettura, il processo di valutazione e i principi di progettazione alla base del nostro sistema di filtraggio della privacy.
Cosa ci siamo prefissati di fare
Protezione generale della privacy tramite la minimizzazione dei dati. Quando un utente chatta con un modello remoto, il modello non ha bisogno di un nome reale, di un indirizzo di casa, di un'email reale o del numero di telefono di un cliente per rispondere alla domanda dell'utente. Ha bisogno della forma della domanda, e deve apparire come una domanda reale affinché l'LLM non scarti il quesito considerandolo un test. Il filtro rimuove quindi gli identificatori reali dai dati inviati all'AI e ricompone i valori reali nel percorso di ritorno. Il modello vede nomi e identificatori sintetici; l'utente vede la conversazione reale.
Assistenza per la conformità HIPAA. Una seconda modalità si rivolge ai 18 identificatori previsti dalla norma HIPAA Safe Harbor (§164.514) e alla variante più flessibile Limited Data Set. Un clinico, un amministratore sanitario o chiunque lavori su un flusso di lavoro coperto può parlare con un modello generico di casi reali senza inviare informazioni sanitarie protette all'AI. Non siamo il responsabile della conformità dell'ente interessato — ma possiamo essere il livello che impedisce alla PHI di lasciare il laptop in primo luogo. Le nostre valutazioni forniscono benchmark misurabili che le organizzazioni possono utilizzare per valutare l'idoneità del filtro rispetto ai propri standard di conformità e privacy. Tutte le misure di privacy e sicurezza sono decisioni discrezionali che ricadono sotto la responsabilità dell'utente o dell'ente utente.
Abbiamo scelto entrambi perché l'ingegneria è la stessa, e il caso d'uso PHI è tecnicamente più semplice grazie all'uso di entità nominate distinte, che sono più facili da oscurare rispetto ai dati più generici della categoria Dati Personali. Il filtraggio HIPAA è inoltre agevolato dal fatto che è generalmente in inglese o spagnolo. Rileviamo gli identificatori, sostituiamo pseudonimi stabili e identificatori sostitutivi nello stesso formato, li ripristiniamo al ritorno e non registriamo mai i valori reali. La mappa tra le informazioni sintetiche e le informazioni reali rimane solo sul dispositivo dell'utente, in modo che l'utente possa leggere le informazioni reali nelle risposte dell'agente. L'elenco delle categorie e il gate della policy sono ciò che cambia tra le modalità.
Perché regex più machine learning, e non solo uno dei due
Esistono due tecnologie di filtraggio principali nel nostro pseudonimizzatore: un linguaggio di riconoscimento di pattern deterministico chiamato regex e modelli di machine learning addestrati.
Il regex è imbattibile sui formati superficiali. Un indirizzo email ha una forma ([email protected]). Lo stesso vale per un IP, una carta di credito, un IBAN, un VIN, un SSN (XXX-XX-XXXX), una API key. Se il formato è affidabile, il regex lo intercetta in modo deterministico, ogni volta, senza carico del modello e senza costi di inferenza.
Il regex è, tuttavia, inutile sul contesto. "La cartella di Sarah di martedì scorso" contiene una persona e una data, ma nessuna delle due può essere distinta solo dal suo formato. "Il paziente al 14 di Elm" contiene un indirizzo che si sovrappone a mille non-indirizzi. "Il loro MRN è 7741032" ha bisogno delle parole intorno al numero per significare qualcosa.
Un piccolo modello linguistico ottimizzato (fine-tuned) gestisce il contesto — il nostro è un encoder da 110 milioni di parametri appositamente addestrato e distillato da un tiny language model multilingue —. Legge la frase, non la sottostringa, ed è abbastanza piccolo da girare velocemente su un dispositivo, persino su un telefono cellulare.
I benchmark illustrano i punti di forza complementari dei due livelli. Abbiamo testato i due livelli isolatamente per assicurarci che ognuno faccia effettivamente la sua parte. Sul set di 150 domande PrivacyBench-PD, dove le domande e le risposte NON sono state esplicitamente utilizzate per addestrare il modello:
| Livello | PII intercettate | Tasso di cattura |
|---|---|---|
| Solo Regex | 205 / 670 | 30.6 % |
| Solo ML | 516 / 670 | 77.0 % |
| Entrambi (produzione) | 625 / 670 | 93.3 % |
Il solo regex manca i tre quarti degli identificatori perché la maggior parte degli identificatori nella prosa reale non è strutturata. Il solo ML manca 16 punti percentuali che il livello regex avrebbe intercettato — le cose che sono puramente la loro forma (una carta di credito sembra una carta di credito; il modello non ha segnali extra da aggiungere). Insieme coprono ciò che nessuno dei due copre da solo.
Analizzando più a fondo dove ogni livello è decisivo: in quello stesso set, 16 valori di test sono stati intercettati solo dal regex (email, IP, conti finanziari, ID strutturati) e 327 sono stati intercettati solo dal ML (nomi, identificatori contestuali, frasi multilingue).
Piccolo, intelligente, veloce — e gira ovunque
Abbiamo dovuto far girare il filtro on-device, il che è stata una sfida ingegneristica.
Deve essere piccolo perché la nostra app gira localmente su molti sistemi: all'interno di un'estensione del browser, un'app macOS, un'app iOS, un'app Android, o su Windows e Linux. Il pacchetto è di circa 113 MB per modello. Ci sono due modelli — uno per i dati personali generali, uno per le informazioni sanitarie protette — e la modalità Safe Harbor li esegue entrambi in parallelo. Tra questi, un dispositivo Android di fascia bassa è il meno performante, eppure il nostro sistema funziona bene.
Deve essere intelligente perché i falsi negativi espongono dati reali a un LLM remoto e i falsi positivi rovinano la conversazione. I nomi devono essere oscurati; i pronomi no. L'email del medico in una discussione inoltrata dovrebbe essere oscurata; il piè di pagina [email protected] probabilmente no.
Deve essere veloce perché si trova direttamente nel percorso di ogni messaggio che l'utente invia o riceve. Abbiamo misurato il sovraccarico del ciclo completo a meno di 200 ms su un singolo thread della CPU, principalmente per la tokenizzazione. Su WebGPU e sul Neural Engine di Apple è minuscolo rispetto alla latenza di rete della chiamata LLM stessa.
Deve girare in più runtime perché Caiioo è multipiattaforma. Lo stesso sistema gira nelle estensioni Chrome, su macOS e iOS, Android, e su Windows e Linux. Un unico modello di rilevamento, un'unica libreria regex, un unico modulo di fusione, un'unica policy — comportamento identico su ogni superficie dove gira Caiioo.
I punteggi
Dopo cicli di test e addestramento, abbiamo stabilito la sedicesima versione dei nostri modelli. Di seguito sono riportati tre benchmark, ognuno dei quali misura un aspetto diverso.
Il nostro set di test, 150 domande che il modello non ha mai visto
Prima di effettuare i test rispetto ai benchmark pubblici, abbiamo eseguito il nostro filtro Personal Data su un set di test interno che abbiamo deliberatamente tenuto fuori dai dati di addestramento — in modo che il rilevatore non avesse mai visto nessuna di queste domande prima d'ora. 150 domande suddivise in quattro gruppi (snippet di codice, prosa di documenti, frasi intenzionalmente insolite e 10 lingue non inglesi), oltre a un gruppo "negativo" che non contiene affatto dati privati (un controllo di integrità per assicurarci di non eccedere nella redazione). Pipeline combinata regex + ML:
| Sub-bench | Catturati | Tasso |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Tutti i 4 bench positivi | 625 / 670 | 93.3 % |
(Il gruppo negativo non aveva dati privati da trovare. Il filtro ha mascherato un elemento che non avrebbe dovuto — coerentemente con i numeri di precisione riportati più in basso.)
Il sistema di valutazione è rigoroso: ogni frammento di dati privati atteso deve scomparire completamente dall'output mascherato affinché la domanda riceva un punteggio. Nessun credito parziale, nessun "abbastanza vicino". Questo è più severo dei benchmark che chiedono a un altro LLM di fare da giudice (i giudici LLM tendono a essere generosi). Per numeri direttamente comparabili con altri sistemi, vedere la sezione del confronto diretto più in basso.
PrivacyBenchHIPAA — 40 domande sanitarie
Ogni domanda elenca informazioni sanitarie protette che devono essere redatte (nomi, numeri di cartella clinica, ecc.) E segnali che devono essere mantenuti (date, area geografica, età se inferiore a 90 anni — la regola HIPAA Limited Data Set). Il valutatore controlla entrambe le direzioni: abbiamo rimosso ciò che avremmo dovuto rimuovere e abbiamo lasciato invariato ciò che avremmo dovuto lasciare invariato?
| Modalità | PHI redatti | Mantenuti conservati |
|---|---|---|
| Limited Data Set (preserva date / geo / età ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (redige tutto, comprese le date) | 99 / 104 (95.2 %) | — |
La sottomodalità Limited Data Set è perfetta su questo benchmark. Safe Harbor — che ha più elementi da redigere, quindi più opportunità di errore — copre il 95.2%.
Risultati categoria per categoria sui nostri dati, 200 campioni per modalità
I benchmark pubblici raggruppano tutto insieme. I nostri dati di test interni suddividono i risultati per categoria (nomi, email, indirizzi e così via) ed eseguono ognuna in tre modi: solo regex, solo ML e entrambi insieme. Questo ci dice esattamente quale tecnologia sta catturando quale tipo di identificatore — e dove l'una ha bisogno dell'altra. Ultima esecuzione, 2026-05-20:
Riepilogo tra tutte e tre le modalità di filtro
| Modalità | Recall combinato | Precisione | F2 | Campioni |
|---|---|---|---|---|
| Filtro Personal Data | 97.3 % | 97.8 % | 97.4 | 200 |
| Filtro HIPAA — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| Filtro HIPAA — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Questi numeri escludono gli URL, che lasciamo deliberatamente invariati — colpire un URL interromperebbe le azioni a valle come "apri questo link" o "recupera quella pagina". Maggiori informazioni a riguardo nella sezione sul workflow più avanti.
Il quadro generale prima delle tabelle per categoria: in ogni modalità, gli identificatori che identificano effettivamente una persona vengono catturati al 100% o quasi. Nomi, email, numeri di telefono, indirizzi postali, ID governativi, ID biometrici, geolocalizzazione precisa, numeri di cartella clinica, date di nascita, numeri di previdenza sociale — catturati in ogni campione, in ogni test. Le categorie in cui scendiamo sotto il 100% sono prevedibili: ID dei dispositivi (vasta gamma di formati nel testo reale), ID istituzionali vari (numeri fedeltà, ID dipendente — stesso problema) e foto (un filtro solo testuale non può vedere cosa c'è dentro un'immagine). Nessuno di questi è l'identificatore "nome su una cartella" o "email in una bozza" che conta davvero per la fuga di dati. Le categorie ad alto rischio sono quelle affidabili.
Filtro Personal Data
Ordinato per recall combinato (migliore per primo), quindi per livello di rischio (T1 = più sensibile).
| Categoria | Tier | Recall Regex | Recall ML (grezzo) | Recall combinato | 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 |
Leggendo i dati, il design a due livelli sta dando i suoi frutti. Indirizzi postali, date di nascita e nomi di persone ottengono un punteggio dello 0–13% solo con regex — non c'è un pattern da far corrispondere, quindi solo il modello ML può catturarli. Email, numeri di telefono, IP, ID governativi, ID biometrici e geolocalizzazione precisa ottengono il 100% solo con regex — formati superficiali che il modello ML ottiene gratuitamente. Handle online, ID veicoli e segreti di autenticazione sono misti: regex cattura le forme standard, ML cattura il resto. Il recall combinato soddisfa o supera quello del singolo livello più forte, in ogni categoria.
Gli ID dei dispositivi e gli ID istituzionali vari sono le categorie al di sotto del 100%, e sappiamo perché: hanno la più ampia varietà di formati nel testo reale. Preferiamo essere onesti sulle categorie in cui il recall cala piuttosto che fingere che il filtro sia perfetto ovunque.
Filtro HIPAA — sottomodalità Limited Data Set
La sottomodalità Limited Data Set preserva date, area geografica ed età pari o inferiori a 89 anni per progettazione — questi sono i segnali che HIPAA consente a un'organizzazione di conservare per scopi legittimi di ricerca clinica e operazioni.
| Categoria | Tier | Recall Regex | Recall ML (grezzo) | Recall combinato | 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 |
Le foto sono una mancanza nota — un filtro solo testuale non può vedere cosa c'è dentro un'immagine. Le PHI nelle immagini sono un problema separato che non abbiamo ancora rilasciato. Ogni altra categoria in questa modalità è al 100%.
Filtro HIPAA — sottomodalità Safe Harbor
Safe Harbor rimuove tutto ciò che la sottomodalità Limited Data Set avrebbe mantenuto — date, età superiori a 89 anni, area geografica. Per ottenere la copertura più rigorosa, esegue entrambi i modelli di filtro in parallelo: quello specifico per HIPAA e quello generale per i dati personali.
| Categoria | Tier | Recall Regex | Recall ML (grezzo) | Recall combinato | 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 |
Le due righe interessanti sono le date generali (regex 100%, ML 30%) e le età superiori a 89 anni (regex 100%, ML 0%). Abbiamo deliberatamente lasciato che regex gestisse entrambi in Safe Harbor: le date hanno una forma che regex cattura ogni volta, e non vogliamo che un modello probabilistico metta in discussione una soglia numerica come ">89". Una regola deterministica è più affidabile che chiedere al modello ML di imparare la stessa regola.
Numeri complessivi per tutte le categorie
Sommando tutto: come si comporta la pipeline completa (regex + ML insieme) rispetto a ciascun livello da solo?
| Modalità | Livelli | Recall | Precisione | F2 |
|---|---|---|---|---|
| Personal Data | solo regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | solo ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | entrambi | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | solo regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | solo ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | entrambi | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | solo regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | solo ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | entrambi | 92.4 % | 88.9 % | 91.7 % |
La riga "entrambi" del filtro Personal Data batte entrambe le versioni a livello singolo su ogni metrica — combinare regex (per i formati superficiali) con il modello ML (per il contesto) fornisce davvero qualcosa che nessuno dei due livelli da solo può offrire. Il dato del 97.3% citato all'inizio di questo post è il numero che riflette ciò che ottiene un utente reale. Il numero nella tabella sopra è leggermente inferiore solo perché include la categoria URL, che preserviamo deliberatamente per non interrompere link e chiamate a strumenti.
Confronto diretto con altri filtri per la privacy dedicati
Il confronto equo per un filtro per la privacy on-device e quasi istantaneo come il nostro è con altri filtri per la privacy on-device e quasi istantanei — non con giganti LLM ospitati nel cloud che impiegano secondi per messaggio e richiedono un viaggio di andata e ritorno sulla rete. Abbiamo eseguito ogni sistema di questa classe sugli stessi set di test, utilizzando le stesse regole di corrispondenza. Stesso standard per tutti.
La classe dei pari:
- openai/privacy-filter — il filtro per la privacy dedicato open-source di OpenAI. Circa 50 milioni di parametri, abbastanza piccolo da essere eseguito in qualsiasi browser moderno.
- piiranha-v1 — un rilevatore da 278 milioni di parametri di iiiorg. La sua licenza lo limita solo alla ricerca e alla valutazione (possiamo misurarlo, ma non può essere distribuito commercialmente).
- Microsoft Presidio — il redattore open-source più diffuso, che combina il pattern matching tradizionale con un piccolo modello linguistico per il contesto.
- famiglia GLiNER PII — una famiglia di piccoli classificatori di entità per scopi generali. Knowledgator distribuisce varianti small (~44M), base (~86M) e large (~304M); NVIDIA ha rilasciato una variante da 570M nell'ottobre 2025.
- Caiioo in tutte e tre le modalità (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall in tutti e cinque i set di test, ordinati con Caiioo per primo:
| Sistema | PrivacyBench PD-25 | Caiioo sintetico PD-200 | PrivacyBenchHIPAA-40 | Caiioo sintetico PHI-200 | Multilingual PD-40 (10 locali) |
|---|---|---|---|---|---|
| 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 guida la classe dei filtri dedicati nei due test più grandi (PD-200 e PHI-200), pareggia o guida nei benchmark pubblici ed è secondo nel multilingua. Nel test più piccolo (PrivacyBench PD-25, solo 25 domande) Caiioo e openai/privacy-filter pareggiano al 96.2%. Nel multilingua, openai/privacy-filter guida ancora con il 94.9% con Caiioo al 92.6% — la lingua in cui restiamo più indietro è il cinese; ovunque altrove siamo in cima o vicini alla vetta. Se la copertura multilingua è fondamentale per la missione, openai/privacy-filter è una ragionevole alternativa. Per la maggior parte degli altri carichi di lavoro in questa classe, lo è Caiioo.
Il risultato HIPAA è il titolo principale. Entrambe le modalità HIPAA di Caiioo hanno raggiunto il 100% di recall in ogni test HIPAA — ogni nome di paziente, ogni numero di cartella clinica, ogni data di nascita, ogni numero di conto viene catturato. Il secondo miglior sistema è openai/privacy-filter con il 93.7% su PrivacyBenchHIPAA — un divario di 6.3 punti, in un benchmark dove ogni mancanza è una divulgazione nel mondo reale.
Un secondo numero che vale la pena leggere: sovra-redazione — mascherare cose che non erano effettivamente dati privati. La sovra-redazione non è un danno alla privacy, è un costo di usabilità. Mascherando troppe cose, il ragionamento dell'LLM peggiora e la risposta restituita è degradata. Caiioo maschera inutilmente 1–24 volte nei set di test. Presidio: 10–51. GLiNER di NVIDIA: 31–64 solo nei test HIPAA. La precisione conta quanto il recall quando l'obiettivo è la migliore risposta possibile con la minima esposizione possibile.
E se usassi semplicemente un LLM di frontiera come filtro?
Possono farlo — e sul recall grezzo, vincono. I grandi LLM per scopi generali (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B e simili), eseguiti nel cloud o localmente, possono ottenere punteggi del 95–100% in ogni test, incluso il multilingua. Questa è un'opzione reale per gli utenti che necessitano del massimo recall e sono disposti a pagarne il prezzo.
Gli svantaggi sono però reali:
- È lento. Secondi per messaggio invece di millisecondi. Il filtro si trova davanti a ogni messaggio inviato dall'utente.
- O il messaggio lascia la macchina dell'utente, o lo fa il modello. Per filtrare nel cloud, il messaggio deve andare lassù — vanificando lo scopo. Per filtrare on-device è necessario scaricare un modello da 1–17 GB.
- Può essere ingannato. Un modello generativo può essere convinto, a metà messaggio, a non redigere (un attacco di "prompt injection"). Un piccolo classificatore come il nostro non può esserlo.
- Stesso input, output diverso. I modelli generativi non danno sempre la stessa risposta due volte. Questo rompe il viaggio di andata e ritorno — mascherare in uscita e smascherare al ritorno si basa sul fatto che lo stesso valore reale mappi sempre sullo stesso falso.
Caiioo è costruito per l'altro lato di questo compromesso: un filtro minuscolo, prevedibile, inferiore al secondo che viene eseguito nel composer prima che l'utente prema invio, e che produce sempre lo stesso falso per lo stesso valore reale all'interno di una conversazione, in modo che il viaggio di andata e ritorno rimanga coerente. La tabella della classe dei pari sopra è il confronto alla pari per questo tipo di caso d'uso.
La prova del nove
I benchmark sono un punto di partenza, non il traguardo. Il filtro è integrato nella nuova funzionalità di Caiioo: lo pseudonimizzatore — il componente che si interpone effettivamente tra il compositore e il modello.
Ecco cosa succede quando l'utente preme invio.
- Rilevamento. Il livello regex viene eseguito per primo — è deterministico e veloce nell'ordine dei microsecondi. Il modello ML viene eseguito successivamente su ciò che rimane. Se i due livelli si sovrappongono sullo stesso frammento di testo, utilizziamo una regola semplice: la regex vince sui formati superficiali, il ML vince sul contesto.
- Tagging sé vs. altri. Caiioo separa gli identificatori che si riferiscono all'utente dagli identificatori che si riferiscono ad altre persone. L'utente può scegliere di oscurare solo uno dei due, o entrambi. I nomi che l'utente ha aggiunto a un dizionario personale contano sempre come "sé".
- Sostituzione. Ogni valore reale riceve uno pseudonimo stabile e coerente con lo stile. "Sarah Goldberg" diventa "Maya Hartwell" — e rimane "Maya Hartwell" per l'intera conversazione, in modo che il ragionamento del modello su quella persona non si frammenti tra i vari passaggi. Una tabella di ricerca da reale a finto viene conservata sul dispositivo dell'utente, crittografata con una chiave proveniente dal portachiavi della piattaforma.
- Invio. Il modello riceve un messaggio completamente fittizio. Nessun identificatore reale attraversa mai la rete e il nostro registro di audit registra solo i conteggi — mai i valori stessi.
- Ripristino. La risposta in streaming viene rimappata man mano che arriva. "Maya Hartwell" nella risposta del modello diventa "Sarah Goldberg" prima di raggiungere lo schermo, visualizzata con un piccolo indicatore luminoso in modo che l'utente possa vedere a colpo d'occhio cosa è stato protetto.
- Ripristino anche degli argomenti degli strumenti. Se il modello richiama un tool — inviare un'email, aprire un ticket, scrivere su un documento — e gli argomenti contengono dati fittizi, sostituiamo i valori reali prima che il tool venga eseguito. Il modello ragiona sui dati fittizi; l'azione riceve il valore reale.
Al filtro non importa quale servizio AI sia in uso. Viene eseguito prima che il messaggio raggiunga il modello, quindi OpenRouter, Anthropic, Google, OpenAI e un Ollama locale ricevono tutti lo stesso payload mascherato. L'aggiunta di un nuovo provider non riapre la falla nella privacy.
Chi protegge
L'utente. Il nome dell'utente, l'email, l'indirizzo, il telefono, l'IP e gli identificatori biometrici — le cose che, prese insieme, identificano una persona per un aggregatore — non lasciano mai il dispositivo quando il filtro è attivo.
Le persone di cui parla l'utente. La maggior parte degli strumenti per la privacy si concentra sulla persona che scrive, ma ciò che ignorano è il "contratto sociale" — il fatto che abbiamo tutti una responsabilità verso gli altri oltre che verso noi stessi. Inviare "Per favore analizza la condotta del Sig. Saunders per incompetenza" a un LLM, dove potrebbe essere registrato nei log di sistema a tempo indeterminato, è irresponsabile (e potenzialmente diffamatorio). Chiedere aiuto a un LLM per un Google Sheet che contiene 1.000 contatti commerciali deposita tutti quei dati nella rete della conservazione dati (in misura variabile, a seconda della reale "zero data retention" in vigore). Il filtro di Caiioo copre anche terze parti: il cliente per cui si sta redigendo un contratto, il paziente il cui record viene analizzato, il collega la cui email è stata incollata nel contesto. Non hanno acconsentito a che un LLM remoto vedesse i loro identificatori. Il filtro rispetta questo per impostazione predefinita; l'utente può passare a "solo me stesso" o "solo altri" se un flusso di lavoro lo richiede.
Entità — aziende, ospedali, studi legali. Numeri di conto, numeri di licenza, numeri di cartella clinica, dettagli di routing finanziario, ID interni, chiavi API, elenchi clienti. Un'azienda ha lo stesso interesse alla minimizzazione dei dati di una persona. Un medico che usa Caiioo per redigere una nota di dimissione non sta inviando il numero di cartella clinica del paziente a OpenAI. Un avvocato non sta inviando il numero di conto del cliente ad Anthropic. Un ingegnere del supporto non sta inviando la chiave API dal log del cliente a Google. Il filtro non si chiede se l'identificatore appartenga a una persona o a un'entità — lo mantiene semplicemente sul dispositivo.
Massima utilità, minima esposizione
Il punto cruciale è che l'utente non dovrebbe percepire il filtro.
La maggior parte degli strumenti per la privacy costringe a una scelta: oscurare in modo aggressivo e vedere peggiorare la risposta del modello, oppure mantenere il prompt utilizzabile e vedere erodersi la promessa di privacy. Abbiamo rifiutato questo compromesso. Il modello riceve comunque un prompt completo — vede un nome, un luogo, una data, un numero di cartella clinica, tutti nelle posizioni grammaticali corrette. Vede solo dati finti. Il suo ragionamento è identico; solo le stringhe sono ripulite.
La sostituzione stabile è ciò che permette questo funzionamento. Poiché lo stesso valore reale mappa sempre sullo stesso valore finto all'interno di una conversazione — nel messaggio dell'utente, nel risultato dello strumento che ritorna citando quel nome, nella risposta precedente del modello che lo menzionava — il modello ha una persona, un luogo o una cosa coerente su cui ragionare. Le conversazioni a più turni non vengono confuse. Le chiamate agli strumenti non si rompono. I sub-agenti ereditano la mappa della conversazione genitore e rimangono coerenti durante l'intera attività.
L'output che l'utente vede è la conversazione reale. I dati che il provider vede sono una finzione coerente. Il lavoro avviene nel divario tra queste due visioni, e l'obiettivo — l'unico obiettivo — è rendere quel divario invisibile.
Un filtro per la privacy che intralcia verrà disattivato. Un filtro per la privacy che scompare nel flusso di lavoro è l'unico che valga la pena distribuire.
Questo è lo standard per cui abbiamo costruito.