Nastavak razgovora s chatbotom: Sesije, promjena uređaja i sigurna predaja

Posjetitelj u web chatbotu postavi tri pitanja, prijeđe na stranicu proizvoda i kasnije se vrati. Klijentica započne razgovor na pametnom telefonu i želi nastaviti na prijenosnom računalu. U podršci naposljetku preuzima čovjek. U sva tri slučaja očekivanje je isto: razgovor se treba smisleno nastaviti. Međutim, tehnički i organizacijski to su tri različita zadatka. Tko ih pomiješa, riskira gubitak konteksta, neželjeno dijeljenje podataka ili sesiju koja ostaje aktivna dulje nego što je potrebno.

„Nastaviti“ nije isto što i „prepoznati“

Za planiranje pomaže jasna razdvojba triju razina kontinuiteta:

1. Unutar jednog posjeta: Razgovor ostaje sačuvan dok netko kormilari između stranica ili zatvori i ponovno otvori prozor chata.
2. Prilikom kasnijeg povratka: Isti preglednik unutar ograničenog roka ponovno pronalazi raniji razgovor.
3. Između različitih uređaja: Osoba nastavlja razgovor na drugom pregledniku ili uređaju. Za to je u pravilu potrebna pouzdana povezanost s računom ili namjerno pokrenut, kratkotrajan postupak prijenosa.

Postojeća povijest razgovora još uvijek ne dokazuje identitet. Tko posjeduje ID razgovora ili poveznicu, stoga ne smije automatski pristupati narudžbama, ugovornim podacima ili osobnim informacijama. To je ista osnovna granica koja vrijedi i kod razdvajanja javnog chatbota i autentificiranog korisničkog portala: kontekst može stvoriti udobnost, ali ne zamjenjuje prijavu i provjeru ovlaštenja.

Tehnička osnova: Referenca u pregledniku, stanje na poslužitelju

Robusna arhitektura u pregledniku pohranjuje, ako je moguće, samo nasumičnu referencu bez značenja. Pripadajuće stanje razgovora nalazi se na strani poslužitelja i provjerava se pri svakom zahtjevu na temelju valjanosti, zakupca (tenant), ovlaštenja i datuma isteka. Preporuke OWASP-a o upravljanju sesijama savjetuju beznačajne identifikatore sesija koje je teško pogoditi i vremenska ograničenja kontrolirana na poslužitelju. Identifikatori sesija također ne spadaju u URL-ove: mogu se proslijediti putem povijesti, dnevnika, referala ili dijeljenih poveznica.

Pohrana u pregledniku ima različite dosege. Prema MDN Web Storage API-ju, sessionStorage je vezan uz karticu i podrijetlo (origin) te obično završava sa zatvaranjem kartice. localStorage, s druge strane, ostaje sačuvan kroz sesije preglednika, ali i dalje samo u istom profilu preglednika. Ni jedno ni drugo ne stvara identitet na više uređaja. Izravno pohranjivanje osjetljivih transkripata ili trajnih pristupnih tokena ondje dodatno povećava posljedice pristupa skripti ili uređaju.

Koje bi podatke stanje trebalo sadržavati

Za korisno nastavljanje sustavu je često potrebno manje od potpunog transkripta. Kompaktan, verzioniran skup podataka o stanju može biti dovoljan:

• trenutačni upit i potvrđeni cilj,
• već razjašnjene, neosjetljive činjenice,
• otvorena dodatna pitanja i sljedeći smisleni korak,
• korišteni izvori znanja ili njihove verzije,
• status privole, autentifikacije i predaje (handoff),
• trenutak posljednje aktivnosti i utvrđeni datum isteka.

Tako se razgovor može dosljedno nastaviti bez beskonačnog kopiranja svake ranije poruke u aktivni prompt. Potpuna povijest može se pohraniti odvojeno, kraće ili nikako – ovisno o svrsi, očekivanju korisnika i utvrđenim pravilima. Za osobne podatke, načela iz Članka 5. GDPR-a kao što su ograničenje svrhe, smanjenje količine podataka i ograničenje pohrane predstavljaju važna dizajnerska načela. To ne zamjenjuje pojedinačno pravno savjetovanje, ali pruža jasan zahtjev za proizvod: pohranjujte samo ono što je zaista potrebno za navedenu svrhu.

Različit tretman anonimnih i prijavljenih razgovora

Anonimni povratak u istom pregledniku

Kod anonimnih posjetitelja funkcija „nastavi razgovor“ trebala bi ostati ograničena pogodnost. Smisleni su kratak rok pohrane, jasno vidljiva naredba za brisanje i objašnjenje da se povijest može ponovno pronaći samo na tom pregledniku. Chatbot iz povratka ne smije zaključiti da ispred njega sjedi ista fizička osoba. Nakon isteka ili gubitka lokalne reference započinje nova sesija.

U praksi chatbot pri povratku može pitati: „Želite li nastaviti razgovor o odabiru proizvoda ili započeti novi?“ To je bolje nego tiho aktivirati stari kontekst. Na zajedničkim uređajima ova potvrda sprječava da sljedeća osoba odmah vidi sadržaj koji je se ne tiče.

Promjena uređaja uz prijavu

Kontinuitet na više uređaja trebao bi biti vezan uz verificirani račun i njegove trenutačne ovlasti. Nakon prijave poslužitelj učitava samo razgovore koji su dodijeljeni tom računu i ispravnom zakupcu. Kod osjetljivih radnji – poput promjene adrese, informacija o ugovoru ili narudžbe – smislena je ponovna autentifikacija, čak i ako je opći chat još uvijek aktivan.

Važeće smjernice NIST SP 800-63B o upravljanju sesijama opisuju sesije kao vezu između autentificirane osobe i usluge putem tajne sesije. Zahtijevaju i neaktivna i ukupna vremenska ograničenja te prekid na strani poslužitelja. Za timove koji razvijaju proizvod iz toga slijedi: „Prijavljen“ ne smije biti neograničeno stanje, a istekli token računa ili sesije ne smije se oživljavati putem još postojeće povijesti chata.

Kôd za prijenos samo kao strogo ograničeni most

Neke usluge žele omogućiti anonimnu promjenu uređaja putem jednokratnog koda ili QR koda. U tom slučaju kôd treba biti kratkotrajan, jednokratno upotrebljiv i moguć za opoziv. On ne sadrži ni transkript ni podatke o kupcima, već samo nasumičnu referencu na odobreno, minimalno stanje razgovora. Nakon uspješnog preuzimanja stara referenca postaje nevažeća. Kôd je most za kontekst, a ne dokaz identiteta ili odobrenje osjetljivih podataka o računu.

Pravila isteka moraju biti razumljiva u sučelju

Tehnička vremenska ograničenja rješavaju samo polovicu zadatka. Korisnici moraju znati hoće li i koliko dugo njihov razgovor ostati sačuvan. Smjernice NIST-a o korisničkom iskustvu (CX) naglašavaju jasne informacije o završetku sesije kako se rad ne bi izgubio i kako ljudi ne bi pribjegavali nesigurnim zaobilaznim rješenjima.

Dobar koncept isteka stoga izravno u chatu odgovara na pitanja:

• Ostaje li razgovor sačuvan nakon zatvaranja?
• Vrijedi li to samo za ovaj preglednik ili i nakon prijave na drugim uređajima?
• Kada sesija završava zbog neaktivnosti i kada se izbrisana povijest uklanja?
• Koje dijelove korisnik može sam ukloniti ili izvesti?
• Što se događa s otvorenim slučajem podrške nakon isteka?

Prije očekivanog završetka sesije diskretna obavijest može ponuditi spremanje otvorenih informacija ili njihovo prosljeđivanje podršci. Nakon isteka sučelje bi trebalo jasno razlikovati „sesija je završena“ od „povijest je izbrisana“. Jedno se odnosi na pristup, drugo na pohranu.

Human Handoff: Predaja konteksta i prikazivanje odgovornosti

Prilikom prelaska na ljudskog agenta kratak strukturirani sažetak često je vrjedniji od dugačke povijesti bez komentara. Navodi upit, potvrđene podatke, već predložene korake, otvorena pitanja i korištene izvore. Osjetljivi sadržaji predaju se samo ako su potrebni za slučaj podrške i odobreni za to.

Korisnik bi trebao vidjeti da sada preuzima čovjek, koje se informacije prosljeđuju i nastaje li novo vrijeme čekanja. Istovremeno, umjetna inteligencija nakon predaje mora znati treba li šutjeti, pružati samo organizacijsku podršku ili kasnije ponovno preuzeti razgovor. Konkretne okidače i pravila eskalacije opisuje članak o Human Handoff-u u web chatbotu.

Implementacija u šest koraka

1. Imenovanje scenarija korištenja: Odvojeno specificirajte navigaciju stranicom, kasniji povratak, promjenu uređaja i ljudsku predaju.
2. Definiranje razina povjerenja: Utvrdite koji su sadržaji dostupni anonimno, nakon povezivanja računa ili tek nakon ponovne autentifikacije.
3. Minimiziranje stanja: Dizajnirajte strukturirano stanje nastavka (resume state) s ciljem, potvrđenim činjenicama, otvorenim točkama i vremenom isteka.
4. Prisilno provođenje životnog ciklusa: Testirajte ograničenje neaktivnosti, apsolutno ograničenje, brisanje, opoziv i odjavu na strani poslužitelja.
5. Oblikovanje predaja: Učinite vidljivima potvrdu korisnika, sažetak za podršku, status čekanja i nadležnost.
6. Mjerenje uspjeha bez punog teksta: Bilježite događaje poput „ponuđen nastavak“, „prihvaćeno“, „isteklo“, „promjena uređaja dovršena“ i „predaja uspješna“. Kako to postići uz štednju podataka pokazuje vodič za analitiku AI chatbota.

Matrica testiranja za stolna računala, mobilne uređaje i stvarne granične slučajeve

Prije pokretanja ne bi trebala funkcionirati samo idealna staza. Mala matrica testiranja pokriva tipične pogreške:

• Navigacija unutar iste web stranice s otvorenim i zatvorenim prozorom chata,
• povratak u istom pregledniku prije i nakon ograničenja neaktivnosti,
• povratak u privatnom prozoru ili nakon brisanja lokalnih podataka preglednika,
• promjena uređaja prije i nakon prijave te nakon odjave,
• promjena računa na zajedničkom uređaju,
• istekli, već iskorišteni ili opozvani kôd za prijenos,
• izbrisani razgovor, blokirani račun i promijenjena ovlaštenja zakupca,
• nastavak nakon ažuriranja baze znanja,
• predaja sa sažetkom i bez izričito odobrenog sažetka,
• dugački naslovi, jezici s drugačijom duljinom teksta i mobilne širine bez horizontalnog prelijevanja.

U svakom slučaju, osim vidljivog odgovora, u provjeru spadaju i mrežni pristupi, invalidacija sesije, dnevnici pogrešaka i događaji analitike. Chatbot smije ljubazno objasniti da kontekst više nije dostupan. Ali ga nikada ne smije rekonstruirati iz sličnih podataka korisnika ili ga dodijeliti novoj osobi.

Zaključak: Kontinuitet je kontrolirana predaja

Dobar doživljaj nastavka ne znači pohranjivanje svega zauvijek. To znači nošenje pravog, minimalnog konteksta preko jasno ograničene dionice. Isti preglednik, prijavljeni drugi uređaj i ljudski kanal podrške za to trebaju različita pravila povjerenja i isteka. Kada stanje razgovora, identitet i ovlaštenja ostanu razdvojeni, nastaje udobnost bez tihog dijeljenja podataka.

Tko rano ugradi ova pravila u Conversational UX, može smanjiti prekide sesija i učiniti predaje podršci razumljivijima. ChatReact značajke pružaju pregled mogućih gradivnih blokova za web chatbotove; konkretnu konfiguraciju sesija i zaštite podataka zatim treba planirati i testirati u skladu s vlastitim slučajem upotrebe.

Izvori

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Opća uredba o zaštiti podataka, Članak 5.