Le revisioni di sicurezza aziendale ormai includono una domanda che blocca rapidamente le trattative: quanto tempo serve per cancellare i dati di un utente da memoria, embeddings e log del vostro agente IA e potete dimostrare che l’operazione è avvenuta? La risposta è spesso “non lo sappiamo”, perché la maggior parte delle startup non ha ancora costruito un meccanismo di cancellazione prima che la domanda venga posta.

Il contesto normativo: l’articolo 17 del GDPR

Il diritto alla cancellazione (articolo 17 del GDPR) non si limita ai dati di input grezzi, ma si estende anche a tutti gli output degli agenti IA e alle derivazioni create durante il training, come le embeddings e i pesi finemente aggiustati. La normativa è vigente dal 2018, ma il gap operativo è emerso solo di recente, quando le grandi imprese hanno iniziato a richiedere evidenze pratiche nei loro accordi di trattamento dei dati (DPA).

Il caso italiano: il Garante sospende ChatGPT

Nel marzo 2023 il Garante per la protezione dei dati personali ha sospeso temporaneamente ChatGPT in Italia, evidenziando l’assenza di una base chiara per la conservazione dei dati di conversazione e la mancanza di un meccanismo semplice per la loro rimozione. OpenAI ha risolto la sospensione aggiungendo un’opzione di opt‑out per l’uso dei dati a fini di training e chiarendo le proprie politiche di conservazione, ma il caso ha mostrato come la “incapacità di cancellare” sia considerata una violazione concreta del GDPR.

Le quattro superfici di dati da gestire

Quando un cliente richiede la cancellazione, è necessario coprire quattro livelli distinti, ciascuno con modalità operative diverse:

    • Record sorgente: riga in PostgreSQL, documento in MongoDB o ticket in Zendesk. È il livello più semplice, perché la maggior parte delle aziende dispone già di funzioni di delete per la chiusura degli account.
    • Memoria dell’agente: se l’agente mantiene uno stato di sessione o una memoria a lungo termine per utente, tale memoria deve essere indicizzabile per ID utente, così da permettere la cancellazione singola senza intaccare le sessioni di altri utenti.
    • Embeddings e vector store: le rappresentazioni vettoriali dei dati (es. Pinecone, Weaviate) sono compressioni perdenti ma ancora riconducibili all’individuo. È fondamentale taggare ogni vettore con il relativo ID cliente al momento della scrittura, per consentire una purga selettiva.
    • Log e derivati del modello: se i dati del cliente sono stati usati in un processo di fine‑tuning, la loro rimozione completa può richiedere il re‑training del modello, che è costoso e complesso. Se non si effettua il fine‑tuning, occorre dichiararlo esplicitamente nel DPA.

Perché le startup falliscono nella prima risposta

Molte startup pensano che la cancellazione di un log di chat sia sufficiente, ma trascurano che l’embedding di quel log rimane in un vector database e continua a influenzare le risposte successive dell’agente. Questo è lo stato di default della maggior parte delle architetture RAG (Retrieval‑Augmented Generation) oggi sul mercato.

Costruire una policy di conservazione dei dati per agenti IA

Una policy efficace deve includere:

    • Una tabella di retention che specifichi i tempi di conservazione per ciascun livello (es. 30 giorni per le richieste API, 90 giorni per log di monitoraggio, cancellazione immediata su richiesta del cliente).
    • Un meccanismo di cancellazione automatizzato che, al ricevimento di una richiesta, invii comandi di delete a tutti i data store coinvolti.
    • Un registro di audit che salvi data, ora e numero di record eliminati, per fornire prova al cliente.
    • Un SLA di cancellazione, tipicamente 5‑10 giorni lavorativi, da includere nel contratto.

Come implementare il meccanismo di cancellazione

Taggare i dati alla scrittura

Il tagging deve avvenire al momento della creazione di ogni oggetto: memoria dell’agente, embedding, log o modello. Retro‑fittare il tagging su un anno di dati esistenti è costoso; implementarlo in tempo reale è quasi privo di costi aggiuntivi.

Creare un endpoint di cancellazione unico

Un singolo endpoint HTTP deve orchestrare la cancellazione su tutti i repository. L’endpoint:

    • Riceve l’ID cliente o l’ID utente.
    • Invoca in parallelo le API di PostgreSQL, MongoDB, il vector store e il servizio di logging.
    • Registra l’esito di ogni operazione in un audit log centralizzato.

Gestire i backup e le cache

Le copie di backup devono essere invalidate o marcate per l’eliminazione entro il periodo di SLA. Molti fornitori di backup (es. AWS RDS snapshots) offrono API per impostare politiche di “expire” basate su tag, quindi è possibile allineare le scadenze di cancellazione ai backup.

Esempio pratico: flusso di cancellazione in un agente di supporto

Immaginiamo un agente IA che legge ticket di supporto, li memorizza e crea embeddings per il recupero. Quando arriva una richiesta di cancella per il cliente “Acme Corp”:

    • L’endpoint di cancellazione riceve l’ID “acme‑123”.
    • Viene eseguita la query DELETE su PostgreSQL per rimuovere i ticket originali.
    • Vengono invocati gli script di “purge” su Pinecone/Weaviate con filtro tag=acme‑123 per eliminare gli embeddings.
    • Viene svuotata la memoria sessione di tutti gli agenti associati a quell’ID.
    • Vengono cancellati i log di attività correlati.
    • Il sistema scrive un record di audit con timestamp, numero di record eliminati per ciascuna categoria e un hash di conferma.

Che cosa chiedono i DPA e le domande tipiche

    • “Qual è il tempo medio di cancellazione dei dati per utente?” – deve essere misurabile e garantito da SLA.
    • “Dove sono conservate le copie di backup e come vengono eliminate?” – richiede politiche di retensione dei backup sincronizzate con le richieste di cancellazione.
    • “Il vostro modello è stato addestrato sui nostri dati? In caso affermativo, come potete rimuoverli?” – se non si fa fine‑tuning, la risposta è “no, non vengono usati”. Se sì, è necessario un piano di “unlearning”.
    • “Potete fornire prove (log, report) della cancellazione?” – un audit log firmato è la risposta attesa.

Strumenti di supporto e best practice del settore

Prodotti come Securiti e OneTrust offrono soluzioni per automatizzare la cancellazione su database tradizionali. Per gli agenti IA, è possibile estendere questi strumenti aggiungendo plug‑in specifici per vector store (es. Weaviate SDK) e per la gestione della memoria degli agenti. L’integrazione preventiva è decisamente più economica rispetto a un retrofit successivo.

Il ruolo delle clausole contrattuali

Un addendum di trattamento dei dati (DPA) deve includere:

    • Elenco esplicito dei sub‑processori (es. provider di vector database).
    • Descrizione dettagliata del processo di cancellazione per ciascun livello di dati.
    • Impegni di residenza dei dati (es. EU‑only storage) con riferimento a configurazioni tecniche, non solo a pagine di impostazione.
    • Clausole di audit e verifica, ad esempio auditor di terze parti o monitoraggio SOC 2 Type II.

Conclusioni

Il diritto alla cancellazione è una realtà operativa, non solo un concetto legale. Le startup che vendono agenti IA devono costruire un meccanismo di cancellazione che copra source record, memoria dell’agente, embeddings e log, documentarlo con SLA chiari e fornire prove verificabili. Solo così potranno superare le revisioni di sicurezza dei grandi clienti e chiudere trattative di valore a sei cifre senza troppi intoppi.