Chatbot-keskustelujen jatkaminen: istunnot, laitteen vaihto ja turvallinen siirto

Kävijä esittää verkkosivuston chatbotille kolme kysymystä, siirtyy tuotesivulle ja palaa myöhemmin takaisin. Asiakas aloittaa keskustelun älypuhelimella ja haluaa jatkaa kannettavalla tietokoneella. Lopulta asiakastuelsta ihminen ottaa tilanteen haltuunsa. Kaikissa kolmessa tapauksessa odotus on sama: keskustelun tulisi jatkua mielekkäästi. Teknisesti ja organisatorisesti kyseessä on kuitenkin kolme täysin eri tehtävää. Jos ne sekoitetaan keskenään, riskinä ovat kontekstin katoaminen, tahattomat tietovuodot tai istunto, joka pysyy aktiivisena tarpeettoman kauan.

„Jatkaminen“ ei tarkoita samaa kuin „tunnistaminen“

Suunnittelun helpottamiseksi on hyvä erottaa toisistaan kolme jatkuvuuden tasoa:

1. Saman vierailun aikana: Keskustelu säilyy, kun käyttäjä siirtyy sivulta toiselle tai sulkee ja avaa ikkunan uudelleen.
2. Myöhemmän paluun yhteydessä: Sama selain löytää aikaisemman keskustelun määritellyn aikarajan puitteissa.
3. Laitteiden välillä: Käyttäjä jatkaa keskustelua toisella selaimella tai laitteella. Tämä vaatii yleensä luotettavan tiliin yhdistämisen tai tietoisesti käynnistetyn, lyhytkestoisen siirtoprosessin.

Olemassa oleva keskusteluhistoria ei vielä todista henkilöllisyyttä. Keskustelutunnisteen (ID) tai linkin hallussapito ei siten saa automaattisesti myöntää pääsyä tilauksiin, sopimustietoihin tai henkilötietoihin. Tämä on sama perusraja, joka pätee myös julkisen chatbotin ja autentifioidun asiakasportaalin erottamiseen: konteksti lisää mukavuutta, mutta se ei korvaa kirjautumista eikä käyttöoikeuksien tarkistusta.

Tekninen perusta: viite selaimessa, tila palvelimella

Vankka arkkitehtuuri tallentaa selaimelle mieluiten vain satunnaisen, ei-selittävän viitteen. Sitä vastaava keskustelutila sijaitsee palvelimella, ja sen voimassaolo, järjestelmäosio, valtuudet sekä vanhentumisaika tarkistetaan jokaisen pyynnön yhteydessä. OWASP:n istunnonhallinnan suositukset kehottavat käyttämään merkityksettömiä, vaikeasti arvattavia istuntotunnisteita sekä palvelinpuolella hallittuja aikarajoja. Istuntotunnisteet eivät myöskään kuulu URL-osoitteisiin: ne voivat levitä historian, lokien, viittaajien tai jaettujen linkkien kautta.

Selaimen tallennustilalla on eri laajuuksia. MDN Web Storage API:n mukaan sessionStorage on sidottu välilehteen ja alkuperään (origin), ja se päättyy yleensä välilehden sulkemiseen. localStorage sitä vastoin säilyy selainistuntojen yli, mutta edelleen vain samassa selainprofiilissa. Kumpikaan ei luo laitteiden välistä identiteettiä. Arkaluontoisten keskustelutallenteiden tai pysyvien pääsytunnisteiden tallentaminen suoraan niihin lisää lisäksi skriptihyökkäyksen tai laitteen vaarantumisen seurauksia.

Mitä tietoja tilan tulisi sisältää

Hyödyllistä jatkamista varten järjestelmä tarvitsee usein vähemmän tietoa kuin täydellisen keskusteluhistorian. Tiivis, versioitu tilatietue voi riittää:

• nykyinen asia ja vahvistettu tavoite,
• jo selvitetyt, ei-arkaluontoiset tosiasiat,
• avoimet kysymykset ja seuraava mielekäs vaihe,
• käytetyt tietolähteet tai niiden versiot,
• suostumus-, autentikointi- ja Handoff-tila,
• viimeisimmän aktiivisuuden ajankohta sekä määritetty vanhentumispäivä.

Näin keskustelua voidaan jatkaa johdonmukaisesti ilman, että jokaista aiempaa viestiä kopioidaan rajoituksetta aktiiviseen kehotteeseen (prompt). Täydellinen historia voidaan säilyttää erillään, lyhennettynä tai ei lainkaan – käyttötarkoituksen, käyttäjän odotusten ja asetettujen sääntöjen mukaan. Henkilötietojen osalta erityisesti Tietosuoja-asetuksen (GDPR) 5 artiklan käyttötarkoitussidonnaisuus, tietojen minimointi ja säilytyksen rajoittaminen ovat tärkeitä suunnitteluperiaatteita. Tämä ei korvaa oikeudellista neuvontaa, mutta antaa selkeän tuotevaatimuksen: tallenna vain se, mitä tiettyyn tarkoitukseen todella tarvitaan.

Käsittele anonyymeja ja kirjautuneita keskusteluja eri tavalla

Anonyymi paluu samalla selaimella

Anonyymien kävijöiden kohdalla „keskustelun jatkamisen“ tulisi pysyä rajoitettuna mukavuustoimintona. Järkeviä ratkaisuja ovat lyhyt säilytysaika, selkeästi näkyvä poistokomento sekä selitys siitä, että historia löytyy vain tästä selaimesta. Chatbot ei saa päätellä palaamisesta, että sen edessä istuu sama luonnollinen henkilö. Aikarajan umpeutumisen tai paikallisen viitteen katoamisen jälkeen alkaa uusi istunto.

Käytännössä chatbot voi kysyä paluun yhteydessä: „Haluatko jatkaa tuotevalintaa koskevaa keskustelua vai aloittaa alusta?“ Tämä on parempi kuin vanhan kontekstin hiljainen aktivoiminen. Yhteiskäyttöisillä laitteilla tämä vahvistus estää seuraavaa henkilöä näkemästä välittömästi sisältöä, joka ei kuulu hänelle.

Laitteen vaihto kirjautuneena

Laitteiden välisen jatkuvuuden tulisi olla sidottu vahvistettuun tiliin ja sen senhetkisiin käyttöoikeuksiin. Kirjautumisen jälkeen palvelin lataa vain keskustelut, jotka on osoitettu tälle tilille ja oikealle järjestelmäosiolle. Arkaluontoisissa toimissa – kuten osoitteenmuutoksessa, sopimustietojen kyselyssä tai tilauksessa – uudelleenautentikointi on järkevää, vaikka yleinen chat olisi vielä aktiivinen.

Uusin NIST SP 800-63B -ohjeistus istunnonhallinnasta kuvaa istunnot sidoksena autentifioidun henkilön ja palvelun välillä istuntosalaisuuden kautta. Se vaatii sekä inaktiivisuus- että kokonaisaikarajoja sekä palvelinpuolen lopetusta. Tuotetiimeille tämä tarkoittaa: „Kirjautunut“ ei saa olla rajoittamaton tila, eikä vanhentunutta tili- tai istuntotunnistetta saa herättää henkiin vielä olemassa olevalla chat-historialla.

Siirtokoodi vain tiukasti rajoitettuna siltana

Jotkin palvelut haluavat mahdollistada anonyymin laitteenvaihdon kertakäyttökoodilla tai QR-koodilla. Tällöin koodin tulee olla lyhytikäinen, kerran käytettävä ja peruutettavissa. Se ei sisällä keskustelutallennetta eikä asiakastietoja, vaan ainoastaan satunnaisen viitteen jaettuun, minimaaliseen keskustelutilaan. Onnistuneen siirron jälkeen vanha viite mitätöidään. Koodi on siltana kontekstille, ei henkilöllisyyden osoitus eikä lupa tarkastella arkaluonteisia tilitietoja.

Vanhentumissääntöjen on oltava ymmärrettäviä käyttöliittymässä

Tekniset aikarajat ratkaisevat vain puolet tehtävästä. Käyttäjien on tiedettävä, säilyykö heidän keskustelunsa ja kuinka kauan. NIST:n asiakaskokemusta koskevat ohjeet korostavat selkeitä tietoja istunnon päättymisestä, jotta työtä ei mene hukkaan eivätkä ihmiset turvaudu turvattomiin kiertoteihin.

Hyvä vanhentumiskonsepti vastaa siksi suoraan chatissa seuraaviin kysymyksiin:

• Säilyykö keskustelu sulkemisen jälkeen?
• Päteekö tämä vain tähän selaimen vai myös kirjautumisen jälkeen muilla laitteilla?
• Milloinka istunto päättyy inaktiivisuuden vuoksi, ja milloin tallennettu historia poistetaan?
• Mitä osia käyttäjä voi itse poistaa tai viedä?
• Mitä tapahtuu avoimelle tukipyynnölle istunnon vanhenemisen jälkeen?

Ennen odotettavissa olevaa istunnon päättymistä hienovarainen ilmoitus voi tarjota mahdollisuutta tallentaa avoimet tiedot tai siirtää ne asiakastuelle. Vanhentumisen jälkeen käyttöliittymän tulee erottaa selkeästi „istunto päättynyt“ ja „historia poistettu“. Toinen koskee pääsyä, toinen säilytystä.

Human Handoff: siirrä konteksti, tee vastuusta näkyvää

Ihmisasiakaspalvelijaan siirryttäessä lyhyt, strukturoitu yhteenveto on usein arvokkaampi kuin kommentoimaton pitkä historia. Siinä mainitaan asia, vahvistetut tiedot, jo ehdotetut vaiheet, avoin kysymys ja käytetyt lähteet. Arkaluontoista sisältöä siirretään vain, jos se on tukipyyntöä varten tarpeellista ja siihen on annettu lupa.

Käyttäjän tulee nähdä, että ihminen ottaa nyt vastuun, mitä tietoja välitetään ja syntyykö uusi odotusaika. Samalla tekoälyn on tiedettävä siirron jälkeen, tuleeko sen olla hiljaa, tukea vain organisatorisesti vai voiko se ottaa vastuun myöhemmin takaisin. Konkreettisia laukaisimia ja eskalointisääntöjä kuvataan artikkelissa Human Handoff verkkosivuston chatbotissa.

Toteutus kuudessa vaiheessa

1. Määritä käyttötapaukset: Määrittele erikseen sivunavigointi, myöhempi paluu, laitteen vaihto ja siirto ihmiselle.
2. Määritä luottamustasot: Päätä, mitkä sisällöt ovat saatavilla anonyymisti, tiliin yhdistämisen jälkeen tai vasta uudelleenautentikoinnin jälkeen.
3. Minimoi tila: Suunnittele strukturoitu jatkotila (resume-state), joka sisältää tavoitteen, vahvistetut tosiasiat, avoimet kohdat ja vanhentumisajan.
4. Pakota elinkaari: Testaa palvelinpuolella inaktiivisuusraja, ehdoton aikaraja, poisto, peruutus ja uloskirjautuminen.
5. Muotoile siirrot: Tee käyttäjän vahvistus, tuen yhteenveto, odotustila ja vastuualueet näkyviksi.
6. Mittaa menestystä ilman kokotekstiä: Kerää tapahtumia, kuten „Jatkamista tarjottu“, „Hyväksytty“, „Vanhentunut“, „Laitteen vaihto suoritettu“ ja „Siirto onnistui“. Miten tämä onnistuu tietosuojaa kunnioittaen, selvitetään oppaassa Tekoäly-chatbot-analytiikka.

Testausmatriisi työpöydälle, mobiilille ja todellisille rajatapauksille

Ennen julkaisua ei pelkän ihannetapauksen (happy path) tulisi toimia. Pieni testausmatriisi kattaa tyypilliset virheet:

• Navigointi saman verkkosivuston sisällä chat-ikkunan ollessa auki ja kiinni,
• Paluu samassa selaimessa ennen inaktiivisuusrajaa ja sen jälkeen,
• Paluu yksityisessä ikkunassa tai selaimen paikallisten tietojen poistamisen jälkeen,
• Laitteen vaihto ennen kirjautumista, sen jälkeen sekä uloskirjautumisen jälkeen,
• Tilin vaihto yhteiskäyttöisellä laitteella,
• Vanhentunut, jo käytetty tai peruutettu siirtokoodi,
• Poistettu keskustelu, estetty tili ja muuttuneet järjestelmäosion käyttöoikeudet,
• Keskustelun jatkaminen tietopohjan päivittämisen jälkeen,
• Siirto ihmiselle nimenomaisesti hyväksytyn yhteenvedon kanssa ja ilman sitä,
• Pitkät otsikot, eripituiset tekstit eri kielillä ja mobiilileveydet ilman vaakasuoraa ylijuoksua (overflow).

Jokaisessa tapauksessa näkyvän vastauksen lisäksi tarkistukseen kuuluvat verkkopyynnöt, istunnon mitätöinti, virhelokit ja analytiikkatapahtumat. Chatbot saa selittää ystävällisesti, että konteksti ei ole enää saatavilla. Se ei saa kuitenkaan koskaan rekonstruoida sitä samanlaisista käyttäjätiedoista tai osoittaa sitä uudelle henkilölle.

Tiivistelmä: Jatkuvuus on hallittu luovutus

Hyvä jatkamiskokemus ei tarkoita kaiken tallentamista ikuisesti. Se tarkoittaa oikean, minimaalisen kontekstin ottamista mukaan selkeästi rajatulla matkalla. Sama selain, kirjautunut toinen laite ja ihmisen tarjoama tukikanava tarvitsevat tätä varten erilaiset luottamus- ja vanhentumissäännöt. Kun keskustelutila, identiteetti ja käyttöoikeudet pidetään erillään, syntyy mukavuutta ilman hiljaista tietojen luovuttamista.

Ne, jotka sisällyttävät nämä säännöt keskustelukäyttöliittymään (Conversational UX) varhaisessa vaiheessa, voivat vähentää istuntojen keskeytymisiä ja tehdä tuen siirroista ymmärrettävämpiä. ChatReact-ominaisuudet antavat yleiskuvan verkkosivustojen chatbotteihin mahdollisesti sisältyvistä rakennuspalikoista; konkreettinen istunto- ja tietosuoja-asetusten konfigurointi tulee sen jälkeen suunnitella ja testata omaan käyttötapaukseen sopivaksi.

Lähteet

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Yleinen tietosuoja-asetus, 5 artikla