Chatbot-Gespräche fortsetzen: Sitzungen, Gerätewechsel und sichere Übergabe

Ein Besucher stellt im Website-Chatbot drei Fragen, wechselt zur Produktseite und kehrt später zurück. Eine Kundin beginnt am Smartphone und möchte am Laptop weitermachen. Im Support übernimmt schließlich ein Mensch. In allen drei Fällen lautet die Erwartung: Das Gespräch soll sinnvoll weitergehen. Technisch und organisatorisch sind das jedoch drei unterschiedliche Aufgaben. Wer sie vermischt, riskiert verlorenen Kontext, ungewollte Datenfreigaben oder eine Sitzung, die länger aktiv bleibt als nötig.

„Fortsetzen“ ist nicht gleich „wiedererkennen“

Für die Planung hilft eine klare Trennung von drei Kontinuitätsstufen:

1. Innerhalb eines Besuchs: Das Gespräch bleibt erhalten, während jemand zwischen Seiten navigiert oder das Chatfenster schließt und wieder öffnet.
2. Bei einer späteren Rückkehr: Derselbe Browser findet innerhalb einer begrenzten Frist eine frühere Unterhaltung wieder.
3. Über Geräte hinweg: Eine Person setzt das Gespräch auf einem anderen Browser oder Gerät fort. Dafür ist in der Regel eine verlässliche Kontobindung oder ein bewusst ausgelöster, kurzlebiger Übertragungsprozess nötig.

Ein vorhandener Gesprächsverlauf beweist noch keine Identität. Wer eine Gesprächs-ID oder einen Link besitzt, darf deshalb nicht automatisch auf Bestellungen, Vertragsdaten oder personenbezogene Informationen zugreifen. Das ist dieselbe Grundgrenze, die auch beim Trennen von öffentlichem Chatbot und authentifiziertem Kundenportal gilt: Kontext kann Komfort schaffen, ersetzt aber keine Anmeldung und keine Berechtigungsprüfung.

Die technische Basis: Referenz im Browser, Zustand auf dem Server

Eine robuste Architektur speichert im Browser möglichst nur eine zufällige, nicht sprechende Referenz. Der zugehörige Gesprächszustand liegt serverseitig und wird bei jeder Anfrage anhand von Gültigkeit, Mandant, Berechtigung und Ablaufdatum geprüft. Die OWASP-Empfehlungen zum Session Management raten zu bedeutungslosen, schwer erratbaren Sitzungskennungen und serverseitig kontrollierten Zeitlimits. Sitzungskennungen gehören außerdem nicht in URLs: Sie können über Verlauf, Protokolle, Referrer oder geteilte Links weitergegeben werden.

Browser-Speicher hat unterschiedliche Reichweiten. Laut MDN Web Storage API ist sessionStorage an Tab und Ursprung gebunden und endet normalerweise mit dem Tab. localStorage bleibt dagegen über Browser-Sitzungen hinweg erhalten, aber weiterhin nur in demselben Browserprofil. Beides schafft keine geräteübergreifende Identität. Sensible Transkripte oder dauerhafte Zugangstoken direkt dort abzulegen, vergrößert zudem die Folgen eines Skript- oder Gerätezugriffs.

Welche Daten der Zustand enthalten sollte

Für eine hilfreiche Fortsetzung braucht das System häufig weniger als ein vollständiges Transkript. Ein kompakter, versionierter Zustandsdatensatz kann genügen:

• das aktuelle Anliegen und das bestätigte Ziel,
• bereits geklärte, nicht sensible Fakten,
• offene Rückfragen und der nächste sinnvolle Schritt,
• verwendete Wissensquellen oder deren Versionen,
• Einwilligungs-, Authentifizierungs- und Handoff-Status,
• Zeitpunkt der letzten Aktivität sowie festgelegtes Ablaufdatum.

So lässt sich die Unterhaltung zusammenhängend fortführen, ohne jede frühere Nachricht unbegrenzt in den aktiven Prompt zu kopieren. Der vollständige Verlauf kann getrennt, kürzer oder gar nicht aufbewahrt werden – abhängig von Zweck, Nutzererwartung und den festgelegten Regeln. Für personenbezogene Daten sind insbesondere Zweckbindung, Datenminimierung und Speicherbegrenzung aus Artikel 5 DSGVO wichtige Gestaltungsprinzipien. Das ersetzt keine individuelle Rechtsberatung, liefert aber eine klare Produktanforderung: Nur speichern, was für einen benannten Zweck wirklich benötigt wird.

Anonyme und angemeldete Gespräche unterschiedlich behandeln

Anonyme Rückkehr im selben Browser

Bei anonymen Besuchern sollte „Gespräch fortsetzen“ eine begrenzte Komfortfunktion bleiben. Sinnvoll sind eine kurze Aufbewahrungsfrist, ein gut sichtbarer Löschbefehl und eine Erklärung, dass der Verlauf nur auf diesem Browser wiedergefunden wird. Der Chatbot darf aus der Wiederkehr nicht ableiten, dass dieselbe natürliche Person vor ihm sitzt. Nach Ablauf oder beim Verlust der lokalen Referenz beginnt eine neue Sitzung.

Praktisch kann der Chatbot bei der Rückkehr fragen: „Möchten Sie Ihr Gespräch zur Produktauswahl fortsetzen oder neu beginnen?“ Das ist besser, als alten Kontext stillschweigend zu aktivieren. Auf gemeinsam genutzten Geräten verhindert diese Bestätigung, dass die nächste Person sofort Inhalte sieht, die sie nichts angehen.

Gerätewechsel mit Anmeldung

Geräteübergreifende Kontinuität sollte an ein verifiziertes Konto und dessen aktuelle Berechtigungen gebunden sein. Nach der Anmeldung lädt der Server nur Gespräche, die diesem Konto und dem richtigen Mandanten zugeordnet sind. Bei sensiblen Aktionen – etwa Adressänderung, Vertragsauskunft oder Bestellung – ist eine erneute Authentifizierung sinnvoll, selbst wenn der allgemeine Chat noch aktiv ist.

Die aktuelle NIST-Leitlinie SP 800-63B zur Sitzungsverwaltung beschreibt Sitzungen als Bindung zwischen authentifizierter Person und Dienst über ein Sitzungsgeheimnis. Sie fordert sowohl Inaktivitäts- als auch Gesamtzeitlimits sowie eine serverseitige Beendigung. Für Produktteams folgt daraus: „Angemeldet“ darf kein unbegrenzter Zustand sein, und ein abgelaufenes Konto- oder Sitzungstoken darf nicht durch einen noch vorhandenen Chatverlauf wiederbelebt werden.

Übertragungscode nur als eng begrenzte Brücke

Manche Angebote möchten einen anonymen Wechsel per Einmalcode oder QR-Code ermöglichen. Dann sollte der Code kurzlebig, einmal verwendbar und widerrufbar sein. Er enthält weder Transkript noch Kundendaten, sondern nur eine zufällige Referenz auf einen freigegebenen, minimalen Gesprächszustand. Nach erfolgreicher Übernahme wird die alte Referenz ungültig. Der Code ist eine Brücke für den Kontext, kein Identitätsnachweis und keine Freigabe sensibler Kontodaten.

Ablaufregeln müssen im Interface verständlich sein

Technische Zeitlimits lösen nur die halbe Aufgabe. Nutzer müssen wissen, ob und wie lange ihr Gespräch erhalten bleibt. Die NIST-Hinweise zur Customer Experience betonen klare Informationen zum Sitzungsende, damit keine Arbeit verloren geht und Menschen nicht zu unsicheren Umgehungen greifen.

Ein gutes Ablaufkonzept beantwortet daher direkt im Chat:

• Bleibt das Gespräch nach dem Schließen erhalten?
• Gilt das nur für diesen Browser oder auch nach einer Anmeldung auf anderen Geräten?
• Wann endet die Sitzung wegen Inaktivität, und wann wird der gespeicherte Verlauf gelöscht?
• Welche Teile kann der Nutzer selbst entfernen oder exportieren?
• Was geschieht mit einem offenen Supportfall nach dem Ablauf?

Vor einem erwartbaren Sitzungsende kann ein dezenter Hinweis anbieten, offene Informationen zu sichern oder an den Support zu übergeben. Nach dem Ablauf sollte die Oberfläche klar zwischen „Sitzung beendet“ und „Verlauf gelöscht“ unterscheiden. Das eine betrifft den Zugriff, das andere die Aufbewahrung.

Human Handoff: Kontext übergeben, Verantwortung sichtbar machen

Beim Wechsel zu einem Menschen ist eine kurze strukturierte Zusammenfassung oft wertvoller als ein unkommentierter langer Verlauf. Sie nennt Anliegen, bestätigte Angaben, bereits vorgeschlagene Schritte, offene Frage und verwendete Quellen. Sensible Inhalte werden nur übergeben, wenn sie für den Supportfall erforderlich und dafür freigegeben sind.

Der Nutzer sollte sehen, dass nun ein Mensch übernimmt, welche Informationen weitergegeben werden und ob eine neue Wartezeit entsteht. Gleichzeitig muss die KI nach der Übergabe wissen, ob sie schweigen, nur organisatorisch unterstützen oder später wieder übernehmen darf. Konkrete Auslöser und Eskalationsregeln beschreibt der Beitrag zum Human Handoff im Website-Chatbot.

Umsetzung in sechs Schritten

1. Nutzungsszenarien benennen: Seitennavigation, spätere Rückkehr, Gerätewechsel und menschliche Übergabe getrennt spezifizieren.
2. Vertrauensstufen definieren: Festlegen, welche Inhalte anonym, nach Kontobindung oder erst nach erneuter Authentifizierung verfügbar sind.
3. Zustand minimieren: Einen strukturierten Resume-State mit Ziel, bestätigten Fakten, offenen Punkten und Ablaufzeit entwerfen.
4. Lebenszyklus erzwingen: Inaktivitätslimit, absolutes Limit, Löschung, Widerruf und Logout serverseitig testen.
5. Übergaben gestalten: Nutzerbestätigung, Supportzusammenfassung, Wartestatus und Zuständigkeit sichtbar machen.
6. Erfolg ohne Volltext messen: Ereignisse wie „Fortsetzung angeboten“, „angenommen“, „abgelaufen“, „Gerätewechsel abgeschlossen“ und „Handoff erfolgreich“ erfassen. Wie das datensparsam gelingt, zeigt der Leitfaden zu KI-Chatbot-Analytics.

Testmatrix für Desktop, Mobile und reale Grenzfälle

Vor dem Rollout sollte nicht nur der glückliche Pfad funktionieren. Eine kleine Testmatrix deckt die typischen Fehler ab:

• Navigation innerhalb derselben Website mit geöffnetem und geschlossenem Chatfenster,
• Rückkehr im selben Browser vor und nach dem Inaktivitätslimit,
• Rückkehr im privaten Fenster oder nach dem Löschen lokaler Browserdaten,
• Gerätewechsel vor und nach Anmeldung sowie nach einem Logout,
• Kontowechsel auf einem gemeinsam genutzten Gerät,
• abgelaufener, bereits verwendeter oder widerrufener Übertragungscode,
• gelöschtes Gespräch, gesperrtes Konto und geänderte Mandantenberechtigung,
• Fortsetzung nach einer Aktualisierung der Wissensbasis,
• Handoff mit und ohne ausdrücklich freigegebene Zusammenfassung,
• lange Titel, Sprachen mit anderer Textlänge und mobile Breiten ohne horizontalen Überlauf.

Bei jedem Fall gehören neben der sichtbaren Antwort auch Netzwerkzugriffe, Sitzungsinvalidierung, Fehlerprotokolle und Analytics-Ereignisse zur Prüfung. Ein Chatbot darf freundlich erklären, dass ein Kontext nicht mehr verfügbar ist. Er darf ihn aber niemals aus ähnlichen Nutzerdaten rekonstruieren oder einer neuen Person zuordnen.

Fazit: Kontinuität ist eine kontrollierte Übergabe

Ein gutes Fortsetzungs-Erlebnis bedeutet nicht, alles für immer zu speichern. Es bedeutet, den richtigen, minimalen Kontext über eine klar begrenzte Strecke mitzunehmen. Derselbe Browser, ein angemeldetes zweites Gerät und ein menschlicher Supportkanal brauchen dafür unterschiedliche Vertrauens- und Ablaufregeln. Wenn Gesprächszustand, Identität und Berechtigung getrennt bleiben, entsteht Komfort ohne stillschweigende Datenfreigabe.

Wer diese Regeln früh in die Conversational UX einbaut, kann Sitzungsabbrüche reduzieren und Supportübergaben verständlicher machen. Die ChatReact-Funktionen geben einen Überblick über mögliche Bausteine für Website-Chatbots; die konkrete Sitzungs- und Datenschutzkonfiguration sollte anschließend passend zum eigenen Anwendungsfall geplant und getestet werden.

Quellen

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Datenschutz-Grundverordnung, Artikel 5