Un cliente scrive all’indirizzo commerciale: «Cancellate i miei dati». Fino a poco tempo fa voleva dire togliere un record dal CRM e dalla lista newsletter. Se però in azienda c’è un chatbot che risponde sui documenti interni o un agente AI che ricorda le conversazioni, quei dati possono trovarsi anche in un indice vettoriale, nella memoria dell’agente, nei log delle chiamate al modello e nei backup. Il diritto alla cancellazione GDPR (art. 17) vale anche lì. Per rispettarlo servono tre cose: sapere dove finiscono i dati, poterli eliminare per identificativo in ogni archivio e intercettare le richieste ovunque arrivino. In questo articolo spiego come le progetto, con un workflow n8n concreto.
Cosa ha ribadito il Garante e perché riguarda anche l’AI
Nel parere n. 760/2026 il Garante per la protezione dei dati personali sottolinea la necessità di misure tecniche e organizzative che garantiscano l’effettivo esercizio dei diritti di rettifica e cancellazione, indipendentemente dal sistema o dal modello di intelligenza artificiale utilizzato. Tradotto: «il modello non permette di cancellare» non è una giustificazione. Se il sistema non consente di togliere un dato, il problema è nella sua progettazione.
Nella stessa comunicazione il Garante ricorda che le richieste di cancellazione sono valide anche se inviate a caselle email aziendali non dedicate. Quindi una richiesta arrivata a info@, all’indirizzo di un commerciale o all’amministrazione fa partire comunque i termini. L’art. 12 del GDPR prevede una risposta entro un mese dal ricevimento, prorogabile di due mesi nei casi complessi, comunicando la proroga entro il primo mese.
Il tema crescerà. Secondo un report OpenAI ripreso da PMI.it, tra maggio e ottobre 2026 gli utenti di agenti AI nelle PMI italiane si sono moltiplicati per 10,8. Più agenti in produzione significa più posti in cui i dati personali restano salvati.
Dove finiscono i dati personali in un RAG o in un agente AI
Prima di automatizzare qualsiasi cosa bisogna fare l’inventario. In un sistema tipico, un dato personale può trovarsi in:
- Documenti sorgente: PDF, email, ticket, contratti caricati nella base di conoscenza.
- Chunk ed embedding: i frammenti di testo e i vettori salvati nel database vettoriale. Il vettore da solo è poco leggibile, ma il chunk associato contiene il testo in chiaro.
- Memoria dell’agente: fatti estratti dalle conversazioni («il cliente Rossi preferisce essere chiamato al mattino»).
- Storico delle conversazioni e trascrizioni delle chiamate, se c’è un voice agent.
- Log e tracce di osservabilità: prompt completi, risposte, parametri dei tool chiamati.
- Cache delle risposte o dei risultati di ricerca.
- Backup di tutti i punti precedenti.
- Fornitori esterni: le API dei modelli e i servizi gestiti hanno proprie politiche di conservazione, da verificare nel contratto e nell’accordo sul trattamento dei dati.
- Modelli addestrati o fine-tuned su dati che includono persone identificabili. Togliere un dato da un modello addestrato non è un’operazione praticabile per una PMI: la regola che applico è non addestrare su dati personali.
Su come si progetta la parte documentale ho scritto in RAG per aziende: l’AI sui documenti interni, mentre per la gestione dei ricordi rimando a memoria degli agenti AI. Qui interessa un solo aspetto: ogni archivio deve permettere di trovare ed eliminare i dati di una persona.
Progettare la cancellazione fin dall’inizio
Metadati su ogni chunk e ogni ricordo
La scelta decisiva si fa in fase di indicizzazione. Ogni chunk salvato nel database vettoriale deve avere metadati come id del documento sorgente, data di inserimento e, quando possibile, id degli interessati collegati (per esempio l’id cliente del CRM). Lo stesso vale per i ricordi dell’agente. Con questi campi la cancellazione diventa una delete con filtro. Senza, bisogna cercare un nome nel testo con ricerche full-text e semantiche, sperando di non perdere varianti, refusi o soprannomi.
Rettifica: aggiornare la fonte e reindicizzare
Correggere un dato nel documento originale non corregge l’indice. Il flusso giusto è: aggiornare la fonte, eliminare i chunk derivati da quel documento, rigenerare gli embedding. Per la memoria dell’agente conviene salvare ogni fatto con la sua provenienza, così un dato corretto nel CRM può invalidare automaticamente il ricordo vecchio, invece di convivere con quello nuovo.
Backup e lista di soppressione
Riscrivere i backup per togliere un singolo record di solito non è realistico. La pratica che adotto è documentare la retention dei backup (dopo quanti giorni vengono sovrascritti) e tenere una lista di soppressione: un elenco minimo di identificativi cancellati che viene applicato dopo ogni ripristino, perché un restore non reintroduca dati già eliminati. La lista va limitata al minimo indispensabile per funzionare.
Log e tracce con scadenza
I log degli agenti servono per il debug e per ricostruire gli incidenti, ma non devono conservare prompt completi per sempre. Imposto una retention breve sui contenuti, mascherando email e numeri di telefono dove possibile, e tengo più a lungo solo i metadati delle azioni (chi, cosa, quando).
Il workflow n8n per intercettare le richieste in qualsiasi casella
Visto che una richiesta può arrivare a qualunque indirizzo aziendale, serve un sistema che le riconosca. Con n8n la struttura che uso è questa:
- Raccolta: trigger IMAP sulle caselle principali, oppure una regola di inoltro in copia da tutte le caselle verso un indirizzo di servizio. Si aggiungono i moduli web e, se presenti, i canali di chat.
- Classificazione: un modello linguistico legge il messaggio e risponde con un JSON strutturato: è una richiesta di esercizio dei diritti? Di che tipo (accesso, rettifica, cancellazione, opposizione)? Quali identificativi contiene? Il prompt va tarato per non perdere richieste: meglio un falso positivo da scartare che una richiesta ignorata. Siccome anche questo passaggio tratta dati personali, valuto un modello self-hosted o un fornitore con condizioni chiare.
- Apertura pratica: creazione di un ticket con data di ricevimento, scadenza calcolata a un mese e promemoria automatici prima della scadenza.
- Verifica dell’identità: una persona controlla che il richiedente sia davvero l’interessato. Questo passaggio resta umano, come spiego in human-in-the-loop negli agenti AI.
- Propagazione: dopo l’approvazione, il workflow chiama le API dei sistemi coinvolti: CRM, piattaforma email, delete con filtro sul database vettoriale, cancellazione dei ricordi dell’agente e dello storico conversazioni, inserimento nella lista di soppressione.
- Verifica: una nuova ricerca per identificativo in ogni archivio deve restituire zero risultati. Se un sistema fallisce, il ticket resta aperto.
- Risposta e registro: invio della conferma all’interessato con un modello approvato e registrazione delle azioni svolte, utile in caso di verifica.
Per i dettagli su come strutturo i flussi rimando a automazione dei flussi di lavoro con n8n.
Cosa non va automatizzato
Non tutto deve essere automatico. La valutazione sulle eccezioni resta a una persona, con il supporto del DPO o del consulente privacy. Per esempio, quando la conservazione è imposta da obblighi di legge: le fatture vanno tenute per i termini previsti dalla normativa fiscale. Lo stesso vale per la risposta in casi ambigui e per le richieste che arrivano da avvocati o da terzi. L’automazione serve a non perdere richieste e a eseguire la cancellazione in modo completo, non a decidere al posto dell’azienda.
Checklist operativa
- Inventario scritto di tutti gli archivi in cui un agente o un RAG salva dati.
- Metadati con id documento e id interessato su chunk e ricordi.
- Procedura di reindicizzazione per le rettifiche.
- Retention definita per log, conversazioni e backup.
- Lista di soppressione applicata dopo i ripristini.
- Intercettazione delle richieste su tutte le caselle, con scadenze tracciate.
- Test periodico: una cancellazione di prova su un interessato fittizio, da verificare in ogni archivio.
Domande frequenti
Cancellare il documento sorgente basta a rispettare la richiesta?
No. I chunk e gli embedding derivati restano nel database vettoriale finché non vengono eliminati esplicitamente, e possono continuare a comparire nelle risposte del chatbot. Bisogna cancellare anche i chunk collegati, le cache e i ricordi dell’agente.
Si può togliere un dato da un modello già addestrato?
In pratica, per una PMI, no. Per questo i dati personali vanno tenuti fuori dall’addestramento e gestiti tramite RAG, dove la cancellazione è un’operazione sul database.
Una richiesta arrivata alla mail di un commerciale è valida?
Sì: il Garante ha ricordato che le richieste di cancellazione valgono anche se inviate a email aziendali non dedicate. Per questo conviene monitorare tutte le caselle, non solo quella indicata nell’informativa.
Il workflow n8n sostituisce il DPO?
No. Automatizza raccolta, scadenze ed esecuzione tecnica. Le valutazioni giuridiche, come le eccezioni per obblighi di conservazione, restano a chi ha la competenza per farle.
Se in azienda hai già un chatbot, un agente AI o una base di conoscenza interna e non sai dove finiscono i dati dei clienti, il punto di partenza è l’inventario degli archivi, seguito dal workflow che li collega. Posso aiutarti a progettare entrambi e a integrarli con CRM e caselle email esistenti: contattami qui per parlarne.
