Daten & Technologie
AI im Banking | Customer Brain 1/5: Customer 360 reicht nicht
Warum eine vollständige Kundensicht noch keine kontrollierte Entscheidung ermöglicht und welche Schichten einem Customer Brain fehlen.
•
acceleraid Redaktion
5 Min. Lesezeit

AI im Banking · Customer-Brain-Serie · Teil 1 von 5
Eine Customer-360-Sicht beantwortet eine wichtige Frage: Was wissen wir über diesen Kunden? Ein Customer Brain muss eine schwierigere Frage beantworten: Was ist in dieser Situation relevant, was dürfen wir daraus ableiten, und welche nächste Handlung ist angemessen? Zwischen beiden Konzepten liegt nicht nur mehr KI. Es liegt ein Wechsel von der Datenansicht zur kontrollierten Entscheidung.
Viele Banken haben ihre Kundendaten über Jahre zusammengeführt. CRM, Transaktionen, Servicekontakte, Kampagnenreaktionen und digitale Ereignisse landen in Data Warehouses, Lakehouses oder Customer Data Platforms. Das ist notwendige Grundlagenarbeit. Sie erzeugt aber noch kein System, das Kontext über Zeit bewahrt, Beziehungen versteht, Regeln anwendet und aus Ergebnissen lernt. Customer 360 ist eine Sicht. Ein Customer Brain ist ein Architekturmodell für kontextbezogene, nachvollziehbare Entscheidungen.
Customer 360 beschreibt – ein Customer Brain interpretiert
Customer 360 bündelt Profile, Konten, Produkte, Kontakte und Ereignisse. Im besten Fall entsteht eine verlässliche, aktuelle Sicht für Analyse und Segmentierung. Der Nutzen ist real: Teams arbeiten mit weniger Datensilos und einer konsistenteren Grundlage. Doch eine vollständige Ansicht trifft noch keine Entscheidung.
Dafür fehlen mehrere Fähigkeiten. Das System muss erkennen, welche Identitäten zusammengehören, welche Ereignisse zeitlich oder fachlich verbunden sind und welcher Kontext für den jeweiligen Zweck zulässig ist. Es muss kurzfristige Signale von stabilem Wissen unterscheiden. Außerdem braucht es Regeln für Einwilligung, Zugriff, Ausschlüsse, Eskalation und Freigabe. Erst dann lässt sich aus „Der Kunde hat Produkt A und Ereignis B“ eine begründete Empfehlung ableiten.
Das ist auch der Grund, warum ein Sprachmodell allein nicht genügt. Ein LLM kann Sprache verarbeiten und Schlussfolgerungen formulieren. Es kennt aber nicht automatisch die verlässliche Kundenidentität, den gültigen Consent, die aktuelle Produktberechtigung oder die Bankrichtlinie für eine konkrete Aktion. Diese Informationen und Grenzen müssen aus kontrollierten Systemen kommen.
„Das Customer Brain ist keine ferne Vision mehr. Die erforderlichen technischen Bausteine sind heute verfügbar. Wir stehen nicht mehr vor einem Forschungsproblem, sondern vor einer Umsetzungs- und Governance-Aufgabe. Entscheidend ist, Daten, Modelle, Gedächtnis und Agents so zu verbinden, dass Datenschutz, Zugriffsrechte, fachliche Regeln und menschliche Kontrolle von Anfang an Teil der Architektur sind.“ — Michael Altendorf, CEO von Acceleraid

Drei Situationen zeigen den Unterschied
Churn: Eine Customer-360-Sicht kann sinkende Nutzung, abnehmende Einlagen, wiederholte Servicekontakte oder ausbleibende Reaktionen anzeigen. Ein Customer Brain würde diese Signale nicht pauschal in eine Kampagne übersetzen. Es müsste ihren zeitlichen Verlauf, offene Beschwerden, Produktstatus, Kontaktpräferenzen und Ausschlussregeln berücksichtigen. Die Handlung kann ein Servicekontakt, eine zurückhaltende Information, ein Angebot oder bewusst keine Ansprache sein. Entscheidend ist nicht nur der Score, sondern die begründete Wahl unter zulässigen Optionen.
Onboarding: Ein Dashboard zeigt, welche Schritte abgeschlossen sind. Ein Customer Brain würde verstehen, an welchem Ziel der Prozess stockt, welche Information bereits gegeben wurde und ob eine Erinnerung hilfreich oder störend wäre. Es könnte zwischen einem technischen Abbruch, einer ausstehenden Legitimation und fehlendem Produktverständnis unterscheiden. Die nächste Aktion bliebe an Regeln gebunden: etwa an zulässige Kanäle, Fristen und die Übergabe an einen Menschen.
Beschwerdekontext: Eine isolierte Marketinglogik sieht möglicherweise ein Cross-Sell-Signal. Der Service weiß zugleich, dass eine Beschwerde offen ist. Ein Customer Brain muss diesen Zusammenhang herstellen und der Beschwerde Vorrang geben. Es sollte frühere Zusagen, Bearbeitungsstand und Tonalität verfügbar machen, ohne mehr personenbezogene Daten offenzulegen als für die Aufgabe nötig. Das Resultat ist nicht automatisch eine Antwort, sondern zunächst ein sicherer Kontext für die richtige Person oder den richtigen Prozess.
Diese Beispiele zeigen: Der Mehrwert entsteht nicht aus maximaler Datenmenge, sondern aus passendem Kontext, klaren Regeln und einer steuerbaren Aktion.
Gedächtnis bedeutet nicht grenzenlose Speicherung
Der Begriff „Brain“ kann in die falsche Richtung führen. Gemeint ist kein allwissender Kundenspeicher. Für Banken wäre ein solcher Ansatz weder fachlich sinnvoll noch datenschutzrechtlich vertretbar. Die europäische Datenschutzaufsicht betont, dass KI-Modelle mit personenbezogenen Trainingsdaten nicht automatisch anonym sind und die Rechtsgrundlage sowie Anonymität im Einzelfall geprüft werden müssen (EDPB Opinion 28/2024).
Ein belastbares Customer Brain arbeitet deshalb mit zweckgebundenem Gedächtnis. Es hält nur den Kontext vor, den ein definierter Use Case benötigt, trennt Rollen und Zwecke und dokumentiert, woher eine Information stammt. Vergessen, Löschung und Korrektur sind ebenso wichtig wie Erinnern. Der relevante Beschwerdekontext darf beispielsweise für die Servicebearbeitung zugänglich sein, aber nicht automatisch in jede Vertriebsentscheidung einfließen.
Auch regulatorisch zählt die konkrete Funktion. Der EU AI Act ordnet Kreditwürdigkeitsprüfung und Credit Scoring natürlicher Personen ausdrücklich den Hochrisiko-Anwendungen zu; Betrugserkennung ist in diesem Punkt ausgenommen (EU AI Act, Annex III). Ein Informationsassistent, eine Churn-Empfehlung und eine Kreditentscheidung dürfen daher nicht unter einem pauschalen „KI“-Kontrollmodell betrieben werden. Risiko, Datenzugriff und menschliche Aufsicht müssen je Use Case festgelegt werden.
Von der Sicht zur Handlungsfähigkeit
Der praktikable Weg beginnt nicht mit einer unternehmensweiten Brain-Plattform. Er beginnt mit einem abgegrenzten Entscheidungsproblem. Eine Bank kann einen Use Case wählen, die zulässigen Datenquellen definieren, eine Identitäts- und Kontextlogik aufbauen und die erlaubten Aktionen begrenzen. Danach werden Ergebnis, Eingriff und Ausnahmefälle gemessen. So wird Governance Teil des Designs statt einer nachträglichen Prüfung.
Für diese Umsetzung braucht es mindestens fünf klar getrennte Ebenen:
verlässliche Daten und Identitäten,
fachliche Bedeutung und Beziehungen,
zweckgebundenes Gedächtnis,
Entscheidung und Richtlinienprüfung,
kontrollierte Aktion mit Feedback.
Diese Trennung verhindert, dass ein generatives Modell gleichzeitig Datenquelle, Entscheider und Ausführender wird. Sie schafft zudem überprüfbare Übergaben zwischen Technik, Fachbereich, Datenschutz, Informationssicherheit und Modellrisikomanagement.
Acceleraid ist in diesem Bild nicht als heute ausgeliefertes Customer Brain zu verstehen. Die sachliche Rolle ist die einer kontrollierten Customer-Activation-Schicht: Kunden- und Transaktionssignale werden für Segmentierung, Predictive Decisioning, Trigger und personalisierte Aktivierung nutzbar gemacht. Damit kann eine Bank den Schritt von der konsolidierten Sicht zur überwachten Handlung unterstützen, ohne Data Warehouse, Lakehouse oder CDP zu ersetzen. Wie diese Aktivierungsschicht zwischen Core-Systemen und Kundendialog einzuordnen ist, erläutert auch der bestehende Beitrag zu dynamischen Banking-Engagement-Plattformen.
Customer 360 bleibt also wichtig. Es ist aber die Datenbasis, nicht das Zielbild. Das Customer Brain beginnt dort, wo Identität, Bedeutung, Gedächtnis, Regeln und Aktionen zu einem kontrollierbaren Entscheidungsprozess verbunden werden. Teil 2 dieser Serie zerlegt diese Architektur in ihre einzelnen Bausteine.
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.
Weitere Insights
Wir verwenden Cookies 🍪
Unbedingt erforderliche Cookies, etwa für Pipedrive-Formulare, bleiben aktiv. Mit Ihrer Einwilligung nutzen wir außerdem Google Analytics zur Analyse und Leadfeeder zur Besucheridentifikation. Weitere Informationen finden Sie in unserer Datenschutzerklärung.
Ablehnen
Alle akzeptieren