Assistent im Kundenkonto: persönliche Antworten

Ein öffentlicher Website-Assistent beantwortet Fragen, die für alle gleich sind: Öffnungszeiten, Versandkosten, Leistungsumfang. Sobald derselbe Assistent hinter dem Login steht, ändert sich seine Rolle grundlegend. Er weiß jetzt, wer fragt, und kann auf Vertrag, Tarif, offene Rechnungen, Lieferadressen und Nutzungsstand zugreifen. Aus einer allgemeinen Auskunft wird eine konkrete Angabe: nicht mehr „bitte sehen Sie in Ihren Unterlagen nach“, sondern „Ihr Vertrag läuft bis zum 31. März, ein Wechsel ist ab dem 1. Februar möglich“. Der Unterschied ist erheblich, und genau deshalb ist der Konto-Assistent der Punkt, an dem Architektur und Datenschutz zusammenkommen. 81 Prozent (Harvard Business Review 2017) der Kundinnen und Kunden versuchen zuerst, ein Problem selbst zu lösen; der häufigste Grund für gescheiterte Selbsthilfe ist mit 43 Prozent (Gartner), dass sich im Self-Service kein Inhalt findet, der zur konkreten Lage passt. Genau diese Lücke schließt ein Assistent, der die eigenen Daten kennt. Dieser Beitrag zeigt, wie Sitzung und Identität sauber an den Assistenten gebunden werden, wie Rechte pro Rolle in Lesen und Handeln getrennt werden, wie jede Datenabfrage an die angemeldete Person gekoppelt bleibt und was das für Protokollierung, Zweckbindung und Löschkonzept bedeutet.

Grafik vergrößern

Beschriftungen der Abbildung

• Frage im Kundenkonto
• Angemeldet · Konto K-10482
• Wann läuft mein Vertrag aus
• und was kostet ein Wechsel?
• Ohne Login: allgemeine Antwort
• Bitte sehen Sie dazu in Ihren
• Vertragsunterlagen nach.
• Ein Widget, zwei Betriebsarten
• Öffentlich: Inhalte der Website
• Angemeldet: Daten des Kontos
• Wechsel nur über die Sitzung
• Abmelden fällt zurück auf öffentlich
• Vier Prüfungen vor der Antwort
• 1
• Sitzung geprüft
• gültiges Sitzungsmerkmal, kein Konto im Text
• 2
• Identität gebunden
• das Konto setzt der Server, nicht der Chat
• 3
• Rechte je Rolle
• lesen frei, handeln nur mit Bestätigung
• 4
• Abfrage gefiltert
• jede Abfrage auf dieses Konto begrenzt
• Antwort mit echten Daten
• Tarif
• Komfort M
• Laufzeit bis
• 31.03.2027
• Offene Rechnung
• keine
• Lieferadresse
• Hauptstraße 12
• Nutzung im Monat
• 62 Prozent
• Tarifwechsel vorbereitet
• schreibend erst nach Bestätigung
• Protokoll: Zweck, Zeitpunkt, Rolle
• Löschfrist je Zweck festgelegt
• Typische Fälle
• Adresse ändern
• Tarif wechseln
• Rechnung erneut senden
• Laufzeit nachsehen
• jede schreibende Aktion erst nach Bestätigung

KI-Assistent im Kundenkonto: personalisiert antworten

Was sich hinter dem Login ändert

Der Unterschied zwischen einem öffentlichen Assistenten und einem Konto-Assistenten ist keine Frage der Technik im Hintergrund, sondern eine Frage des Kontexts. Der öffentliche Assistent kennt die Inhalte der Website, die Preisliste, die Versandbedingungen und die häufigen Fragen. Er antwortet für alle gleich, weil er über alle dasselbe weiß. Der Konto-Assistent kennt zusätzlich die Person, die gerade schreibt: welchen Tarif sie gebucht hat, wann ihr Vertrag ausläuft, ob eine Rechnung offen ist, an welche Adresse zuletzt geliefert wurde und wie weit ihr Kontingent im laufenden Monat aufgebraucht ist. Damit verschiebt sich die Antwort von einer Auskunft zu einer Entscheidungsgrundlage, und aus einem Gespräch über Möglichkeiten wird ein Gespräch über den eigenen Fall.

Dass dieser Schritt lohnt, zeigt das Verhalten der Kundschaft. 73 Prozent (Gartner) nutzen auf ihrem Lösungsweg an irgendeinem Punkt einen Self-Service-Kanal, und 81 Prozent (Harvard Business Review 2017) versuchen ein Problem zuerst selbst zu lösen. Abgeschlossen wird dort allerdings wenig: Nur 14 Prozent (Gartner) der Anliegen kommen im Self-Service vollständig zum Ziel, und selbst bei Anliegen, die Nutzer selbst als sehr einfach einstufen, sind es lediglich 36 Prozent (Gartner). Der häufigste Grund ist banal und teuer zugleich: In 43 Prozent (Gartner) der Fälle findet sich kein Inhalt, der zur eigenen Lage passt. Eine allgemeine Hilfeseite kann diese Lücke kaum schließen, weil sie den Fall des Einzelnen nicht kennt. Ein Assistent im Kundenkonto kennt ihn.

Sitzung und Identität sauber binden

Die wichtigste Regel steht am Anfang: Der Assistent erfährt nicht aus dem Gespräch, wer da schreibt, sondern aus der Sitzung. Tippt jemand „zeig mir die Rechnungen von Kundennummer 10482“, ist das für einen sauber gebauten Konto-Assistenten keine Anweisung, sondern schlicht Text. Maßgeblich ist ausschließlich das Sitzungsmerkmal, das der Server beim Anmelden vergeben hat. Das Widget schickt dieses Merkmal mit, der Server prüft es und leitet daraus die Kontoidentität ab, bevor überhaupt eine Anfrage an das Sprachmodell geht. Alles, was danach passiert, spielt sich innerhalb dieser einen Identität ab. Diese Reihenfolge ist der Kern der ganzen Architektur, und sie lässt sich weder durch geschickte Formulierungen noch durch eine besonders freundliche Bitte umkehren.

• Das Sitzungsmerkmal wird serverseitig geprüft, bevor der Assistent überhaupt zu antworten beginnt
• Die Kontoidentität setzt der Server aus der geprüften Sitzung, nicht aus dem Text der Nachricht
• Kontonummern, Rechnungsnummern und Adressen im Verlauf sind Inhalt, aber keine Berechtigung
• Das Widget erhält kein dauerhaftes Geheimnis, sondern ein kurzlebiges, an die Sitzung gebundenes Merkmal
• Läuft die Sitzung ab oder meldet sich die Person ab, verliert der Assistent den Zugriff im selben Moment
• Wechselt jemand das Konto, etwa in einer Verwaltung mit mehreren Mandanten, bleibt der Verlauf des vorherigen Kontos außen vor

Technisch ist das kein Sonderweg, sondern dieselbe Prüfung, die das Kundenkonto ohnehin schützt. Der Assistent greift nicht auf eine eigene Datenbank zu, sondern auf die bestehenden Schnittstellen des Kontos, und zwar mit genau den Rechten, die die angemeldete Person auch im Portal hätte. Sieht sie eine Rechnung im Kundenkonto nicht, sieht der Assistent sie ebenfalls nicht. Diese Deckungsgleichheit ist der einfachste Prüfstein für die Architektur, denn der Assistent sollte höchstens so viel können wie die Oberfläche, in der er sitzt. Wie Werkzeuge und Schnittstellen dafür definiert werden, zeigen die Seite zur Anbindung bestehender Systeme und der Beitrag über Function Calling und die Steuerung eigener Tools.

Rechte pro Rolle: lesen und handeln trennen

Ein Konto-Assistent bekommt keine Generalvollmacht, sondern eine Liste erlaubter Werkzeuge. Jedes Werkzeug hat eine feste Aufgabe, eine feste Datenmenge und eine feste Richtung: Es liest, oder es schreibt. Diese Trennung ist der wichtigste Hebel, denn ein Lesefehler ist unangenehm, ein Schreibfehler dagegen folgenreich. Wer beides in einem einzigen Werkzeug bündelt, verliert die Möglichkeit, unterschiedlich streng zu prüfen. In der Praxis bewährt sich eine Abstufung in drei Klassen: frei lesbar, lesbar mit zusätzlicher Prüfung, und schreibend ausschließlich nach ausdrücklicher Bestätigung durch die angemeldete Person.

Die Rollen selbst kommen aus dem bestehenden System und werden im Assistenten nicht neu erfunden. In einem Geschäftskundenkonto darf eine Einkaufsleitung Bestellungen freigeben, eine Fachkraft sie aber nur vorbereiten; in einem Mitgliederbereich darf der Vorstand Stammdaten ändern, ein Mitglied dagegen nur die eigenen. Der Assistent übernimmt diese Rollenlogik unverändert und stellt Werkzeuge nur dort bereit, wo die Rolle sie ohnehin erlaubt. Fehlt ein Recht, sagt er das offen und bietet den passenden Weg an, statt eine Antwort zu erfinden oder still zu scheitern. Wie sich Rollen und Rechte in einer internen Umgebung ordnen lassen, vertieft der Beitrag über den internen KI-Assistenten für Mitarbeitende.

Jede Abfrage an die angemeldete Person koppeln

Zwischen „der Assistent darf Rechnungen lesen“ und „der Assistent darf die Rechnungen dieses Kontos lesen“ liegt der ganze Unterschied. Die Kopplung gehört deshalb nicht in die Anweisung an das Modell, sondern in den Aufruf: Der Server hängt die Kontoidentität an jede Abfrage, bevor sie die Datenbank erreicht. Das Modell kann diesen Filter weder sehen noch verändern, es formuliert lediglich, welche Art von Auskunft gebraucht wird. Der Filter selbst ist Code. Damit ist ausgeschlossen, dass ein geschickt formulierter Satz im Chat einen fremden Datensatz sichtbar macht, und ebenso, dass eine Kontonummer aus einem früheren Gespräch versehentlich wiederverwendet wird.

• Die Nachricht trifft zusammen mit dem Sitzungsmerkmal ein, der Server prüft die Sitzung
• Aus der Sitzung wird die Kontoidentität abgeleitet und für die gesamte Anfrage festgehalten
• Der Assistent wählt ein Werkzeug aus der Liste, die für diese Rolle freigegeben ist
• Der Server ergänzt die Kontoidentität als festen Filter und ruft die Schnittstelle auf
• Das Ergebnis wird auf die Felder gekürzt, die für die Antwort tatsächlich gebraucht werden
• Der Assistent ist angewiesen, die Antwort ausschließlich aus diesem Ergebnis zu formulieren, nicht aus Erinnerung

Die fünfte Stufe wird häufig übersehen: Es genügt nicht, die richtige Kundin zu treffen, es sollten auch nur die nötigen Felder zurückkommen. Für die Frage nach der Vertragslaufzeit braucht der Assistent das Enddatum und die Kündigungsfrist, nicht die Bankverbindung. Diese Sparsamkeit folgt dem Grundsatz der Datenminimierung und Zweckbindung (DSGVO, Art. 5) und wirkt zugleich handfest: Was gar nicht erst in den Kontext gelangt, kann auch nicht versehentlich in einer Antwort auftauchen. Welche Rahmenbedingungen für Verarbeitung und Speicherort gelten, fasst die Seite zu Datenschutz und Hosting in Deutschland zusammen.

Manipulierte Anfragen im personalisierten Kontext

Sobald echte Kontodaten im Spiel sind, wird aus einem Ärgernis ein Risiko. Die OWASP Foundation führt Prompt Injection in ihrer Top 10 für LLM-Anwendungen als LLM01 und damit auf Platz 1 (OWASP) von insgesamt zehn Risikokategorien (OWASP); direkt dahinter steht die Offenlegung sensibler Informationen als LLM02 (OWASP), und übermäßige Handlungsvollmacht folgt als LLM03 (OWASP). Genau diese drei Kategorien beschreiben das Konto-Szenario: Jemand versucht, den Assistenten mit Text zu einer Auskunft oder einer Handlung zu bewegen, die ihm nicht zusteht. Auch die weitere Entwicklung wird nüchtern eingeschätzt. Gartner rechnet damit, dass bis 2029 15 Prozent (Gartner) der KI-Anwendungen in Unternehmen mindestens einen schwerwiegenden Sicherheitsvorfall pro Jahr verzeichnen, ausgehend von 3 Prozent (Gartner) im Jahr 2025.

• Fremde Inhalte werden als Material gelesen und nicht als Anweisung ausgeführt: eine hochgeladene Rechnung erweitert keine Rechte
• Die Kontoidentität stammt aus der Sitzung und ist im Werkzeugaufruf nicht überschreibbar
• Werkzeuge sind eng geschnitten: eine Aufgabe, eine feste Datenmenge, eine klare Richtung
• Schreibende Werkzeuge verlangen eine ausdrückliche Bestätigung durch die angemeldete Person
• Ausgaben werden gegen Muster geprüft, damit interne Kennungen und Systemhinweise nicht durchrutschen
• Auffällige Verläufe werden protokolliert und ausgewertet, damit Muster früh sichtbar werden

Keine dieser Maßnahmen wirkt für sich allein; sie greifen als Kette ineinander, weil jede einzelne umgangen werden kann. Diese gestaffelte Absicherung ist schon bei einem öffentlichen Assistenten sinnvoll, im Kundenkonto aber unverzichtbar, denn der mögliche Schaden besteht dort nicht mehr in einer falschen Auskunft, sondern in einem fremden Datensatz. Wie die einzelnen Leitplanken im Detail aufgebaut sind, beschreibt der Beitrag zur Absicherung gegen Prompt Injection; wie sich das Ergebnis vor dem Start prüfen lässt, zeigen die Testfälle für die Abnahme eines Assistenten.

Selbstbedienung mit sauberer Bestätigungsstrecke

Der Alltag im Kundenkonto besteht aus wenigen, wiederkehrenden Vorgängen. Eine Adresse ändert sich, ein Tarif passt nicht mehr, eine Rechnung ist im Postfach untergegangen, und vor einer Kündigung möchte jemand wissen, bis wann der Vertrag eigentlich läuft. Diese vier Fälle machen erfahrungsgemäß einen großen Teil der Kontaktaufnahmen aus, und alle vier lassen sich im Chat abschließen, sofern der Weg vom Wunsch zur Ausführung geordnet ist. Lesende Fälle wie die Frage nach der Vertragslaufzeit beantwortet der Assistent direkt aus den Daten des Kontos. Schreibende Fälle wie eine Adressänderung durchlaufen dagegen eine feste Strecke, die sich in sechs Schritten beschreiben lässt.

• Das Anliegen erfassen und in eine eindeutige Aktion übersetzen, statt frei zu interpretieren
• Den heutigen Stand anzeigen: Welche Adresse, welcher Tarif, welche Laufzeit ist hinterlegt?
• Die geplante Änderung im Klartext zeigen, samt Wirkung, Termin und möglichen Kosten
• Ausdrücklich bestätigen lassen, mit einer klaren Zustimmung statt eines beiläufigen Nebensatzes
• Die Aktion ausführen und das Ergebnis zurückmelden, mit Vorgangsnummer und Zeitpunkt
• Den Vorgang protokollieren und eine Bestätigung im Konto oder per E-Mail hinterlegen

Der vierte Schritt ist der wichtigste und wird am häufigsten weggelassen. Ein Assistent, der eine Adressänderung sofort ausführt, weil sie in einem Satz stand, verwechselt Verstehen mit Auftrag. Die Anzeige vor der Ausführung kostet einen Klick und verhindert genau die Fälle, die später teuer werden: die Lieferadresse eines längst zurückliegenden Umzugs, der versehentlich genannte falsche Tarif, die Rechnung an die private statt an die geschäftliche Anschrift. Zugleich schafft sie Nachvollziehbarkeit, denn der bestätigte Wortlaut lässt sich festhalten. Für Anliegen, die sich nicht sauber in eine Aktion übersetzen lassen, bleibt der Weg zum Team offen; wie diese Übergabe an Mitarbeitende ohne Reibung gelingt, beschreibt der verlinkte Beitrag.

Protokoll, Zweckbindung und Löschkonzept

Ein personalisierter Verlauf ist etwas anderes als ein anonymer Chat. Sobald Vertragsdaten, Adressen und Rechnungsnummern darin auftauchen, entsteht ein Datensatz mit Personenbezug, für den dieselben Regeln gelten wie für das Kundenkonto selbst. Die Verordnung verlangt Zweckbindung und Datenminimierung (DSGVO, Art. 5), Datenschutz durch Technikgestaltung samt datenschutzfreundlicher Voreinstellungen (DSGVO, Art. 25) sowie angemessene technische und organisatorische Maßnahmen (DSGVO, Art. 32). Praktisch heißt das: Festgehalten wird, was für Nachvollziehbarkeit und Abrechnung nötig ist, und nicht der vollständige Wortlaut auf Vorrat. Wer diesen Unterschied früh trifft, spart sich später eine schwierige Aufräumarbeit.

• Zweck je Datenart festlegen: Betrieb, Nachweis schreibender Aktionen, Verbesserung der Qualität
• Schreibende Aktionen vollständig festhalten: Zeitpunkt, Rolle, Aktion, Ergebnis und Vorgangsnummer
• Gesprächsinhalte kürzer aufbewahren als Nachweise und getrennt von ihnen speichern
• Für Auswertungen mit aggregierten oder pseudonymisierten Daten arbeiten statt mit Klartextverläufen
• Auskunft und Löschung im Kundenkonto abbilden, damit Betroffenenrechte (DSGVO, Art. 15 und 17) praktisch erfüllbar bleiben
• Löschfristen je Zweck festlegen und technisch durchsetzen, statt sie organisatorisch zu versprechen

Der Ort der Verarbeitung gehört ebenfalls zur Architektur. Für 64 Prozent (Bitkom Cloud Report) der Unternehmen ab 20 Beschäftigten gehören Rechenzentrums-Standorte in Deutschland oder der EU zu den Kriterien bei der Wahl eines Cloud-Anbieters, und 76 Prozent (Cisco Consumer Privacy Survey 2022) der Verbraucher kaufen nicht bei einem Unternehmen, dem sie ihre Daten nicht anvertrauen. Für einen Assistenten mit Vertrags- und Rechnungsdaten ist das keine Nebensache, sondern eine Voraussetzung dafür, dass die Funktion überhaupt genutzt wird. Ein Verstoß gegen die Verordnung kann im Übrigen bis zu 20 Millionen Euro (DSGVO, Art. 83) oder vier Prozent des weltweiten Jahresumsatzes kosten. Die datenschutzrechtlichen Grundlagen im Detail behandelt der Beitrag zum datenschutzkonformen Betrieb eines KI-Assistenten.

Wo der Konto-Assistent bewusst aufhört

Auch mit vollem Zugriff auf das Konto bleibt ein Assistent ein Werkzeug für klar umrissene Vorgänge. Strittige Rechnungen, Kulanzentscheidungen, Kündigungen im Ärger und alles, was Verhandlung erfordert, gehören zu einem Menschen. Das deckt sich mit dem, was Kundinnen und Kunden erwarten: 62 Prozent (Bitkom) der Online-Käufer möchten sich im Problemfall an eine schnell erreichbare, menschliche Kontaktperson wenden, während ein Chatbot von 36 Prozent (Bitkom) gewünscht wird. Ein Konto-Assistent verspricht deshalb keine feste Entlastungsquote; belastbar ist der Mechanismus, nicht eine bestimmte Zahl. Verwandte Anwendungsfälle außerhalb des eingeloggten Bereichs zeigen der Beitrag zu Bewerberfragen auf der Karriereseite und der Beitrag über B2B-Preisanfragen und Angebote im Chat.

In wenigen Schritten zum Konto-Assistenten

Der Weg beginnt nicht bei der Technik, sondern bei einer Liste: Welche Fragen stellen angemeldete Kundinnen und Kunden heute am häufigsten, und welche davon lassen sich aus vorhandenen Daten beantworten? Daraus entstehen die Werkzeuge, die der Assistent bekommt, samt Rolle, Datenumfang und Richtung. Anschließend werden Sitzung und Rechteprüfung angebunden, die Bestätigungsstrecke für schreibende Aktionen festgelegt und der Assistent auf Ihre Fälle und Ihren Ton trainiert. Welche Funktionen sich dabei eigens umsetzen lassen, zeigt die Seite zu den individuellen Funktionen. Beispiele aus der Praxis stehen bei den Referenzprojekten, eine Übersicht nach Einsatzbereich bei den Branchenlösungen und die Rahmenbedingungen bei den Preisen und Paketen. Welche Aktionen der Assistent in Ihren Systemen lesen oder auslösen darf und wo er vorher um Freigabe bittet, beschreibt die Tool-Steuerung.

• Die häufigsten Fragen angemeldeter Kundinnen und Kunden sammeln und nach lesend oder schreibend sortieren
• Vorhandene Schnittstellen sichten: Welche Daten liegen bereit, welche Rollen gibt es bereits?
• Werkzeuge eng schneiden: eine Aufgabe, eine feste Datenmenge, eine klare Richtung
• Bestätigungsstrecke für jede schreibende Aktion festlegen und im Wortlaut abstimmen
• Protokollumfang, Zweckbindung und Löschfristen schriftlich festhalten
• Vor dem Start mit echten Rollen testen, auch mit Konten ohne die jeweilige Berechtigung

Häufige Fragen