Nadaljevanje pogovora s chatbotom: Seje, menjava naprav in varen prenos

Obiskovalec v spletnem chatbotu postavi tri vprašanja, se premakne na stran z izdelkom in se pozneje vrne. Stranka začne na pametnem telefonu in želi nadaljevati na prenosniku. V podpori pa na koncu prevzame človek. V vseh treh primerih je pričakovanje enako: pogovor naj se smiselno nadaljuje. Tehnično in organizacijsko pa so to tri različne naloge. Kdor jih zameša, tvega izgubo kontexta, neželeno razkritje podatkov ali sejo, ki ostane aktivna dlje, kot je potrebno.

„Nadaljevanje“ ni enako „prepoznavanju“

Za načrtovanje pomaga jasna ločitev treh stopenj kontinuitete:

1. V okviru enega obiska: Pogovor se ohrani, ko nekdo krmari med stranmi ali zapre in znova odpre okno klepeta.
2. Ob poznejši vrnitvi: Isti brskalnik v določenem časovnem roku znova najde prej potekajoči pogovor.
3. Med različnimi napravami: Oseba nadaljuje pogovor v drugem brskalniku ali na drugi napravi. Za to je običajno potrebna zanesljiva povezava z računom ali zavestno sprožen, kratkotrajen postopek prenosa.

Obstoječa zgodovina pogovora še ne dokazuje identitete. Kdor ima ID pogovora ali povezavo, zato ne sme samodejno dostopati do naročil, pogodbenih podatkov ali osebnih informacij. To je enaka osnovna meja, ki velja tudi pri ločevanju javnega chatbota in avtenticiranega portala za stranke: kontekst lahko ustvari udobje, vendar ne nadomešča prijave in preverjanja pravic.

Tehnična osnova: Referenca v brskalniku, stanje na strežniku

Robustna arhitektura v brskalniku shranjuje le naključno, nepovedno referenco. Pripadajoče stanje pogovora je na strani strežnika in se ob vsaki zahtevi preveri glede na veljavnost, najemnika, pooblastila in datum poteka. Priporočila OWASP za upravljanje sej svetujejo uporabo brezpomenskih identifikatorjev sej, ki jih je težko uganiti, ter strežniško nadzorovanih časovnih omejitev. Identifikatorji sej prav tako ne sodijo v URL-je: prenosljivi so namreč preko zgodovine, dnevnikov, napotiteljev ali deljenih povezav.

Pomnilnik brskalnika ima različne dosege. Glede na MDN Web Storage API je sessionStorage vezan na zavihek in izvor ter se običajno konča z zaprtjem zavihka. localStorage po drugi strani ostane ohranjen skozi seje brskalnika, vendar še vedno le v istem profilu brskalnika. Nobeden od njiju ne ustvarja identitete med napravami. Shranjevanje občutljivih zapisov ali trajnih dostopnih žetonov neposredno tam povečuje posledice morebitnega dostopa do skripta ali naprave.

Katere podatke naj vsebuje stanje

Za koristno nadaljevanje sistem pogosto potrebuje manj kot celoten zapis pogovora. Zadošča lahko kompakten, verzioniran nabor podatkov o stanju:

>
• trenutna zadeva in potrjeni cilj,
• že razjasnjena, neobčutljiva dejstva,
• odprta vprašanja in naslednji smiseln korak,
• uporabljeni viri znanja ali njihove različice,
• status privolitve, avtentikacije in predevanja (handoff),
• čas zadnje aktivnosti ter določen datum poteka.

Tako je mogoče pogovor smiselno nadaljevati, ne da bi vsako prejšnje sporočilo neomejeno kopirali v aktivni poziv (prompt). Celotna zgodovina se lahko hrani ločeno, v krajši obliki ali pa sploh ne – odvisno od namena, pričakovanj uporabnika in določenih pravil. Za osebne podatke so zlasti načelo omejitve namena, najmanjšega obsega podatkov in omejitve shranjevanja iz 5. člena Splošne uredbe o varstvu podatkov (GDPR) pomembna oblikovalska načela. To ne nadomešča individualnega pravnega svetovanja, daje pa jasno zahtevo za izdelek: shranite le tisto, kar je resnično potrebno za navedeni namen.

Anonimne in prijavljene pogovore obravnavajte različno

Anonimna vrnitev v istem brskalniku

Pri anonimnih obiskovalcih bi moralo „nadaljevanje pogovora“ ostati omejena funkcija udobja. Smiselni so kratek rok hrambe, dobro viden ukaz za izbris in razlaga, da se zgodovina najde le v tem brskalniku. Chatbot iz ponovne vrnitve ne sme sklepati, da pred njim sedi ista fizična oseba. Po poteku ali ob izgubi lokalne reference se začne nova seja.

V praksi lahko chatbot ob vrnitvi vpraša: „Želite nadaljevati pogovor o izbiri izdelka ali začeti znova?“ To je boljše kot tiho aktiviranje starega konteksta. Na skupno rabljenih napravah to potrdilo preprečuje, da bi naslednja oseba takoj videla vsebino, ki se je ne tiče.

Menjava naprave s prijavo

Kontinuiteta med napravami mora biti vezana na preverjen račun in njegova trenutna pooblastila. Po prijavi strežnik naloži le pogovore, ki so dodeljeni temu računu in pravemu najemniku. Pri občutljivih dejanjih – na primer spremembi naslova, informacijah o pogodbi ali naročilu – je smiselna ponovna avtentikacija, tudi če je splošni klepet še vedno aktiven.

Trenutne smernice NIST SP 800-63B glede upravljanja sej opisujejo seje kot povezavo med avtenticirano osebo in storitvijo preko skrivnosti seje. Zahtevajo tako časovne omejitve neaktivnosti kot tudi skupne časovne omejitve ter strežniško prekinitev. Za produktne ekipe iz tega sledi: „prijavljen“ ne sme biti neomejeno stanje, poteklega žetona računa ali seje pa se ne sme obuditi z še obstoječo zgodovino klepeta.

Koda za prenos le kot strogo omejen most

Nekatere ponudbe želijo omogočiti anonimno menjavo s pomočjo enkratne kode ali kode QR. V tem primeru mora biti koda kratkotrajna, enkratno uporabna in preklicljiva. Ne vsebuje niti prepisa niti podatkov o strankah, temveč le naključno referenco na odobreno, minimalno stanje pogovora. Po uspešnem prevzemu stara referenca postane neveljavna. Koda je most za kontekst, ne dokazilo o identiteti in ne odobritev občutljivih podatkov o računu.

Pravila poteka morajo biti v vmesniku razumljiva

Tehnične časovne omejitve rešijo le polovico naloge. Uporabniki morajo vedeti, ali in kako dolgo bo njihov pogovor shranjen. Smernice NIST o uporabniški izkušnji (Customer Experience) poudarjajo jasne informacije o koncu seje, da se delo ne izgubi in da se ljudje ne poslužujejo nevarnih rešitev.

Dober koncept poteka zato neposredno v klepetu odgovarja na vprašanja:

• Ali pogovor ostane ohranjen po zaprtju?
• Ali to velja le za ta brskalnik ali tudi po prijavi na drugih napravah?
• Kdaj se seja konča zaradi neaktivnosti in kdaj se shranjena zgodovina izbriše?
• Katere dele lahko uporabnik sam odstrani ali izvozi?
• Kaj se zgodi z odprtim primerom podpore po poteku seje?

Pred pričakovanim koncem seje lahko nevsiljivo obvestilo ponudi možnost, da se odprte informacije shranijo ali predajo podpori. Po poteku mora vmesnik jasno razlikovati med „seja končana“ in „zgodovina izbrisana“. Eno se nanaša na dostop, drugo na hrambo.

Human Handoff: Predaja konteksta, razkritje odgovornosti

Pri prehodu na človeka je kratka, strukturirana povzetek pogosto dragocenejša od nekomentirane dolge zgodovine. Navaja zadevo, potrjene podatke, že predlagane korake, odprta vprašanja in uporabljene vire. Občutljive vsebine se predajo le, če so potrebne za primer podpore in so bile za to odobrene.

Uporabnik bi moral videti, da sedaj prevzema človek, katere informacije se posredujejo in ali nastane nov čakalni čas. Hkrati mora umetna inteligenca po predaji vedeti, ali mora molčati, pomagati le organizacijsko ali pozneje znova prevzeti vodenje. Konkretne sprožilce in pravila eskalacije opisuje prispevek o predaji človeku (Human Handoff) v spletnem chatbotu.

Izvedba v šestih korakih

1. Določite scenarije uporabe: Ločeno specificirajte navigacijo po strani, poznejšo vrnitev, menjavo naprave in predajo človeku.
2. Definirajte stopnje zaupanja: Določite, katere vsebine so na voljo anonimno, po povezavi z računom ali šele po ponovni avtentikaciji.
3. Minimizirajte stanje: Zasnovajte strukturirano stanje nadaljevanja (Resume-State) s ciljem, potrjenimi dejstvi, odprtimi točkami in časom poteka.
4. Uveljavite življenjski cikel: Na strežniški strani preizkusite omejitev neaktivnosti, absolutno omejitev, izbris, preklic in odjavo.
5. Oblikujte predaje: Naredite vidne potrditev uporabnika, povzetek za podporo, status čakanja in odgovornost.
6. Merite uspeh brez celotnega besedila: Beležite dogodke, kot so „ponujeno nadaljevanje“, „sprejeto“, „poteklo“, „menjava naprave zaključena“ in „predaja uspešna“. Kako to doseči z minimalno količino podatkov, prikazuje vodnik po analitiki AI chatbotov.

Testna matrika za namizne računalnike, mobilne naprave in realne mejne primere

Pred začetkom uporabe ne bi smela delovati le idealna pot. Majhna testna matrika pokriva tipične napake:

• navigacija znotraj istega spletnega mesta z odprtim in zaprtim oknom klepeta,
• vrnitev v istem brskalniku pred in po omejitvi neaktivnosti,
• vrnitev v zasebnem oknu ali po izbrisu lokalnih podatkov brskalnika,
• menjava naprave pred in po prijavi ter po odjavi,
• sprememba računa na skupno rabljeni napravi,
• potekla, že uporabljena ali preklicana koda za prenos,
• izbrisan pogovor, blokiran račun in spremenjena pooblastila najemnika,
• nadaljevanje po posodobitvi baze znanja,
• predaja z izrecno odobrenim povzetkom in brez njega,
• dolgi naslovi, jeziki z drugačno dolžino besedila in mobilne širine brez vodoravnega prelivanja.

Pri vsakem primeru sodijo poleg vidnega odgovora k preverjanju tudi omrežni dostopi, neveljavnost seje, dnevniki napak in analitični dogodki. Chatbot lahko prijazno razloži, da kontekst ni več na voljo. Nikoli pa ga ne sme rekonstruirati iz podobnih uporabniških podatkov ali ga dodeliti novi osebi.

Zaključek: Kontinuiteta je nadzorovana predaja

Dobra izkušnja z nadaljevanjem ne pomeni shranjevanja vsega za vedno. Pomeni prenos pravega, minimalnega konteksta preko jasno omejene poti. Isti brskalnik, prijavljena druga naprava in človeški podporni kanal za to potrebujejo različna pravila zaupanja in poteka. Če stanje pogovora, identiteta in pooblastila ostanejo ločeni, nastane udobje brez tihega razkritja podatkov.

Kdor ta pravila zgodaj vgradi v Conversational UX, lahko zmanjša prekinitve sej in naredi predaje podpori razumljivejše. Funkcije ChatReact ponujajo pregled možnih gradnikov za spletne chatbote; konkretno konfiguracijo sej in varstva podatkov pa je treba nato načrtovati in preizkusiti glede na lasten primer uporabe.

Viri

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Splošna uredba o varstvu podatkov, 5. člen