🤖 AI

Addressing Labelled Data Scarcity: Taxonomy-Agnostic Annotation of PII Values in HTTP Traffic using LLMs

Questo articolo propone e valuta una pipeline multi-stadio basata su Large Language Model che abilita un'annotazione flessibile e indipendente dalla tassonomia delle Informazioni di Identificazione Personale nel traffico HTTP, affrontando la scarsità di dati attraverso la generazione di traffico sintetico e dimostrando una rilevazione accurata attraverso definizioni della privacy diversificate.

Autori originali: Thomas Cory, Axel Küpper

Pubblicato 2026-05-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Thomas Cory, Axel Küpper

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere un ispettore della privacy per una città affollata. Il tuo lavoro consiste nel controllare ogni lettera, pacco e messaggio digitale in uscita dalla città per assicurarti che nessuno stia inviando per errore informazioni personali segrete (come indirizzi di casa, numeri di telefono o cartelle cliniche). Queste informazioni segrete sono chiamate PII (Informazioni di Identificazione Personale).

Per anni, gli ispettori hanno utilizzato due strumenti principali:

Il Manuale di Regole: Un elenco rigido di parole chiave (come "email" o "SSN"). Questo funziona bene per lettere semplici, ma fallisce quando le persone scrivono in modi strani o usano codici.
Il Cane Addestrato: Un modello di machine learning addestrato su migliaia di esempi. È intelligente, ma conosce solo le regole specifiche a cui è stato istruito. Se le regole cambiano (ad esempio, una nuova legge definisce i "dati sanitari" in modo diverso), il cane deve essere riaddestrato da zero, il che richiede molto tempo e una massiccia fornitura di lettere reali e segrete da studiare.

Il Problema: Le lettere segrete reali sono difficili da ottenere (a causa delle leggi sulla privacy) e le regole su ciò che conta come "segreto" cambiano continuamente. Questo lascia gli ispettori con una carenza di buoni dati di addestramento e strumenti che non possono adattarsi.

La Nuova Soluzione: Il "Super-Traduttore"

Questo articolo introduce un nuovo approccio che utilizza i Modelli Linguistici di Grandi Dimensioni (LLM). Pensa a un LLM non come a un cane addestrato, ma come a un traduttore super-intelligente e flessibile che ha letto quasi tutto nella biblioteca. Non hai bisogno di addestrare questo traduttore su regole specifiche; gli consegni semplicemente il manuale di regole in questo momento (a runtime), e lui può comprenderlo istantaneamente.

Ecco come gli autori hanno costruito il loro sistema, utilizzando semplici analogie:

1. La Catena di Montaggio (La Pipeline)

Invece di chiedere al traduttore di fare tutto in una volta, gli autori hanno costruito una catena di montaggio in tre fasi:

Fase 1: Il Pulitore (Pre-elaborazione): Prima che il traduttore veda il messaggio, una macchina lo pulisce. Decifra i codici (come trasformare %20 di nuovo in uno spazio) in modo che il traduttore veda una frase chiara e leggibile.
Fase 2: L'Investigatore e lo Scriba (Annotazione in Due Fasi):
- L'Investigatore: Prima, l'LLM guarda il messaggio e dice: "Vedo un numero di telefono e un nome qui, ma nessun registro medico". Crea un breve elenco di cosa cercare.
- Lo Scriba: Poi, un secondo passaggio si concentra solo sul trovare il testo esatto per quegli elementi specifici. Riducendo il campo di attenzione, lo Scriba non si confonde con altri numeri o parole.
Fase 3: L'Editore (Revisione): Un controllo finale esamina il lavoro. Se lo Scriba ha saltato un numero o ha preso la parola sbagliata, l'Editore lo corregge.

2. La Fabbrica di "Lettere Finte" (Dati Sintetici)

Poiché gli ispettori non possono usare le lettere segrete delle persone reali per addestrare i loro strumenti, gli autori hanno costruito una Fabbrica che produce lettere finte.

Questa fabbrica prende un manuale di regole (una tassonomia) e chiede all'LLM di scrivere lettere che sembrano realistiche e che contengono segreti specifici (come "il numero di telefono di Mario Rossi").
Crucialmente, la fabbrica scrive anche le risposte (la verità fondamentale) per ogni lettera che produce.
Perché questo è importante: Questo risolve il problema della "carenza". Puoi generare migliaia di lettere di pratica con risposte perfette istantaneamente, senza mai toccare i dati privati di una persona reale.

3. La Prova su Strada (Valutazione)

Gli autori hanno testato questo sistema con tre diversi "Manuali di Regole" (Tassonomie):

AI4Privacy: Un elenco ampio di segreti comuni (nomi, email, ID).
mHealth: Un elenco specifico per le app sanitarie (segni vitali, dati di fitness).
PlayStore: Un elenco di alto livello utilizzato dagli store di applicazioni (ad esempio, "Dati Finanziari" o "Posizione").

I Risultati:

Successo: Il sistema ha funzionato incredibilmente bene sui primi due manuali di regole. Poteva leggere un messaggio, guardare il manuale di regole specifico fornito quel giorno e trovare accuratamente i segreti.
Sfida: Ha faticato un po' di più con il manuale di regole "PlayStore". Gli autori spiegano che questo è dovuto al fatto che quel manuale utilizza categorie molto ampie (come "Dati Finanziari") che sono più difficili da collegare a una parola specifica in un messaggio rispetto a cose concrete come "Numero di Telefono".
La Fase "Editore": Interessantemente, il passaggio finale dell'"Editore" non ha sempre migliorato le cose. A volte correggeva gli errori, ma altre volte ne introduceva di nuovi. Gli autori suggeriscono che questo potrebbe essere dovuto al fatto che l'Editore utilizzava lo stesso "cervello" dello Scriba, quindi commetteva gli stessi tipi di errori.

Il Punto Chiave

Questo articolo dimostra che non è necessario riaddestrare una macchina ogni volta che le regole sulla privacy cambiano. Invece, puoi utilizzare un'IA flessibile che legge le regole al volo.

Per gli Ispettori: Puoi scambiare i manuali di regole istantaneamente senza ricostruire i tuoi strumenti.
Per la Scarsità di Dati: Puoi generare i tuoi dati di pratica (lettere finte) per testare i tuoi strumenti, così non hai bisogno di rubare i dati delle persone reali.

Gli autori concludono che, sebbene questo non sia ancora una sostituzione perfetta per i rilevatori leggeri e veloci, è uno strumento potente per creare dati di addestramento di alta qualità e per auditare i sistemi mentre le leggi sulla privacy evolvono. Suggeriscono che il miglior percorso futuro sia utilizzare questa IA flessibile per creare i dati e poi insegnare a macchine più piccole e veloci come svolgere il lavoro.

Riepilogo Tecnico: Annotazione Agnostica rispetto alla Tassonomia dei Valori PII nel Traffico HTTP tramite LLM

Enunciato del Problema

Le audit automatizzate sulla privacy delle applicazioni web e mobili si basano sempre più sull'analisi del traffico HTTP in uscita per rilevare fughe di Informazioni Personalmente Identificabili (PII). Tuttavia, i rilevatori esistenti basati sull'apprendimento automatico affrontano due limitazioni critiche:

Scarsità di Dati: Dipendono da dataset di alta qualità etichettati manualmente, la cui creazione è laboriosa e il cui mantenimento è difficile.
Rigidità della Tassonomia: Questi modelli sono strettamente accoppiati a tassonomie di etichette fisse. Man mano che le definizioni della privacy evolvono o differiscono tra domini (ad esempio, GDPR vs. mHealth vs. politiche dello Store Play), è necessario un riaddestramento e le prestazioni spesso si degradano significativamente anche con minime modifiche alla tassonomia o alla distribuzione dei dati.

Il documento ipotizza che i Modelli Linguistici di Grandi Dimensioni (LLM), in quanto modelli generalisti capaci di eseguire compiti in modalità zero-shot o few-shot senza riaddestramento, offrano una potenziale soluzione per abilitare l'annotazione agnostica rispetto alla tassonomia dei valori PII in tempo di esecuzione.

Metodologia

Gli autori propongono un quadro completo costituito da due componenti principali: una pipeline di annotazione multistadio e un generatore di dati sintetici.

1. Pipeline di Annotazione Multistadio
La pipeline scompone il compito complesso del rilevamento PII in sottoproblemi specializzati per migliorare l'accuratezza e gestire la variabilità del traffico HTTP:

Pre-elaborazione Deterministica: I corpi dei messaggi HTTP vengono normalizzati per mitigare la variabilità di codifica. Ciò include la decodifica URL (RFC 3986), la risoluzione dei riferimenti ai caratteri HTML e la decodifica opzionale a livello applicativo (ad esempio, Base64) per le sottostringhe che corrispondono a specifici pattern sintattici. Sia le rappresentazioni originali che quelle normalizzate sono preservate per la tracciabilità.
Annotazione a Due Stadi:
- Classificazione a Livello di Etichetta: Un LLM prevede l'insieme delle etichette PII ( $L_m$ ) esplicitamente presenti nel messaggio, aderendo a un requisito rigoroso di "valore esplicito" (nessuna inferenza da chiavi vuote).
- Estrazione a Livello di Istanza: Un secondo LLM esegue un Riconoscimento di Entità Nominate (NER) mirato sul corpo normalizzato, condizionato dalle etichette previste. Questa fase si concentra sul rilevamento dei confini e sulla disambiguazione utilizzando indizi contestuali (nomi delle chiavi, pattern dei valori, posizione strutturale).
Revisione Post-Annotazione: Una terza fase LLM funge da revisore, affinando le annotazioni iniziali per correggere falsi negativi, mismatch di etichette ed errori di confine.
Strumento di Inferenza LLM: Per garantire la robustezza, la pipeline impiega la Generazione Aumentata dal Recupero (RAG) per iniettare esempi pertinenti al compito (strutturali e specifici per etichetta) nei prompt. Un livello di validazione deterministico impone la conformità allo schema e normalizza gli output delle etichette (ad esempio, mappando "E-mail" su "Email") utilizzando la similarità coseno rispetto alla tassonomia target.

2. Generatore di Messaggi HTTP Sintetici
Per affrontare la scarsità di dati etichettati senza esporre il traffico reale degli utenti, gli autori introducono un generatore guidato dalla tassonomia:

Generazione di Scenari: L'LLM crea modelli di scenari (ad esempio, creazione di account, checkout) basati su una tassonomia fornita.
Istante dei Messaggi: L'LLM genera richieste HTTP concrete (e opzionalmente risposte) contenenti valori PII espliciti.
Validazione: Un livello di validazione garantisce la correttezza strutturale, la conformità alla tassonomia e che tutti i valori annotati appaiano verbatim nel payload generato.
Monitoraggio della Copertura: Il sistema monitora la copertura delle etichette per garantire una rappresentazione diversificata attraverso la tassonomia.

Contributi Chiave

Il documento delinea tre contributi principali:

C1 (Pipeline di Annotazione): Un approccio basato su LLM multistadio per l'identificazione granulare delle PII nei payload HTTP che supporta il cambio di tassonomie di etichette in tempo di esecuzione senza riaddestramento.
C2 (Generatore Sintetico): Un meccanismo basato su LLM per generare traffico HTTP sintetico con annotazioni PII di verità fondamentale, riducendo la dipendenza dalla curatela manuale per tassonomie in evoluzione.
C3 (Valutazione): Una valutazione completa su tre tassonomie distinte (AI4Privacy, mHealth e PlayStore) che coprono diversi domini e livelli di granularità per valutare flessibilità e prestazioni.

Risultati

La valutazione ha utilizzato tre dataset derivati dal generatore sintetico, suddivisi in 80/20 per la valutazione e per gli esempi RAG. Le prestazioni sono state misurate utilizzando Precisione, Recall e punteggio F1 a livello di etichetta e di istanza.

Prestazioni Complessive: La pipeline ha ottenuto prestazioni solide sulle tassonomie AI4Privacy (53 classi) e mHealth (38 classi). Il rilevamento a livello di etichetta è stato vicino al limite massimo (F1 > 0,98) nella fase di classificazione, e l'estrazione a livello di istanza è rimasta elevata (F1 > 0,95).
Varianza della Tassonomia: Le prestazioni sono state inferiori sulla tassonomia PlayStore (38 classi), che utilizza categorie di livello superiore rivolte alle policy. Ciò suggerisce che la difficoltà di annotazione è correlata alla granularità semantica della tassonomia; le categorie ampie sono più difficili da mappare su valori specifici del payload rispetto ai tipi concreti di PII.
Impatto Architetturale:
- La configurazione a due stadi (classificazione seguita da estrazione mirata) ha generalmente superato o eguagliato l'annotazione a stadio singolo su AI4Privacy e mHealth, migliorando principalmente la recall a livello di istanza.
- Su PlayStore, l'approccio a due stadi ha migliorato il rilevamento delle etichette ma non si è tradotto in una migliore estrazione di istanze, indicando che output del classificatore rumorosi possono propagare errori in tassonomie complesse.
Fase di Revisione: La fase di revisione ha fornito un beneficio netto limitato, degradando occasionalmente le prestazioni. Gli autori suggeriscono che ciò è dovuto al fatto che è stata utilizzata la stessa famiglia di modelli per l'annotazione e la revisione, potenzialmente riproducendo assunzioni condivise anziché fornire una correzione indipendente.

Significato e Affermazioni

Il documento afferma che gli LLM costituiscono una base promettente per l'annotazione del traffico flessibile e agnostica rispetto alla tassonomia. I punti chiave includono:

Fattibilità: Gli LLM possono identificare e annotare con precisione i valori PII trasmessi esplicitamente quando la tassonomia è fornita in tempo di esecuzione, eliminando la necessità di riaddestramento su nuovi insiemi di etichette.
Generazione di Dati: Il traffico HTTP sintetico con annotazioni di verità fondamentale è un substrato vitale per la valutazione controllata e il prompting few-shot, mitigando la scarsità di dati reali etichettati.
Limitazioni e Ambito: Gli autori sono modesti riguardo al dispiegamento di questo approccio come sostituto diretto di rilevatori leggeri per la produzione. Osservano che:
- Le prestazioni dipendono fortemente dalla progettazione della tassonomia e dalla struttura del payload.
- I dati sintetici, sebbene utili per la valutazione, potrebbero non catturare appieno la distribuzione del traffico reale (ad esempio, offuscamento, payload malformati).
- La valutazione attuale è limitata ai valori trasmessi esplicitamente nei corpi delle richieste, escludendo intestazioni, cookie e traffico cifrato.
Percorso Futuro: Gli autori propongono un approccio ibrido come la strada più promettente: utilizzare l'annotazione basata su LLM per creare o affinare dataset etichettati sotto tassonomie in evoluzione e, successivamente, distillare queste annotazioni in modelli più piccoli e discriminativi per il dispiegamento ad alto throughput.