Una guida Sluis per i team privacy, sicurezza e piattaforma. Ultima verifica: 23 settembre 2026.
Ogni prompt che arriva a un fornitore di IA è una comunicazione di dati. Questa guida spiega quali dati personali finiscono tipicamente nei prompt, quanto bene ciascun metodo di rilevamento li rimuove, che cosa ottiene la sostituzione con segnaposto secondo il diritto UE dopo la sentenza della Corte di giustizia del settembre 2025 e che cosa devi comunque fare anche quando la redazione funziona.
In breve
- Il pattern matching intercetta gli identificativi strutturati: indirizzi e-mail, numeri di telefono, IBAN, numeri di carta, numeri di identificazione nazionali, chiavi API. Nel nostro test ha rimosso il 57% dei dettagli personali annotati. Nomi e descrizioni sono ciò che gli sfugge.
- Un modello addestrato per il riconoscimento di entità colma gran parte di questo divario. Nello stesso test ha portato la rimozione al 98,7%, al costo di circa mezzo secondo per segmento di testo.
- Sostituire gli identificativi con segnaposto può far sì che il testo non sia più un dato personale per il fornitore di IA. La Corte di giustizia lo ha confermato in GEPD/CRU, ma solo dove il fornitore non ha alcun modo realistico di reidentificare la persona, anche combinando più dettagli.
- Per te i dati restano dati personali e devi comunque informare le persone che vengono inviati al fornitore di IA. La Corte ha valutato questo obbligo dal punto di vista del titolare del trattamento, nel momento in cui i dati sono raccolti.
- Controlla l'impostazione predefinita di conservazione nel contratto, non sulla pagina di marketing. Diversi grandi fornitori hanno cambiato le proprie impostazioni predefinite negli ultimi dodici mesi.
Che cosa finisce nei prompt
Ciò che i dipendenti incollano negli strumenti di IA segue il lavoro che svolgono. Le stesse categorie compaiono in quasi ogni organizzazione:
| Dati | Esempio | Che cosa li rileva |
|---|---|---|
| Identificativi strutturati | jan.devries@example.nl, NL91 ABNA 0417 1643 00, +31 6 1234 5678 | Pattern e checksum, in modo molto affidabile |
| Credenziali | Chiavi API, token di accesso, stringhe di connessione nei log incollati | Pattern e controlli di entropia |
| Nomi di persone | "Rispondi a Marieke sul suo rimborso" | Dizionari per i nomi comuni; un modello addestrato per il resto |
| Organizzazioni e luoghi | Nomi di aziende, indirizzi, città | Dizionari più un modello addestrato |
| Categorie particolari di dati | "È in malattia per burn-out da maggio" | Il contesto. Nessun rilevatore è affidabile qui: serve una regola d'uso |
| Combinazioni identificanti | "La nostra unica socia della sede di Eindhoven" | Nulla di affidabile. A identificare è la combinazione, non una singola parola |
Le ultime due righe sono le più importanti. Un rilevatore trova valori; non capisce che un ruolo, un luogo e una data insieme indicano una sola persona. Questi casi si gestiscono meglio con una policy: alcuni compiti non dovrebbero andare a un modello esterno.
Quanto funziona il rilevamento: la nostra misurazione
Abbiamo misurato tre configurazioni di rilevamento nel nostro gateway su 105 casi di test sintetici tenuti fuori dall'addestramento (non 105 documenti indipendenti), con 372 dettagli annotati per configurazione. Se ciascun dettaglio fosse stato rimosso nel suo contesto lo ha giudicato il valutatore del benchmark, un modello linguistico separato, non una revisione umana.
| Configurazione | Che cosa viene eseguito | Dettagli rimossi | Percentuale |
|---|---|---|---|
| Solo pattern | Espressioni regolari, checksum, regole di contesto, elenco di nomi e dizionari | 211 su 372 | 56,7% |
| Pattern e modello leggero | Quanto sopra più un piccolo modello multilingue di riconoscimento di entità | 299 su 372 | 80,4% |
| Pattern e modello PII | Quanto sopra con un modello addestrato specificamente per i dati personali | 367 su 372 | 98,7% |
| Modello PII e revisione LLM | Quanto sopra più una revisione facoltativa da parte di un modello linguistico ospitato | 371 su 372 | 99,7% |
Misurato il 15 settembre 2026. Due cose da tenere presenti quando usi questi numeri:
- Misurano quanti dettagli annotati sono stati rimossi nel contesto. Non misurano se un intero documento è diventato anonimo. Basta un dettaglio sfuggito per identificare qualcuno.
- Sono misurazioni della nostra pipeline sul nostro set di test sintetico. Non abbiamo eseguito prodotti di altri fornitori sugli stessi casi di test. Esegui un test simile su 50 dei tuoi documenti prima di fidarti della cifra di qualsiasi fornitore, compresa la nostra.
Quanto costa
| Livello | Tempo mediano per chiamata | Più lenta su 30 chiamate |
|---|---|---|
| Modello leggero | 3,5 ms | 4,0 ms |
| Modello PII | 521,5 ms | 549,6 ms |
Misurato il 14 settembre 2026 su un testo multilingue di 919 caratteri, in-process, esclusi i tempi di rete. Per un assistente chat, mezzo secondo prima che il modello inizi a rispondere di solito è accettabile. Per un'API ad alto volume con obiettivi di latenza stretti è una scelta di progetto.
Anche il recall ha un costo in precisione. Le regole aggressive rimuovono cose che non sono dati personali. Una regola che tratta ogni parola maiuscola sconosciuta come un possibile nome rimuoverà anche nomi di prodotti, codici di progetto e nomi di modelli, e le risposte possono peggiorare. Per questo forniamo quella regola disattivata. Misura i falsi positivi sui tuoi documenti insieme al recall.
Fail closed
Decidi che cosa succede quando il rilevamento fallisce: un modello va in timeout, un documento non può essere analizzato, un tipo di file è sconosciuto. Una pipeline che fa fail open invia il testo non redatto. Una pipeline che fa fail closed blocca la richiesta. Per i dati personali, scegli fail closed. Questa singola impostazione conta più della scelta del modello.
Segnaposto invece della cancellazione
Cancellare i dati personali rende inutili molti prompt: "Scrivi una risposta a [rimosso] sul rimborso di EUR 40 a [rimosso]" non dà al modello nulla su cui lavorare. Sostituirli conserva la struttura:
Scrivi una risposta a «PERSON_NAME_1» sul rimborso di EUR 40 a «IBAN_1».
Il gateway conserva la corrispondenza tra «PERSON_NAME_1» e il nome reale, invia al fornitore solo il segnaposto e ripristina i valori reali nella risposta prima che arrivi all'utente. Due dettagli lo fanno funzionare nella pratica:
- Coerenza. La stessa persona riceve lo stesso segnaposto per tutta la conversazione, così il modello può seguire chi è chi.
- Informazione sul tipo. «PERSON_NAME_1» e «IBAN_1» dicono al modello che tipo di valore c'era, e questo mantiene le risposte grammaticali e utili.
Che cosa dice la legge
La Corte di giustizia: GEPD/CRU, 4 settembre 2025
La causa (C-413/23 P) riguardava il Comitato di risoluzione unico (CRU), che aveva sostituito i nomi delle persone che avevano presentato osservazioni con codici di 33 cifre generati casualmente, aveva conservato la tabella che collega i codici ai nomi e aveva trasmesso 1.104 osservazioni a Deloitte. La Corte ha statuito:
- Le opinioni sono dati personali riguardanti il loro autore (punti da 58 a 60). Il testo che il tuo personale scrive in un prompt è, di norma, un dato personale che lo riguarda.
- I dati pseudonimizzati non sono automaticamente dati personali per tutti. L'esistenza di una tabella di corrispondenza fa sì che i dati pseudonimizzati non possano mai essere considerati anonimi in ogni caso (punto 73). Ma la pseudonimizzazione "può, a seconda delle circostanze del caso di specie, effettivamente impedire a persone diverse dal titolare del trattamento di identificare l'interessato in modo tale che, per esse, quest'ultimo non sia o non sia più identificabile" (punto 86).
- Per il destinatario, ciò dipende da due condizioni (punto 77): il destinatario non può revocare la pseudonimizzazione e non può identificare la persona "anche mediante il ricorso ad altri mezzi di identificazione, quali una sovrapposizione con altri elementi".
- Il tuo obbligo di informazione non cambia. L'obbligo di dire alle persone che i loro dati sarebbero stati comunicati a un destinatario si valuta dal punto di vista del titolare del trattamento, al momento della raccolta (punti 111 e 112). Ciò che il destinatario può o non può identificare in seguito è irrilevante per questo obbligo.
Applicato ai prompt:
| Prompt inviato al fornitore | Identificabile per il fornitore? | Perché |
|---|---|---|
| "Rimborso per «PERSON_NAME_1», IBAN «IBAN_1», ordine 48213" | Probabilmente no | Il numero d'ordine non significa nulla per il fornitore e la corrispondenza resta presso di te |
| "«PERSON_NAME_1», la nostra unica socia a Eindhoven, è in malattia" | Sì | La descrizione la identifica senza un nome e rivela dati sulla salute |
| Uno stack trace che contiene l'indirizzo e-mail di un cliente | Sì | L'identificativo non è stato rilevato, quindi è stato inviato in chiaro |
Le linee guida dell'EDPB sono ancora una bozza
Le Linee guida 01/2025 sulla pseudonimizzazione dell'EDPB (Comitato europeo per la protezione dei dati) sono state pubblicate per la consultazione a gennaio 2025; la consultazione si è chiusa il 14 marzo 2025. Non abbiamo trovato una versione definitiva. La bozza sostiene che i dati pseudonimizzati restano dati personali quando possono essere attribuiti mediante informazioni aggiuntive. È precedente alla sentenza e non è ancora chiaro come il testo finale la recepirà.
In pratica: tratta i prompt come dati personali nei tuoi registri e nella tua DPIA; usa le due condizioni della sentenza per valutare la posizione del fornitore; e metti per iscritto il tuo ragionamento.
Che cosa devi comunque fare
- Indica il fornitore di IA come destinatario nell'informativa sulla privacy, oppure la categoria di destinatari, come chiarisce il punto 111 della sentenza.
- Svolgi una DPIA dove l'uso può presentare un rischio elevato, ad esempio per dati HR, sanitari o di clienti su larga scala.
- Tieni un registro dei trattamenti che includa il fornitore di IA come responsabile del trattamento o destinatario.
- Verifica la posizione sui trasferimenti se il fornitore o la sua capogruppo si trova fuori dall'UE. La nostra guida sull'esposizione al CLOUD Act lo affronta.
Che cosa conservano i fornitori
Le impostazioni predefinite di conservazione sono cambiate più volte nell'ultimo anno. Le posizioni qui sotto sono quelle dichiarate dai fornitori in annunci e pagine di assistenza; confermale rispetto ai termini che firmi davvero.
| Fornitore | Impostazione predefinita per i clienti API, come dichiarata | Che cosa chiedere |
|---|---|---|
| OpenAI | Contenuti non usati per l'addestramento per impostazione predefinita per i clienti business. Zero data retention disponibile per i clienti API idonei, ribadita ad agosto 2026 | Zero data retention nel tuo accordo e se i tuoi endpoint sono idonei |
| Anthropic | Log API conservati per 7 giorni da settembre 2025. Accordi di zero data retention per i clienti enterprise idonei. Uno schema di conservazione di 30 giorni per i suoi modelli più capaci, con la possibilità di tenere i dati nel proprio cloud, annunciato per l'autunno 2026 | Quale conservazione si applica ai modelli che usi e l'accordo di zero retention |
L'ordinanza del tribunale nel caso del New York Times che imponeva a OpenAI di conservare a tempo indeterminato i log degli output di ChatGPT è stata revocata a ottobre 2025, con eccezioni per i log già conservati e gli account segnalati nel caso. Viene ancora citata come rischio attuale; non è più un obbligo senza limiti di tempo.
Checklist
- Casi d'uso mappati sui dati che inseriscono nei prompt
- Compiti che non devono mai andare a un modello esterno definiti nella policy sull'uso dell'IA
- Livelli di rilevamento scelti per ogni caso d'uso, con un modello addestrato ovunque compaiano nomi
- La pipeline fa fail closed quando il rilevamento dà errore o va in timeout
- Recall e falsi positivi misurati su almeno 50 dei tuoi documenti
- Segnaposto usati al posto della cancellazione, coerenti all'interno di una conversazione
- L'informativa sulla privacy indica il fornitore di IA o la categoria di destinatari
- DPIA completata per gli usi ad alto rischio
- Impostazioni di conservazione e di addestramento del fornitore confermate nei termini firmati
Fonti
- Corte di giustizia dell'Unione europea, GEPD/CRU, causa C-413/23 P, sentenza del 4 settembre 2025, punti da 23 a 28, da 58 a 60, da 72 a 77, 85, 86, 111 e 112
- Comitato europeo per la protezione dei dati, Guidelines 01/2025 on Pseudonymisation, versione in consultazione, periodo di osservazioni dal 17 gennaio al 14 marzo 2025
- OpenAI, Offering Zero Data Retention for frontier models, 19 agosto 2026
- Anthropic, documentazione su API e conservazione dei dati
- La revoca dell'ordinanza di conservazione nel caso del New York Times (ordinanza del 9 ottobre 2025) e lo schema di conservazione di Anthropic per l'autunno 2026 provengono da notizie di stampa, tra cui Engadget e CNBC.
- Cifre di rilevamento e latenza: misurazioni Sluis del 15 e del 14 settembre 2026. Il metodo è descritto nella documentazione Sluis sulla protezione dei dati.