Il problema non è riconoscere un nome, ma decidere se quel nome può restare nel testo. I sistemi di mascheramento contestuale dei PII hanno bisogno di esempi che distinguono le menzioni da oscurare da quelle da preservare anche quando appartengono allo stesso tipo di entità. Il lavoro su ReCoPII parte da qui: le restrizioni sulla privacy rendono difficile accedere a dati reali e le tecniche di augmentation basate sull'autore, come SPY, introducono un'etichettatura fragile perché assumono un unico soggetto dei dati.
ReCoPII rovescia il presupposto. Il framework pianifica relazioni tra entità vincolate da ontologia, genera frasi di inserimento con segnaposto, ricostruisce le annotazioni con codice e fa verificare il risultato a un LLM separato. Da qui derivano le etichette MASK/KEEP non dall'identità dell'autore, ma dalle relazioni tra entità. Il risultato su documenti coreani di sei domini è ReCoPII-Ko, un corpus con annotazioni di relazione, privacy e MASK/KEEP.
Il dato più indicativo non è solo l'accordo tra annotatori: l'88,42% sulle etichette KEEP campionate contro il 26,27% dell'augmentation SPY sugli stessi documenti. È il segnale che il presupposto autore-centrico non è un dettaglio tecnico, ma una falla strutturale. Se un'organizzazione usa SPY per costruire dati di mascheramento, rischia di etichettare come non-PII menzioni che andrebbero preservate, oppure di addestrare il sistema con esempi incoerenti. In un contesto di conformità, questo non produce solo rumore: erode la capacità di decidere cosa oscurare e cosa mantenere.
Il secondo risultato cambia la prospettiva sull'equilibrio tra protezione e utilità. Il fine-tuning congiunto con un rilevatore PII, dentro un budget di leakage fisso, elimina la maggior parte dell'over-masking che il solo rilevatore introdurrebbe. Su record verificati da umani, i quattro detector che rispettano il vincolo mostrano un over-masking massimo del 5,04% con un leakage massimo del 4,18%. Non è un benchmark astratto: è un trade-off operativo. Mascherare troppo non protegge di più, degrada il testo per i modelli a valle. Mascherare troppo poco espone dati personali. La relazione tra questi due errori è ciò che un team di deployment deve governare.
C'è anche un segnale per chi guarda all'efficienza. Il detector compatto è paragonabile a XLM-R-large su KDPII con circa un quarto dei parametri. In un'architettura self-hosted questo si traduce in minore pressione su VRAM, latenza più contenuta e costi di inference più bassi, senza rinunciare alla capacità di rilevamento su quel benchmark. Non è una raccomandazione: è un vincolo strutturale che sposta l'attenzione dal modello più grande alla qualità del dato e del fine-tuning.
La lezione di ReCoPII è più ampia. La privacy nei LLM non si risolve solo con un layer di mascheramento, ma con dati di addestramento che riflettono le relazioni reali tra entità. Il passaggio da etichette basate sull'autore a etichette basate sulle relazioni riduce l'arbitrarietà e avvicina il mascheramento alla semantica del documento. Chi opera in contesti regolati, dove i dati non possono uscire dal perimetro locale, ha bisogno esattamente di questo: meccanismi che decidano cosa proteggere senza distruggere il contesto necessario all'LLM.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!