KI in Banken: Wo sie heute arbeitet und welche Regeln gelten

Stand: September 2026

KI in Banken ist 2026 kein Innovationsprojekt mehr, sondern ein Aufsichtsthema. Gemeint sind Systeme, die aus Daten lernen und daraus Vorschläge, Klassifizierungen oder Texte erzeugen: vom Modell, das Transaktionen auf Geldwäscheverdacht prüft, bis zum Sprachmodell, das eine Kreditakte zusammenfasst. Neu ist nicht die Technik, sondern der Rahmen. Seit Januar 2025 gilt der Digital Operational Resilience Act (DORA), die Hochrisiko-Pflichten der EU-KI-Verordnung greifen ab dem 2. Dezember 2027, und seit Juli 2026 überwacht die BaFin auch KI-Systeme, die direkt mit regulierten Finanztätigkeiten zusammenhängen.

Die meiste KI arbeitet im Hintergrund

Wie schnell sich das ändert, zeigt eine Zahl der Aufsicht. Die BaFin verweist auf eine Umfrage der Europäischen Bankenaufsichtsbehörde (EBA) unter bedeutenden Instituten: Ende 2024 setzten etwa 40 Prozent der befragten Banken generative KI ein, im ersten Quartal 2025 waren es über 60 Prozent. Für Sparkassen, Genossenschaftsbanken und kleinere Privatbanken nennt die BaFin keine Quote. Sie beschreibt aber, wofür diese Häuser KI vor allem nutzen: für interne Prozesse wie Texterstellung und Chatbots sowie für Betrugserkennung und die Abwehr von Cyberkriminalität. In der Kreditwürdigkeitsprüfung setzen sie KI laut BaFin nur selten ein.

Typisch ist ein zweites Muster: viele Piloten, wenige Systeme im Regelbetrieb. Der Engpass ist selten das Modell. Es sind die Übergänge. Wer nimmt das Ergebnis fachlich ab? In welches Kernsystem schreibt die KI zurück? Wie fällt ein falsch ausgelesenes Feld auf?

Vier Einsatzfelder, in denen KI heute trägt

Kreditprozess. KI liest Gehaltsnachweise, Bilanzen und Selbstauskünfte aus, verdichtet Jahresabschlüsse zu Kennzahlen und unterstützt das Scoring. Rechtlich heikel ist nur das Scoring: Bewertet ein KI-System die Kreditwürdigkeit einer natürlichen Person, gilt es nach der EU-KI-Verordnung als Hochrisiko-System. Für Firmenkunden greift diese Einstufung nicht automatisch, bei Einzelunternehmern ist die Grenze genau zu ziehen.

Dokumente. Ein Sprachmodell mit vorgeschalteter Texterkennung liest Verträge, Sicherheitenunterlagen oder Behördenschreiben, überträgt Felder in eine feste Struktur und markiert, wo es sich unsicher ist. Sicher erkannte Felder laufen durch, unsichere gehen an einen Sachbearbeiter. Den Nutzen misst man an drei Größen: Durchlaufzeit je Vorgang, Anteil der Felder ohne Nacharbeit und Fehlerquote in einer Stichprobe.

KYC und Geldwäscheprävention. Beim Onboarding übernimmt KI das Lesen und Vergleichen von Ausweisen, Registerauszügen und Sanktionslisten, der Mensch bewertet die Auffälligkeiten. Im Transaktionsmonitoring sollen Modelle die Zahl falscher Alarme senken, die in Geldwäsche-Teams viel Prüfaufwand erzeugen.

Kundenservice. Chatbots beantworten Standardfragen, interne Assistenten durchsuchen Richtlinien und Arbeitsanweisungen. Seit dem 2. August 2026 gelten dafür Transparenzpflichten: Wer mit einem KI-System spricht, muss das erkennen können.

Drei Regelwerke greifen ineinander

Ein eigenes KI-Gesetz für Banken gibt es nicht. DORA regelt, ob die IT dahinter belastbar ist. KI-Systeme sind Teil der IKT, also gelten Drittparteienrisiko und Vorfallsmeldung auch für sie. Die KI-Verordnung regelt, welche Pflichten ein Anwendungsfall auslöst. Und Artikel 22 DSGVO regelt, ob eine rein automatisierte Entscheidung über Menschen überhaupt zulässig ist.

Zwei Daten verdienen Aufmerksamkeit. Am 31. Dezember 2026 endet die BAIT vollständig. Wer seine IT-Governance noch an BAIT-Kapiteln ausrichtet, sollte das Mapping auf DORA bis dahin abschließen. Am 2. Dezember 2027 greifen die Hochrisiko-Pflichten, ursprünglich für August 2026 geplant und durch die Verordnung (EU) 2026/1744 um 16 Monate verschoben. Aufgehoben sind sie nicht. Betreiber eines Kredit-Scorings müssen dann vor der Inbetriebnahme eine Grundrechte-Folgenabschätzung durchführen, auch wenn sie das Modell von einem Dienstleister einkaufen.

Praktisch wichtig: Ein KI-Ausfall kann ein meldepflichtiger IKT-Vorfall sein. Die Erstmeldung eines schwerwiegenden Vorfalls ist innerhalb von 4 Stunden nach der Einstufung fällig, spätestens 24 Stunden nach Kenntnis.

Der Betriebsort entscheidet über die Aufsichtsfähigkeit

Die teuerste Fehlentscheidung fällt selten beim Modell, sondern beim Betriebsort. Wer ein Sprachmodell über eine öffentliche API nutzt, bezieht eine IKT-Dienstleistung eines Drittanbieters. Das löst nach DORA Informationsregister, Vertragsanforderungen und Ausstiegsstrategie aus. Für interne Entwürfe ohne Kundendaten ist das vertretbar. KYC-Daten und Kreditakten gehören eher auf eigene Infrastruktur oder in eine Sovereign Cloud. Die Faustregel: Der Betriebsort folgt der Datenklasse, nicht der Vorliebe des Projektteams.

Wie das konkret aussehen kann, beschreibt Pexon Consulting auf seiner Seite zum KI-Engineering für Banken: eine Sovereign-RAG-Plattform, die wahlweise on-premise oder in der Azure Sovereign Cloud Frankfurt mit Open-Weight-Modellen wie Llama, Mistral oder Qwen läuft. Dazu kommen revisionssichere Protokolle mit Audit-Trail und eine menschliche Freigabe im Sinne von Artikel 22 DSGVO.

Was der Einstieg kostet

Überblicksartikel zu KI in Banken nennen fast nie Kosten. Pexon Consulting veröffentlicht Preisanker: ein Compliance-Audit mit DORA-Gap-Analyse und Einstufung nach der KI-Verordnung ab 15.000 € als Festpreis über 3 bis 4 Wochen, eine Banking-Transformation über 3 bis 12 Monate ab 150.000 €. Das sind Einstiegspreise, keine Budgets. Die tatsächlichen Kosten treiben der Zustand der Daten, die Zahl der angebundenen Kernsysteme und die Frage, ob der Anwendungsfall als Hochrisiko gilt. Laufende Kosten für Rechenleistung, Monitoring und Modellpflege fehlen in vielen Business Cases.

Fahrplan in fünf Schritten

1. KI-Inventar anlegen, auch für zugekaufte Software mit eingebetteter KI.
2. Je System einstufen: Hochrisiko oder nicht, Drittanbieter nach DORA, welche Datenklasse.
3. BAIT-Verweise bis zum 31. Dezember 2026 durch DORA-Anforderungen ersetzen.
4. Betriebsmodell je Datenklasse festlegen.
5. Einen Piloten mit Abbruchkriterium starten und Protokollierung sowie Vorfallsprozess vor dem Go-live klären.

Dieser Beitrag entstand in Zusammenarbeit mit Pexon Consulting. Die Pexon Consulting GmbH, Grünwald bei München, berät den regulierten deutschen Mittelstand in Fertigung, Energie, Banking und Versicherung zu Cloud-Architekturen, KI-Plattformen, Data Services sowie Kubernetes und DevOps. Autor ist Phillip Pham, Geschäftsführer der Pexon Consulting GmbH.