Pseudonimizzazione e modelli linguistici: usare l'AI senza esporre dati personali

Risposta breve

La pseudonimizzazione dei dati, prima di inviare un testo a un LLM (Large Language Model) esterno, sostituisce nomi, codici fiscali, IBAN e altri identificativi con segnaposto reversibili; la tabella di corrispondenza resta in azienda. Riduce l’esposizione, ma per il GDPR i dati restano personali per chi conserva la chiave. Va affiancata da minimizzazione, contratto con il fornitore, elaborazione nell’UE, modelli locali per i dati sensibili e DPIA (Data Protection Impact Assessment).

Il problema: il testo intero esce dall’azienda

Un LLM (modello linguistico di grandi dimensioni) lavora sul testo che riceve. Per classificare una email, riassumere un contratto o preparare una risposta a un reclamo, l’applicazione invia al modello il documento, spesso per intero. Se il modello è erogato in cloud da un fornitore terzo, quel testo lascia il perimetro aziendale.

Nella posta di un ufficio amministrativo o di un help desk i dati personali sono ovunque: nomi, indirizzi, codici fiscali, partite IVA di ditte individuali, IBAN, certificati medici allegati a una richiesta di permesso. Un agente AI che automatizza il back office tratta questi dati per costruzione.

Le autorità guardano con attenzione a questi flussi. A dicembre 2024 il Garante per la protezione dei dati personali ha sanzionato OpenAI per 15 milioni di euro, contestando tra l’altro la base giuridica del trattamento, la trasparenza verso gli utenti e una violazione di dati non notificata (provvedimento comunicato il 20/12/2024) (Garante privacy, 2024). Il Tribunale di Roma, con sentenza n. 4785 del 18/03/2026, ha poi annullato la sanzione per un motivo di competenza: secondo il giudice il caso spettava all’autorità irlandese, in base al meccanismo dello sportello unico. Il merito non è stato esaminato (Diritto.it, 2026).

Per un’azienda che usa questi servizi la domanda pratica è un’altra: quali dati è davvero necessario mandare al modello?

Pseudonimizzazione e anonimizzazione: cosa dice il GDPR

I due termini vengono spesso confusi. Il GDPR li distingue con precisione.

Pseudonimizzazione (art. 4, punto 5, GDPR). È un trattamento che impedisce di attribuire i dati a una persona specifica senza usare informazioni aggiuntive. Queste informazioni devono essere conservate separatamente e protette da misure tecniche e organizzative. In pratica: “Mario Rossi” diventa “PERSONA_1”, e la tabella che collega i due valori resta in un luogo sicuro.

Anonimizzazione (considerando 26). Un dato è anonimo quando la persona non è più identificabile con mezzi ragionevolmente utilizzabili, tenendo conto di costi, tempo e tecnologia disponibile. I dati anonimi escono dall’ambito del GDPR. Lo stesso considerando precisa che i dati pseudonimizzati, se attribuibili a una persona con informazioni aggiuntive, vanno considerati informazioni su persona identificabile.

La conseguenza è netta. Per chi conserva la tabella di corrispondenza, i dati pseudonimizzati restano dati personali. L’azienda che sostituisce i nomi prima di chiamare il modello e li reinserisce al ritorno continua a trattare dati personali, con tutti gli obblighi connessi.

Una sentenza recente aggiunge una sfumatura. Con la decisione del 4 settembre 2025 nella causa C-413/23 P, EDPS (European Data Protection Supervisor) contro SRB (Single Resolution Board), la Corte di giustizia UE ha chiarito che i dati pseudonimizzati non sono automaticamente personali per ogni soggetto che li riceve. Occorre valutare se quel destinatario dispone di mezzi ragionevoli per reidentificare le persone (Jones Day, 2025). Per il titolare che conserva la chiave, però, nulla cambia. E gli obblighi di informativa si valutano dal suo punto di vista, al momento della raccolta.

Anche il Comitato europeo per la protezione dei dati (EDPB) ha dedicato alla materia le linee guida 01/2025, pubblicate in versione per la consultazione pubblica a gennaio 2025 (EDPB, 2025). Il documento tratta la pseudonimizzazione come misura di sicurezza e di minimizzazione, non come via d’uscita dal regolamento.

Quando il processo è reversibile, quindi, si parla di pseudonimizzazione: chiamarlo “anonimizzazione” crea aspettative sbagliate, anche nei contratti.

Come funziona la pseudonimizzazione dei dati con segnaposto reversibili

Lo schema tipico ha quattro passaggi. Si colloca nella pipeline, cioè la sequenza di elaborazioni che il testo attraversa prima e dopo la chiamata al modello.

1. Rilevamento delle entità. Un componente locale individua nel testo i dati identificativi. Le tecniche si combinano: espressioni regolari per i formati fissi, modelli di riconoscimento delle entità per nomi, luoghi e organizzazioni, dizionari per anagrafiche note (clienti, dipendenti, fornitori).
2. Sostituzione. Ogni entità viene sostituita da un segnaposto coerente: PERSONA_1, CF_1, IBAN_1. La coerenza conta: se lo stesso nome compare tre volte, deve diventare sempre lo stesso segnaposto, altrimenti il modello perde il filo.
3. Mappatura interna. La tabella che collega segnaposto e valori originali resta nel sistema dell’azienda, cifrata, con accessi limitati e una durata definita.
4. Reidentificazione al ritorno. La risposta del modello contiene i segnaposto. Il componente locale li sostituisce con i valori originali prima di passare il risultato all’operatore o al sistema gestionale.

Per i testi italiani alcuni identificativi hanno strutture riconoscibili e vanno gestiti esplicitamente:

I controlli formali riducono i falsi positivi: un numero di 11 cifre non è sempre una partita IVA.

Un esempio. L’email “Sono Giulia Bianchi, CF BNCGLI80A41F205X, vi chiedo il rimborso sull’IBAN IT60X0542811101000000123456” arriva al modello come “Sono PERSONA_1, CF CF_1, vi chiedo il rimborso sull’IBAN IBAN_1”. Il modello può classificare la richiesta e preparare una bozza senza conoscere il nome. (I dati dell’esempio sono fittizi.)

I rischi che restano

Sostituire i campi strutturati è la parte facile.

Testo libero. Un modello di riconoscimento delle entità non è infallibile. Un cognome che è anche un nome comune, un soprannome, un indirizzo scritto in modo irregolare possono sfuggire. La copertura va misurata su campioni reali, non presunta.

Identificatori indiretti. “Il responsabile acquisti della nostra filiale di Avellino” non contiene nomi, ma in un’azienda di medie dimensioni identifica una persona. Lo stesso vale per combinazioni di età, ruolo, data e luogo.

Reidentificazione dal contesto. Una lettera che descrive un incidente stradale con data e incrocio precisi può essere collegata a una persona tramite fonti pubbliche.

Categorie particolari. Una diagnosi o un’appartenenza sindacale citata nel corpo di un messaggio resta un dato sensibile anche se il nome è stato sostituito.

Allegati e metadati. PDF scansionati, firme in calce, proprietà dei documenti: spesso finiscono nella chiamata al modello senza passare dal filtro.

La pseudonimizzazione, quindi, riduce il rischio ma non lo azzera, e va descritta così anche nelle valutazioni interne.

Le misure complementari

La pseudonimizzazione è una misura tecnica coerente con l’art. 25 (protezione dei dati fin dalla progettazione) e con l’art. 32 (sicurezza del trattamento) del GDPR. Va affiancata da altre misure.

• Minimizzazione. Prima di sostituire, togliere. Se per classificare un’email bastano oggetto e prime righe, non serve inviare la conversazione intera né gli allegati.
• Modelli on-premise per i dati più delicati. On-premise significa installato su server dell’azienda o in un data center controllato, senza invio a terzi. Per categorie particolari (salute, dati giudiziari, dati sindacali) un modello locale è spesso la scelta più prudente. Il confronto tra le due opzioni è approfondito in LLM on-premise o in cloud?.
• Contratto e DPA (Data Processing Agreement). Il fornitore del modello agisce di norma come responsabile del trattamento ai sensi dell’art. 28. Serve un accordo sul trattamento dei dati (DPA) che definisca finalità, sub-responsabili, misure di sicurezza, cancellazione.
• Clausole di non addestramento. Verificare per iscritto che i dati non siano usati per addestrare i modelli e per quanto vengano conservati.
• Elaborazione nell’UE. Preferire servizi con elaborazione e conservazione in territorio UE. Se ci sono trasferimenti verso paesi terzi, verificare la base del trasferimento.
• DPIA. La valutazione d’impatto (art. 35) è richiesta quando il trattamento presenta un rischio elevato. Uso di nuove tecnologie, grandi volumi o categorie particolari sono indizi forti in questo senso.
• Tracciabilità. Registrare quali dati sono stati inviati, a quale modello, con quale esito. Il tema è trattato in Un registro di audit per l’AI.

Un’impostazione di questo tipo è descritta nella pagina Privacy by design e, per l’infrastruttura, in Architettura. Gli obblighi dell’AI Act sono riassunti in AI Act: cosa cambia per chi usa agenti AI nei processi aziendali, scadenza per scadenza.

Checklist per il DPO

Una traccia per il DPO (Data Protection Officer), da usare quando un’area aziendale propone di collegare un LLM esterno a un processo.

1. Finalità e base giuridica. Il trattamento tramite modello rientra in una finalità già dichiarata? L’informativa va aggiornata?
2. Inventario dei dati. Quali tipi di dati contengono i testi? Ci sono categorie particolari o dati giudiziari?
3. Minimizzazione. Quali parti del testo sono davvero necessarie al compito? Gli allegati vengono esclusi o filtrati?
4. Pseudonimizzazione. Quali entità vengono rilevate? Come sono gestiti codice fiscale, partita IVA, IBAN? Qual è il tasso di entità non rilevate su un campione reale?
5. Gestione della chiave. Dove risiede la tabella di corrispondenza? È cifrata? Chi vi accede? Per quanto viene conservata?
6. Fornitore. C’è un DPA ai sensi dell’art. 28? Sono elencati i sub-responsabili? Esiste una clausola di non addestramento?
7. Luogo di elaborazione. Dove vengono elaborati e conservati i dati? Ci sono trasferimenti extra UE e con quale garanzia?
8. Alternativa locale. Per i dati più delicati è stato valutato un modello on-premise?
9. DPIA. È stata fatta o motivatamente esclusa? È documentata?
10. Controllo umano e registro. Chi verifica gli output prima che producano effetti? Le chiamate al modello sono tracciate?
11. Gestione degli incidenti. La procedura di data breach copre anche il fornitore del modello?
12. Revisione periodica. Quando si ripetono i test di copertura e la verifica del contratto?

Da ricordare

• Inviare un testo a un LLM esterno significa comunicare a terzi tutti i dati personali che contiene.
• La pseudonimizzazione è reversibile: per chi conserva la chiave i dati restano personali e il GDPR si applica per intero.
• L’anonimizzazione richiede che la reidentificazione non sia ragionevolmente possibile: un caso raro nei testi aziendali.
• I campi strutturati italiani (codice fiscale, partita IVA, IBAN) si gestiscono bene con controlli formali; il testo libero e il contesto sono il vero punto debole.
• La pseudonimizzazione va combinata con minimizzazione, contratti, elaborazione nell’UE, modelli locali per i dati sensibili e DPIA.

Domande frequenti

I dati pseudonimizzati sono ancora dati personali per il GDPR?

Sì, per chi conserva le informazioni aggiuntive che permettono di ricollegarli alle persone. Il considerando 26 del GDPR stabilisce che i dati pseudonimizzati, se attribuibili a una persona con informazioni aggiuntive, restano informazioni su una persona identificabile. Un’azienda che sostituisce i nomi con segnaposto prima di chiamare un modello linguistico e li reinserisce al ritorno continua quindi a trattare dati personali, con tutti gli obblighi del regolamento.

Qual è la differenza tra dati pseudonimizzati e dati anonimi?

I dati pseudonimizzati non sono attribuibili a una persona senza informazioni aggiuntive, che però esistono e sono conservate separatamente: il processo è reversibile e il GDPR si applica. I dati anonimi, invece, non permettono di identificare la persona con mezzi ragionevolmente utilizzabili, tenendo conto di costi, tempo e tecnologia disponibile, e per questo escono dall’ambito del GDPR. Nei testi aziendali l’anonimizzazione vera è rara.

Come si usa un modello linguistico esterno in azienda rispettando il GDPR?

Si parte dalla minimizzazione, inviando al modello solo le parti di testo necessarie al compito. Si pseudonimizzano gli identificativi, si firma con il fornitore un accordo sul trattamento ai sensi dell’art. 28 con clausola di non addestramento, si preferisce l’elaborazione nell’UE e si valuta un modello installato in locale per i dati più delicati. Si verifica se serve una valutazione d’impatto e si tracciano le chiamate al modello.

Come si pseudonimizzano codice fiscale, partita IVA e IBAN in un testo?

Questi identificativi hanno strutture fisse e si rilevano con espressioni regolari, controllando i caratteri di verifica per ridurre i falsi positivi: il carattere finale del codice fiscale, gestendo l’omocodia; la cifra di controllo delle 11 cifre della partita IVA; il controllo modulo 97 dell’IBAN italiano di 27 caratteri. Ogni valore diventa un segnaposto coerente, come CF_1 o IBAN_1, e la tabella di corrispondenza resta cifrata nei sistemi dell’azienda.

Cosa ha stabilito la Corte di giustizia UE nella causa EDPS contro SRB sui dati pseudonimizzati?

Con la sentenza del 4 settembre 2025, causa C-413/23 P, la Corte di giustizia UE ha chiarito che i dati pseudonimizzati non sono automaticamente dati personali per ogni soggetto che li riceve: occorre valutare se quel destinatario dispone di mezzi ragionevoli per reidentificare le persone. Per il titolare che conserva la chiave non cambia nulla, e gli obblighi di informativa si valutano dal suo punto di vista al momento della raccolta.

Serve una DPIA per collegare un LLM a un processo aziendale?

La valutazione d’impatto prevista dall’art. 35 del GDPR è obbligatoria quando il trattamento presenta un rischio elevato per i diritti delle persone. L’uso di nuove tecnologie, grandi volumi di dati o categorie particolari come salute e dati sindacali sono indizi forti in questo senso. Se la valutazione viene esclusa, conviene documentarne i motivi, così da poter dimostrare la scelta in caso di verifica.

Bibliografia e fonti

1. Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali (GDPR), art. 4(5), 25, 28, 32, 35 e considerando 26, EUR-Lex, Gazzetta ufficiale dell’Unione europea L 119, 27/04/2016 (pubblicato il 04/05/2016). https://eur-lex.europa.eu/eli/reg/2016/679/oj, consultato il 10/10/2026.
2. Garante per la protezione dei dati personali, ChatGPT, il Garante privacy chiude l’istruttoria. OpenAI dovrà realizzare una campagna informativa di sei mesi e pagare una sanzione di 15 milioni di euro (comunicato stampa, docweb 10085432), garanteprivacy.it, 20/12/2024. https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10085432, consultato il 10/10/2026.
3. Lorena Papini, OpenAI vince contro il Garante privacy: perché il Tribunale di Roma ha annullato la sanzione da 15 milioni (commento alla sentenza del Tribunale di Roma n. 4785 del 18/03/2026), Diritto.it, 03/06/2026. https://www.diritto.it/?p=249907, consultato il 10/10/2026.
4. Jones Day (J. Hladjk, O. Haas, M. A. Myers, M. F. Paez, U. von Diemar), CJEU Clarifies Scope of Personal Data in EDPS v SRB Decision (commento alla sentenza del 04/09/2025, causa C-413/23 P), jonesday.com, settembre 2025. https://www.jonesday.com/es/insights/2025/09/cjeu-clarifies-scope-of-personal-data-in-edps-v-srb-decision, consultato il 10/10/2026.
5. Comitato europeo per la protezione dei dati (EDPB), Guidelines 01/2025 on Pseudonymisation (versione per la consultazione pubblica, 17/01/2025 - 14/03/2025), edpb.europa.eu, gennaio 2025. https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en, consultato il 10/10/2026.

Approfondisci

• LLM on-premise o in cloud? Guida alla scelta per le imprese: i criteri per scegliere dove far girare il modello in base alla sensibilità dei dati.
• Un registro di audit per l’AI: perché la tracciabilità è un requisito di prodotto: cosa registrare quando un agente AI invia dati a un modello e come conciliarlo con il GDPR.
• AI Act: cosa cambia per chi usa agenti AI nei processi aziendali, scadenza per scadenza: gli obblighi del regolamento europeo sull’intelligenza artificiale per chi usa agenti AI.
• Privacy by design negli agenti AI: l’approccio alla protezione dei dati fin dalla progettazione.
• Architettura della piattaforma: modelli in cloud e in locale: come è organizzata l’infrastruttura.

Questo articolo ha finalità informative e non costituisce consulenza legale.