Continuarea conversațiilor cu chatbotul: sesiuni, schimbarea dispozitivului și predare securizată

Un vizitator pune trei întrebări în chatbotul de pe site, navighează către pagina de produs și revine mai târziu. O clientă începe conversația pe smartphone și dorește să continue pe laptop. În cele din urmă, la suport preia un agent uman. În toate cele trei cazuri, așteptarea este aceeași: conversația trebuie să continue într-un mod logic. Din punct de vedere tehnic și organizațional, acestea sunt însă trei sarcini distincte. Persoanele care le confundă riscă să piardă contextul, să provoace partajări neintenționate de date sau să mențină o sesiune activă mai mult timp decât este necesar.

„A continua” nu este totuna cu „a recunoaște”

Pentru planificare, este utilă o delimitare clară a trei niveluri de continuitate:

1. În cadrul unei vizite: Conversația este păstrată în timp ce utilizatorul navighează între pagini sau închide și redeschide fereastra de chat.
2. La o revenire ulterioară: Același browser regăsește o conversație anterioară în cadrul unui termen limitat.
3. Între dispozitive diferite: O persoană continuă conversația pe un alt browser sau dispozitiv. Pentru aceasta este necesară, de regulă, o asociere de încredere cu un cont sau un proces de transfer de scurtă durată declanșat intenționat.

Existența unui istoric de conversație nu dovedește identitatea. Oricine deține un ID de conversație sau un link nu trebuie să aibă acces automat la comenzi, date contractuale sau informații cu caracter personal. Aceasta este aceeași limită fundamentală care se aplică și la separarea chatbotului public de portalul de clienți autentificat: contextul poate oferi confort, dar nu înlocuiește autentificarea și verificarea permisiunilor.

Baza tehnică: referința în browser, starea pe server

O arhitectură robustă stochează în browser doar o referință aleatorie, fără semnificație directă. Starea corespunzătoare a conversației este păstrată pe server și este verificată la fiecare cerere în funcție de validitate, tenant, permisiune și data de expirare. Recomandările OWASP pentru Session Management sugerează utilizarea unor identificatori de sesiune fără semnificație, greu de ghicit și limite de timp controlate pe server. În plus, identificatorii de sesiune nu trebuie să apară în URL-uri: aceștia pot fi divulgați prin istoric, jurnale, rețeaua referrer sau linkuri distribuite.

Stocarea în browser are domenii de aplicare diferite. Conform MDN Web Storage API, sessionStorage este legat de filă și origine și se încheie de obicei odată cu închiderea filei. În schimb, localStorage persistă între sesiunile browserului, dar rămâne limitat la același profil de browser. Niciuna dintre opțiuni nu creează o identitate cross-device. Stocarea transcrierilor sensibile sau a tokenurilor de acces permanente direct acolo mărește impactul unui eventual acces neautorizat la scripturi sau dispozitiv.

Ce date ar trebui să conțină starea

Pentru o continuare utilă, sistemul are nevoie adesea de mai puțin decât o transcriere completă. Un set de date de stare compact și versionat poate fi suficient:

• solicitarea curentă și obiectivul confirmat,
• faptele clarificate deja, care nu sunt sensibile,
• întrebările rămase deschise și următorul pas logic,
• sursele de cunoștințe utilizate sau versiunile acestora,
• statusul de consimțământ, autentificare și handoff,
• momentul ultimei activități și data de expirare stabilită.

Astfel, conversația poate fi reluată coerent, fără a copia fiecare mesaj anterior în promptul activ pe termen nelimitat. Istoricul complet poate fi păstrat separat, într-o formă mai scurtă sau deloc – în funcție de scop, așteptările utilizatorului și regulile stabilite. Pentru datele cu caracter personal, principiile de legare de scop, minimizare a datelor și limitare a stocării din Articolul 5 GDPR reprezintă principii de proiectare esențiale. Aceasta nu înlocuiește consultanța juridică individuală, dar oferă o cerință clară de produs: stocați doar ceea ce este cu adevărat necesar pentru un scop definit.

Tratarea diferențiată a conversațiilor anonime și a celor autentificate

Revenirea anonimă în același browser

Pentru vizitatorii anonimi, funcția „continuare conversație” ar trebui să rămână o opțiune de confort limitată. Sunt recomandate o perioadă scurtă de păstrare, o comandă de ștergere bine vizibilă și o explicație clară că istoricul poate fi regăsit doar în acest browser. Chatbotul nu trebuie să deducă din revenirea utilizatorului că în fața sa se află aceeași persoană fizică. După expirare sau la pierderea referinței locale, începe o nouă sesiune.

În practică, chatbotul poate întreba la revenire: „Doriți să continuați conversația despre selectarea produsului sau să începeți una nouă?” Acest lucru este de preferat activării silențioase a vechiului context. Pe dispozitivele partajate, această confirmare previne situația în care următoarea persoană vede imediat conținuturi care nu îi sunt destinate.

Schimbarea dispozitivului prin autentificare

Continuitatea între dispozitive ar trebui conectată la un cont verificat și la permisiunile curente ale acestuia. După autentificare, serverul încarcă doar conversațiile alocate acestui cont și tenantului corect. Pentru acțiuni sensibile – cum ar fi modificarea adresei, informații despre contract sau plasarea unei comenzi – este indicată o reautentificare, chiar dacă chatul general este încă activ.

Ghidul actual NIST SP 800-63B privind gestionarea sesiunilor descrie sesiunile ca o legătură între o persoană autentificată și un serviciu prin intermediul unui secret de sesiune. Acesta solicită atât limite de timp pentru inactivitate, cât și limite absolute de timp, alături de o închidere controlată de pe server. Pentru echipele de produs, concluzia este clară: starea de „autentificat” nu trebuie să fie nelimitată, iar un token de cont sau de sesiune expirat nu trebuie reactivat prin intermediul unui istoric de chat încă existent.

Codul de transfer doar ca o punte strict limitată

Unele servicii doresc să permită o schimbare anonimă prin intermediul unui cod unic sau al unui cod QR. În acest caz, codul ar trebui să fie de scurtă durată, de unică folosință și revocabil. Acesta nu conține transcriere și nici date despre clienți, ci doar o referință aleatorie către o stare de conversație minimă și aprobată. După preluarea cu succes, veche referință devine invalidă. Codul este o punte pentru context, nu o dovadă a identității și nici o autorizare pentru date sensibile de cont.

Regulile de expirare trebuie să fie ușor de înțeles în interfață

Limitele tehnice de timp rezolvă doar jumătate din problemă. Utilizatorii trebuie să știe dacă și pentru cât timp este păstrată conversația lor. Recomandările NIST privind Customer Experience subliniază importanța informațiilor clare despre finalizarea sesiunii, astfel încât nicio activitate să nu se piardă și oamenii să nu recurgă la soluții nesigure.

Un concept bun de expirare răspunde astfel direct în chat la următoarele întrebări:

• Conversația este păstrată după închidere?
• Acest lucru este valabil doar pentru acest browser sau și după autentificare pe alte dispozitive?
• Când se încheie sesiunea din cauza inactivității și când se șterge istoricul salvat?
• Ce părți poate elimina sau meține utilizatorul însuși prin export?
• Ce se întâmplă cu un caz de suport deschis după expirare?

Înainte de o închidere previzibilă a sesiunii, o notificare discretă poate oferi opțiunea de a salva informațiile deschise sau de a le transmite către suport. După expirare, interfața trebuie să facă o distincție clară între „Sesiune încheiată” și „Istoric șters”. Prima se referă la acces, iar a doua la stocare.

Human Handoff: predarea contextului, vizibilitatea responsabilității

La trecerea către un agent uman, un rezumat scurt și structurat este adesea mai valoros decât un istoric lung și necomentat. Acesta menționează solicitarea, datele confirmate, pașii deja propuși, întrebările deschise și sursele utilizate. Conținuturile sensibile sunt transmise doar dacă sunt necesare pentru cazul de suport și au fost aprobate în acest scop.

Utilizatorul ar trebui să vadă că un agent uman preia conversația, ce informații sunt transmise și dacă apare un nou timp de așteptare. În același timp, IA trebuie să știe după predare dacă trebuie să tacă, să ofere doar suport organizațional sau dacă poate prelua din nou conversația mai târziu. Declanșatorii concreți și regulile de escaladare sunt descrise în articolul despre Human Handoff în chatbotul de pe site.

Implementare în șase pași

1. Specificarea scenariilor de utilizare: Se definesc separat navigarea în pagină, revenirea ulterioară, schimbarea dispozitivului și predarea către un agent uman.
2. Definirea nivelurilor de încredere: Se stabilește ce conținuturi sunt disponibile anonim, după conectarea contului sau doar după reautentificare.
3. Minimizarea stării: Se proiectează o stare de reluare structurată cu obiectiv, fapte confirmate, puncte deschise și timp de expirare.
4. Aplicarea ciclului de viață: Se testează pe server limita de inactivitate, limita absolută, ștergerea, revocarea și deconectarea.
5. Conceperea predărilor: Se fac vizibile confirmarea utilizatorului, rezumatul pentru suport, statusul de așteptare și responsabilitatea.
6. Măsurarea succesului fără text complet: Se înregistrează evenimente precum „continuare oferită”, „acceptată”, „expirată”, „schimbare dispozitiv finalizată” și „handoff reușit”. Modul în care se poate realiza acest lucru cu un consum minim de date este prezentat în ghidul despre Analytics pentru chatboturi IA.

Matrice de testare pentru desktop, mobil și cazuri limită reale

Înainte de lansare, nu doar scenariul ideal ar trebui să funcționeze. O matrice de testare restrânsă acoperă erorile tipice:

• navigarea în cadrul aceluiași site cu fereastra de chat deschisă și închisă,
• revenirea în același browser înainte și după limita de inactivitate,
• revenirea într-o fereastră privată sau după ștergerea datelor locale din browser,
• schimbarea dispozitivului înainte și după autentificare, precum și după deconectare,
• schimbarea contului pe un dispozitiv partajat,
• cod de transfer expirat, deja utilizat sau revocat,
• conversație ștersă, cont blocat și permisiuni modificate pentru tenant,
• continuarea după o actualizare a bazei de cunoștințe,
• handoff cu și fără un rezumat aprobat în mod explicit,
• titluri lungi, limbi cu lungimi diferite de text și lățimi mobile fără depășire orizontală.

În fiecare caz, pe lângă răspunsul vizibil, verificarea trebuie să includă accesul la rețea, invalidarea sesiunii, jurnalele de erori și evenimentele de analytics. Un chatbot poate explica amabil că un context nu mai este disponibil. Însă nu trebuie să îl reconstruiască niciodată din date similare ale utilizatorilor și nici să îl aloce unei persoane noi.

Concluzie: Continuitatea este o predare controlată

O experiență bună de continuare nu înseamnă stocarea tuturor datelor pentru totdeauna. Înseamnă preluarea contextului minim și corect pe o durată clar delimitată. Același browser, un al doilea dispozitiv pe care utilizatorul este autentificat și un canal de suport uman au nevoie de reguli diferite de încredere și expirare. Când starea conversației, identitatea și permisiunile rămân separate, se obține confort fără partajarea neintenționată a datelor.

Echipele care integrează aceste reguli devreme în UX-ul conversațional pot reduce abandonul sesiunilor și pot face predările către suport mai ușor de înțeles. Funcționalitățile ChatReact oferă o imagine de ansamblu asupra componentelor posibile pentru chatboturile de pe site-uri; configurarea concretă a sesiunilor și a protecției datelor ar trebui apoi planificată și testată în funcție de propriul caz de utilizare.

Surse

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Regulamentul general privind protecția datelor, Articolul 5