AI im Banking | Customer Brain 2/5: Die Architektur

AI im Banking · Customer-Brain-Serie · Teil 2 von 5

Ein Customer Brain für Banken ist kein einzelnes Modell und keine neue Bezeichnung für eine Customer Data Platform. Es ist eine zusammengesetzte Architektur, die Daten, Bedeutung, Gedächtnis, Entscheidungen, Richtlinien und Aktionen kontrolliert verbindet. Wie in Teil 1 der Serie erläutert, liefert Customer 360 die Sicht auf den Kunden. Das Customer Brain ergänzt die Fähigkeit, eine Situation einzuordnen und innerhalb klarer Grenzen zu handeln.

Für die Architekturplanung ist diese Unterscheidung entscheidend. Wer mit dem LLM beginnt, optimiert früh die sichtbare Antwort, aber spät die Verlässlichkeit des Systems. Banken sollten stattdessen von Quellen, Identitäten, erlaubten Zwecken und Entscheidungspunkten ausgehen. Das Sprachmodell ist dabei eine mögliche Komponente – das LLM ist nicht das Brain.

1. Multi-Source Data: Quellen behalten ihre Autorität

Ein Customer Brain benötigt Daten aus mehreren Systemen: etwa Kundenstammdaten, Konten und Produkte, Transaktionen, digitale Interaktionen, Kampagnenreaktionen, Servicefälle und Einwilligungen. Diese Daten sollten nicht ungeprüft in einen gemeinsamen Kontext kopiert werden. Jede Quelle braucht einen definierten Eigentümer, Qualitätsstatus, Aktualitätswert und zulässigen Zweck.

Die Architektur muss außerdem zwischen System of Record und abgeleiteter Information unterscheiden. Ein Kernsystem kann den Produktstatus verbindlich führen; ein Modell kann daraus eine Abwanderungswahrscheinlichkeit ableiten. Beides darf nicht denselben Wahrheitsstatus erhalten. Herkunft, Zeitpunkt und Transformationsweg müssen nachvollziehbar bleiben.

2. Identity: Die richtige Person im richtigen Kontext

Identity Resolution verbindet Datensätze, ohne vorschnell Identitäten zu verschmelzen. Neben Kundennummern können Haushaltsbeziehungen, Bevollmächtigungen, Unternehmensrollen, Geräte oder anonyme digitale Sitzungen relevant sein. Die Regeln dafür müssen deterministisch oder probabilistisch gekennzeichnet und überprüfbar sein.

Besonders im Banking ist „gleicher Kunde“ nicht gleich „gleiche Berechtigung“. Eine Person kann Privatkunde, Vertreter eines Unternehmens und Bevollmächtigter eines weiteren Kontos sein. Der zulässige Kontext hängt von Rolle, Zweck, Kanal und Zeitpunkt ab. Deshalb gehört Autorisierung nicht nachträglich an die Benutzeroberfläche, sondern in die Identitäts- und Zugriffsebene.

3. Semantik und Beziehungen: Daten bekommen fachliche Bedeutung

Semantik übersetzt technische Felder in bankfachliche Begriffe. Sie beschreibt zum Beispiel, was „aktive Nutzung“, „Onboarding abgeschlossen“, „Beschwerde offen“ oder „Kontakt erlaubt“ konkret bedeutet. Beziehungen verbinden Kunden, Produkte, Ereignisse, Vorgänge, Kanäle und Richtlinien.

Dafür ist nicht zwingend eine einzelne Graphdatenbank erforderlich. Entscheidend ist ein konsistentes semantisches Modell, das Beziehungen explizit und abfragbar macht. Es muss Versionen, Definitionen und Verantwortliche haben. Ohne diese Ebene kann ein Modell sprachlich plausibel antworten, aber fachlich unterschiedliche Bedeutungen vermischen.

4. Vier Arten von Gedächtnis

Ein Customer Brain braucht nicht „mehr Speicher“, sondern getrennte Gedächtnisfunktionen mit unterschiedlichen Fristen und Kontrollen:

• Working Memory hält den kurzfristigen Kontext einer Aufgabe: aktuelle Frage, relevante Transaktion, aktiver Vorgang und bereits ausgeführte Schritte. Es sollte klein, zweckgebunden und zeitlich begrenzt sein.

• Semantic Memory enthält relativ stabiles Wissen: Produktdefinitionen, Fachbegriffe, zulässige Prozessvarianten oder kuratierte Wissensartikel. Quellen und Gültigkeit müssen erkennbar sein.

• Episodic Memory erfasst relevante Ereignisse einer Kundenbeziehung, etwa einen Servicekontakt, eine Beschwerde, ein Angebot oder dessen Ergebnis. Nicht jedes Ereignis verdient dauerhafte Speicherung.

• Procedural Memory beschreibt, wie eine Aufgabe korrekt ausgeführt wird: Prüfschritte, Freigaben, Eskalationswege und Kanalregeln. Es ist eher versioniertes Prozesswissen als freie Erinnerung.

Diese Trennung unterstützt Datenminimierung. Die europäische Datenschutzaufsicht weist darauf hin, dass die Verarbeitung personenbezogener Daten in KI-Modellen eine konkrete Rechtsgrundlage und eine Einzelfallprüfung verlangt; eine bloße Datenschutzerklärung begründet noch keine vernünftige Erwartung der betroffenen Person (EDPB Opinion 28/2024). Gedächtnis braucht daher Löschfristen, Korrekturwege, Zweckbindung und Zugriffskontrollen.

5. Reasoning: Optionen bewerten, nicht Wahrheit erfinden

Die Reasoning-Schicht kombiniert aktuelle Signale, gespeicherten Kontext und fachliche Logik. Sie kann Regeln, statistische Modelle, Optimierung und ein LLM verwenden. Ihre Aufgabe ist, mögliche Erklärungen oder Aktionen zu bewerten – nicht fehlende Fakten zu ergänzen.

Ein guter Entscheidungsdatensatz enthält deshalb nicht nur das Ergebnis. Er hält auch verwendete Quellen, Modellversion, Unsicherheit, ausgeschlossene Optionen und den Auslöser fest. Bei hohem Risiko oder unzureichender Evidenz endet Reasoning mit einer Eskalation statt einer automatischen Aktion.

6. Policy Layer: Zulässigkeit vor Ausführung

Die Policy Layer prüft, ob eine vorgeschlagene Aktion erlaubt ist. Dazu gehören Consent, Zweckbindung, Rollenrechte, Kontaktregeln, Produktvoraussetzungen, Sperrlisten, Risikolimits und menschliche Freigaben. Richtlinien sollten als versionierte, testbare Artefakte geführt werden, nicht nur als Text in einem Prompt.

Die Kontrolle muss Use-Case-spezifisch sein. Der EU AI Act stuft Systeme zur Kreditwürdigkeitsprüfung und zum Credit Scoring natürlicher Personen ausdrücklich als Hochrisiko-Anwendungen ein (EU AI Act, Annex III). Für Betreiber von Hochrisiko-Systemen nennt Artikel 26 unter anderem kompetente menschliche Aufsicht, Monitoring und die Aufbewahrung automatisch erzeugter Logs für mindestens sechs Monate, soweit anderes Recht keine längere Frist verlangt (AI Act, Artikel 26). Ein Servicehinweis und eine Kreditentscheidung brauchen daher unterschiedliche Kontrollen.

7. Agents: Begrenzte Verantwortung statt Autonomie

Agents koordinieren Schritte innerhalb eines definierten Auftrags. Ein Agent kann Kontext abrufen, eine Empfehlung vorbereiten, eine Richtlinienprüfung anstoßen oder eine freigegebene Aktion an ein Zielsystem übergeben. Er sollte nur die Werkzeuge und Daten sehen, die seine Rolle benötigt.

Damit bleibt Verantwortung sichtbar. Für jeden Agenten sollten Zweck, erlaubte Tools, Eingabe- und Ausgabeformate, Abbruchkriterien und menschliche Übergaben dokumentiert sein. Ein LLM kann die sprachliche oder planerische Funktion unterstützen. Es ersetzt aber weder Identität noch Policy Layer, System of Record oder Audit Trail.

8. Aktionen: Der Punkt, an dem Risiko real wird

Eine Empfehlung wird erst durch Ausführung wirksam. Aktionen können eine Aufgabe im CRM, eine Servicenachricht, eine Next Best Action, eine Kanalunterdrückung oder eine Übergabe an Mitarbeitende sein. Schreibende Zugriffe verdienen strengere Kontrollen als lesende: Freigaben, Idempotenz, Betrags- oder Häufigkeitsgrenzen, Rücknahmeoptionen und vollständige Protokollierung.

Für Banken ist auch der Lieferantenkontext relevant. BaFin erwartet bei Cloud-Auslagerungen unter anderem belastbare Prüfungsrechte, durchgängige Rechte in Unterauftragnehmerketten und eine gegen konkrete Alternativanbieter getestete Exit-Strategie (BaFin-Aufsichtsmitteilung zu Cloud-Auslagerungen). Diese Anforderungen gehören in die Betriebsarchitektur, nicht nur in den Einkaufsvertrag.

9. Feedback: Lernen unter Aufsicht

Feedback verbindet Ergebnis und nächste Entscheidung. Dazu zählen Zustellung, Reaktion, Abschluss, Ablehnung, Beschwerde, menschliche Korrektur und unerwartete Nebenwirkungen. Nicht jedes Feedback darf automatisch ein Modell verändern. Zunächst muss klar sein, ob es die Datenqualität, eine Regel, ein Modell, einen Prozess oder die Aktion selbst betrifft.

Ein kontrollierter Closed Loop trennt Messen, Bewerten und Ändern. Modellupdates, neue Regeln und erweiterte Agentenrechte durchlaufen Tests und Freigaben. So bedeutet „lernend“ nicht „unkontrolliert selbstverändernd“.

Das Zielbild schrittweise bauen

Die Architektur sollte an einem begrenzten Use Case getestet werden. Ein sinnvoller Start definiert Quellen, Identität, Gedächtnis, Entscheidung, Policy, erlaubte Aktion und Erfolgsmaß im Voraus. Danach lässt sich beobachten, wo Menschen eingreifen, welche Daten fehlen und welche Regeln zu grob sind.

Acceleraid kann in einem solchen Zielbild sachlich als kontrollierte Customer-Activation-Schicht eingeordnet werden. Dokumentiert sind die Verbindung von Kunden- und Transaktionssignalen mit Segmentierung, Predictive Decisioning, Triggern und personalisierter Aktivierung. Das ist ein möglicher Ausführungsteil der Architektur, aber kein Anspruch, heute ein vollständiges Customer Brain mit gemeinsamem Gedächtnis, Ontologie und autonomen Agents auszuliefern. Die bestehende Einordnung von CDP, Predictions und Agents findet sich ergänzend im Beitrag zur Intelligence Layer.

Ein Customer Brain entsteht somit nicht durch die Wahl eines besonders leistungsfähigen Modells. Es entsteht durch sauber definierte Übergänge: von autoritativen Daten zu Identität und Bedeutung, von Bedeutung zu begrenztem Gedächtnis, von Reasoning zu Richtlinien und von freigegebenen Aktionen zu überprüfbarem Feedback. Genau diese Übergänge machen die Architektur bankfähig.

Die vollständige Customer-Brain-Serie

Leitartikel: Die Customer-Brain-Roadmap · Teil 1: Customer 360 reicht nicht · Teil 2: Architektur · Teil 3: Daten und Governance · Teil 4: Retention Loop · Teil 5: Reifegradmodell

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.