EBA-Entwurf zu operationellen Risiken: Was Banken bei KI und Automation jetzt tun sollten

Die neue EBA-Konsultation zu operationellen Risiken ist für Banken mehr als ein Thema für die Risikofunktion. Sie betrifft direkt, wie kundennahe Automatisierung, KI-Assistenten und digitale Workflows entworfen, freigegeben, überwacht und verbessert werden. Wer solche Lösungen einkauft oder betreibt, sollte deshalb nicht nur nach Modellgüte und Integration fragen, sondern nach klarer Verantwortung, belastbaren Ereignisdaten und nachweislich wirksamen Kontrollen.

Wichtig ist der regulatorische Status: Die Europäische Bankenaufsichtsbehörde (EBA) hat am 26. August 2026 einen Entwurf technischer Regulierungsstandards (RTS) nach Artikel 323 CRR3 zur Konsultation gestellt. Es handelt sich nicht um finales Recht. Stellungnahmen sind bis 31. Dezember 2026 möglich; danach will die EBA den Entwurf auf Basis der Rückmeldungen finalisieren und der Europäischen Kommission zur Annahme vorlegen. EBA-Pressemitteilung zur Konsultation EBA-Konsultationsseite

Drei Bausteine statt einer isolierten Kontrollliste

Der Entwurf strukturiert den Rahmen in drei Komponenten: Governance-Regelungen, den laufenden Prozess zur Steuerung operationeller Risiken und das System zur Risikobewertung. Ergänzend behandelt er unter anderem Risikodaten und Taxonomie, Berichterstattung, interne Validierung, Prüfung und Data Governance. Proportionalität ist ausdrücklich vorgesehen; Umfang und Frequenz einzelner Anforderungen hängen unter anderem von Größe und Komplexität des Instituts ab. EBA-Pressemitteilung zur Konsultation

Für kundennahe Automatisierung ergibt sich daraus ein zusammenhängender Steuerungskreislauf. Governance legt Risikobereitschaft, Rollen und Eskalationswege fest. Der Managementprozess identifiziert, überwacht, kontrolliert, mindert und berichtet Risiken fortlaufend. Das Bewertungssystem verbindet Prozessabbildung, Risiko- und Kontrollbewertungen sowie – soweit relevant – Szenarioanalysen und Stresstests. Ergebnisse sollen wieder in Entscheidungen, Maßnahmen und Änderungen einfließen. EBA-Konsultationspapier, Artikel 4 bis 8

Das ist für Käufer relevant: Ein Produktnachweis darf nicht bei einer Funktionsdemo enden. Benötigt wird eine belastbare Zuordnung zwischen Kundenprozess, automatisierter Entscheidung oder Empfehlung, möglichen Fehlerwirkungen, Kontrollen, Ereignisdaten und verantwortlichen Rollen. Diese Zuordnung macht aus einer technischen Komponente einen steuerbaren Bankprozess.

Workflow-Verantwortung muss bis zum Ausnahmefall reichen

Der Entwurf verlangt ein dokumentiertes, institutsweites Rahmenwerk mit klaren, transparenten und konsistenten Verantwortungswegen. Für jeden Bestandteil des operationellen Risikoprozesses sollen verantwortliche Mitarbeitende eindeutig benannt sein; zugleich soll die unabhängige Risikomanagementfunktion neue oder wesentlich geänderte Produkte, Prozesse und Systeme hinterfragen. EBA-Konsultationspapier, Artikel 4, 6 und 10

Für einen KI-Assistenten im Service, eine automatisierte Next-Best-Action oder einen digitalen Onboarding-Workflow sollte der fachliche Owner deshalb nicht nur für den Normalablauf zuständig sein. Der Verantwortungsbereich sollte auch Abbruch, Übergabe an Mitarbeitende, falsche Klassifizierung, unzulässige Eingabe, fehlende Daten, Anbieter-Ausfall und nachträgliche Korrektur umfassen. Das ist eine praktische Umsetzungsempfehlung, keine wörtliche Liste aus dem Entwurf.

Beschaffung und Change Management sollten dazu mindestens fünf Artefakte einfordern: eine End-to-End-Prozesskarte, eine Rollenmatrix, dokumentierte Freigabekriterien, definierte Eskalationswege und eine Versionshistorie der wesentlichen Änderungen. Der Entwurf nennt Prozessabbildung als mögliches Bewertungsinstrument und verlangt, dass Ergebnisse der Risikobewertung systematisch in Change Management und Aktionspläne eingehen. Außerdem soll die zweite Verteidigungslinie wesentliche Änderungen an Produkten, Aktivitäten, Prozessen und Systemen unabhängig hinterfragen. EBA-Konsultationspapier, Artikel 7, 8 und 10

Kontrollen für Automatisierung: vorbeugen, erkennen, korrigieren

Der Entwurf unterscheidet präventive, detektive und korrektive Kontrollmaßnahmen. Dokumentiert werden sollen Design, Implementierung und getestete Wirksamkeit der Kontrollen; das Rahmenwerk soll anhand einer fortlaufenden Bewertung des Kontrollumfelds überprüft und bei Bedarf angepasst werden. EBA-Konsultationspapier, Artikel 5 und 6

Für kundennahe Systeme lässt sich das konkret übersetzen. Präventive Kontrollen begrenzen zulässige Datenquellen, Aktionen und Kundensegmente; sie erzwingen Freigaben für sensible Schritte. Detektive Kontrollen erkennen ungewöhnliche Abbruchraten, widersprüchliche Ausgaben, Regelverstöße oder auffällige manuelle Übersteuerungen. Korrektive Kontrollen stoppen einen Ablauf, leiten Fälle um, korrigieren Kundendaten und dokumentieren die Behebung. Welche Kontrollen angemessen sind, hängt vom Risiko und Prozess ab. Entscheidend ist, dass Kontrollbehauptungen testbar sind und nicht nur in einer Produktbeschreibung stehen.

Der Entwurf sieht zudem Routinen zur Erfassung genehmigter Ausnahmen, Management Overrides und anderer Abweichungen vor. Für AI-gestützte Workflows sollten solche Eingriffe daher als eigener Datentyp mit Grund, Rolle, Zeitpunkt, betroffener Version und Ergebnis behandelt werden. So wird sichtbar, ob menschliche Eingriffe einzelne Sonderfälle lösen oder auf ein wiederkehrendes Prozessproblem hinweisen. EBA-Konsultationspapier, Artikel 12

Vorfälle und Verluste brauchen eine gemeinsame Sprache

Gute Telemetrie allein ist noch keine Risikodatenbasis. Der Entwurf fordert Prozesse zum Erfassen, Speichern, Aggregieren, Analysieren und Überwachen genauer, vollständiger, konsistenter und zeitnaher operationeller Risikodaten. Vorgesehen sind auch Vorfälle und Beinaheereignisse ohne Verlustwirkung sowie Mindestfelder für Treiber, Ursachen, Folgen und die Verbindung zum betroffenen Geschäftsprozess. Die genaue Datentiefe ist proportional ausgestaltet. EBA-Konsultationspapier, Artikel 9

Für Käufer bedeutet das: Anbieter-Logs, CRM-Ereignisse, Service-Tickets, Beschwerdedaten und Buchungsfolgen müssen über stabile Kennungen verbunden werden können. Eine gemeinsame Taxonomie sollte zwischen technischem Fehler, Prozessfehler, Datenproblem, Fehlverhalten, Drittanbieterproblem und Kundenwirkung unterscheiden. Der Entwurf verlangt Governance, Ownership und Änderungskontrolle für die Risikotaxonomie sowie nachvollziehbare Datenflüsse, Datenqualitätskontrollen und Audit Trails. EBA-Konsultationspapier, Artikel 9 und 15

Dabei sollten Teams nicht nur monetäre Verluste betrachten. Wiederholte Fehlberatungen, unnötige Eskalationen oder knapp vermiedene Fehlaktionen können ein Kontrollproblem zeigen, bevor ein buchbarer Verlust entsteht. Der Entwurf verfolgt ausdrücklich einen vorausschauenden Ansatz und verbindet Ereignis-, Near-Miss-, Kontroll- und Szenariodaten mit Eskalation, Entscheidung und Abhilfe. EBA-Konsultationspapier, Artikel 7 und 9

Validierung und Audit sind unterschiedliche Nachweise

Interne Validierung und Audit haben im Entwurf getrennte, sich ergänzende Aufgaben. Soweit Modelle für Entscheidungen eingesetzt werden, soll die interne Validierung unter anderem die Solidität von Modellen für KI-Anwendungen und Kundenprofilierung beurteilen. Ergebnisse sind zu dokumentieren und für interne Entscheidungen sowie die aufsichtliche Prüfung nutzbar zu machen. Audit soll dagegen Zuverlässigkeit und Wirksamkeit von Prozess und Bewertungssystem bestätigen sowie Richtlinien, relevante Verfahren, Kontrollen und Datenqualität prüfen. EBA-Konsultationspapier, Artikel 12 bis 14

Ein Freigabepaket für eine Kundenautomation sollte deshalb zwei Fragen getrennt beantworten. Erstens: Funktioniert die Lösung unter den definierten Bedingungen, Grenzen und Szenarien belastbar? Zweitens: Ist das gesamte Steuerungssystem – einschließlich Rollen, Daten, Ausnahmen, Kontrollen und Maßnahmenverfolgung – unabhängig prüfbar? Lieferanten sollten dafür reproduzierbare Tests, Versionsnachweise, Datenherkunft, bekannte Grenzen und exportierbare Prüfspuren bereitstellen. Die Verantwortung der Bank wird dadurch nicht ausgelagert.

DORA abdecken, aber den breiteren Rahmen nicht darauf reduzieren

DORA regelt detailliert ICT-Risikomanagement, ICT-bezogene Vorfälle und Meldungen, Resilienztests sowie ICT-Drittparteienrisiken. Der RTS-Entwurf erlaubt Banken, vorhandene DORA-Strategien, Prozesse, Protokolle, Werkzeuge und Kontrollen zu verwenden, soweit sie auch die Anforderungen des breiteren operationellen Risikorahmens erfüllen. ICT-Vorfälle sollen zugleich als operationelle Risikoereignisse behandelt werden, wenn sie in dessen Anwendungsbereich fallen. EBA-Konsultationspapier, Artikel 2 und Erwägungsgründe

Damit ist DORA eine wichtige Grundlage, aber kein Ersatz für die Gesamtbetrachtung. Ein KI-Assistent kann technisch verfügbar und cyberseitig kontrolliert sein und dennoch operationelle Risiken durch ungeeignete Empfehlungen, unklare Zuständigkeit, fehlerhafte Prozessübergaben oder unvollständige Verlustdaten erzeugen. Banken sollten daher DORA-Nachweise wiederverwenden, die verbleibenden fachlichen und organisatorischen Lücken aber ausdrücklich dokumentieren.

Was Käufer bis zum Ende der Konsultation tun können

Bis zum 31. Dezember 2026 sollten Institute keine vermeintlich finale RTS-Checkliste bauen. Sinnvoller ist ein reversibler Readiness-Sprint: priorisierte Kundenworkflows abbilden, je Workflow einen Owner benennen, Kontrolltypen und Eskalationen zuordnen, Ereignis- und Verlustdaten auf Verknüpfbarkeit prüfen sowie Validierung und Audit früh einbinden. Offene Punkte können anschließend als begründete Konsultationsbeiträge formuliert werden. Die EBA bittet um Rückmeldungen mit klarem Bezug, Begründung, Evidenz und möglichen Alternativen. EBA-Konsultationspapier, Konsultationshinweise

Der unmittelbare Nutzen liegt nicht in vorweggenommener Compliance. Er liegt in besserer Kauf- und Betriebsfähigkeit: Teams können Anforderungen an Anbieter präziser formulieren, Risiken über Systemgrenzen hinweg verfolgen und Änderungen kontrolliert freigeben. Sollte sich der Entwurf verändern, bleiben diese Grundlagen für kundennahe Automation dennoch operativ nützlich.

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.