Cancellare ed esportare la cronologia del chatbot: un controllo sicuro per l'utente

La cronologia di un chatbot è comoda per gli utenti: possono rileggere le risposte, riprendere una conversazione più tardi o trasferire informazioni al supporto. La stessa cronologia, tuttavia, può contenere numeri d'ordine, descrizioni di problemi, dati di contatto o altre informazioni sensibili. Per questo motivo, chi memorizza le conversazioni ha bisogno di molto più di un discreto pulsante "Cronologia". Gli utenti dovrebbero comprendere quali dati sono presenti, come possono scaricarli, cancellarli o revocare un ulteriore accesso.

Questa guida presenta un modello tecnico e di prodotto applicabile per i chatbot dei siti web. Unisce usabilità, minimizzazione dei dati, verifica sicura dell'identità e stati di sistema trasparenti. Queste indicazioni non costituiscono una consulenza legale individuale; gli obblighi concreti dipendono, tra l'altro, da finalità, base giuridica, architettura di sistema e dati interessati.

Quattro funzioni invece di un singolo pulsante di cronologia

"Gestisci cronologia" è una dicitura troppo generica. Nell'interfaccia e nel backend si dovrebbero separare quattro diverse intenzioni:

• Visualizzare: gli utenti leggono le conversazioni salvate, gli allegati e i metadata identificabili in una cronologia chiara.
• Esportare: ricevono una copia in un formato leggibile e, se opportuno o legalmente richiesto per il caso d'uso, anche in un formato strutturato leggibile da dispositivo automatico.
• Cancellare: rimuovono singole conversazioni o l'intera cronologia associata. L'interfaccia spiega l'ambito, i tempi ed eventuali eccezioni.
• Revocare l'accesso: rendono non validi i link di condivisione, i dispositivi noti o i token di ripresa sessione, senza dover necessariamente cancellare subito tutti i contenuti.

Questa separazione previene pericolosi fraintendimenti. Disconnettersi non cancella i dati delle conversazioni. "Nascondere la cronologia" non è un'eliminazione. E un link scaduto non significa automaticamente che i dati sottostanti siano scomparsi. Per approfondire, consulta la nostra guida su come riprendere in sicurezza le conversazioni con il chatbot.

Iniziare con un modello dati chiaro

Prima di progettare i pulsanti, i team dovrebbero inventariare gli oggetti memorizzati. Una conversazione spesso non consiste solo di messaggi. Vi si aggiungono identificativi di sessione, marcatori temporali, riferimenti ai file, eventi di sicurezza, ticket di supporto, feedback e log tecnici. Per ciascun oggetto è necessario uno scopo documentato, un responsabile, una regola di conservazione e un percorso di cancellazione.

Il Regolamento Generale sulla Protezione dei Dati cita nell'Articolo 5, tra gli altri, i principi di minimizzazione dei dati e limitazione della conservazione. L'Articolo 15 riguarda il diritto di accesso, l'Articolo 17 il diritto alla cancellazione con relativi requisiti ed eccezioni, e l'Articolo 20 la portabilità dei dati nei rispettivi ambiti di applicazione. Ciò non implica che ogni interfaccia chatbot debba offrire funzioni identiche. I team di prodotto dovrebbero tuttavia strutturare i flussi di dati in modo che le richieste legittime possano essere gestite con affidabilità.

Verificare l'identità in modo adeguato prima di esportare o cancellare

Rendere accessibile una cronologia solo tramite un link indovinabile o un identificativo di sessione riutilizzato espone al rischio di fuga di dati. Allo stesso tempo, una verifica dell'identità non deve richiedere indiscriminatamente più dati personali di quanti ne servano per l'azione specifica. Le linee guida definitive EDPB 01/2022 sul diritto di accesso trattano, tra l'altro, la verifica dell'identità, l'ambito e la fornitura sicura delle copie. L'Articolo 12, paragrafo 6 del GDPR consente di richiedere informazioni supplementari per confermare l'identità qualora sussistano ragionevoli dubbi.

Nella pratica, un approccio basato sul rischio si dimostra efficace. La visualizzazione di una breve cronologia pseudonimizzata sullo stesso dispositivo può richiedere una sessione valida e a breve termine. Un'esportazione completa, una cancellazione irreversibile o la revoca da tutti i dispositivi giustificano invece una riautenticazione. Le attuali linee guida NIST sulla gestione delle sessioni descrivono la riautenticazione, i limiti di tempo e la chiusura della sessione come controlli autonomi. La robustezza concreta deve essere proporzionata al rischio; i requisiti NIST per le agenzie federali statunitensi non costituiscono una norma legale universale per ogni azienda.

Per i widget pubblici e le aree clienti autenticate, il confine deve rimanere ben visibile. Il nostro articolo su identità e accesso ai dati nel portale clienti spiega perché una chat pubblica non debba trasformarsi silenziosamente in un canale di dati dell'account.

Un'esportazione deve essere chiara e completamente comprensibile

Un'esportazione ben fatta non è un semplice dump grezzo dal database. Inizia con una panoramica: periodo di creazione, conversazioni incluse, allegati, fuso orario utilizzato e versione del formato. Seguono i contenuti in ordine cronologico chiaro. Il formato JSON può essere utile per un'ulteriore elaborazione strutturata; un formato HTML o PDF risulta più facile da leggere per molte persone. Se e in quale misura sia richiesto un formato portabile a livello legale deve essere valutato caso per caso.

Se il sistema genera l'esportazione in modo asincrono, l'interfaccia deve mostrare uno stato univoco: "in preparazione", "disponibile fino a…", "scaduto" o "non riuscito". Il link per il download deve essere temporaneo, non indovinabile e revocabile dopo l'uso. Dati riservati come prompt interni, chiavi di accesso o dati di terzi non devono far parte del pacchetto. Prima della messa a disposizione, un filtro lato server deve verificare se i collegamenti a ticket di supporto, conversazioni condivise o contenuti di terze parti richiedano un trattamento speciale.

La cancellazione come macchina a stati anziché come promessa immediata

Un pulsante con il messaggio "Tutto cancellato" è problematico se l'indice di ricerca, l'archivio analytics, il sistema di supporto o i backup contengono ancora delle copie. È preferibile una semplice macchina a stati che rispecchi il processo reale.

Stati di cancellazione utili

1. Richiesta: l'identità e l'ambito richiesto sono stati confermati.
2. Bloccata: la cronologia non è più accessibile per l'uso normale; i token di ripresa e condivisione sono invalidati.
3. In corso: sono in corso le operazioni su memoria primaria, indice di ricerca, file storage, analytics e integrazioni.
4. Completata: i sistemi attivi previsti sono stati bonificati; le copie di backup rimanenti sono soggette alla rotazione documentata dei backup o a un'eccezione motivata.
5. Parzialmente bloccata: un sistema non è stato ripulito o i dati devono essere conservati momentaneamente. Il caso viene gestito ed scalato in modo tracciabile.

Non dimenticare i dati correlati

I messaggi possono fare riferimento a file, embedding, indici di ricerca, valutazioni di qualità, record CRM o ticket di supporto. La richiesta di cancellazione necessita quindi di un ID di richiesta stabile e di passaggi operativi idempotenti: un nuovo esito non deve generare nuove copie né annullare i passaggi già completati. Per i dati di misurazione, occorre decidere fin dalla fase di progettazione se le metriche aggregate e non più riconducibili all'utente possano essere conservate. Maggiori dettagli si trovano nell'articolo su analytics orientati alla minimizzazione dei dati nei chatbot.

La revoca protegge specialmente sui dispositivi condivisi

In hotel, punti vendita, officine o contesti familiari, persone diverse si alternano sullo stesso dispositivo. Pertanto, "Revoca accesso" dovrebbe fare di più che cancellare un cookie a livello locale. Lato server, i token di sessione noti, i link di condivisione ed eventualmente le associazioni di dispositivo devono diventare non validi. L'interfaccia dovrebbe distinguere tra "questo dispositivo", "tutti i dispositivi" e "tutti i link condivisi".

Dopo la revoca, il pulsante "Indietro" del browser non deve mostrare alcuna cronologia sensibile recuperata dalla cache. Le anteprime nelle notifiche, il completamento automatico del browser e i dati locali offline rientrano nei controlli da eseguire. Contestualmente, l'utente dovrebbe ricevere una conferma chiara di quali accessi siano stati terminati e se i dati della conversazione siano ancora salvati. In questo modo si evita di confondere la revoca con la cancellazione.

Rendere la conferma di eliminazione accessibile e tollerante agli errori

Un'azione irreversibile richiede una conferma chiara e ponderata. Le spiegazioni WCAG 2.2 al criterio di successo 3.3.4 si riferiscono esplicitamente anche alla modifica o eliminazione di dati controllabili dall'utente. È prevista almeno una modalità di annullamento, verifica o conferma. Quale variante sia idonea dipende dal prodotto.

Un buon dialogo indica chiaramente ad esempio "3 conversazioni e 2 allegati" anziché solo "dati". L'azione principale e quella distruttiva sono visivamente distinte, accessibili da tastiera e non spiegate unicamente attraverso il colore. Dopo l'invio, un'area di stato accessibile conferma che la richiesta è stata presa in carico. Un cestino con un periodo di ripristino limitato può prevenire errori operativi, ma non deve silenziosamente contraddire una promessa di cancellazione immediata.

Passaggio al supporto umano senza copie ombra

Quando una conversazione viene trasferita a un operatore umano, si genera spesso un ticket di supporto separato. Questo oggetto può avere una finalità diversa, ruoli di accesso distinti e una regola di conservazione differente. Le impostazioni della cronologia nel chatbot non devono né eliminare in modo invisibile né ignorare silenziosamente questo ticket. Prima del passaggio, l'interfaccia dovrebbe spiegare quali contenuti verranno trasferiti. In caso di successiva richiesta, il sistema deve trovare il collegamento e gestire il caso secondo le regole vigenti.

Se un'eliminazione automatica fallisce o se l'identità e l'ambito non sono chiari, il processo richiede un canale umano sicuro. L'articolo sul trasferimento all'operatore umano (Human Handoff) nel supporto web descrive i pacchetti di contesto e le regole di escalation ideali. Deve essere trasferito solo ciò di cui l'operatore incaricato ha realmente bisogno.

Checklist di implementazione per i team di prodotto e supporto

1. Inventariare tutti gli oggetti dati e le posizioni di archiviazione di una conversazione.
2. Modellare visualizzazione, esportazione, cancellazione e revoca come autorizzazioni distinte.
3. Richiedere una nuova autenticazione basata sul rischio per le azioni sensibili.
4. Strutturare i pacchetti di esportazione in modo chiaro e impostare scadenze di sicurezza.
5. Rendere i passaggi di cancellazione idempotenti e tracciabili con un ID di richiesta.
6. Includere indice di ricerca, file, analytics, integrazioni, cache e ticket di supporto.
7. Testare le finestre di dialogo di conferma e i messaggi di stato con tastiera e screen reader.
8. Simulare dispositivi condivisi, link scaduti e dispositivi smarriti.
9. Gestire gli errori parziali in modo visibile ed scalabile, senza copiare contenuti sensibili nei log.
10. Verificare regolarmente le regole di conservazione e cancellazione con il responsabile della protezione dati e i reparti di competenza.

I test fondamentali prima del go-live

I casi di test non dovrebbero coprire solo il percorso ideale. Verificate richieste di cancellazione parallele, un login che scade durante l'esportazione, link già revocati, nuovi messaggi durante un'eliminazione in corso e il guasto di un sistema collegato. Controllate inoltre se un'esportazione contiene messaggi altrui provenienti da account condivisi e se un file cancellato è ancora accessibile tramite un vecchio URL.

Per ogni azione è necessario un risultato atteso nell'interfaccia, nell'API e nell'archiviazione. Un buon test di accettazione non termina quindi con un messaggio di successo verde: verifica successivamente gli archivi dati rilevanti, i token e gli URL pubblici. I log degli eventi dovrebbero dimostrare che un passaggio è stato eseguito, senza salvare nuovamente il contenuto della conversazione eliminata.

Conclusione: il controllo dell'utente è una proprietà end-to-end

Un chatbot affidabile non si limita a rendere reperibile la cronologia. Separa visualizzazione, esportazione, cancellazione e revoca, verifica adeguatamente le azioni sensibili e mostra lo stato reale di elaborazione. L'elemento fondamentale è l'unione di una UX chiara con un modello dati che conosca tutti i sistemi correlati.

Integrare queste funzioni fin dall'inizio nell'architettura, nei processi di supporto e nei test riduce le eccezioni manuali ed evita false promesse. Durante la pianificazione, verificate anche quali funzionalità di ChatReact si adattano al vostro sito web e al vostro processo di supporto. Iniziate con un inventario dei dati e un singolo test end-to-end: esportare la cronologia, revocare gli accessi, avviare la cancellazione e verificare il risultato in tutti i sistemi coinvolti.

Fonti e riferimenti di approfondimento

• EUR-Lex: Regolamento (UE) 2016/679, in particolare gli Articoli 5, 12, 15, 17 e 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Version 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.