Pokračovanie v chate s chatbotom: Relácie, zmena zariadenia a bezpečné odovzdanie

Návštevník položí v webovom chatbotovi tri otázky, prejde na stránku produktu a neskôr sa vráti. Zákazníčka začne na smartfóne a chce pokračovať na notebooku. V zákazníckej podpore napokon prevezme komunikáciu človek. Vo všetkých troch prípadoch sa očakáva to isté: konverzácia by mala zmysluplne pokračovať. Technicky a organizačne však ide o tri odlišné úlohy. Kto ich zmešavá, riskuje stratu kontextu, neúmyselné zdieľanie údajov alebo reláciu, ktorá zostáva aktívna dlhšie, než je potrebné.

„Pokračovať“ neznamená „rozpoznať“

Pri plánovaní pomáha jasné rozlíšenie troch úrovní kontinuity:

1. V rámci jednej návštevy: Konverzácia zostáva zachovaná, kým niekto prechádza medzi stránkami alebo zatvorí a znova otvorí okno chatu.
2. Pri neskoršom návrate: Ten istý prehliadač nájde v rámci obmedzenej lehoty predchádzajúcu konverzáciu.
3. Naprieč zariadeniami: Osoba pokračuje v konverzácii v inom prehliadači alebo na inom zariadení. Na to je spravidla potrebné spoľahlivé prepojenie s účtom alebo vedome spustený, krátkodobý proces prenosu.

Existujúca história konverzácie ešte nedokazuje identitu. Kto vlastní ID konverzácie alebo odkaz, nesmie z toho dôvodu automaticky získať prístup k objednávkam, zmluvným údajom alebo osobným informáciám. Ide o rovnakú základnú hranicu, ktorá platí aj pri oddeľovaní verejného chatbota od autentifikovaného zákazníckeho portálu: Kontext môže vytvoriť komfort, ale nenahrádza prihlásenie ani kontrolu oprávnení.

Technický základ: Referencia v prehliadači, stav na serveri

Robustná architektúra ukladá v prehliadači pokiaľ možno len náhodnú, nevypovedajúcu referenciu. Príslušný stav konverzácie je uložený na strane servera a pri každej požiadavke sa overuje jeho platnosť, tenant, oprávnenia a dátum exspirácie. Odporúčania OWASP pre Session Management radostne odporúčajú bezzmyslové, ťažko uhádnuteľné identifikátory relácií a časové limity kontrolované na strane servera. Identifikátory relácií navyše nepatria do URL adries: môžu sa preniesť prostredníctvom histórie, protokolov, referrerov alebo zdieľaných odkazov.

Ukladací priestor prehliadača má rôzny dosah. Podľa MDN Web Storage API je sessionStorage viazaný na kartu a pôvod (origin) a zvyčajne sa končí so zatvorením karty. localStorage naproti tomu zostáva zachovaný naprieč reláciami prehliadača, no stále iba v tom istom profile prehliadača. Ani jedno nevytvárá identitu naprieč zariadeniami. Ukladanie citlivých transkriptov alebo trvalých prístupových tokenov priamo tam navyše zvyšuje následky v prípade prístupu skriptu alebo neoprávneného prístupu k zariadeniu.

Aké údaje by mal stav obsahovať

Pre užitočné pokračovanie systém často potrebuje menej ako kompletný transkript. Postačiť môže kompaktný, verziovaný dátový záznam stavu:

• aktuálna požiadavka a potvrdený cieľ,
• už vyjasnené, necitlivé fakty,
• otvorené doplňujúce otázky a ďalší zmysluplný krok,
• použité zdroje vedomostí alebo ich verzie,
• stav súhlasu, autentifikácie a odovzdania (handoff),
• čas poslednej aktivity ako aj stanovený dátum exspirácie.

Týmto spôsobom je možné v konverzácii súvisle pokračovať bez toho, aby sa každá predchádzajúca správa neobmedzene kopírovala do aktívneho promptu. Úplná história sa môže uchovávať oddelene, v skrátenej forme alebo vôbec – v závislosti od účelu, očakávaní používateľa a stanovených pravidiel. Pre osobné údaje sú dôležitými konštrukčnými princípmi najmä obmedzenie účelu, minimalizácia údajov a obmedzenie uchovávania z článku 5 GDPR. To nenahrádza individuálne právne poradenstvo, ale poskytuje jasnú produktovú požiadavku: ukladajte len to, čo je skutočne potrebné na uvedený účel.

S anonymnými a prihlásenými konverzáciami zaobchádzajte odlišne

Anonymný návrat v rovnakom prehliadači

Pri anonymných návštevníkoch by malo „Pokračovať v konverzácii“ zostávať obmedzenou komfortnou funkciou. Zmysel má krátka lehota uchovávania, dobre viditeľný príkaz na vymazanie a vysvetlenie, že históriu je možné znova nájsť iba v tomto prehliadači. Chatbot by z návratu nemal vyvodzovať, že pred ním sedí tá istá fyzická osoba. Po uplynutí lehoty alebo pri strate lokálnej referencie sa začína nová relácia.

V praxi sa chatbot môže pri návrate opýtať: „Chcete pokračovať v konverzácii o výbere produktu, alebo začať znova?“ To je lepšie, než ticho aktivovať starý kontext. Na zdieľaných zariadeniach toto potvrdenie zabráni tomu, aby ďalšia osoba okamžite uvidela obsah, do ktorého jú nič nie je.

Zmena zariadenia s prihlásením

Kontinuita naprieč zariadeniami by mala byť viazaná na overený účet a jeho aktuálne oprávnenia. Po prihlásení server načíta iba konverzácie priradené k tomuto účtu a správnemu tenantovi. Pri citlivých úkonoch – ako je zmena adresy, informácie o zmluve alebo objednávka – má zmysel opätovná autentifikácia, aj keď je všeobecný chat stále aktívny.

Aktuálne usmernenie NIST SP 800-63B o správe relácií popisuje relácie ako väzbu medzi autentifikovanou osobou a službou prostredníctvom tajomstva relácie. Vyžaduje časové limity neaktivity ako aj celkové časové limity a ukončenie na strane servera. Pre produktové tímy z toho vyplýva: „Prihlásený“ nesmie byť neobmedzený stav a exspirovaný token účtu alebo relácie sa nesmie oživiť prostredníctvom stále existujúcej histórie chatu.

Prenosový kód len ako úzko vymedzený mostík

Niektoré služby chcú umožniť anonymný prechod pomocou jednorazového kódu alebo QR kódu. V takom prípade by mal byť kód krátkodobý, jednorazovo použiteľný a odvolateľný. Neobsahuje ani transkript, ani zákaznícke údaje, ale iba náhodnú referenciu na schválený, minimálny stav konverzácie. Po úspešnom prevzatí sa stará referencia stane neplatnou. Kód je mostíkom pre kontext, nie dokladom identity ani schválením citlivých údajov účtu.

Pravidlá exspirácie musia byť v rozhraní zrozumiteľné

Technické časové limity riešia len polovicu úlohy. Používatelia musia vedieť, či a ako dlho zostane ich konverzácia zachovaná. Odporúčania NIST pre Customer Experience zdôrazňujú jasné informácie o konci relácie, aby sa nestratila žiadna práca a ľudia nesiahali po nebezpečných obchádzkach.

Dobrý koncept exspirácie preto odpovedá priamo v chate:

• Zostane konverzácia zachovaná aj po zatvorení?
• Platí to len pre tento prehliadač, alebo aj po prihlásení na iných zariadeniach?
• Kedy sa relácia skončí z dôvodu neaktivity a kedy sa vymaže uložená história?
• Aké časti môže používateľ sám odstrániť alebo exportovať?
• Čo sa stane s otvoreným prípadom podpory po exspirácii?

Pred očakávaným koncom relácie môže nenápadné upozornenie ponúknuť uloženie otvorených informácií alebo ich odovzdanie na podporu. Po exspirácii by malo rozhranie jasne rozlišovať medzi „Relácia sa skončila“ a „História bola vymazaná“. Jedno sa týka prístupu, druhé uchovávania.

Human Handoff: Odovzdanie kontextu, zviditeľnenie zodpovednosti

Pri prechode na človeka je krátke štruktúrované zhrnutie často hodnotnejšie ako nekomentovaná dlhá história. Uvádza požiadavku, potvrdené údaje, už navrhnuté kroky, otvorenú otázku a použité zdroje. Citlivý obsah sa odovzdáva len vtedy, ak je potrebný pre prípad podpory a bol na to schválený.

Používateľ by mal vidieť, že teraz preberá komunikáciu človek, aké informácie sa odovzdávajú a či vzniká nová čakacia doba. Zároveň musí AI po odovzdaní vedieť, či má mlčať, poskytovať len organizačnú podporu, alebo neskôr znova prevziať úlohu. Konkrétne spúšťače a pravidlá eskalácie popisuje článok o Human Handoff vo webovom chatbotovi.

Implementácia v šiestich krokoch

1. Pomenujte scenáre používania: Samostatne špecifikujte navigáciu po stránke, neskorší návrat, zmenu zariadenia a odovzdanie človeku.
2. Definujte úrovne dôvery: Určite, aký obsah je dostupný anonymne, po prepojení s účtom alebo až po opätovnej autentifikácii.
3. Minimalizujte stav: Navrhnite štruktúrovaný stav na obnovenie (resume-state) s cieľom, potvrdenými faktami, otvorenými bodmi a časom exspirácie.
4. Vynúťte životný cyklus: Otestujte limit neaktivity, absolútny limit, vymazanie, odvolanie a odhlásenie na strane servera.
5. Navrhnite odovzdania: Zviditeľnite potvrdenie používateľom, zhrnutie pre podporu, stav čakania a zodpovednosť.
6. Merajte úspech bez celého textu: Zaznamenávajte udalosti ako „Ponúknuté pokračovanie“, „Prijaté“, „Exspirované“, „Zmena zariadenia dokončená“ a „Handoff úspešný“. Ako to dosiahnuť s ohľadom na úsporu údajov, ukazuje sprievodca pre analytiku AI chatbotov.

Testovacia matica pre desktop, mobilné zariadenia a reálne hraničné prípady

Pred spustením by nemala fungovať len ideálna cesta. Malá testovacia matica pokrýva typické chyby:

• navigácia v rámci rovnakej webovej stránky s otvoreným a zatvoreným oknom chatu,
• návrat v rovnakom prehliadači pred a po limite neaktivity,
• návrat v anonymnom okne alebo po vymazaní lokálnych údajov prehliadača,
• zmena zariadenia pred prihlásením, po prihlásení a po odhlásení,
• zmena účtu na zdieľanom zariadení,
• exspirovaný, už použitý alebo odvolaný prenosový kód,
• vymazaná konverzácia, zablokovaný účet a zmenené oprávnenia tenanta,
• pokračovanie po aktualizácii bázy znalostí,
• handoff s výslovne schváleným zhrnutím aj bez neho,
• dlhé názvy, jazyky s inou dĺžkou textu a mobilné šírky bez horizontálneho pretečenia.

Pri každom prípade patria ku kontrole okrem viditeľnej odpovede aj sieťové prístupy, invalidácia relácie, chybové protokoly a analytické udalosti. Chatbot môže zdvorilo vysvetliť, že kontext už nie je k dispozícii. Nesmie ho však nikdy rekonštruovať z podobných údajov používateľa ani priradiť novej osobe.

Záver: Kontinuita je kontrolované odovzdanie

Dobrý zážitok z pokračovania neznamená ukladať všetko navždy. Znamená to vziať so sebou ten správny, minimálny kontext po jasne vymedzenej trase. Ten istý prehliadač, prihlásené druhé zariadenie a ľudský kanál podpory na to potrebujú odlišné pravidlá dôvery a exspirácie. Ak zostane stav konverzácie, identita a oprávnenie oddelené, vzniká komfort bez tichého zdieľania údajov.

Kto zapracuje tieto pravidlá do Conversational UX včas, môže znížiť počet prerušených relácií a spraviť odovzdania na podporu zrozumiteľnejšími. Funkcie ChatReact poskytujú prehľad možných stavebných prvkov pre webové chatboty; konkrétna konfigurácia relácií a ochrany údajov by mala byť následne naplánovaná a otestovaná podľa vlastného prípadu použitia.

Zdroje

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Všeobecné nariadenie o ochranne údajov, článok 5