AI im Banking | Customer Brain 3/5: Daten und Governance

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

Bankdaten machen aus einer allgemeinen Kundenarchitektur ein System mit besonderen Pflichten. Eine Kartenautorisierung, eine Adressänderung, ein Beschwerdevermerk und eine errechnete Abwanderungswahrscheinlichkeit mögen im selben Kundenkontext erscheinen. Sie sind trotzdem nicht dasselbe. Sie haben unterschiedliche Herkunft, Aussagekraft, Schutzbedarfe und zulässige Verwendungen. Wer sie in einem gemeinsamen „Brain“ vermischt, baut keine intelligentere Entscheidungsschicht, sondern eine schwer prüfbare Risikozone.

Für Banken beginnt die Architektur deshalb nicht beim Modell. Sie beginnt mit einer sauberen Trennung von Informationstypen, einer dokumentierten Herkunft und der Frage, welcher Zweck welche Nutzung rechtfertigt. Erst danach folgen Prognosen, Regeln und Aktionen.

Sechs Informationstypen, sechs unterschiedliche Rollen

Ein kontrollierbares System sollte mindestens sechs Klassen auseinanderhalten:

• Fakt: ein verifizierter Zustand aus einem führenden System, etwa ein aktiver Kartenvertrag oder ein hinterlegter Kontaktkanal.

• Ereignis: eine zeitgebundene Beobachtung, etwa eine abgelehnte Kartenzahlung, ein abgebrochener Onboarding-Schritt oder ein eingegangener Servicefall.

• Prognose: eine modellbasierte Schätzung, etwa eine erhöhte Wahrscheinlichkeit sinkender Kartennutzung. Sie ist kein Beweis für eine Absicht.

• Regel: eine fachliche, rechtliche oder operative Vorgabe, etwa ein Kontaktausschluss, eine Freigabeschwelle oder der Vorrang eines offenen Beschwerdefalls.

• Erfahrung: ein dokumentiertes Ergebnis früherer Interventionen, etwa dass eine Serviceübergabe in einem bestimmten Kontext hilfreicher war als eine Verkaufsansprache.

• Aktion: eine tatsächlich ausgeführte oder bewusst unterlassene Maßnahme mit Zeitpunkt, Kanal, Freigabe und Ergebnis.

Diese Trennung ist praktisch. Wenn eine Prognose wie ein Fakt behandelt wird, entsteht schnell eine falsche Gewissheit. Wenn ein Ereignis ohne Zeitraum dauerhaft im Profil bleibt, kann ein vorübergehender Zustand spätere Entscheidungen unangemessen prägen. Und wenn Erfahrung zu einer pauschalen Regel wird, ohne Segment, Zeitpunkt und Versuchsdesign zu dokumentieren, lernt das System womöglich nur alte Kampagnengewohnheiten.

Lineage ist die Voraussetzung für Erklärbarkeit

Jedes entscheidungsrelevante Datenelement braucht Lineage: Quellsystem, Erhebungszeitpunkt, Verarbeitungsschritte, verantwortliche Stelle, Qualitätsstatus und zulässige Verwendung. Bei einer Prognose gehören zusätzlich Modellversion, Merkmalsstand, Berechnungszeitpunkt und Gültigkeitsfenster dazu. Bei einer Regel müssen Version, Freigabe, Anwendungsbereich und Ausnahmeweg feststehen.

Damit wird eine Empfehlung rückwärts prüfbar. Die Bank kann nachvollziehen, ob eine Next Best Action auf einem aktuellen Fakt, einem kurzfristigen Ereignis, einer unsicheren Prognose oder einer verbindlichen Regel beruhte. Ohne diese Unterscheidung bleibt ein Audit-Trail zwar technisch vollständig, fachlich aber unverständlich.

Lineage darf auch nicht an der Modellgrenze enden. Wenn ein Signal in eine Entscheidung und anschließend in einen Kanal fließt, muss die Kette bis zur Ausführung reichen: Welche Daten wurden verwendet? Welche Regel hat eine Option ausgeschlossen? Wer oder was hat freigegeben? Welche Nachricht ging wann über welchen Kanal hinaus? Welches Ergebnis wurde zurückgeführt? Nur dann lässt sich ein Fehler korrigieren, ohne das gesamte System stillzulegen.

Zweckbindung muss technisch durchgesetzt werden

Die Datenschutzfrage lautet nicht nur, ob eine Bank Daten besitzt. Entscheidend ist, ob sie diese Daten für den konkreten Zweck verwenden darf. Der Europäische Datenschutzausschuss betont, dass KI-Modelle mit personenbezogenen Daten nicht automatisch anonym sind und Rechtsgrundlage sowie tatsächliche Anonymität im Einzelfall geprüft werden müssen (EDPB Opinion 28/2024). Eine Datenschutzerklärung allein schafft dabei keine berechtigte Erwartung für jede spätere KI-Nutzung.

Daraus folgen technische Guardrails:

1. Purpose Tags: Daten und abgeleitete Merkmale werden mit erlaubten Zwecken, Fristen und Ausschlüssen versehen.

2. Zugriff nach Rolle und Aufgabe: Ein Service-Team erhält den für den Fall nötigen Kontext, nicht automatisch Marketing-, Risiko- oder Vermögensdaten.

3. PII-Schutz vor Modellzugriff: Identifikatoren werden entfernt, maskiert oder tokenisiert, wenn der Use Case keine Klardaten benötigt. Modell-Prompts und Ausgaben werden auf personenbezogene Daten geprüft.

4. Minimierte Kontextpakete: Ein Modell bekommt nur die Felder und Dokumente, die für die konkrete Aufgabe erforderlich sind.

5. Trennung von Entscheidung und Ausführung: Eine Empfehlung darf nicht automatisch zum Versand werden. Kanalregeln, Consent, Sperren und Freigaben werden unmittelbar vor der Aktion erneut geprüft.

6. Löschung und Korrektur: Abgeleitete Merkmale, Zwischenspeicher und Ergebnisprotokolle müssen in Lösch- und Berichtigungsprozesse einbezogen sein.

Besonders sensible Situationen verlangen zusätzliche Zurückhaltung. Hinweise auf finanzielle Belastung dürfen nicht als frei nutzbares Vertriebssignal interpretiert werden. Sie benötigen einen eng begrenzten Service- oder Schutzkontext, klare Berechtigungen und häufig eine menschliche Prüfung. Eine wahrscheinlichkeitsbasierte Deutung darf nie als feststehende persönliche Eigenschaft behandelt werden.

DORA, GDPR, AI Act und BaFin steuern unterschiedliche Risiken

Die Regelwerke sollten nicht zu einem allgemeinen „Compliance“-Label verschmolzen werden. Die EDPB Opinion 28/2024 nennt mögliche zusätzliche Anforderungen für ausschließlich automatisierte Entscheidungen mit erheblicher rechtlicher Wirkung auf Personen. Der AI Act klassifiziert konkrete Funktionen: Kreditwürdigkeitsprüfung und Credit Scoring natürlicher Personen sind in Annex III als Hochrisiko-Anwendungen genannt; Betrugserkennung ist von dieser konkreten Kategorie ausgenommen (EU AI Act, Annex III). Ein Retention-Signal und eine Kreditentscheidung brauchen daher unterschiedliche Kontrollniveaus.

DORA adressiert die digitale operationelle Resilienz einschließlich IKT-Drittparteirisiken. Finanzunternehmen müssen Vertragsbeziehungen mit IKT-Dienstleistern in einem Informationsregister erfassen; die EBA beschreibt dafür harmonisierte Meldetemplates und gruppenbezogene Regeln (EBA DORA FAQ). Für die Architektur bedeutet das: Anbieter, Unterauftragnehmer, Datenstandorte, kritische Abhängigkeiten, Exit-Pfade und Wiederanlauf müssen von Anfang an dokumentierbar sein.

BaFin behandelt IKT-Risiken beim KI-Einsatz über den gesamten Lebenszyklus von Datenbeschaffung und Entwicklung bis Betrieb und Außerbetriebnahme und betont dabei das Drittparteirisiko (BaFin-Leitfaden zu IKT-Risiken beim KI-Einsatz). In ihrer Aufsichtsmitteilung zu Cloud-Auslagerungen fordert sie zudem belastbare Prüf- und Zugangsrechte; die bloße Existenz eines Zertifikats reicht grundsätzlich nicht aus (BaFin-Aufsichtsmitteilung).

Präzise Guardrails heißen deshalb: Use-Case-Klassifizierung vor Entwicklung, Daten- und Modellinventar, versionierte Regeln, Least-Privilege-Zugriff, verschlüsselte Übertragung und Speicherung, getestete Wiederherstellung, Drittparteienregister, definierte Aufbewahrung, laufendes Monitoring, dokumentierte Ausnahmebehandlung und ein abschaltbarer Aktionspfad. „DORA-konform“ oder „BaFin-validiert“ ist kein sinnvolles pauschales Produktversprechen; die konkrete Konfiguration und das Betriebsmodell entscheiden.

Die Aktivierungsschicht bleibt bewusst begrenzt

Acceleraid kann in diesem Bild Kunden- und Transaktionsdaten für Predictive Decisioning, Trigger, Next Best Action und kontrollierte Aktivierung nutzbar machen. Das ersetzt weder Core Banking noch Data Lake, Datenschutzorganisation oder Modellrisikomanagement. Es ist auch keine Behauptung, dass heute ein fertiges Customer Brain, ein Knowledge Graph oder ein organisationsweites Shared Memory ausgeliefert wird.

Der sinnvolle Einstieg ist ein begrenzter Use Case mit bekannten Quellen, einer zulässigen Aktion und einer messbaren Wirkungshypothese. Die Architektur muss zeigen können, was Fakt, Ereignis, Prognose, Regel und Erfahrung war. Erst wenn diese Kette verständlich bleibt, kann Bankdatenintelligenz operativ vertrauenswürdig werden. Wie eine solche Aktivierungsschicht zwischen Kernsystemen und Kundendialog einzuordnen ist, beschreibt der Beitrag zu dynamischen Banking-Engagement-Plattformen.

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.