Kontext-Layer im Banking: Warum Kundenkontext Tempo, Zweckbindung und ein Verfallsdatum braucht

Ein Kontext-Layer im Banking ist die Schicht, die einem KI-Agenten im richtigen Moment genau den Kundenkontext gibt, den er für eine Aufgabe braucht und verwenden darf – nicht mehr und nicht weniger. Wie diese Schicht grundsätzlich aufgebaut ist und warum der Golden Record dafür nicht reicht, haben wir in Teil 2 unserer Serie zur Agentic Experience Platform beschrieben. Dieser Beitrag geht einen Schritt weiter, in den Betrieb. Kontext verändert sich unterschiedlich schnell, er ist an Zwecke gebunden und muss vergessen werden können. Wer das nicht als Daten modelliert, baut einen Agenten, der zwar viel weiß, aber Veraltetes oder Unerlaubtes verwendet.

Kontext ist kein Datensatz, sondern ein Gefüge mit vier Tempi

Kundenkontext besteht aus Schichten, die sich unterschiedlich schnell ändern, und jede Schicht braucht eigene Regeln für Aktualität. Scott Brinker hat „Context“ zum Martech-Wort des Jahres 2026 erklärt. Im „State of Martech 2026“ beschreibt er Kontext als Zusammensetzung vieler Teile, die sich in sehr unterschiedlichen Zeitskalen bewegen, und überträgt dafür das Modell des Pace Layering auf Marketing und KI (Scott Brinker, chiefmartec, Mai 2026). Pace Layering stammt aus der Architekturtheorie: Langsame Schichten geben Stabilität, schnelle Schichten tragen Veränderung.

Übertragen auf eine Bank ergeben sich vier Schichten. Ganz unten liegen Produkte, Konditionen und Regeln, die sich über Monate ändern. Darüber kommt die Beziehung zum Kunden mit Verträgen, Einwilligungen und Präferenzen; sie ändert sich über Wochen. Dann folgt der Anlass, etwa ein Umzug, eine Reklamation oder eine fällige Festgeldanlage, der sich über Tage entwickelt. Ganz oben steht der Moment selbst: das laufende Gespräch, die letzte Nachricht, die geöffnete Seite in der App. Ein Kontext-Layer, der alle vier Schichten mit derselben Aktualität behandelt, ist entweder zu langsam für den Moment oder zu teuer für die Regeln.

Erlaubnis und Zweck gehören in den Kontext, nicht daneben

Ein Agent darf nur Kontext sehen, dessen Verwendungszweck zur aktuellen Aufgabe passt – deshalb müssen Einwilligung und Zweck als Daten am Kontextobjekt hängen. Die DSGVO verlangt, dass personenbezogene Daten nur für festgelegte, eindeutige und legitime Zwecke erhoben und nicht in einer damit unvereinbaren Weise weiterverarbeitet werden (DSGVO, Art. 5 Abs. 1 lit. b). Widerspricht eine Kundin der Direktwerbung, dürfen ihre Daten für diesen Zweck nicht mehr verarbeitet werden (Art. 21 Abs. 3). Eine Einwilligung kann jederzeit widerrufen werden, und der Widerruf muss so einfach sein wie die Erteilung (Art. 7 Abs. 3).

In einer klassischen Architektur liegt diese Information in einem Consent-System, das Kampagnen vor dem Versand abfragen. Ein Agent arbeitet aber nicht in Kampagnen, sondern in Gesprächen. Er stellt Kontext in Sekunden neu zusammen. Wenn Erlaubnis und Zweck nicht am Kontextobjekt selbst hängen, sieht der Agent die Information zum Umzug, aber nicht, dass sie nur für den Service verwendet werden darf. Dass große Anbieter das Problem erkannt haben, zeigt Oracle: Das im Oktober 2026 vorgestellte „AI Agent Memory“ wird ausdrücklich als „governed memory core“ beschrieben, mit Isolation und Governance für produktive Agenten (Oracle Developers Blog, Oktober 2026). Für Banken reicht Governance auf Speicherebene allerdings nicht. Sie braucht die Zweckbindung je Kontextelement.

Illustration: KI-generiert, hypothetisches Beispiel.

Hypothetisches Beispiel: Ein Kunde zieht im Oktober um und meldet die neue Adresse in der App. In derselben Woche widerspricht er der Werbung per E-Mail. Zwei Tage später ruft er an, weil eine Lastschrift an die alte Adresse zurückgekommen ist. Der Assistent der Beraterin zeigt den Umzug, die zurückgegebene Lastschrift und den Widerspruch, aber kein Angebot für eine Hausratversicherung, obwohl das Modell sie als passend einstufen würde. Die Beraterin klärt die Lastschrift und fragt am Ende nur, ob sonst noch etwas offen ist. Der Kunde und die Bank sind frei erfunden.

Vergessen ist eine Funktion des Kontext-Layers

Was ein Agent nicht mehr wissen darf, muss der Kontext-Layer aktiv entfernen – aus Speicher, Zusammenfassungen und abgeleiteten Merkmalen. Die DSGVO verlangt die Löschung, wenn Daten für ihren Zweck nicht mehr notwendig sind oder eine Einwilligung widerrufen wurde (Art. 17). Sie verlangt außerdem, dass Daten sachlich richtig und auf dem neuesten Stand sind (Art. 5 Abs. 1 lit. d). Für Agenten entsteht daraus eine neue Pflicht. Gelöscht werden muss nicht nur der Ursprungsdatensatz, sondern auch die Zusammenfassung eines alten Gesprächs, die ein Agent im Gedächtnis abgelegt hat, und ein daraus abgeleitetes Merkmal wie „interessiert an Baufinanzierung“.

Praktisch heißt das: Jedes Kontextobjekt trägt ein Verfallsdatum und eine Löschregel. Momentkontext verfällt nach dem Gespräch. Anlasskontext verfällt, wenn der Anlass abgeschlossen ist. Beziehungskontext folgt den Aufbewahrungsfristen und den Einwilligungen. Abgeleitete Merkmale verweisen auf ihre Quellen und fallen weg, wenn eine Quelle wegfällt.

Ein Kontextobjekt in der Praxis

Ein brauchbares Kontextobjekt beschreibt nicht nur, was bekannt ist, sondern auch woher, wofür, wie lange und für wen. Die folgende Tabelle zeigt die Mindestfelder am Beispiel des Umzugs aus der Geschichte oben.

Der AI Context Layer von ACCELERAID folgt diesem Prinzip: Er gibt einem Agenten nur den Kontext, den er für einen Zweck lesen darf, macht Einwilligungen, Widersprüche und das freie Kontaktbudget im Moment der Entscheidung abfragbar und protokolliert jeden Zugriff revisionssicher. Ein Widerspruch wirkt sofort. Die Verarbeitung läuft in einem ISO-27001-zertifizierten Rechenzentrum in Frankfurt, On-Premise ist auf Anfrage möglich. Wie Einwilligungen selbst sauber verwaltet werden, beschreibt unser Beitrag zum DSGVO-Consent-Management im KI-Banking.

Drei Prüffragen für den eigenen Kontext-Layer

Ob ein Kontext-Layer betriebsfähig ist, zeigt sich an drei einfachen Tests. Erstens: Ein Kunde widerspricht der Werbung. Nach wie vielen Minuten sieht kein Agent mehr ein werbliches Merkmal dieses Kunden? Zweitens: Ein Anlass ist abgeschlossen. Verschwindet die Zusammenfassung aus dem Gedächtnis der Agenten, oder taucht sie in drei Monaten in einem Gespräch wieder auf? Drittens: Ein Prüfer fragt, warum ein Agent eine bestimmte Information verwendet hat. Lässt sich für jedes Kontextelement zeigen, aus welcher Quelle es kam und welcher Zweck es erlaubte?

Wer diese Fragen heute nur mit „das prüft die Kampagnensteuerung“ beantworten kann, hat einen Kontext für Kampagnen, aber noch keinen für Agenten.

Fünf Punkte zum Mitnehmen

1. Ein Kontext-Layer im Banking liefert einem Agenten den Kundenkontext, den er für eine Aufgabe braucht und verwenden darf, und nicht alles, was die Bank weiß.

2. Kontext hat vier Tempi – Regeln, Beziehung, Anlass, Moment –, und jede Schicht braucht eine eigene Aktualitätsregel; Scott Brinker beschreibt dieses Pace Layering im „State of Martech 2026“.

3. Zweck und Erlaubnis gehören als Daten an jedes Kontextobjekt, weil die DSGVO Zweckbindung, Widerruf und Werbewiderspruch verlangt und Agenten Kontext in Sekunden neu zusammenstellen.

4. Vergessen ist eine Funktion: Löschung betrifft auch Gesprächszusammenfassungen und abgeleitete Merkmale, nicht nur den Ursprungsdatensatz.

5. Drei Tests zeigen die Betriebsreife: Zeit bis zur Wirkung eines Widerspruchs, Verschwinden abgeschlossener Anlässe und Herkunftsnachweis für jedes verwendete Kontextelement.

Illustrationen: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.