Scenario illustrativo. Il team che costruisce il tuo agente per l’assistenza clienti chiede, con tutta la logica del mondo, «un campione di ticket reali per affinarlo». Esportano duemila conversazioni dal CRM, le mettono in una cartella condivisa e l’agente comincia a migliorare. Nessuno ha deciso nulla: è successo. E quella cartella ora contiene nomi, indirizzi e problemi di persone che non hanno mai saputo che i loro messaggi sarebbero serviti a testare un software.
La tesi in una riga: testare un agente con dati reali non è una scorciatoia tecnica, è un trattamento di dati personali con il suo rischio e il suo responsabile, e quasi sempre si può evitare o circoscrivere, al prezzo di una perdita di qualità che conviene misurare invece di ignorare.
Dati di test per agenti IA: perché «testare sul reale» è già trattare dati
L’autorità spagnola per la protezione dei dati (AEPD) lo dice senza giri di parole nel suo post sugli ambienti di sviluppo e pre-produzione (aprile 2022): i test software con dati personali «sono, o fanno parte di, trattamenti di dati personali», con tutti gli obblighi del GDPR, e dove possibile va evitato l’uso di dati personali in sviluppo, pre-produzione o qualsiasi altro ambiente di test. Aggiunge una cosa scomoda: il rischio in quegli ambienti può essere pari o superiore a quello della produzione, perché ci sono più fornitori, più copie e meno controlli.
Con un agente l’esposizione è più difficile da vedere che con un’applicazione classica. I dati di test non restano in un database: viaggiano nei prompt verso un modello di terzi, finiscono nelle tracce di osservabilità e in set di valutazione che vengono versionati e condivisi. Ogni copia è un luogo in più in cui i dati dei tuoi clienti esistono senza che nessuno li abbia contati; è lo stesso problema di cosa esce dal tuo perimetro a ogni chiamata. La regola di fondo è europea; l’applicazione concreta può variare da un’autorità nazionale all’altra.
Quali alternative ai dati reali esistono e cosa si perde con ciascuna?
Nessuna opzione è gratis. Ogni alternativa protegge qualcosa e costa qualcosa; scegliere bene significa sapere quale test si perde con ognuna.
| Alternativa | Cosa fa | Cosa si perde | Quando va bene |
|---|---|---|---|
| Anonimizzare davvero | Rimuove o trasforma i dati finché nessuno può identificare la persona, nemmeno con informazioni aggiuntive | I dettagli che rendevano reale il caso: lo storico, il filo che lega un messaggio al successivo. Farlo bene è difficile, e se si può invertire non è anonimizzazione | Dati brevi e strutturati; quasi mai testo libero lungo |
| Pseudonimizzare | Sostituisce gli identificativi con codici e conserva la chiave a parte | Quasi nessun realismo. Ma restano dati personali: le linee guida 01/2025 del Comitato europeo per la protezione dei dati ricordano che i dati pseudonimizzati restano personali se informazioni aggiuntive permettono la reidentificazione | Quando serve continuità tra i casi e controlli chi ha la chiave |
| Dati sintetici | Genera dati con la forma di quelli reali, che non corrispondono a nessuno | Le stranezze che nessuno ha pensato di simulare: il refuso, il cliente che mescola due lingue, il campo vuoto tranne il martedì | Testare flusso, formato, permessi e integrazioni |
| Casi costruiti a mano | Scritti da chi conosce il processo, a partire da schemi reali | Volume e sorpresa: trovi solo ciò che sapevi già di cercare | Casi limite e test che devono essere ripetibili |
| Dati reali circoscritti | Un sottoinsieme minimo, con decisione documentata, accesso limitato e data di cancellazione | Nessun realismo perso, ma tutto il rischio, ridotto | Solo quando il resto non basta e c’è un motivo concreto |
L’AEPD riporta questa gerarchia: i dati sintetici evitano in molti casi di trattare dati personali nei test, e i dati di test derivati da dati reali devono conservare la struttura senza contenere veri dati personali. Se non basta, chiede una decisione documentata che limiti il più possibile i dati reali usati.
Cosa non si può testare con dati finti?
Ciò che si rompe in produzione raramente è quello che avevi immaginato. Un agente testato solo su dati puliti supera esami che la produzione non pone: messaggi di tre righe senza contesto, allegati scansionati storti, il cliente che risponde a un’altra domanda. È il meccanismo di la demo che usava i tuoi casi migliori, applicato ai test.
Per questo la risposta non è «mai dati reali», ma separare cosa si testa dove. Logica, formati, integrazioni e permessi si testano con dati sintetici e casi a mano. La qualità di fronte alla varietà reale si misura dopo, in un’esecuzione in ombra in cui l’agente legge input reali ma scrive su destinazioni finte, come spiega la guida per testare le modifiche senza rompere l’automazione. Attenzione: quella copia legge dati reali, quindi resta un trattamento e richiede una propria giustificazione e propri limiti.
Quale regola pratica evita il problema fin dall’inizio?
- Parti dal sintetico e sali solo se serve. Ogni gradino verso il reale richiede una ragione scritta: quale test preciso non puoi fare senza.
- Dai all’ambiente di test i permessi di un ambiente di test. Credenziali proprie, nessun accesso alla produzione né a invii reali, come in quali permessi dare a un agente IA.
- Segui il percorso dei dati. Prompt, tracce, set di valutazione e copie del fornitore contano. Se il fornitore conserva i tuoi input di test, l’ambiente di test non è più solo tuo.
- Metti una data di cancellazione al set di test. Un set di valutazione con dati reali che nessuno rivede è un archivio di dati personali senza responsabile.
- Decide una persona con nome e cognome. Chi approva l’uso di dati reali e chi verifica periodicamente che serva ancora.
Cosa fare quando è il fornitore a chiedere un campione reale?
Succede più spesso di quanto sembri: il fornitore deve «vedere i vostri casi» per configurare l’agente. Prima di inviare qualsiasi cosa, quattro domande, per iscritto:
- A cosa serve, esattamente? Un campione per capire il formato non è un campione per addestrare né per valutare.
- Cosa ne fa il fornitore? Se lo usa per migliorare i propri modelli o per altro oltre al tuo progetto, la conversazione cambia.
- Dove viene conservato e chi può accedervi? Paese, sub-responsabili, tempo di conservazione. È la domanda di fondo di quello che il tuo fornitore non ti dice su IA e GDPR.
- Si può risolvere con dati sintetici? Quasi sempre dieci casi scritti a mano e uno schema dei campi bastano per configurare; il campione reale arriva dopo, circoscritto, e solo se serve.
Quando ha senso usare dati reali?
Quando misurare la qualità reale è l’obiettivo e il sintetico non la rappresenta. Una valutazione continua su un campione piccolo, circoscritto e con accesso limitato è difendibile, ed è il tipo di misurazione che sviluppiamo in valutare la qualità dei tuoi agenti IA e in eval: senza misurare non sai se funziona. Non è difendibile farlo per inerzia.
In quel caso l’AEPD chiede un’analisi di necessità e proporzionalità e misure di sicurezza in linea con l’articolo 32 del GDPR. In pratica sta in una pagina: perché, quanti dati, chi accede e fino a quando. E se bisogna fare debug di un guasto su dati reali senza alternative, la stessa AEPD indica cosa serve: autorizzazione del titolare, registro e audit di quell’autorizzazione e delle azioni svolte, dati minimi e accesso solo a chi ne ha bisogno.
La frase da portarsi a casa: non chiedere se il tuo agente ha superato i test, chiedi con i dati di chi li ha superati. Se la risposta è «con quelli reali» e nessuno l’ha deciso, non hai testato un agente: hai aperto un archivio.
Fonti (consultate il 20 ottobre 2026): AEPD, «Brechas de datos personales: entornos de desarrollo y preproducción» (18 aprile 2022, in spagnolo); Regolamento (UE) 2016/679, artt. 4(5) e 32; e una sintesi delle linee guida 01/2025 dell’EDPB sulla pseudonimizzazione (adottate il 16 gennaio 2025). Informazione generale, non consulenza legale.