Customer Data Platform mit Kontext-Layer: Vom Golden Record zum Golden Context

Serie Agentic Experience Platform für Banken · Teil 2 von 5. Der Leitartikel beschreibt die fünf Schichten; Teil 1 legt das Betriebsmodell. Dieser Teil behandelt die unterste Schicht: die Customer Data Platform mit Kontext-Layer.

Ein Golden Record ist ein Versprechen aus der Zeit der Berichte: ein Kunde, ein Datensatz, alle Felder gefüllt und widerspruchsfrei. Für einen Agenten, der im Moment einer Entscheidung handeln soll, reicht das nicht. Er braucht nicht nur den Datensatz, sondern dessen Bedeutung, dessen Erlaubnis und dessen Vorgeschichte. Scott Brinker hat dafür im Oktober 2026 den treffenderen Begriff vorgeschlagen: Golden Context, der Schnittpunkt aus Kundenkontext, Unternehmenskontext und Systemkontext (chiefmartec). Dieser Teil zeigt, was dieser Schnittpunkt in einer Bank technisch bedeutet und warum er nicht größer werden darf, als die Zweckbindung erlaubt.

Drei Kontexte, ein kleiner Schnittpunkt

Brinkers Unterscheidung ist einfach und folgenreich. Der Kundenkontext ist alles, was die Situation eines Kunden ausmacht: Ziele, Absichten, Präferenzen, Lebensereignisse, Historie. Der Unternehmenskontext ist alles, was die Bank über sich selbst weiß: Produktregeln, Risikoappetit, Kontaktpolitik, Zuständigkeiten, Governance. Beide existieren in der Wirklichkeit, unabhängig von jeder Software. Der Systemkontext ist der Teil davon, der in Systemen so abgebildet ist, dass ein Agent ihn abfragen und darauf handeln kann. Und dieser Teil ist meist ein kleiner Ausschnitt (chiefmartec).

Daraus folgen zwei Arbeitsrichtungen, die Brinker Kontext-Engineering und Wert-Engineering nennt. Kontext-Engineering vergrößert den Systemkontext: mehr Kundensituation und mehr Unternehmensregeln werden maschinenlesbar. Wert-Engineering sorgt dafür, dass beides richtig zusammenkommt, dass also die passende Regel auf die passende Situation trifft. Die Branchenzahlen zeigen, wie weit beides noch entfernt ist. In der von Adobe beauftragten Befragung von 150 Anwendern von Customer Data Platforms nannten nur 39 Prozent harmonisierte Profile als heute stärkste Fähigkeit ihrer Plattform, und nur 27 Prozent trauten ihrem Data Warehouse zu, Profile, Segmente und die nächste beste Erfahrung in Echtzeit zu liefern. Bei den Kaufkriterien stand Echtzeit-Leistung mit 69 Prozent an erster Stelle (Adobe, CDP Study 2026).

Für Banken kommt eine dritte Richtung dazu, die in der Marketing-Literatur fehlt: Kontext-Begrenzung. Der Systemkontext darf nicht alles enthalten, was technisch verfügbar wäre, sondern nur, was für den jeweiligen Zweck erhoben und erlaubt ist. Der Europäische Datenschutzausschuss hat in seiner Stellungnahme zu KI-Modellen klargestellt, dass die Verarbeitung personenbezogener Daten für Entwicklung und Einsatz solcher Modelle eine Rechtsgrundlage und eine Einzelfallprüfung des berechtigten Interesses braucht (EDPB, Stellungnahme 28/2024). Golden Context in einer Bank ist deshalb nicht der größtmögliche, sondern der zulässige Schnittpunkt.

Was die Kontextschicht leisten muss

Wir ordnen der Kontextschicht der Acceleraid-Plattform fünf Funktionen zu. Die Benennung ist unsere; die Funktionen sind in jeder Bank dieselben, unabhängig vom Anbieter.

Datenmanagement bringt Signale aus Kernbank, Karte, App, Service und Einwilligungsverwaltung zusammen, mit Herkunft und Zeitstempel. Das ist die klassische Aufgabe einer Customer Data Platform und bleibt die aufwendigste. Identitätsauflösung verbindet diese Signale zu einer Person über Konten, Kanäle und Rollen hinweg, inklusive der Fälle, die in Banken häufig sind: Gemeinschaftskonten, Bevollmächtigte, Kunden mit Privat- und Geschäftsbeziehung. Einwilligung und Zweck speichert nicht nur, ob eine Einwilligung vorliegt, sondern wofür, seit wann und mit welchen Widersprüchen; diese Information muss im Moment der Entscheidung abfragbar sein, nicht erst bei der Prüfung durch den Datenschutz. Semantik und Beziehungen geben den Daten Bedeutung: Was ein Gehaltseingang ist, was eine Abweichung vom Muster bedeutet, welche Produkte zueinander in Beziehung stehen. Gedächtnis schließlich unterscheidet vier Arten, die wir in unserer Customer-Brain-Serie eingeführt haben: den kurzfristigen Arbeitsstand einer laufenden Interaktion, Episoden wie einen abgeschlossenen Servicefall, Fakten wie die bevorzugte Kontaktzeit und Regeln wie die Kontaktpolitik der Bank.

Dass Gedächtnis eine knappe Ressource ist, gilt nicht nur für Menschen. Anthropic beschreibt in seiner Anleitung zum Kontext-Engineering für Agenten den Kontext als kritische, aber endliche Ressource und formuliert als Ziel, die kleinste Menge an aussagekräftigen Informationen zu finden, die das gewünschte Ergebnis wahrscheinlich macht (Anthropic). Für die Kontextschicht einer Bank heißt das: Sie liefert dem Agenten nicht den ganzen Golden Record, sondern den Ausschnitt, der für diese Entscheidung relevant und erlaubt ist.

Vier Arten von Gedächtnis, vier verschiedene Pflichten

Die vier Gedächtnisarten verdienen einen genaueren Blick, weil sie unterschiedlich behandelt werden müssen. Das Arbeitsgedächtnis hält den Stand einer laufenden Interaktion: Was die Kundin im Chat gerade gefragt hat, welche Optionen der Berater schon genannt hat. Es ist flüchtig und darf es sein; nach Abschluss der Interaktion bleibt davon nur das Ergebnis. Das episodische Gedächtnis speichert abgeschlossene Vorgänge: der Servicefall, die Beschwerde, der Beratungstermin, mit Datum und Ausgang. Es ist das Gedächtnis, das verhindert, dass dieselbe Kundin dreimal dasselbe erklären muss, und es unterliegt Löschfristen. Das semantische Gedächtnis hält stabile Fakten: bevorzugter Kanal, Rolle im Haushalt, Produktbestand. Es ändert sich selten und muss bei jeder Änderung versioniert werden, weil Entscheidungen darauf beruhen. Das prozedurale Gedächtnis schließlich enthält die Regeln der Bank: Kontaktpolitik, Eignungsregeln, Schwellen für Freigaben. Es gehört dem Fachbereich, nicht dem Agenten, und jede Änderung ist eine Governance-Entscheidung.

Ein Agent, der diese vier Arten nicht auseinanderhält, macht zwei typische Fehler: Er behandelt flüchtige Zustände als Fakten und schreibt sie fort, oder er behandelt Regeln als Beobachtungen und beginnt, sie zu optimieren. Beides ist in Banken nicht tolerierbar.

Was der Agent nicht sehen soll

Kontext-Begrenzung hat eine praktische Seite. Es gibt Datenfelder, die technisch im Golden Record liegen, aber nicht in den Kontext eines Agenten gehören, der Hinweise und Angebote vorbereitet: besondere Kategorien personenbezogener Daten, Freitextnotizen aus Beratungsgesprächen, Transaktionsdetails jenseits des Musters, das für den Zweck gebraucht wird. Die Kontextschicht liefert deshalb nicht Zugriff auf Tabellen, sondern Antworten auf definierte Fragen: Weicht das Einkommensmuster ab, ja oder nein. Besteht ein Werbewiderspruch, ja oder nein. Gab es in den letzten 30 Tagen einen Servicefall, ja und welcher Art. Jede dieser Fragen ist dokumentiert, jeder Abruf protokolliert. So bleibt der Systemkontext handlungsfähig und zugleich kleiner als die Datenbasis.

Vom Datensatz zum Kontextobjekt

Wie aus einem Feld ein Kontext wird, zeigt ein hypothetisches Beispiel in fünf Stufen. Ausgangspunkt ist ein einzelnes Rohdatum aus den Transaktionsdaten der Kernbank: Gehaltseingang im Oktober null.

Die Identitätsauflösung ordnet das Datum einer Kundin zu und stellt fest, dass kein zweites Konto bekannt ist, auf das der Eingang gewandert sein könnte. Die Semantik erkennt, dass die vorherigen 14 Monate ein stabiles Muster zeigten und der Oktober davon abweicht. Die Einwilligungsverwaltung liefert, dass Kundenbetreuung zulässig ist, Werbung aber widersprochen wurde. Das episodische Gedächtnis ergänzt, dass vor drei Wochen ein Servicefall wegen Kartenverlust abgeschlossen wurde, der die Kundin möglicherweise verärgert hat. Erst das Kontextobjekt, das aus diesen fünf Stufen entsteht, geht an die Entscheidungsschicht, mit der Vorgabe: Hinweis prüfen, kein Kreditangebot.

Fehlt eine der Stufen, bleibt das Feld ein Datum. Ohne Identität weiß niemand, wessen Gehalt fehlt. Ohne Bedeutung ist null einfach eine Zahl. Ohne Erlaubnis ist jede Reaktion ein Risiko. Ohne Gedächtnis wirkt ein gut gemeinter Hinweis wie ein zweites Ärgernis in drei Wochen. Das ist der praktische Unterschied zwischen Golden Record und Golden Context: Der Record ist vollständig, der Kontext ist handlungsfähig.

Warum das keine Frage der Architekturmode ist

Die Diskussion um Kundendatenplattformen wird gern als Architekturstreit geführt: zentral oder föderiert, Plattform oder Warehouse, mit oder ohne eigene Speicherung. Wir haben im Beitrag zum sogenannten Headless CDP argumentiert, dass diese Frage zweitrangig ist. Entscheidend ist, ob die fünf Funktionen im Moment der Entscheidung verfügbar sind, in der Latenz, die der Kundenmoment verlangt, und mit der Zweckbindung, die das Datenschutzrecht verlangt. Ob die Daten dafür kopiert oder abgefragt werden, ist eine Betriebsentscheidung, keine Grundsatzfrage.

Ein Anbieter, der sich von Treasure Data in Treasure AI umbenennt, zieht aus derselben Beobachtung die Konsequenz, Agenten direkt auf die Datenschicht zu setzen (Treasure AI). In einer Bank muss dazwischen die Kontextschicht liegen, die Bedeutung, Erlaubnis und Gedächtnis beisteuert und zugleich begrenzt, was der Agent sieht. Das ist kein Umweg. Es ist die einzige Form, in der Geschwindigkeit und Zweckbindung gleichzeitig möglich sind.

Drei Fragen für die eigene Bestandsaufnahme

Wer die eigene Kontextschicht einschätzen will, braucht keine Reifegradstudie. Drei Fragen reichen. Erstens: Kann ein System im Moment einer Entscheidung abfragen, für welche Zwecke diese Kundin eingewilligt und welchen sie widersprochen hat, in weniger als einer Sekunde? Zweitens: Weiß dasselbe System, was in den letzten Wochen mit dieser Kundin passiert ist, über Kanäle hinweg, inklusive abgeschlossener Servicefälle? Drittens: Ist dokumentiert, welche Datenfelder für welchen Zweck in den Kontext eines Agenten gelangen dürfen? Wer alle drei Fragen mit Ja beantwortet, hat einen Golden Context. Wer eine mit Nein beantwortet, hat einen Golden Record, und sollte den Agenten noch warten lassen.

Was im nächsten Teil folgt

Ein Kontextobjekt ist eine Eingabe, keine Entscheidung. Was daraus wird, entscheidet die Schicht darüber: Prognosen, Regeln, Ziele und Grenzen, verbunden zu einem Entscheidungsdatensatz. Teil 3 behandelt KI und Decision Engine mit Predictions in der Mitte des Kreislaufs.

Fünf Punkte zum Mitnehmen

1. Golden Context ist der Schnittpunkt aus Kundenkontext, Unternehmenskontext und Systemkontext; in Banken ist er nicht der größtmögliche, sondern der zulässige Schnittpunkt.

2. Die Kontextschicht hat fünf Funktionen: Datenmanagement, Identitätsauflösung, Einwilligung und Zweck, Semantik und Beziehungen, Gedächtnis in vier Arten.

3. Aus einem Feld wird erst durch Identität, Bedeutung, Erlaubnis und Gedächtnis ein Kontextobjekt, auf das ein Agent reagieren darf; fehlt eine Stufe, bleibt es ein Datum.

4. Kontext ist eine endliche Ressource: Die Schicht liefert dem Agenten den relevanten und erlaubten Ausschnitt, nicht den ganzen Datensatz.

5. Ob Daten kopiert oder abgefragt werden, ist eine Betriebsentscheidung; entscheidend sind Verfügbarkeit im Kundenmoment und Zweckbindung.

Illustration: 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.