Riassunto Tecnico: SurrogateShield

Problematica

Gli assistenti basati su Large Language Model (LLM) trasmettono le query degli utenti in modo letterale a endpoint API di terze parti, esponendo le Informazioni di Identificazione Personale (PII) a rischi di violazione dei dati, citazioni in giudizio o cambiamenti nelle policy. La mitigazione prevalente, la redazione tramite placeholder (ad es. sostituire "John Doe" con [PERSONA]), preserva la privacy per costruzione ma distrugge la coerenza semantica. Questa degradazione strutturale costringe l'LLM a elaborare query "strutturalmente degradate", risultando in risposte corrispondentemente degradate e una perdita misurabile di utilità nei compiti downstream. La sfida centrale è impedire che PII reali attraversino il confine di rete senza sacrificare l'utilità semantica necessaria per interazioni LLM di alta qualità.

Metodologia: SurrogateShield

SurrogateShield è un proxy lato client che intercetta le query degli LLM, sostituisce le PII rilevate con valori surrogati generati localmente e coerenti con il tipo, e ripristina in modo trasparente i valori originali nella risposta prima della visualizzazione. Il sistema opera su tre principi di progettazione:

1. Nessuna PII attraversa il confine dell'API: L'applicazione avviene a livello di trasporto locale prima che la richiesta HTTP venga costruita.
2. I surrogati preservano l'utilità: I valori fittizi (ad es. nomi, SSN) sono realistici, coerenti con il tipo e statisticamente non collegati all'originale, preservando la struttura della frase e l'accordo grammaticale.
3. Ripristino trasparente: I valori originali sono ripristinati nella risposta dell'LLM tramite un ResolvePass a tre passaggi prima che l'utente veda l'output.

Architettura del Sistema

La pipeline consiste in quattro componenti primari:

1. SentinelLayer (Cascata di Rilevamento a Tre Stadi)
Il rilevamento avviene attraverso una cascata sequenziale in cui ogni stadio maschera gli intervalli di caratteri rivendicati per prevenire la doppia elaborazione:

• PatternScan: Applica espressioni regolari ordinate per priorità con validatori di checksum (Luhn per le carte di credito, ABA per i numeri di routing) per rilevare 1le 16 tipologie strutturate di PII (ad es. SSN, email, indirizzi crypto).
• EntityTrace: Utilizza spaCy (en_core_web_lg) per il Named Entity Recognition (NER) sul testo rimanente. Classifica le entità in "confermate" (punteggio ≥0.85) e "al limite" (0.60–0.85). Include la logica di riclassificazione (ad es. promuzione di organizzazioni a entità geopolitiche se sono presenti preposizioni di luogo) e blocklist per sopprimere i falsi positivi comuni.
• ContextGuard: Esegue un modello NER DistilBERT (dslim/distilbert-NER) ospitato localmente per verificare le entità al limite e rilevare entità mancate. Questa fase viene eseguita interamente offline dopo un download iniziale del modello.

2. Intelligenza delle Query di Servizio e Rischio di Quasi-Identificatore

• ServiceQueryDetector: Distingue tra query in cui la posizione è l'argomento (ad es. "ristoranti vicino a X") rispetto a query in cui la posizione identifica l'utente. Per le query di servizio, applica un'anonimizzazione proporzionale (ad es. spostando i numeri civici di ±2–8) piuttosto che una sostituzione completa per mantenere l'utilità.
• Quasi-Identifier Risk Detector: Basato sul framework di k-anonimità di Sweeney, rileva combinazioni di campi (ad es. CAP + data di nascita + genere) che potrebbero statisticamente re-identificare un utore anche se i singoli campi non sono PII tradizionali.

3. MimicGen (Generazione di Surrogati)
Genera surrogati coerenti con il tipo utilizzando la libreria faker e logiche personalizzate. Garantisce la resistenza alle collisioni all'interno di una sessione e valida i formati (ad es. checksum Luhn validi per le carte di credito, codifica Base58 per gli indirizzi Bitcoin).

4. ShadowMap & ResolvePass

• ShadowMap: Un dizionario in memoria per conversazione che mappa i surrogati agli originali, persistito come file binario criptato AES-256-GCM. Le chiavi sono derivate tramite HKDF-SHA256 da un segreto a livello di dispositivo.
• Dual History: Il sistema mantiene due cronologie di messaggi: api_messages (solo surrogati, inviati all'API) e messages (valori reali ripristinati, mostrati all'utente). Ciò evita l'accumulo di PII nei contesti multi-turno.
• ResolvePass: Ripristina gli originali nella risposta dell'LLM utilizzando tre passaggi: corrispondenza esatta (per primi i più lunghi), corrispondenza a componenti (per l'uso parziale del nome) e corrispondenza fuzzy (utilizzando rapidfuzz).

Contributi Chiave

1. Sistema SurrogateShield: Il primo proxy end-to-end lato client che implementa la sostituzione di surrogati coerenti con il tipo con mappatura localmente protetta crittograficamente e ricostruzione trasparente della risposta.
2. Cascata di Rilevamento: Una nuova pipeline a tre stadi che combina regex, spaCy NER e DistilBERT NER locale, aumentata da una suite di post-elaborazione per la deduplicazione e il filtraggio topico.
3. Validazione dell'Utilità Empirica: Dimostrazione che la sostituzione con surrogati supera significativamente la redazione tramite placeholder in termini di utilità semantica, misurata tramite BERTScore.
4. Robustezza Avversaria: Evidenza empirica che i messaggi sostituiti con surrogati resistono al recupero avversario basato su LLM, mentre i token placeholder espongono le posizioni degli slot all'inferenza.
5. Analisi di Ablazione: Quantificazione del contributo marginale F1 di ogni stadio di rilevamento, identificando il ruolo specifico di PatternScan (PII strutturate), EntityTrace (entità nominate) e ContextGuard (località al limite).

Risultati Sperimentali

Valutati su un corpus di 1.124 query annotate (sintetiche ma strutturalmente realistiche):

• Qualità del Rilevamento: La cascata completa ha raggiunto un F1 score del 98,87%. SurrogateShield ha eguagliato o superato Microsoft Presidio su tutti gli 11 tipi di entità confrontabili, con guadagni significativi su identificatori strutturati come le patenti di guida USA (+50,00 pp F1) e gli indirizzi Crypto (+45,45 pp F1).
• Utilità Semantica: SurrogateShield ha preservato il 94,85% dell'utilità semantica (BERTScore F1), rispetto all'81,59% della redazione tramite placeholder (un miglioramento di 13,26 punti percentuali, $p < 0,001$).
• Garanzie di Privacy:
  • Tasso di Leak PII: 0,00% (nessuna PII reale ha raggiunto l'API nel corpus di 1.124 query).
  • Tasso di Leak di Risoluzione: 0,00% (nessun surrogato è rimasto non ripristinato nella visualizzazione finale).
  • Recupero Avversario: In una prova di 100 query contro un avversario LLM indotto da prompt (Claude Haiku), il tasso di recupero per i messaggi sostituiti con surrogati era dello 0,00%, rispetto all'1,53% per i messaggi con redazione tramite placeholder.
• Performance: L'overhead di elaborazione locale totale è stato di 25,89 ms per query (dominato da spaCy NER a 24,60 ms), il che è trascurabile rispetto alle tipiche latenze delle API LLM (600–2.000 ms).

Significato e Rivendicazioni

Il documento sostiene che il compromesso tra privacy e utilità nelle interazioni con gli LLM non è fondamentale. SurrogateShield dimostra che la privacy richiede l'assenza di valori PII reali, non l'assenza della struttura della PII.

Sostituendo i valori reali con surrogati coerenti con il tipo, il sistema soddisfa il vincolo di contenimento (nessuna PII reale lascia il dispositivo) preservando al contempo l'integrità strutturale e semantica necessaria per risposte LLM di alta qualità. Gli autori affermano che questo è il primo sistema che valida empiricamente che questo spazio di progettazione è percorribile, ottenendo un'utilità maggiore e una resistenza avversaria più forte rispetto all'approccio prevalente di redazione tramite placeholder, operando interamente in locale con un overhead di latenza minimo. Il lavoro sfida l'assunto che la degradazione semantica sia un costo necessario per le interazioni con gli LLM che preservano la privacy.