Chatbot-Verlauf löschen und exportieren: Sichere Nutzerkontrolle

Ein Chatbot-Verlauf ist für Nutzer praktisch: Sie können Antworten nachlesen, ein Gespräch später fortsetzen oder Informationen an den Support übergeben. Dieselbe Historie kann aber Bestellnummern, Problembeschreibungen, Kontaktdaten oder andere sensible Angaben enthalten. Wer Gespräche speichert, braucht deshalb mehr als einen unscheinbaren „Verlauf“-Schalter. Nutzer sollten verstehen, welche Daten vorhanden sind, wie sie sie mitnehmen, löschen oder den weiteren Zugriff widerrufen können.

Dieser Leitfaden zeigt ein umsetzbares Produkt- und Technikmodell für Website-Chatbots. Er verbindet Nutzerfreundlichkeit, Datensparsamkeit, sichere Identitätsprüfung und nachvollziehbare Systemzustände. Die Hinweise sind keine individuelle Rechtsberatung; konkrete Pflichten hängen unter anderem von Zweck, Rechtsgrundlage, Systemarchitektur und den betroffenen Daten ab.

Vier Funktionen statt eines einzigen Verlaufsschalters

„Verlauf verwalten“ ist zu ungenau. In der Oberfläche und im Backend sollten vier unterschiedliche Absichten getrennt werden:

• Ansehen: Nutzer lesen gespeicherte Gespräche, Anhänge und erkennbare Metadaten in einer verständlichen Chronologie.
• Exportieren: Sie erhalten eine Kopie in einem lesbaren Format und, wenn für den Anwendungsfall sinnvoll oder rechtlich erforderlich, zusätzlich in einem strukturierten maschinenlesbaren Format.
• Löschen: Sie entfernen einzelne Gespräche oder den gesamten zugeordneten Verlauf. Die Oberfläche erklärt Umfang, Fristen und mögliche Ausnahmen.
• Zugriff widerrufen: Sie machen Freigabelinks, bekannte Geräte oder Wiederaufnahme-Tokens ungültig, ohne zwingend alle Inhaltsdaten sofort zu löschen.

Diese Trennung verhindert gefährliche Missverständnisse. „Abmelden“ löscht keine Gesprächsdaten. „Verlauf ausblenden“ ist keine Löschung. Und ein abgelaufener Link bedeutet nicht automatisch, dass die zugrunde liegenden Datensätze verschwunden sind. Ergänzend lohnt sich unser Leitfaden zum sicheren Fortsetzen von Chatbot-Gesprächen.

Mit einem klaren Datenmodell beginnen

Bevor Teams Buttons gestalten, sollten sie die gespeicherten Objekte inventarisieren. Ein Gespräch besteht häufig nicht nur aus Nachrichten. Hinzu kommen Sitzungskennungen, Zeitstempel, Dateiverweise, Sicherheitsereignisse, Support-Tickets, Feedback und technische Protokolle. Für jedes Objekt braucht es einen dokumentierten Zweck, einen Verantwortlichen, eine Aufbewahrungsregel und einen Löschpfad.

Die Datenschutz-Grundverordnung nennt in Artikel 5 unter anderem Datenminimierung und Speicherbegrenzung. Artikel 15 betrifft das Auskunftsrecht, Artikel 17 das Recht auf Löschung mit Voraussetzungen und Ausnahmen, Artikel 20 die Datenübertragbarkeit in ihrem jeweiligen Anwendungsbereich. Daraus folgt nicht, dass jede Chatbot-Oberfläche identische Funktionen anbieten muss. Produktteams sollten aber Datenflüsse so bauen, dass berechtigte Anfragen zuverlässig bearbeitet werden können.

Identität vor Export und Löschung angemessen prüfen

Wer einen Verlauf nur über einen erratbaren Link oder eine wiederverwendete Sitzungskennung zugänglich macht, riskiert Datenabfluss. Gleichzeitig darf eine Identitätsprüfung nicht pauschal mehr personenbezogene Daten verlangen, als für die konkrete Aktion nötig sind. Die finalen EDPB-Leitlinien 01/2022 zum Auskunftsrecht behandeln unter anderem Identifikation, Umfang und sichere Bereitstellung von Kopien. Artikel 12 Absatz 6 DSGVO erlaubt zusätzliche Informationen zur Identitätsbestätigung, wenn begründete Zweifel an der Identität bestehen.

In der Praxis bewährt sich eine risikobasierte Staffelung. Das Anzeigen eines pseudonymen Kurzverlaufs auf demselben Gerät kann eine gültige, kurzlebige Sitzung voraussetzen. Ein Gesamtexport, eine irreversible Löschung oder das Widerrufen aller Geräte rechtfertigt eher eine erneute Authentifizierung. Die aktuelle NIST-Leitlinie zur Sitzungsverwaltung beschreibt Reauthentifizierung, Zeitlimits und Sitzungsterminierung als eigenständige Kontrollen. Die konkrete Stärke muss zum Risiko passen; NIST-Vorgaben für US-Bundesbehörden sind dabei keine pauschale Rechtsvorgabe für jedes Unternehmen.

Für öffentliche Widgets und angemeldete Kundenbereiche sollte die Grenze sichtbar bleiben. Unser Beitrag zu Identität und Datenzugriff im Kundenportal zeigt, warum ein öffentlicher Chat nicht stillschweigend zu einem Konto-Datenkanal werden sollte.

Ein Export muss verständlich und vollständig erklärbar sein

Ein guter Export ist kein Rohdump aus der Datenbank. Er beginnt mit einer Übersicht: Erstellungszeitraum, enthaltene Gespräche, Anhänge, verwendete Zeitzone und Formatversion. Danach folgen die Inhalte in klarer Reihenfolge. JSON kann für strukturierte Weiterverarbeitung sinnvoll sein; HTML oder PDF ist für viele Menschen leichter lesbar. Ob und in welchem Umfang ein portables Format rechtlich verlangt ist, sollte für den konkreten Fall geprüft werden.

Erzeugt das System den Export asynchron, braucht die Oberfläche einen eindeutigen Status: „wird vorbereitet“, „bereit bis …“, „abgelaufen“ oder „fehlgeschlagen“. Der Download-Link sollte kurzlebig, nicht erratbar und nach Verwendung widerrufbar sein. Geheimnisse wie interne Prompts, Zugriffsschlüssel oder Daten anderer Personen gehören nicht in das Paket. Vor der Bereitstellung sollte ein serverseitiger Filter prüfen, ob Beziehungen zu Supportfällen, geteilten Konversationen oder Drittinhalten eine besondere Behandlung erfordern.

Löschung als Zustandsmaschine statt Sofortversprechen

Ein Button mit der Meldung „Alles gelöscht“ ist problematisch, wenn Suchindex, Analyseablage, Supportsystem oder Backup weiterhin Kopien enthalten. Besser ist eine kleine Zustandsmaschine, die den tatsächlichen Prozess abbildet.

Sinnvolle Löschzustände

1. Angefordert: Identität und gewünschter Umfang sind bestätigt.
2. Gesperrt: Der Verlauf ist für normale Nutzung nicht mehr erreichbar; Wiederaufnahme- und Freigabe-Tokens sind ungültig.
3. In Bearbeitung: Primärspeicher, Suchindex, Dateispeicher, Analyse- und Integrationsziele werden abgearbeitet.
4. Abgeschlossen: Die vorgesehenen aktiven Systeme sind bereinigt; verbleibende Sicherungskopien unterliegen der dokumentierten Backup-Rotation oder einer begründeten Ausnahme.
5. Teilweise blockiert: Ein System konnte nicht bereinigt werden oder Daten müssen vorerst erhalten bleiben. Der Fall wird nachvollziehbar eskaliert.

Abhängige Daten nicht vergessen

Nachrichten können auf Dateien, Embeddings, Suchindizes, Qualitätsbewertungen, CRM-Datensätze oder Support-Tickets verweisen. Die Löschanforderung braucht daher eine stabile Anforderungs-ID und idempotente Arbeitsschritte: Ein erneuter Lauf darf nicht neue Kopien erzeugen oder bereits erledigte Schritte rückgängig machen. Für Messdaten sollte schon beim Design entschieden werden, ob aggregierte, nicht mehr zuordenbare Kennzahlen erhalten bleiben können. Mehr dazu steht im Beitrag über datensparsame Chatbot-Analytics.

Widerruf schützt besonders auf gemeinsam genutzten Geräten

In Hotels, Verkaufsräumen, Werkstätten oder Familienhaushalten wechseln Personen häufiger am selben Gerät. Deshalb sollte „Zugriff widerrufen“ mehr können als einen Cookie lokal zu löschen. Serverseitig müssen bekannte Sitzungstokens, Freigabelinks und gegebenenfalls Gerätebindungen ungültig werden. Die Oberfläche sollte unterscheiden zwischen „dieses Gerät“, „alle Geräte“ und „alle geteilten Links“.

Nach dem Widerruf darf die Zurück-Taste keinen sensiblen Verlauf aus einem Cache zeigen. Vorschauen in Benachrichtigungen, Browser-Autovervollständigung und lokale Offline-Daten gehören in die Prüfung. Gleichzeitig sollte der Nutzer eine klare Bestätigung erhalten, welche Zugänge beendet wurden und ob Gesprächsdaten weiterhin gespeichert sind. So wird Widerruf nicht mit Löschung verwechselt.

Löschbestätigung zugänglich und fehlertolerant gestalten

Eine irreversible Aktion braucht eine ruhige, verständliche Bestätigung. Die WCAG-2.2-Erläuterung zu Erfolgskriterium 3.3.4 bezieht sich ausdrücklich auch auf das Ändern oder Löschen nutzerkontrollierbarer Daten. Vorgesehen ist mindestens eine Möglichkeit zur Umkehr, Prüfung oder Bestätigung. Welche Variante passt, hängt vom Produkt ab.

Gute Dialoge nennen konkret „3 Gespräche und 2 Anhänge“ statt nur „Daten“. Die primäre und die destruktive Aktion sind visuell unterscheidbar, per Tastatur erreichbar und nicht allein durch Farbe erklärt. Nach dem Absenden meldet ein zugänglicher Statusbereich, dass die Anfrage angenommen wurde. Ein Papierkorb mit begrenzter Wiederherstellungsfrist kann Bedienfehler abfangen, darf aber nicht heimlich einer zugesagten sofortigen Löschung widersprechen.

Support-Handoff ohne Schattenkopie

Wird ein Gespräch an Menschen übergeben, entsteht oft ein separates Support-Ticket. Dieses Objekt hat möglicherweise einen anderen Zweck, andere Zugriffsrollen und eine andere Aufbewahrungsregel. Die Verlaufseinstellung im Chatbot darf ein solches Ticket weder unsichtbar löschen noch stillschweigend ignorieren. Vor der Übergabe sollte die Oberfläche erklären, welche Inhalte übernommen werden. Bei einer späteren Anfrage muss das System die Verknüpfung finden und den Fall nach den geltenden Regeln behandeln.

Wenn eine automatische Löschung scheitert oder Identität und Umfang unklar sind, braucht der Prozess einen sicheren menschlichen Kanal. Der Beitrag zum Human Handoff im Website-Support beschreibt dafür Kontextpakete und Eskalationsregeln. Übergeben werden sollte nur, was der zuständige Mitarbeiter wirklich benötigt.

Implementierungscheckliste für Produkt- und Supportteams

1. Alle Datenobjekte und Speicherorte eines Gesprächs inventarisieren.
2. Ansehen, Export, Löschung und Widerruf als getrennte Berechtigungen modellieren.
3. Für sensible Aktionen risikobasiert reauthentifizieren.
4. Exportpakete verständlich strukturieren und sichere Ablaufzeiten setzen.
5. Löschschritte idempotent machen und mit einer Anforderungs-ID verfolgen.
6. Suchindex, Dateien, Analytics, Integrationen, Caches und Supportfälle einbeziehen.
7. Bestätigungsdialoge und Statusmeldungen mit Tastatur und Screenreader testen.
8. Gemeinsam genutzte Geräte, abgelaufene Links und verlorene Geräte simulieren.
9. Teilfehler sichtbar eskalieren, ohne sensible Inhalte in Logs zu kopieren.
10. Aufbewahrungs- und Löschregeln regelmäßig mit Datenschutz und Fachbereichen prüfen.

Die wichtigsten Tests vor dem Go-live

Testfälle sollten nicht nur den glücklichen Pfad abdecken. Prüfen Sie parallele Löschanfragen, einen während des Exports ablaufenden Login, bereits widerrufene Links, neue Nachrichten während einer laufenden Löschung und den Ausfall eines angebundenen Systems. Kontrollieren Sie außerdem, ob ein Export fremde Nachrichten aus geteilten Konten enthält und ob eine gelöschte Datei über eine alte URL noch erreichbar ist.

Für jede Aktion braucht es ein erwartetes Ergebnis in Oberfläche, API und Speicher. Ein guter Abnahmetest endet deshalb nicht bei einer grünen Erfolgsmeldung. Er prüft anschließend die maßgeblichen Datenspeicher, Tokens und öffentlichen URLs. Ereignisprotokolle sollten belegen, dass ein Schritt ausgeführt wurde, ohne den gelöschten Gesprächsinhalt erneut zu speichern.

Fazit: Nutzerkontrolle ist eine Ende-zu-Ende-Eigenschaft

Ein vertrauenswürdiger Chatbot macht den Verlauf nicht nur auffindbar. Er trennt Ansicht, Export, Löschung und Widerruf, prüft sensible Aktionen angemessen und zeigt den echten Bearbeitungsstand. Entscheidend ist die Verbindung von klarer UX mit einem Datenmodell, das alle abhängigen Systeme kennt.

Wer diese Funktionen früh in Architektur, Supportprozesse und Tests integriert, reduziert manuelle Sonderfälle und vermeidet falsche Versprechen. Prüfen Sie bei der Planung auch, welche ChatReact-Funktionen zu Ihrer Website und Ihrem Supportprozess passen. Beginnen Sie mit einem Dateninventar und einem einzigen Ende-zu-Ende-Test: Verlauf exportieren, Zugriffe widerrufen, Löschung auslösen und das Ergebnis in allen beteiligten Systemen nachweisen.

Quellen und weiterführende Hinweise

• EUR-Lex: Verordnung (EU) 2016/679, insbesondere Artikel 5, 12, 15, 17 und 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Version 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.