Wer schreibt in deinen KI-Support-Chat?

Du hast deinem Produkt ein KI-Chat-Widget hinzugefügt. Es antwortet aus deinem Hilfecenter, fängt einen guten Teil der Tickets ab, und die Transkripte stehen alle in einer Liste. Du liest sie freitagnachmittags.

Und bei jedem einzelnen steht Anonym.

Du siehst, dass jemand an einem Nachmittag dreimal gefragt hat, wie man die Rechnungs-E-Mail ändert. Du siehst nicht, dass es dieselbe Person war, dass sie deinen größten Plan hat und dass sie am Montag aufgegeben und gekündigt hat.

Genau diese Lücke schließt die Identität.

Was ein anonymes Log verrät und was nicht

Ein anonymes Transkript ist durchaus nützlich. Es zeigt dir, was Leute fragen, welche Fragen deine Dokumentation nicht beantwortet und welche Seiten sie verwirren. Darauf beruht der ganze Kreislauf, in dem du den fehlenden Artikel schreibst, und er funktioniert, ohne einen einzigen Namen zu kennen.

Was es nicht kann: ein Gespräch mit irgendetwas anderem verknüpfen, das du weißt.

• Häufigkeit pro Person, nicht pro Sitzung. Zehn Gespräche über dieselbe Funktion können zehn verwirrte Nutzer sein oder ein sehr hartnäckiger. Diese zwei Situationen verlangen völlig unterschiedliche Reaktionen, und ein anonymes Log kann sie nicht auseinanderhalten.

• Wer betroffen ist. „Drei Leute haben nach dem API-Rate-Limit gefragt“ liest sich anders, wenn einer davon dein größter Kunde ist.

• Die Nachverfolgung. Ein Support-Mitarbeiter, der ein Ticket öffnet, sieht nicht, was die KI diesem Kunden vor einer Stunde schon gesagt hat. Also erklärt der Kunde alles zweimal.

• Das Kündigungssignal. Wiederholte, frustrierte Fragen von einem Account in den zwei Wochen vor der Kündigung sind eines der klarsten Signale, die du je bekommst. Ohne Identität bleibt es unsichtbar.

Die naheliegende Idee und warum sie gefährlich ist

Der naheliegende Schritt: dem Widget sagen, wer angemeldet ist. Deine App weiß es ja schon.

KookeeChat.identify({ id: user.id, email: user.email, name: user.name });

Gefährlich ist, was du als Nächstes tust. Die Versuchung ist groß, so zu denken: Das Widget weiß jetzt, wer das ist, also kann der Assistent Fragen zum Account dieser Person beantworten. Ihre Rechnungen. Ihre Nutzung. Ihre offenen Tickets.

Tu das nicht. Alles, was der Browser sendet, kann die Person im Browser ändern. Entwicklertools öffnen, identify() mit der E-Mail von jemand anderem aufrufen – und wenn der Assistent diesem Feld vertraut, hast du ein Datenleck mit Chat-Oberfläche gebaut.

Das ist keine hypothetische Fehlerklasse. Es ist derselbe Fehler, wie einer vom Client gelieferten User-ID in einem API-Request zu vertrauen, und er hat dieselbe Lösung.

Identität zum Beschriften, Authentifizierung für Daten

Der Ausweg: zwei Dinge auseinanderhalten, die sich wie eins anfühlen.

Identität ist ein Label. Sie sagt, wem das Gespräch wahrscheinlich gehört, damit du deine Transkripte gruppieren, durchsuchen und lesen kannst. Sie ist ungeprüft und entscheidet nichts.

Authentifizierung ist etwas anderes, und es gibt sie schon. Deine App authentifiziert Nutzer. Deine API prüft Sessions. Daran ändert sich nichts, nur weil ein Chat-Widget dazugekommen ist.

Wenn der Assistent also wirklich private Daten braucht, sollte er sie nicht aus dem Identitätsfeld lesen. Er sollte eine Funktion aufrufen, die im Browser des Besuchers läuft, mit dessen eigenem Session-Cookie, gegen deine eigene API:

KookeeChat.init({
  apiKey: 'YOUR_API_KEY',
  visitor: { id: user.id, email: user.email }, // ein Label, für dein Dashboard
  tools: [
    {
      name: 'get_my_invoices',
      description: "Look up the signed-in customer's recent invoices.",
      parameters: { type: 'object', properties: {} },
      handler: () => fetch('/api/my/invoices', { credentials: 'include' }).then((r) => r.json()),
    },
  ],
});

Lies das genau. Nicht das Feld visitor macht das sicher, sondern credentials: 'include'. Dein Server bekommt einen normalen authentifizierten Request und wendet dieselben Regeln an wie überall sonst. Wenn jemand identify() fälscht, bekommt er trotzdem nur seine eigenen Rechnungen, weil das Cookie entscheidet.

Das Identitätsfeld macht in diesem Snippet etwas viel Bescheideneres: Es gibt einer Zeile in deinem Dashboard einen Namen.

Was alle vergessen: das Abmelden

Das ist der Bug, den du auslieferst, wenn du nur den Happy Path baust.

Jemand meldet sich an einem Rechner in der Bibliothek an, stellt dem Assistenten drei Fragen zu seinem Account und meldet sich ab. Die nächste Person setzt sich hin, öffnet den Chat, und das vorige Gespräch ist noch da – weil das Widget es im Browser behalten hat und niemand dem Widget gesagt hat, dass sich etwas geändert hat.

Identität setzt du nicht nur einmal. Sie ändert sich, und diese Änderung ist das wichtige Ereignis:

// beim Anmelden
KookeeChat.identify({ id: user.id, email: user.email, name: user.name });

// beim Abmelden – nicht weglassen
KookeeChat.reset();

Ein Chat-Widget mit Identität muss einen Personenwechsel als harte Grenze behandeln: Transkript verwerfen, neue Session starten, nichts behalten. In Kookee passiert das automatisch, wenn die Identität zu einer anderen Person oder zu niemandem wechselt. Aber das Widget kann nur auf das reagieren, was du ihm sagst, also schreibst du den reset()-Aufruf beim Abmelden selbst.

Eine Feinheit solltest du kennen, denn sie erwischt gerade die, die den Abmelde-Aufruf richtig machen. Die meisten Apps wissen beim ersten Rendern nicht, wer der Nutzer ist. Sie laden die Session, und erst dann können sie jemanden identifizieren. Wenn „ich weiß es noch nicht“ und „niemand ist angemeldet“ für das Widget gleich aussehen, verwirft jeder Seitenaufruf das Gespräch, bevor deine Session-Prüfung fertig ist. Die beiden müssen sich also unterscheiden: Lass den Wert undefined, solange du noch lädst, und übergib ausdrücklich null, sobald du weißt, dass niemand angemeldet ist.

Was du senden solltest

Weniger, als du denkst.

Du brauchst etwas Stabiles zum Gruppieren. Eine User-ID aus deiner eigenen Datenbank leistet das perfekt und sagt niemandem etwas, der keinen Zugriff auf deine Datenbank hat. Eine E-Mail ist im Support nützlicher, weil du danach suchst, wenn ein Kunde schreibt. Sie ist aber auch ein personenbezogenes Datum, für das eine Aufbewahrungsfrist gilt.

Ein vernünftiger Standard:

• Sende immer die ID. Sie ist der Schlüssel zum Gruppieren und verrät nichts.

• Sende die E-Mail, wenn dein Support danach sucht. Das tun die meisten.

• Sende den Namen, damit es lesbar bleibt. So lässt sich das Dashboard schnell überfliegen.

• Sende sonst nichts. Plan, Rolle und Alter des Accounts wirken nützlich, gehören aber in den Kontext, den du dem Assistenten gibst, nicht ins Identitäts-Label. Wer beides mischt, baut einen Speicher personenbezogener Daten, den er nie bauen wollte.

Und schreib es in deine Datenschutzerklärung. Chat-Transkripte sind schon personenbezogene Daten. Eine angehängte E-Mail ändert nichts an der Kategorie, aber daran, wie offensichtlich das für eine Aufsichtsbehörde ist – und für deine Nutzer.

Sollte der Assistent den Namen kennen?

Hier liegt eine verlockende Idee nahe: Wenn das Widget weiß, dass die Besucherin Anna ist, könnte der Assistent mit „Hallo Anna“ beginnen.

Kookee macht das bewusst nicht. Die Identität wird mit dem Gespräch gespeichert und nie an das Modell geschickt. Personenbezogene Daten landen nur dann in einem Request an das Modell, wenn du das so entscheidest.

Wenn du die Begrüßung willst, bekommst du sie. Du musst sie aber ausdrücklich anfordern, über das separate Kontextfeld für alles, was der Assistent wissen soll:

KookeeChat.init({
  apiKey: 'YOUR_API_KEY',
  visitor: { id: user.id, email: user.email, name: user.name }, // dein Dashboard
  appContext: { firstName: user.firstName, plan: user.plan },   // der Assistent
});

Zwei Felder, zwei Empfänger. Das sieht nach Doppelung aus, bis zu dem Tag, an dem jemand fragt, welche personenbezogenen Daten deine Infrastruktur verlassen, und du es genau beantworten kannst.

Was du davon hast

Sobald Gespräche eine Identität tragen, lassen sich ganz normale Fragen beantworten.

Durchsuch deine Transkripte vor einem Verlängerungsgespräch nach der E-Mail eines Kunden, und du weißt, was ihn in diesem Quartal verwirrt hat. Fällt dir auf, dass derselbe Account viermal dasselbe fragt, hast du entweder eine Lücke in der Dokumentation gefunden oder eine im Onboarding. Gib einem Support-Mitarbeiter das KI-Gespräch, das dem Ticket vorausging, und der Kunde muss sich nicht mehr wiederholen.

Dafür muss der Assistent nicht klüger werden. Es muss nur im Log nicht mehr Anonym stehen.

Das Website-Widget von Kookee unterstützt Besucher-Identität sowohl im React-Paket als auch im einfachen Script-Tag. Unter Erkennen, wer chattet findest du alle Regeln, auch dazu, wann genau ein Gespräch verworfen wird.