Riprendere le conversazioni con il chatbot: sessioni, cambio dispositivo e passaggio sicuro

Un visitatore pone tre domande nel chatbot del sito web, passa alla pagina di un prodotto e torna più tardi. Una cliente inizia sullo smartphone e vuole proseguire sul laptop. Nell'assistenza, infine, subentra un operatore umano. In tutti e tre i casi l'aspettativa è la stessa: la conversazione deve proseguire in modo sensato. Dal punto di vista tecnico e organizzativo, tuttavia, si tratta di tre compiti ben distinti. Chi li confonde rischia di perdere il contesto, di condividere involontariamente dei dati o di mantenere attiva una sessione più a lungo del necessario.

"Proseguire" non significa "riconoscere"

Per la pianificazione è utile distinguere chiaramente tre livelli di continuità:

1. All'interno di una singola visita: la conversazione si conserva mentre l'utente naviga tra le pagine o chiude e riapre la finestra di chat.
2. In caso di ritorno successivo: lo stesso browser ritrova una conversazione precedente entro un lasso di tempo limitato.
3. Tra dispositivi diversi: una persona riprende la conversazione su un altro browser o dispositivo. A tal fine è di norma necessario un vincolo d'account affidabile o un processo di trasferimento a breve durata attivato intenzionalmente.

La presenza della cronologia di una conversazione non dimostra ancora l'identità dell'utente. Pertanto, chi possiede l'ID di una conversazione o un link non deve poter accedere automaticamente ad ordini, dati contrattuali o informazioni personali. Si tratta del medesimo limite fondamentale che vale per la separazione tra chatbot pubblico e portale clienti autenticato: il contesto può offrire comodità, ma non sostituisce il login né la verifica delle autorizzazioni.

La base tecnica: riferimento nel browser, stato sul server

Un'architettura solida memorizza nel browser possibilmente solo un riferimento casuale e privo di significato. Lo stato corrispondente della conversazione risiede sul server e viene verificato a ogni richiesta in base a validità, tenant, autorizzazione e data di scadenza. Le raccomandazioni OWASP sulla gestione delle sessioni consigliano di utilizzare identificatori di sessione privi di significato e difficili da indovinare, uniti a limiti di tempo controllati lato server. Gli identificatori di sessione, inoltre, non devono mai figurare negli URL: potrebbero essere inoltrati tramite cronologia, log, referrer o link condivisi.

La memoria del browser ha portate differenti. Secondo le MDN Web Storage API, sessionStorage è legato alla scheda e all'origine e termina normalmente con la chiusura della scheda. localStorage, invece, persiste tra le sessioni del browser, ma rimane limitato allo stesso profilo browser. Nessuno dei due crea un'identità tra più dispositivi. Salvare trascrizioni sensibili o token di accesso permanenti direttamente lì aumenta inoltre le conseguenze di un eventuale accesso non autorizzato a uno script o al dispositivo.

Quali dati dovrebbe contenere lo stato

Per una ripresa della chat davvero utile, al sistema serve spesso meno di una trascrizione completa. Un set di dati di stato compatto e con versione può essere sufficiente:

• la richiesta attuale e l'obiettivo confermato,
• i fatti già chiariti e non sensibili,
• le domande ancora aperte e il passaggio successivo più opportuno,
• le fonti di conoscenza utilizzate o le relative versioni,
• lo stato di consenso, autenticazione e handoff,
• l'orario dell'ultima attività e la data di scadenza stabilita.

In questo modo è possibile proseguire la conversazione in modo coerente senza dover copiare indefinitamente ogni messaggio precedente nel prompt attivo. La cronologia completa può essere conservata separatamente, in forma ridotta o per nulla – a seconda della finalità, delle aspettative dell'utente e delle regole stabilite. Per i dati personali, i principi di limitazione della finalità, minimizzazione dei dati e limitazione della conservazione sanciti dall'Articolo 5 del GDPR rappresentano importanti linee guida di progettazione. Ciò non sostituisce una consulenza legale individuale, ma fornisce un chiaro requisito di prodotto: conservare solo ciò che è realmente necessario per uno scopo preciso.

Trattare in modo diverso le conversazioni anonime e quelle autenticate

Ritorno anonimo nello stesso browser

Per i visitatori anonimi, la funzione "riprendi conversazione" dovrebbe rimanere una funzionalità di comodità limitata. È opportuno prevedere un periodo di conservazione breve, un comando di eliminazione ben visibile e la spiegazione che la cronologia potrà essere ritrovata solo su quel browser specifico. Il chatbot non deve dedurre dal semplice ritorno che si trovi di fronte la stessa persona fisica. Alla scadenza o in caso di perdita del riferimento locale, inizia una nuova sessione.

All'atto del ritorno, il chatbot può chiedere in modo pratico: "Desideri proseguire la conversazione sulla selezione del prodotto o iniziare da capo?". Questo è preferibile al ripristino silenzioso del vecchio contesto. Sugli strumenti condivisi, questa conferma impedisce alla persona successiva di vedere immediatamente contenuti che non la riguardano.

Cambio di dispositivo con autenticazione

La continuità tra più dispositivi dovrebbe essere vincolata a un account verificato e alle sue autorizzazioni correnti. Dopo l'autenticazione, il server carica solo le conversazioni associate a quell'account e al tenant corretto. In caso di azioni sensibili – come la modifica dell'indirizzo, la richiesta di informazioni sul contratto o un ordine – è opportuno richiedere una riautenticazione, anche se la chat generale è ancora attiva.

Le attuali linee guida NIST SP 800-63B sulla gestione delle sessioni descrivono la sessione come un vincolo tra la persona autenticata e il servizio tramite un segreto di sessione. Esse richiedono limiti di tempo sia per l'inattività sia per la durata complessiva, oltre alla chiusura lato server. Per i team di prodotto ne consegue che "autenticato" non deve essere uno stato illimitato, e un token d'account o di sessione scaduto non deve essere riattivato semplicemente grazie a una cronologia chat ancora presente.

Codice di trasferimento solo come ponte strettamente limitato

Alcuni servizi desiderano consentire un passaggio anonimo tramite codice monouso o codice QR. In tal caso, il codice deve essere a breve durata, monouso e revocabile. Esso non deve contenere trascrizioni né dati cliente, ma soltanto un riferimento casuale a uno stato di conversazione condiviso e minimale. Dopo il corretto trasferimento, il vecchio riferimento diventa non valido. Il codice è un ponte per il contesto, non una prova d'identità né un'autorizzazione all'accesso a dati sensibili dell'account.

Le regole di scadenza devono essere chiare nell'interfaccia

I limiti di tempo tecnici risolvono solo metà del problema. Gli utenti devono sapere se e per quanto tempo la loro conversazione verrà conservata. Le indicazioni NIST sulla Customer Experience sottolineano l'importanza di informazioni chiare sul termine della sessione, in modo che nessun lavoro vada perso e che le persone non ricorrano ad espedienti poco sicuri.

Un buon concetto di gestione della scadenza risponde quindi direttamente all'interno della chat:

• La conversazione rimane memorizzata dopo la chiusura?
• Vale solo per questo browser o anche dopo aver effettuato l'accesso su altri dispositivi?
• Quando termina la sessione per inattività e quando viene eliminata la cronologia salvata?
• Quali parti l'utente può rimuovere o esportare autonomamente?
• Cosa succede a una richiesta di supporto aperta dopo la scadenza?

Prima di una scadenza prevedibile della sessione, un avviso discreto può proporre di salvare le informazioni o di trasferirle al supporto. Una volta scaduta la sessione, l'interfaccia deve distinguere chiaramente tra "Sessione terminata" e "Cronologia eliminata". L'una riguarda l'accesso, l'altra la conservazione.

Human Handoff: trasferire il contesto, rendere visibile la responsabilità

Quando si passa a un operatore umano, un riassunto breve e strutturato è spesso più prezioso di una lunga cronologia priva di commenti. In esso vengono indicati la richiesta, i dati confermati, i passaggi già proposti, le domande aperte e le fonti utilizzate. I contenuti sensibili vengono trasferiti solo se necessari per il caso di assistenza e previa autorizzazione.

L'utente dovrebbe vedere che un operatore umano sta subentrando, quali informazioni vengono trasmesse e se si prospetta un nuovo tempo di attesa. Allo stesso tempo, dopo il passaggio, l'IA deve sapere se rimanere in silenzio, fornire solo un supporto organizzativo o riprendere la gestione in un secondo momento. Criteri di attivazione specifici e regole di escalation sono descritti nell'articolo dedicato all'Human Handoff nei chatbot per siti web.

Implementazione in sei passaggi

1. Definire gli scenari d'uso: specificare separatamente navigazione nel sito, ritorno successivo, cambio di dispositivo e passaggio all'operatore umano.
2. Definire i livelli di fiducia: stabilire quali contenuti sono accessibili in modo anonimo, dopo l'associazione all'account o solo dopo una riautenticazione.
3. Minimizzare lo stato: progettare un Resume-State strutturato con obiettivo, fatti confermati, punti aperti e tempo di scadenza.
4. Applicare il ciclo di vita: testare lato server il limite di inattività, il limite assoluto, l'eliminazione, la revoca e il logout.
5. Progettare i passaggi di consegna: rendere visibili la conferma dell'utente, il riassunto per il supporto, lo stato di attesa e le responsabilità.
6. Misurare il successo senza testo integrale: tracciare eventi come "Ripresa offerta", "Accettata", "Scaduta", "Cambio dispositivo completato" e "Handoff riuscito". La guida sull'analisi dei chatbot IA illustra come fare tutto ciò riducendo al minimo la raccolta dei dati.

Matrice di test per desktop, mobile e casi limite reali

Prima del rilascio non deve funzionare soltanto il percorso ideale. Una semplice matrice di test permette di individuare gli errori più comuni:

• Navigazione all'interno dello stesso sito web con la finestra della chat aperta e chiusa,
• Ritorno nello stesso browser prima e dopo il limite di inattività,
• Ritorno in una finestra anonima o dopo l'eliminazione dei dati locali del browser,
• Cambio di dispositivo prima e dopo l'accesso, nonché dopo un logout,
• Cambio di account su un dispositivo condiviso,
• Codice di trasferimento scaduto, già utilizzato o revocato,
• Conversazione eliminata, account bloccato e autorizzazione tenant modificata,
• Prosecuzione dopo un aggiornamento della base di conoscenza,
• Handoff con e senza riassunto espressamente autorizzato,
• Titoli lunghi, lingue con diversa lunghezza del testo e larghezze mobile senza overflow orizzontale.

In ciascun caso, oltre alla risposta visibile, la verifica deve riguardare anche gli accessi di rete, la disattivazione della sessione, i log di errore e gli eventi analitici. Un chatbot può spiegare in modo cortese che un contesto non è più disponibile, ma non deve mai ricostruirlo a partire da dati di utenti simili né assegnarlo a una nuova persona.

Conclusione: la continuità è un passaggio di consegne controllato

Offrire una buona esperienza di ripresa della chat non significa salvare tutto per sempre. Significa trasportare il contesto corretto e minimale lungo un percorso ben delimitato. Lo stesso browser, un secondo dispositivo autenticato e un canale di supporto umano necessitano a tal fine di regole di fiducia e di scadenza differenti. Mantenendo separati lo stato della conversazione, l'identità e le autorizzazioni, si ottiene la massima comodità senza condivisioni di dati indesiderate.

Chi integra queste regole fin da subito nella Conversational UX può ridurre le interruzioni delle sessioni e rendere i passaggi al supporto più chiari e comprensibili. Le funzionalità di ChatReact offrono una panoramica dei componenti disponibili per i chatbot dei siti web; la configurazione specifica della sessione e della protezione dei dati andrà poi pianificata e testata in base al proprio caso d'uso specifico.

Fonti

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Regolamento generale sulla protezione dei dati, Articolo 5