Kontynuacja rozmowy z chatbotem: Sesje, zmiana urządzeń i bezpieczne przekazywanie wątku

Odwiedzający zadaje w chatbocie na stronie internetowej trzy pytania, przechodzi na stronę produktu, a później wraca. Klientka zaczyna rozmowę na smartfonie, a chce ją kontynuować na laptopie. W dziale wsparcia rozmowę przejmuje w końcu człowiek. We wszystkich trzech przypadkach oczekiwanie jest jedno: rozmowa powinna płynnie toczyć się dalej. Z technicznego i organizacyjnego punktu widzenia są to jednak trzy zupełnie różne zadania. Łączenie ich niesie ryzyko utraty kontekstu, niechcianego udostępnienia danych lub utrzymywania sesji aktywnej dłużej niż to konieczne.

„Kontynuacja” to nie to samo co „rozpoznanie”

W planowaniu pomaga jasne rozróżnienie trzech poziomów ciągłości:

1. W ramach jednej wizyty: Rozmowa zostaje zachowana, gdy ktoś przechodzi między podstronami albo zamyka i ponownie otwiera okno czatu.
2. Przy późniejszym powrocie: Ta sama przeglądarka odnajduje wcześniejszą konwersację w określonym przedziale czasowym.
3. Między urządzeniami: Użytkownik kontynuuje rozmowę w innej przeglądarce lub na innym urządzeniu. Wymaga to z reguły niezawodnego powiązania z kontem lub celowo uruchomionego, krótkotrwałego procesu transferu.

Istniejąca historia rozmowy nie stanowi jeszcze dowodu tożsamości. Posiadanie identyfikatora rozmowy (ID) lub linku nie powinno automatycznie dawać dostępu do zamówień, danych z umów czy danych osobowych. Jest to ta sama podstawowa granica, która obowiązuje przy rozdzielaniu publicznego chatbota i uwierzytelnionego portalu klienta: kontekst zwiększa wygodę, ale nie zastępuje logowania ani weryfikacji uprawnień.

Podstawa techniczna: Referencja w przeglądarce, stan na serwerze

Solidna architektura zapisuje w przeglądarce jedynie losową, nic niemówiącą referencję. Powiązany stan rozmowy spoczywa po stronie serwera i przy każdym żądaniu jest sprawdzany pod kątem ważności, dostawcy (tenant), uprawnień oraz daty wygaśnięcia. Zalecenia OWASP dotyczące zarządzania sesjami wskazują na konieczność stosowania bezznaczeniowych, trudnych do odgadnięcia identyfikatorów sesji oraz limitów czasowych kontrolowanych po stronie serwera. Identyfikatory sesji nie powinny trafiać do adresów URL: mogą zostać przekazane dalej poprzez historię przeglądania, logi, nagłówki Referrer czy udostępnione linki.

Pamięć przeglądarki ma różny zasięg. Według MDN Web Storage API obiekt sessionStorage jest powiązany z kartą oraz domeną i zazwyczaj kończy działanie wraz z zamknięciem karty. Z kolei localStorage pozostaje zachowany między sesjami przeglądarki, ale wciąż tylko w ramach tego samego profilu przeglądarki. Żadne z nich nie tworzy tożsamości międzyurządzeniowej. Zapisywanie tam bezpośrednio wrażliwych transkryptów lub trwałych tokenów dostępowych zwiększa ponadto konsekwencje nieuprawnionego dostępu do skryptu lub urządzenia.

Jakie dane powinien zawierać stan rozmowy

Do pomocnego kontynuowania wątku system często potrzebuje znacznie mniej niż pełnego transkryptu. Wystarczyć może zwięzły, wersjonowany zestaw danych o stanie:

• aktualna sprawa i potwierdzony cel,
• wyjaśnione już, niewrażliwe fakty,
• otwarte pytania i kolejny sensowny krok,
• wykorzystane źródła wiedzy lub ich wersje,
• status zgód, uwierzytelnienia oraz przekazania (handoff),
• czas ostatniej aktywności i ustalona data wygaśnięcia.

Pozwala to spójnie kontynuować konwersację bez konieczności bezterminowego kopiowania każdej wcześniejszej wiadomości do aktywnego promptu. Pełny przebieg rozmowy może być przechowywany osobno, w skróconej formie lub wcale – w zależności od celu, oczekiwań użytkownika i ustalonych reguł. W przypadku danych osobowych kluczowymi zasadami projektowymi są w szczególności zasada ograniczenia celu, minimalizacji danych i ograniczenia przechowywania wynikające z artykułu 5 RODO. Nie zastępuje to indywidualnej porady prawnej, ale daje jasne wymaganie produktowe: zapisywać tylko to, co jest naprawdę niezbędne do określonego celu.

Różne traktowanie rozmów anonimowych i zalogowanych

Anonimowy powrót w tej samej przeglądarce

W przypadku anonimowych użytkowników funkcja „kontynuuj rozmowę” powinna pozostać ograniczonym ułatwieniem. Sensowne rozwiązanie to krótki okres przechowywania, łatwo widoczna opcja usunięcia oraz wyjaśnienie, że historię można odnaleźć tylko w tej konkretnej przeglądarce. Chatbot nie może wnioskować z samego faktu powrotu, że ma przed sobą tę samą osobę fizyczną. Po wygaśnięciu sesji lub utracie lokalnej referencji rozpoczyna się nowa sesja.

W praktyce chatbot może przy powrocie zapytać: „Czy chcesz kontynuować rozmowę dotyczącą wyboru produktu, czy zacząć od nowa?”. To lepsze rozwiązanie niż milcząca aktywacja starego kontekstu. Na współdzielonych urządzeniach takie potwierdzenie zapobiega sytuacji, w której kolejna osoba od razu zobaczy treści, które jej nie dotyczą.

Zmiana urządzenia z logowaniem

Ciągłość między urządzeniami powinna być powiązana ze zweryfikowanym kontem i jego aktualnymi uprawnieniami. Po zalogowaniu serwer ładuje tylko te rozmowy, które są przypisane do tego konta i właściwego podmiotu. Przy operacjach wrażliwych – takich jak zmiana adresu, informacja o umowie czy złożenie zamówienia – wskazana jest ponowna autoryzacja, nawet jeśli ogólny czat jest nadal aktywny.

Aktualne wytyczne NIST SP 800-63B dotyczące zarządzania sesją opisują sesję jako powiązanie między uwierzytelnioną osobą a usługą za pomocą tajnego klucza sesji (session secret). Wymagają one limitów czasu bezczynności, jak i bezwzględnych limitów czasu trwania oraz zakończenia sesji po stronie serwera. Dla zespołów produktowych wynika z tego jedno: status „zalogowany” nie może być stanem bezterminowym, a wygasły token konta lub sesji nie może być przywracany do życia przez wciąż istniejącą historię czatu.

Kod transferowy jedynie jako ściśle ograniczony pomost

Niektóre usługi chcą umożliwić anonimową zmianę urządzenia za pomocą jednorazowego kodu lub kodu QR. W takim przypadku kod powinien być krótkotrwały, jednorazowy i możliwy do unieważnienia. Nie zawiera on ani transkryptu, ani danych klienta, a jedynie losową referencję do udostępnionego, minimalnego stanu rozmowy. Po pomyślnym przejęciu stary identyfikator traci ważność. Kod jest jedynie pomostem dla kontekstu, a nie dowodem tożsamości ani zgodą na udostępnienie wrażliwych danych konta.

Reguły wygasania muszą być zrozumiałe w interfejsie

Techniczne limity czasowe rozwiązują tylko połowę zadania. Użytkownicy muszą wiedzieć, czy i jak długo zachowywana jest ich rozmowa. Wskazówki NIST dotyczące Customer Experience kładą nacisk na jasne informacje o zakończeniu sesji, aby nie dopuścić do utraty pracy i zapobiec sięganiu przez ludzi po niebezpieczne obejścia.

Dobre podejście do wygasania sesji odpowiada bezpośrednio w oknie czatu na pytania:

• Czy rozmowa zostanie zachowana po zamknięciu okna?
• Czy dotyczy to tylko tej przeglądarki, czy również stanu po zalogowaniu na innych urządzeniach?
• Kiedy sesja kończy się z powodu bezczynności i kiedy zapisana historia zostanie usunięta?
• Które elementy użytkownik może sam usunąć lub wyeksportować?
• Co dzieje się z otwartym zgłoszeniem do działu obsługi po wygaśnięciu sesji?

Przed oczekiwanym zakończeniem sesji dyskretny komunikat może zaoferować zapisanie otwartych informacji lub przekazanie ich do wsparcia technicznego. Po wygaśnięciu interfejs powinien jasno odróżniać stan „sesja zakończona” od „historia usunięta”. Pierwszy dotyczy dostępu, drugi – przechowywania danych.

Human Handoff: Przekazanie kontekstu i uwidocznienie odpowiedzialności

Przy przekazywaniu rozmowy człowiekowi zwięzłe, ustrukturyzowane podsumowanie jest często cenniejsze niż długi, pozbawiony komentarza zapis rozmowy. Określa ono cel, potwierdzone dane, zaproponowane już kroki, otwarte pytania i użyte źródła. Wrażliwe treści są przekazywane tylko wtedy, gdy są niezbędne dla sprawy i zostały do tego zatwierdzone.

Użytkownik powinien widzieć, że obsługę przejmuje teraz człowiek, jakie informacje są przekazywane i czy wiąże się to z nowym czasem oczekiwania. Jednocześnie sztuczna inteligencja musi po przekazaniu wiedzieć, czy ma milczeć, wspierać jedynie organizacyjnie, czy też będzie mogła później ponownie przejąć rozmowę. Konkretne wyzwalacze i reguły eskalacji opisano w artykule na temat Human Handoff w chatbocie na stronie internetowej.

Wdrożenie w sześciu krokach

1. Określenie scenariuszy użycia: Osobnosprecyzuj nawigację na stronie, późniejszy powrót, zmianę urządzenia oraz przekazanie konsultantowi.
2. Zdefiniowanie poziomów zaufania: Ustal, które treści są dostępne anonimowo, po powiązaniu z kontem, a które dopiero po ponownym uwierzytelnieniu.
3. Zminimalizowanie stanu: Zaprojektuj ustrukturyzowany stan wznowienia (resume-state) z celem, potwierdzonymi faktami, otwartymi punktami i czasem wygaśnięcia.
4. Wymuszenie cyklu życia: Przetestuj po stronie serwera limit bezczynności, limit bezwzględny, usuwanie, unieważnianie i wylogowanie.
5. Zaprojektowanie przekazania: Uwidocznij potwierdzenie użytkownika, podsumowanie dla wsparcia, status oczekiwania i odpowiedzialność.
6. Mierzenie sukcesu bez pełnego tekstu: Rejestruj zdarzenia takie jak „zaproponowano kontynuację”, „zaakceptowano”, „wygasło”, „zakończono zmianę urządzenia” i „handoff udany”. Jak zrobić to z zachowaniem oszczędności danych, wyjaśnia poradnik dotyczący analityki chatbotów AI.

Macierz testowa dla komputerów, urządzeń mobilnych i realnych przypadków brzegowych

Przed wdrożeniem należy sprawdzić nie tylko ścieżkę optymistyczną (happy path). Niewielka macierz testowa pozwoli wykryć typowe błędy:

• nawigacja w obrębie tej samej witryny z otwartym i zamkniętym okienkiem czatu,
• powrót w tej samej przeglądarce przed i po upływie limitu bezczynności,
• powrót w trybie prywatnym lub po usunięciu lokalnych danych przeglądarki,
• zmiana urządzenia przed i po zalogowaniu oraz po wylogowaniu,
• zmiana konta na urządzeniu współdzielonym,
• wygasły, już użyty lub unieważniony kod transferowy,
• usunięta rozmowa, zablokowane konto i zmienione uprawnienia podmiotu,
• kontynuacja po aktualizacji bazy wiedzy,
• przekazanie konsultantowi z wyraźnie zatwierdzonym podsumowaniem i bez niego,
• długie tytuły, języki o innej długości tekstu oraz szerokości ekranów mobilnych bez poziomego przewijania (overflow).

W każdym przypadku – oprócz widocznej odpowiedzi – weryfikacji podlegają także zapytania sieciowe, unieważnianie sesji, logi błędów i zdarzenia analityczne. Chatbot może uprzejmie wyjaśnić, że dany kontekst nie jest już dostępny. Nigdy nie wolno mu jednak rekonstruować go z podobnych danych innych użytkowników ani przypisywać nowej osobie.

Podsumowanie: Ciągłość to kontrolowane przekazanie

Dobre doświadczenie kontynuacji nie oznacza zapisywania wszystkiego na zawsze. Oznacza zabranie właściwego, minimalnego kontekstu na jasno określonym odcinku. Ta sama przeglądarka, zalogowane drugie urządzenie oraz kanał wsparcia z udziałem człowieka wymagają do tego różnych reguł zaufania i wygasania. Gdy stan rozmowy, tożsamość i uprawnienia pozostają rozdzielone, powstaje wygoda bez cichego udostępniania danych.

Wprowadzenie tych zasad na wczesnym etapie projektowania Conversational UX pozwala zmniejszyć liczbę porzuconych sesji i sprawia, że przekazywanie rozmów do działu wsparcia staje się bardziej zrozumiałe. Funkcje ChatReact zapewniają przegląd dostępnych modułów dla chatbotów na stronach WWW; konkretną konfigurację sesji i ochrony danych należy następnie zaplanować i przetestować odpowiednio do własnego przypadku użycia.

Źródła

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Ogólne rozporządzenie o ochronie danych, Artykuł 5