Il GDPR non ha una preferenza linguistica
Il Regolamento generale sulla protezione dei dati si applica in egual misura ai dati personali in tedesco, francese, polacco, svedese, spagnolo, italiano e tutte le altre lingue elaborate da organizzazioni soggette al Regolamento. Un identificatore mancante nei dati dei clienti tedeschi crea la stessa esposizione normativa di un identificatore mancante nei dati dei clienti inglesi. Il GDPR non fa distinzioni linguistiche.
La maggior parte degli strumenti di rilevamento PII lo fa.
Gli strumenti di rilevamento PII commerciali e open-source dominanti sono stati costruiti e testati principalmente su testi in inglese. I loro riconoscitori di entità riflettono questo: numeri di previdenza sociale statunitensi, patenti di guida statunitensi, formati di passaporto statunitensi e identificatori universali comuni (indirizzi email, numeri di telefono in formato NANP, numeri di carte di credito). I riconoscitori per identificatori nazionali non inglesi — quando esistono — sono frequentemente meno accurati, meno mantenuti e più propensi a produrre falsi negativi.
Per le imprese che operano in vari Stati membri dell'UE, questo crea un divario sistematico di conformità: lo strumento riporta che la PII è stata rilevata e rimossa, ma gli identificatori non inglesi che rappresentano la maggiore esposizione al GDPR in alcune giurisdizioni rimangono nei dati.
La differenza strutturale tra identificatori nazionali
Il divario tra strumenti incentrati sull'inglese e strumenti genuinamente multilingue non è una questione di aggiungere più modelli regex. I formati degli identificatori nazionali nei vari Stati membri dell'UE sono strutturalmente distinti in modi che richiedono conoscenze specifiche per giurisdizione per essere rilevati correttamente.
Numero di identificazione fiscale tedesco (Steuer-ID): identificatore fiscale di 11 cifre con un algoritmo di checksum specifico basato sulla variante della formula di Luhn. Un regex generico per SSN non corrisponderà a questo formato. Un regex che corrisponde a qualsiasi numero di 11 cifre produrrà enormi tassi di falsi positivi nei documenti finanziari tedeschi.
NIR francese (Numéro d'inscription au répertoire): identificatore di 15 cifre che incorpora il sesso del titolare, l'anno di nascita, il mese di nascita, il codice del dipartimento o del paese di nascita, il numero d'ordine di nascita e una chiave di controllo di 2 cifre. La rilevazione richiede di comprendere la struttura e di convalidare la chiave di controllo.
Personnummer svedese: identificatore di 10 cifre (a volte con indicatore di secolo che lo rende di 12 cifre) con una cifra di controllo di Luhn. Il formato varia a seconda dell'età: le persone nate prima del 1990 usano un separatore + invece di -, cambiando il formato che deve essere rilevato.
PESEL polacco: identificatore di 11 cifre che codifica la data di nascita, il genere e una cifra di controllo basata su un algoritmo di somma ponderata. La corretta rilevazione richiede sia il matching del formato che la validazione del checksum.
Questi non sono variazioni di formato su un modello comune. Sono identificatori strutturalmente distinti con lunghezze diverse, algoritmi di validazione diversi e schemi di codifica posizionale diversi. Un modello NER addestrato in inglese che incontra un NIR francese nel testo non lo riconoscerà come un identificatore nazionale — lo ignorerà o, se corrisponde a qualche altro modello, lo classificherà erroneamente.
La conseguenza pratica della conformità
Per un responsabile della conformità in un BPO europeo che elabora dati di assistenza clienti da Germania, Francia, Polonia e Paesi Bassi simultaneamente, la conseguenza pratica è un divario sistematico di rilevamento nei registri dei clienti non inglesi.
Lo strumento del responsabile della conformità riporta un'anonimizzazione PII riuscita. I dati anonimizzati contengono ancora Steuer-IDs nei registri tedeschi, numeri NIR nei registri francesi e numeri PESEL nei registri polacchi — perché i riconoscitori dello strumento per questi formati sono assenti o insufficientemente accurati.
Quando il dataset anonimizzato viene successivamente utilizzato per analisi, test o condiviso con un partner di ricerca, i dati "anonimizzati" contengono ancora dati di identificatori nazionali ri-identificabili. La violazione del GDPR non è visibile nei log di output dello strumento. Diventa visibile quando una richiesta di accesso da parte di un soggetto dei dati, un audit da parte di un'autorità di vigilanza o una violazione dei dati rivelano che gli identificatori non inglesi non sono stati rimossi.
Ricerche che confrontano approcci ibridi di rilevamento PII multilingue con strumenti monolingue incentrati sull'inglese hanno trovato che gli approcci ibridi raggiungono punteggi F1 da 0.60 a 0.83 in diverse località europee — rispetto a prestazioni quasi nulle degli strumenti solo in inglese applicati a formati di identificatori non inglesi.
Cosa richiede una copertura completa
Il vero rilevamento PII multilingue per la conformità al GDPR dell'UE richiede tre strati architettonici che lavorano in combinazione:
Modelli spaCy nativi per lingua forniscono comprensione semantica di nomi, organizzazioni e luoghi nella lingua del testo. Un modello spaCy addestrato su testi in tedesco comprende che "Müller" è un cognome comune nel contesto tedesco — non solo una parola in maiuscolo. Esistono modelli per 25 lingue ad alta risorsa dell'UE.
Modelli NLP Stanza estendono la copertura a lingue aggiuntive non coperte da spaCy allo stesso livello di accuratezza.
Modelli di trasformatori cross-lingua (XLM-RoBERTa) gestiscono l'ambiguità cross-lingua che il puro matching di pattern non può affrontare — riconoscendo che un nome che appare in una frase francese è un nome di persona anche se il motore di rilevazione non è stato specificamente addestrato su quel nome.
Regex con validazione specifica per giurisdizione copre identificatori nazionali strutturati — Steuer-ID, NIR, PESEL, Personnummer — con validazione del checksum che elimina i falsi positivi.
Per il responsabile della conformità il cui strumento attualmente ignora gli identificatori non inglesi: il divario è strutturale, non di configurazione. Aggiungere liste di parole o espandere la copertura regex fornisce un miglioramento marginale. La conformità completa al GDPR dell'UE per dati multilingue richiede uno strumento costruito con la copertura degli identificatori dell'UE come requisito di progettazione, non come un ripensamento.
Fonti: