Anonimizzazione e NER tramite IA: la guida che districa anonimizzazione, pseudonimizzazione e GDPR (2026)
Quick Answer: cos’è l’anonimizzazione tramite IA e il NER?
L’anonimizzazione e la pseudonimizzazione tramite IA si appoggiano sulla tecnica del NER (Named Entity Recognition, «riconoscimento di entità nominate»: la capacità di un’IA di individuare automaticamente nomi, indirizzi, numeri, date, organizzazioni in un testo). L’IA identifica questi dati personali poi li sostituisce con marcatori o pseudonimi.
Distinzione GDPR critica:
- Anonimizzazione: trasformazione irreversibile. Il dato esce dall’ambito di applicazione del GDPR (Considerando 26). Molto difficile da raggiungere tecnicamente — bisogna assicurarsi che la persona non possa mai più essere reidentificata, neanche incrociando con altre fonti, neanche se qualcuno recupera la chiave.
- Pseudonimizzazione (art. 4 n. 5 GDPR): sostituzione reversibile sotto accesso ristretto. Il dato resta personale ai sensi del GDPR, ma il rischio è ridotto.
La maggior parte dei progetti detti «anonimizzazione IA» producono in realtà pseudonimizzazione. È la prima cosa da chiarire: tutto il resto — base giuridica, DPIA, periodo di conservazione, trasferimenti extra-UE — ne deriva.
Strumenti 2026:
- Grandi modelli linguistici (Mistral Large, GPT-4o, Claude): precisione 95-98 % in italiano standard, semplici da implementare tramite prompt, ma costo di inferenza e dipendenza dal fornitore.
- Modelli NER dedicati (spaCy it_core_news_lg, ItalianBERT, IT-BERT di Almawave, GLiNER, Microsoft Presidio): più rapidi, più economici a volume, ma tassonomia rigida.
- Per la sovranità: Mistral installato on-premise o Llama 3 self-hosted + spaCy interno, zero uscita di dati verso gli Stati Uniti — pertinente per SSN, fascicolo sanitario elettronico, studi legali e banche vigilate.
Casi d’uso che reggono: preparazione di corpus per fine-tuning interno, condivisione con partner accademici tramite atto di nomina art. 28, risposta a richiesta GDPR art. 15 senza esporre dati di terzi, analisi manageriale di corpus interni nel rispetto dell’art. 4 dello Statuto dei Lavoratori, conformità settoriale (SSN, segreto medico, banche), preparazione di documenti prima di chiamare un LLM SaaS.
Perché questo tema, perché ora
Molte organizzazioni italiane hanno in mente: «inviare i nostri documenti a un LLM, ma senza i dati personali dentro». L’idea è sana. La promessa è raramente mantenuta.
Tre cose sono cambiate nel 2026. Una, gli LLM moderni sanno davvero fare NER in italiano — non era vero nel 2022. Due, i modelli dedicati open-source (spaCy, GLiNER, ItalianBERT, IT-BERT) sono ormai alla portata di un dispiegamento sovrano — non serve inviare una sola parola a OpenAI per anonimizzare una sola parola. Tre, la dottrina regolatoria si è irrigidita su ciò che si chiama veramente «anonimizzazione»: il Garante Privacy e l’EDPB ricordano regolarmente che pseudonimizzare non è anonimizzare (Parere EDPB 28/2024).
La trappola: credere che un rilevatore di nomi basti per «uscire dal GDPR». Non basta. Questo articolo districa ciò che funziona, ciò che non funziona e dove tracciare la frontiera tra IA, organizzazione, DPO e macchina umana di validazione.
Anonimizzazione vs pseudonimizzazione: la distinzione che cambia tutto
È la base. Tutto il resto — base giuridica, DPIA, contratti con responsabili, periodo di conservazione — dipende da questa distinzione.
Anonimizzazione ai sensi del GDPR
Affinché un dato sia veramente anonimizzato, tre condizioni devono essere soddisfatte simultaneamente, come illustrato nel parere del Garante Privacy n. 256/2018 e nelle Linee guida WP29 sull’anonimizzazione (recepite dall’EDPB):
- Nessuna reidentificazione diretta — nomi, identificatori, codici fiscali, IBAN, tessera sanitaria sono eliminati o trasformati.
- Nessuna reidentificazione indiretta — nessuna combinazione di attributi permette di isolare una persona. Ciò include i contesti singolari («l’unico direttore commerciale che ha lasciato ACME S.p.A. nel marzo 2025»).
- Nessuna reidentificazione tramite incrocio — anche combinando con il Registro Imprese, il Registro Anagrafico Centrale, un export LinkedIn o un dataset aperto, la persona resta indistinguibile.
Se queste tre condizioni sono soddisfatte, il dato esce dall’ambito di applicazione del GDPR. È la promessa massima.
Raggiungere queste tre condizioni è tecnicamente molto difficile, particolarmente per testi liberi (e-mail, verbali, contratti). Esistono tecniche formali — k-anonimato, l-diversità, t-vicinanza — ma si applicano soprattutto a basi tabellari, non a testo libero.
Pseudonimizzazione ai sensi del GDPR
L’art. 4 n. 5 GDPR la definisce come «il trattamento dei dati personali in modo tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente e soggette a misure tecniche e organizzative».
In chiaro: si sostituisce Maria Rossi con Persona_001, e si conserva una tabella Persona_001 → Maria Rossi altrove, sotto accesso molto ristretto. La pseudonimizzazione riduce fortemente il rischio, ma il dato resta personale ai sensi del GDPR. Tutti gli obblighi si applicano: registro dei trattamenti, base giuridica, periodo di conservazione, diritti degli interessati, DPIA se applicabile, contratti con responsabili.
Tabella di decisione rapida
| Criterio | Anonimizzazione | Pseudonimizzazione |
|---|---|---|
| Legame con la persona | Distrutto irrimediabilmente | Conservato tramite chiave separata |
| Soggetta al GDPR? | No | Sì |
| Fattibilità su testo libero | Molto difficile | Fattibile con NER + policy |
| Caso d’uso tipico | Pubblicazione di dataset aperto | Trattamento interno, condivisione regolata |
| Rischio residuo | Quasi nullo (se ben fatta) | Basso ma non nullo |
| Sforzo di implementazione | Elevato | Moderato |
Verdetto pratico: la maggior parte dei progetti detti «anonimizzazione IA» sono in realtà pseudonimizzazione. Non è una debolezza, è un quadro chiaro. La trappola consiste nel promettere anonimizzazione e consegnare pseudonimizzazione: la conformità crolla e il DPO scopre il problema sei mesi dopo — tipicamente durante un’ispezione del Garante.
Il NER: cosa fa, cosa non fa
La meccanica
Il NER (Named Entity Recognition) identifica in un testo le entità nominate appartenenti a categorie predefinite. Una tassonomia classica adattata al contesto italiano:
| Categoria | Esempio | Sensibilità GDPR |
|---|---|---|
| PER — persona | Maria Rossi, Sig. Bianchi | Identificatore diretto |
| ORG — organizzazione | ACME S.p.A., Policlinico Gemelli | Indiretto (combinato con PER) |
| LOC — luogo | Roma, Via del Corso 24 | Indiretto, talvolta diretto (indirizzo preciso) |
| DATE | 15 marzo 2026 | Indiretto (date di eventi personali) |
| EMAIL / PHONE / IBAN / CF / TS | maria@acme.it, 06 1234 5678 | Identificatori diretti |
| MISC — vari | Numero di pratica, riferimento interno | Variabile |
Per la pseudonimizzazione in aziende italiane, questa tassonomia si arricchisce di categorie di business: numero paziente (FSE), identificativo cliente, numero di pratica, importi sensibili, identificatori di contratto, CAP (combinato con età e sesso è altamente identificativo — il risultato di Sweeney sui codici ZIP statunitensi si trasferisce ai CAP italiani). È questo lavoro di tipizzazione di dominio a fare la differenza tra un NER generico e una pseudonimizzazione utilizzabile.
Schema semplificato della pipeline
[Testo sorgente]
│
▼
[NER] → lista di entità rilevate (tipo, valore, posizione)
│
▼
[Politica di sostituzione] → cosa eliminare, cosa pseudonimizzare, cosa conservare
│
▼
[Generazione di pseudonimi] → tabella «originale → pseudonimo»
│ │
│ ▼
│ [Cassaforte sicura]
▼ (chiave di reidentificazione,
[Testo pseudonimizzato] accesso molto ristretto)La cassaforte è il pezzo critico. Se chiunque può accedere alla tabella di corrispondenza, la pseudonimizzazione crolla. È un punto architetturale, non un dettaglio implementativo — il Garante esaminerà esattamente questo controllo durante un’ispezione.
Cosa il NER non vede
Il NER, anche eccellente, manca tre famiglie di dati identificativi:
1. Dati indirettamente identificativi per contesto. «Il direttore commerciale che ha lasciato ACME S.p.A. nel marzo 2025 per un concorrente» — nessun nome proprio nella frase, ma una sola persona al mondo corrisponde. Il NER rileva «direttore commerciale», «ACME S.p.A.», «marzo 2025». Non comprende che la combinazione è singolare.
2. Combinazioni rare. «Donna, 47 anni, ingegnere agronoma, residente a Matera, madre di gemelli» — nessun elemento è identificativo preso isolatamente, l’insieme lo è fortemente. Nessun NER rileva «combinazione rara».
3. Riferimenti impliciti interni. «Come concordato ieri al telefono, ecco la bozza di lettera per il cliente di cui parlavamo» — il NER non vede alcuna entità identificabile, eppure un umano che conosce il contesto sa esattamente di chi si tratta.
È per questo che la revisione umana su campione resta obbligatoria: 5-10 % del corpus all’avvio, riducibile all’1-2 % una volta stabilizzati i pattern. Ed è anche per questo che combiniamo sistematicamente il NER con una politica di riscrittura contestuale sui casi ad alto rischio: non sostituiamo solo i nomi, neutralizziamo anche i contesti singolari.
I tre approcci tecnici (in linguaggio semplice)
Approccio 1 — LLM generico con istruzione
Si dà al LLM un’istruzione del tipo: «identifica in questo testo tutte le entità nominate e restituiscile in forma strutturata, con il loro tipo e posizione». I modelli moderni (Mistral Large, GPT-4o, Claude) lo fanno molto bene sull’italiano standard.
| Vantaggi | Limiti |
|---|---|
| Precisione elevata (95-98 % in italiano standard) | Costo di inferenza non trascurabile a volume |
| Gestisce il contesto (utile per casi ambigui) | Latenza (qualche secondo per documento) |
| Flessibile: tassonomia adattata via prompt | Dipendenza dal fornitore LLM |
| Nessuna curva di apprendimento tecnica | Possibile uscita verso fornitore estero se SaaS |
Quando è la scelta giusta: prototipi, volumi bassi-medi (fino a qualche decina di migliaia di documenti al mese), tassonomia evolutiva, team senza expertise NLP.
Approccio 2 — Modello NER dedicato (open-source)
Modello pre-addestrato specializzato: spaCy it_core_news_lg, ItalianBERT, IT-BERT di Almawave, GLiNER, Microsoft Presidio. Gira in locale, molto rapido, basso costo.
| Vantaggi | Limiti |
|---|---|
| Molto rapido (millisecondi per documento) | Tassonomia rigida di default |
| Economico a volume | Prestazioni variabili secondo il dominio |
| Implementabile on-premise, zero uscita di dati | Setup più tecnico (Python, packaging modello) |
| Maturo (spaCy in produzione dal 2015) | Comprensione debole del contesto |
Quando è la scelta giusta: volumi elevati (SSN, banche), latenza critica, esigenza di sovranità massima, budget di inferenza controllato.
Approccio 3 — Ibrido
Modello dedicato per il rilevamento rapido sul grosso del flusso + LLM generico per casi complessi o ambigui + revisione umana sui casi critici.
| Vantaggi | Limiti |
|---|---|
| Ottimo rapporto costo / precisione su grandi volumi | Architettura più complessa |
| Robusto sui casi atipici | Richiede un orchestratore (LangChain, codice custom) |
| Compatibile con sovranità | Richiede tracking metriche (tasso di fallback al LLM) |
Quando è la scelta giusta: produzione stabilizzata, grandi volumi, esigenza di qualità elevata, team capace di operare una pipeline.
Albero di decisione rapido
Volume mensile?
│
├── < 10.000 documenti
│ └── Latenza critica (tempo reale)?
│ ├── Sì → NER dedicato (spaCy)
│ └── No → LLM generico
│
├── 10.000 – 1 milione
│ └── Sensibilità massima (SSN, studio legale)?
│ ├── Sì → Ibrido su stack sovrana
│ └── No → LLM generico sovrano (Mistral)
│
└── > 1 milione
└── Ibrido obbligatorio (economia inferenza + qualità)Casi d’uso che reggono
Nessun catalogo esaustivo. Sei casi robusti, con ciò che bisogna sapere prima di partire.
Caso 1 — Preparare un corpus per fine-tuning interno
Contesto: un’organizzazione italiana vuole adattare un LLM open-source (Llama, Mistral) al proprio business. Dispone di un corpus di verbali interni, scambi di e-mail, documentazione. Senza pseudonimizzazione, questi dati rischiano di finire nei pesi del modello finale e riapparire tramite un attacco detto membership inference («questo documento era nel corpus di addestramento?»).
Volume tipo: da 10.000 a 500.000 documenti.
Cosa può andare storto: pseudonimizzazione incompleta sui riferimenti interni (numeri di pratica, codici progetto) — questi riferimenti non sono visti dal NER ma permettono incroci interni.
Metrica di successo: tasso di reidentificazione < 1 % su un campione manuale post-pseudonimizzazione.
Caso 2 — Condividere con un partner accademico o consulente
Contesto: uno studio legale italiano vuole condividere un corpus di contratti con un dipartimento universitario per analisi statistica. Un’azienda sanitaria vuole condividere verbali con un consulente dati per un audit di qualità.
Volume tipo: qualche migliaio di documenti.
Cosa può andare storto: sottovalutazione dei dati indirettamente identificativi. Un contratto anonimizzato sui nomi delle parti può restare identificabile tramite il numero di causa, il tribunale competente, la data di registrazione.
Salvaguardia: atto di nomina a Responsabile esterno (art. 28 GDPR) con il partner, periodo di conservazione limitato, distruzione dimostrabile, audit possibile. La pseudonimizzazione da sola non sostituisce il contratto — e per i dati SSN, l’accordo deve rispettare anche il Codice di Deontologia Medica e le Linee guida del Garante per il fascicolo sanitario elettronico.
Caso 3 — Rispondere a una richiesta GDPR art. 15
Contesto: una persona richiede l’accesso ai propri dati personali. Ha diritto a riceverli — ma non a ottenere di passaggio i dati di altre persone presenti negli stessi documenti (e-mail, verbali). NER + redazione di terzi rende la risposta conforme. Il Garante ha sanzionato in più procedimenti la cattiva gestione delle richieste di accesso (sanzioni da 20.000 a 200.000 € in settori vari dal 2023).
Volume tipo: variabile, talvolta una manciata di documenti, talvolta diverse centinaia.
Cosa può andare storto: sovra-pseudonimizzazione che rende il documento incomprensibile e impedisce al richiedente di capire i propri dati.
Salvaguardia: politica chiara su cosa redigere e cosa conservare, validazione dal DPO o servizio legale prima dell’invio.
Caso 4 — Analizzare un corpus interno senza cadere nel controllo individuale illegittimo
Contesto: una direzione vuole capire i temi ricorrenti negli scambi interni (e-mail, supporto cliente) senza valicare la linea del controllo individuale illegittimo ai sensi dell’art. 4 dello Statuto dei Lavoratori (L. 300/1970) e delle Linee guida del Garante per posta elettronica e Internet (Provv. 13.3.2007). La pseudonimizzazione dei mittenti e destinatari permette un’analisi aggregata.
Volume tipo: 10.000-1.000.000 messaggi al mese.
Cosa può andare storto: la pseudonimizzazione non basta se l’analisi rivela indirettamente il comportamento individuale (volume di invio atipico, pattern orari unici). Bisogna anche aggregare prima dell’analisi.
Salvaguardia: informativa preventiva e accordo sindacale con la RSU/RSA (richiesto dall’art. 4 St. Lav.), DPIA documentata, finalità limitata, accesso ristretto ai risultati.
Caso 5 — Conformità settoriale (SSN, segreto professionale medico, banche)
Contesto: un’azienda sanitaria vuole usare un LLM esterno per analizzare referti clinici. Se l’identificativo paziente non è necessario all’analisi, la pseudonimizzazione a monte permette di inviare il contenuto a un LLM meno vincolato (Mistral Le Chat Enterprise) invece di imporre un’infrastruttura completa conforme alle Linee guida del Garante per il fascicolo sanitario elettronico. Il segreto medico (art. 10 Codice di Deontologia Medica) e il D.Lgs. 196/2003 continuano ad applicarsi — la pseudonimizzazione non esime l’organizzazione dal documentare finalità, necessità e minimizzazione. Vedi la nostra guida IA conforme al GDPR.
Salvaguardia: atto di nomina con il fornitore LLM, DPIA obbligatoria, tracciabilità di ogni invio, conservazione della versione originale in ambiente AgID-conforme.
Caso 6 — Preparazione contabile e flussi finanziari
Contesto: fatture sensibili (fatture fornitori contenenti dati salariali, fatture sanitarie in polizze salute), note spese dettagliate. Pseudonimizzazione di dati di pazienti o dipendenti prima del trattamento da un LLM SaaS per estrazione strutturata. Vedi la nostra guida automazione fatture tramite IA.
Volume tipo: 10.000-500.000 documenti al mese secondo la dimensione dell’organizzazione.
Architettura di riferimento: cosa costruiamo concretamente
Una pipeline di anonimizzazione IA in produzione si scompone in sette fasi. Ognuna ha le sue trappole.
Fase 1 — Ingestione. Il documento arriva in formato grezzo: PDF, Word, e-mail, export di base dati, immagine scannerizzata. Per documenti non testuali, OCR preliminare (Tesseract, AWS Textract in regione Milano, Doctly). In questa fase si conserva l’originale cifrato per audit.
Fase 2 — Rilevamento NER. LLM o modello dedicato identifica le entità. Output: lista strutturata {tipo, valore, offset_inizio, offset_fine}. Per documenti lunghi si segmenta in blocchi di qualche migliaio di caratteri con sovrapposizione (chunking); altrimenti i modelli mancano le entità ai bordi.
Fase 3 — Politica di sostituzione. Decisione di business, non tecnica:
- Categorie da eliminare (rimozione netta, p. es. numeri di carta in e-mail)
- Categorie da pseudonimizzare (sostituzione tramite identificatore pseudonimo stabile, p. es. nomi di persone)
- Categorie da conservare (utili all’uso a valle, p. es. date se servono all’analisi temporale)
Fase 4 — Generazione di pseudonimi. Maria Rossi → Persona_001. Lo pseudonimo deve essere stabile (la stessa persona riceve lo stesso pseudonimo in tutti i documenti) e non correlato al valore originale (nessun hash del valore — un hash è attaccabile per dizionario se il dominio è piccolo). La tabella di corrispondenza si conserva in cassaforte separata.
Fase 5 — Applicazione al testo. Sostituzione effettiva. Attenzione ai confini di parola, maiuscole/minuscole, accenti, varianti ortografiche. Una Maria Rossi può apparire più avanti come Sig.ra Rossi, M. Rossi, Dott.ssa Rossi — il NER deve collegare queste forme (risoluzione di coreferenza).
Fase 6 — Validazione. Revisione umana su campione (5-10 % all’avvio, riducibile a 1-2 % dopo stabilizzazione). Misuriamo:
- Tasso di entità mancate (recall)
- Tasso di rilevazioni false (precisione)
- Presenza di dati indirettamente identificativi residui
Fase 7 — Audit e log. Conservazione separata:
- Documento originale cifrato (in caso di contenzioso, richiesta GDPR art. 15, audit)
- Documento pseudonimizzato (per uso a valle)
- Tabella di corrispondenza (cassaforte, accesso molto ristretto)
- Log di accesso (chi ha visto cosa, quando)
Schema di produzione semplificato
[Sorgente] [Trattamento] [Destinazioni]
│ │ │
▼ ▼ ▼
PDF / e-mail ──► OCR ──► NER ──► Policy ──► Pseudo. ──► LLM SaaS / fine-tune / condivisione
│ │
└─► Audit ──┘
│
▼
Cassaforte chiave (accesso stretto)
Originale cifrato (AgID se sanità)La trappola della reidentificazione
È il test definitivo. Una pseudonimizzazione che non resiste agli attacchi per incrocio non è pseudonimizzazione utilizzabile — e il Garante lo dirà durante un’ispezione.
Tre attacchi classici
Attacco 1 — Incrocio con fonte aperta. L’attaccante dispone del Registro Imprese, dell’archivio AdEPP, di un export LinkedIn. Incrocia gli attributi rimanenti nel documento pseudonimizzato (età, città, professione, datore di lavoro) con queste fonti. Se una combinazione è unica, la reidentificazione riesce. Il famoso studio Sweeney (1997) ha mostrato che l’87 % degli individui statunitensi sono univocamente identificabili tramite codice ZIP + data di nascita + sesso — i CAP italiani danno risultati simili.
Attacco 2 — Inferenza per contesto. L’attaccante conosce il dominio. Sa che un solo direttore commerciale ha lasciato ACME S.p.A. nel marzo 2025. Deduce l’identità.
Attacco 3 — Membership inference (su LLM affinato). Un attaccante interroga un modello affinato su un corpus pseudonimizzato per indovinare se tale o tale individuo era nel corpus. Se il modello ha sovra-appreso, rivela informazioni. Il lavoro di Carlini et al. (2023) sugli attacchi di estrazione contro GPT-2 ha portato il tema nei consigli di amministrazione.
Tre difese
Difesa 1 — k-anonimato (per basi tabellari). Ogni combinazione di attributi appare almeno k volte nel dataset. Se k = 5, ogni profilo è indistinguibile da almeno altri 4. Su testo libero, trasposizione parziale tramite generalizzazione: «47 anni» → «40-50 anni», «ingegnere agronoma a Matera» → «quadro nel Sud Italia».
Difesa 2 — l-diversità e t-vicinanza. Estensioni del k-anonimato che vincolano anche la diversità dei valori sensibili in ogni gruppo. Utile quando i dati sensibili (salute, opinione) sono al cuore del dataset.
Difesa 3 — Test di reidentificazione. Più pragmatica: si tenta attivamente di reidentificare su un campione. Se ci si riesce troppo facilmente, la pseudonimizzazione è insufficiente. Questa pratica è attesa dal Garante per progetti sensibili nelle proprie Linee guida.
Nessuna delle tre protegge totalmente. Regola pratica: testare esplicitamente la robustezza prima della messa in produzione e documentare i test.
Conformità GDPR: cosa è veramente atteso
L’anonimizzazione/pseudonimizzazione tramite IA è essa stessa un trattamento automatizzato di dati personali. Dunque soggetta al GDPR. Ecco cosa registrare e cosa bisogna poter produrre in caso di ispezione.
Nel registro dei trattamenti (art. 30 GDPR)
Una scheda dedicata: «pseudonimizzazione automatizzata tramite NER per [finalità precisa]». Si registrano:
- Finalità (p. es. preparare corpus per fine-tuning, condividere con partner X, analizzare e-mail interne)
- Categorie di dati trattati (testo libero, tipi di entità rilevate)
- Persone interessate (clienti, dipendenti, pazienti secondo il caso)
- Periodo di conservazione (dell’originale, della versione pseudonimizzata, della tabella di corrispondenza — ognuno giustificato)
- Responsabili del trattamento (fornitore LLM, hosting)
- Misure tecniche e organizzative
Base giuridica
Secondo il contesto:
- Legittimo interesse (art. 6.1.f GDPR): caso più frequente per trattamenti interni, a condizione di documentare il test di bilanciamento (interesse perseguito vs diritti delle persone).
- Esecuzione di un contratto: se il trattamento deriva direttamente dall’esecuzione di un contratto con la persona.
- Obbligo legale: raro, ma possibile (risposta a richiesta GDPR art. 15, per esempio).
- Consenso: eccezionalmente, e da evitare se un’altra base è mobilizzabile — il consenso può essere revocato.
DPIA (valutazione d’impatto)
Raccomandata nella maggior parte dei casi, obbligatoria in diversi scenari elencati dal Garante:
- Volumi elevati
- Dati sensibili (salute, opinioni politiche, biometrici, giudiziari)
- Trattamento su larga scala
- Sorveglianza sistematica di lavoratori
- Incrocio di fonti
La DPIA documenta il rischio residuo dopo pseudonimizzazione, giustifica le scelte tecniche e formalizza il controllo di accesso alla chiave. È tenuta a disposizione del Garante in caso di ispezione. Vedi la nostra guida DPIA per progetti IA.
Atto di nomina con il fornitore LLM
Se utilizza un LLM SaaS, il contratto di nomina a Responsabile esterno (art. 28 GDPR) deve prevedere:
- Localizzazione del trattamento (idealmente UE — Mistral, Scaleway, Aruba Cloud)
- Divieto di usare i dati per addestrare il modello
- Periodo di conservazione di prompt e completamenti
- Sub-responsabili (hosting, backup)
- Modalità di notifica di incidente
Con un fornitore sovrano europeo, il contratto è notevolmente più semplice. Con un fornitore statunitense, diventa un dossier tecnico a sé (clausole contrattuali tipo, transfer impact assessment post-Schrems II, talvolta inutilizzabile secondo la natura dei dati — particolarmente per dati SSN o bancari vigilati).
Localizzazione del trattamento
Per dati sensibili (SSN, segreto medico, dati bancari sotto vigilanza Banca d’Italia, dati salariali), la localizzazione è un tema a sé. Tre livelli:
- Cloud sovrano (Scaleway, OVHcloud, Aruba Cloud, TIM Enterprise, Seeweb) — i dati restano nell’UE, sotto diritto europeo, senza rischio di sequestro ai sensi del Cloud Act statunitense.
- On-premise — l’IA gira sui server dell’organizzazione, zero uscita di dati. Vedi la nostra guida LLM locale in azienda.
- Cloud estero con quadro contrattuale — possibile ma con carico documentale considerevole e rischio residuo non nullo. L’EU-US Data Privacy Framework aiuta per alcuni flussi ma non copre tutti i casi.
Per la maggior parte dei casi sensibili in Italia, si mantiene o un fornitore sovrano (Mistral La Plateforme), o on-premise. È l’approccio che DPLIANCE adotta per i propri clienti, nel quadro di soluzioni IA su misura.
Ciò che rifiutiamo di promettere
Tre antipattern che vediamo regolarmente nei progetti e che evitiamo in DPLIANCE.
«Anonimizzeremo, dunque usciamo dal GDPR.» No, salvo caso molto eccezionale. La pseudonimizzazione resta sotto GDPR. Se la promessa di uscire dal GDPR è necessaria al progetto, occorre ridisegnare il progetto — non torcere il senso delle parole. Le Linee guida del Garante sono esplicite su questo.
«Il NER rileva tutto, non abbiamo bisogno di revisione umana.» Nessun NER rileva i contesti singolari, le combinazioni rare, i riferimenti impliciti. La revisione umana su campione è non negoziabile all’avvio e resta raccomandata in regime stabile.
«Conserviamo la chiave di reidentificazione, ma la blindiamo bene.» Se la chiave resta accessibile a più persone, la pseudonimizzazione diventa teorica. La pratica GDPR si attende un accesso molto ristretto, registrato, con un processo di recupero eccezionale e tracciato.
FAQ
Qual è la differenza concreta tra anonimizzazione e pseudonimizzazione secondo il GDPR?
L’anonimizzazione è irreversibile: diventa impossibile reidentificare la persona, anche incrociando con altre fonti, anche con una chiave. Il dato esce dall’ambito di applicazione del GDPR e del Codice Privacy (Considerando 26). La pseudonimizzazione, definita all’art. 4 n. 5 GDPR, è reversibile: un identificatore pseudonimo sostituisce gli identificatori diretti, ma una chiave di reidentificazione esiste altrove sotto accesso ristretto. Il dato resta personale ai sensi del GDPR. Conseguenza pratica: la maggior parte dei progetti detti «anonimizzazione IA» produce in realtà pseudonimizzazione. Gli obblighi GDPR continuano ad applicarsi (registro dei trattamenti, base giuridica, DPIA se necessaria), anche se il rischio è stato ridotto.
Il NER (riconoscimento di entità nominate) basta ad anonimizzare un testo?
No, quasi mai. Il NER rileva le entità nominate esplicite: nomi, cognomi, numeri di telefono, indirizzi, IBAN, codice fiscale, tessera sanitaria, date. Manca sistematicamente i dati indirettamente identificativi: descrizioni precise («il direttore commerciale che ha lasciato ACME S.p.A. nel marzo 2025»), combinazioni singolari (età + città + professione), riferimenti interni (numero di pratica correlato a un cliente), formulazioni contestuali. Un’anonimizzazione rigorosa richiede NER + analisi contestuale + revisione umana sui casi critici + test di robustezza alla reidentificazione — esattamente ciò che il Garante Privacy si aspetta nelle sue Linee guida sull’anonimizzazione.
Quale precisione attendersi da un NER IA nel 2026 in italiano?
Sull’italiano standard, un LLM moderno (Mistral Large, GPT-4o, Claude, ItalianBERT) rileva dal 95 al 98 % delle entità nominate esplicite con un prompt ben costruito. I modelli dedicati (spaCy it_core_news_lg, ItalianBERT del FBK, IT-BERT di Almawave, GLiNER multilingue) raggiungono dal 92 al 99 % di F1 secondo il dominio. Le prestazioni crollano fortemente su: nomi stranieri o rari, lingue miste (dialetti, tedesco in Alto Adige, francese in Valle d’Aosta), abbreviazioni di settore, riferimenti impliciti all’interno del testo. Nessun modello raggiunge il 100 % — è per questo che la revisione umana su campione resta indispensabile all’avvio.
LLM generico o modello NER dedicato?
Per la maggior parte dei casi nel 2026, un LLM generico ben promptato (Mistral, GPT-4o, Claude) basta con precisione superiore al 95 %. Il modello NER dedicato (spaCy it_core_news_lg, ItalianBERT, IT-BERT, modello affinato) diventa pertinente quando il volume è molto elevato (milioni di documenti al mese), quando la latenza è critica (triage in tempo reale nel SSN o in banche vigilate da Banca d’Italia), o quando il contesto è ultra-specializzato (terminologia clinica, giuridica). Regola semplice: partire con LLM generico per il prototipo, passare a dedicato se il costo di inferenza o le prestazioni lo giustificano.
Un dato pseudonimizzato tramite NER resta soggetto al GDPR?
Sì. Il GDPR considera un dato come personale finché la reidentificazione resta possibile — direttamente, indirettamente, per incrocio con altre fonti o tramite la chiave di pseudonimizzazione. La pseudonimizzazione riduce il rischio ma non fa uscire il dato dall’ambito GDPR. Per raggiungere una vera anonimizzazione ai sensi del GDPR, occorre distruggere la chiave, eliminare i dati indirettamente identificativi e resistere agli attacchi per incrocio. È tecnicamente molto difficile — il Garante Privacy lo ricorda esplicitamente nei propri provvedimenti.
Quali casi d’uso reggono davvero in aziende italiane?
Sei casi robusti: (1) preparare un corpus per fine-tuning di un modello interno senza rischio di leak; (2) condividere un dataset con un consulente o partner accademico tramite atto di nomina a Responsabile esterno (art. 28 GDPR); (3) rispondere a una richiesta di accesso (art. 15 GDPR) senza esporre dati di terzi; (4) analizzare corpus interni (e-mail, verbali) per finalità manageriali senza valicare la linea del controllo individuale illegittimo ai sensi dell’art. 4 dello Statuto dei Lavoratori (L. 300/1970) e delle Linee guida del Garante per posta elettronica e Internet; (5) conformità settoriale (SSN, segreto professionale medico ex Codice di Deontologia Medica, banche secondo Banca d’Italia); (6) preparazione di documenti prima di chiamare un LLM SaaS per ridurre l’esposizione.
Quali strumenti permettono anonimizzazione IA sovrana nel 2026?
LLM generici sovrani: Mistral Large via La Plateforme (Francia), Mistral on-premise tramite vLLM, hosting su provider italiani (Aruba Cloud, TIM Enterprise, Seeweb, Register.it). Modelli dedicati open-source: spaCy it_core_news_lg (eccellente rapporto prestazioni/costo per l’italiano), ItalianBERT della Fondazione Bruno Kessler, IT-BERT di Almawave, GLiNER multilingue. Microsoft Presidio è un eccellente framework open-source ma l’inferenza di default passa via OpenAI — da reindirizzare verso provider sovrano o locale. Per la massima sovranità: Mistral on-prem o Llama 3 self-hosted + spaCy interno, zero uscita di dati.
Serve una DPIA per un progetto di anonimizzazione IA?
Raccomandata nella maggior parte dei casi, obbligatoria in diversi: volumi elevati, dati sensibili (salute, opinioni, biometrici ai sensi art. 9 GDPR), trattamento su larga scala, sorveglianza sistematica di lavoratori, incrocio di fonti. La logica: l’anonimizzazione IA è essa stessa un trattamento automatizzato di dati personali, dunque soggetta al GDPR. La DPIA documenta il rischio residuo dopo pseudonimizzazione, giustifica le scelte tecniche e formalizza il controllo dell’accesso alla chiave di reidentificazione. Il Garante Privacy mantiene l’elenco dei trattamenti soggetti a DPIA sul proprio sito.
Fonti: Regolamento (UE) 2016/679 (GDPR), in particolare art. 4 n. 5 e Considerando 26; D.Lgs. 196/2003 (Codice Privacy); Linee guida WP29 sull’anonimizzazione (recepite dall’EDPB); Parere EDPB 28/2024 sugli aspetti di protezione dei dati nei modelli IA; Garante Privacy, provvedimenti e linee guida sull’anonimizzazione, sul fascicolo sanitario elettronico, sulla posta elettronica e Internet (Provv. 13.3.2007); art. 4 Statuto dei Lavoratori (L. 300/1970); documentazione ufficiale spaCy, Microsoft Presidio, GLiNER, ItalianBERT (FBK), IT-BERT (Almawave); documentazione Mistral AI La Plateforme.
Per inquadrare un progetto di anonimizzazione tramite IA nella propria organizzazione — scelta dello strumento, metodologia, pipeline, conformità — vedi la nostra guida IA conforme al GDPR, la nostra guida DPIA per progetti IA, la nostra guida LLM locale in azienda, o contattaci tramite le nostre soluzioni IA su misura.