BaFin-Orientierungshilfe KI: IKT-Risiken beim KI-Einsatz nach DORA steuern

Entstehung: von der Rede zur Veröffentlichung

Angekündigt hat die Orientierungshilfe Nikolas Speer, Exekutivdirektor Bankenaufsicht, am 04.12.2025 in seiner Keynote „IT-Aufsicht im Finanzsektor: Das erste Jahr DORA“ — mit der Formel „Kein neues Pflichtenheft. Sondern eine Hilfe.“ Am 18.12.2025 folgte die Meldung „Künstliche Intelligenz: BaFin veröffentlicht Orientierungshilfe zu IKT-Risiken“. Herausgeber ist das Referat CTF 5 der Abteilung Cyberrisiken und Technologie im Finanzsektor. Die deutsche Fassung (Stand 18.12.2025, 38 Seiten) ist das Original; die englische Übersetzung „Guidance on ICT Risks in the Use of AI at Financial Entities“ (Version date 23.01.2026, 35 Seiten) erschien am 30.01.2026.

Rechtscharakter: unverbindlich, aber kein Freibrief

Die Orientierungshilfe bezeichnet sich als „nicht verpflichtende Hilfestellung“, beruht u. a. auf Gesprächen mit Finanzunternehmen, stellt „keine verbindliche DORA-Auslegung der BaFin“ dar und „definiert keine aufsichtlichen Erwartungen“ (Kap. I und I.2); auch die Maßnahmen der Fallstudie sind ausdrücklich exemplarisch. Verbindlich bleiben DORA, RTS RMF und RTS Untervergabe. Der BaFin-Jahresbericht 2025 spricht allerdings von einer „aktualisierten Erwartungshaltung“, die in Form der Orientierungshilfe kommuniziert worden sei. Pflichten folgen daraus nicht — als Signal der Aufsichtspraxis sollten Sie die Formulierung aber ernst nehmen.

Adressaten und Grenzen

Gemeint sind Finanzunternehmen im Sinne von Art. 2 Abs. 2 i. V. m. Abs. 1 lit. a–t DORA, insbesondere CRR-Institute und Solvency-II-Versicherungsunternehmen; adressiert sind vor allem von der BaFin beaufsichtigte Unternehmen, die Art. 5 bis 15 DORA einhalten müssen. Der vereinfachte Rahmen nach Art. 16 DORA bedarf laut Orientierungshilfe einer gesonderten Betrachtung und ist nicht Gegenstand. Inhaltlich geht es ausschließlich um IKT-Risiken und deren Behandlung unter DORA und den ergänzenden RTS; die mathematische Modellmethodik samt Daten, Entwicklung und Validierung bleibt außen vor (Kap. I.1).

Die Orientierungshilfe versteht sich als „lebendes Dokument“ (Kap. I.3); maßgeblich ist derzeit der Stand 18.12.2025 (DE) bzw. 23.01.2026 (EN). Die BaFin verweist bereits darauf: in „Risiken im Fokus 2026“ vom 28.01.2026, das u. a. Abhängigkeiten von Drittanbietern für Cloud und KI-Modelle sowie Data- und Model-Poisoning als KI-Risiken nennt, und im BaFinJournal-Interview zum KI-MIG vom 29.07.2026.

Drei Schritte der Begriffsbildung (Kap. I.1)

1. 1
   Art. 3 Nr. 1 KI-VOLegaldefinition übernehmen

   Ein KI-System ist ein maschinengestütztes System, das für einen in unterschiedlichem Grade autonomen Betrieb ausgelegt ist, nach Betriebsaufnahme anpassungsfähig sein kann und aus Eingaben für explizite oder implizite Ziele ableitet, wie es Ausgaben wie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erstellt, die physische oder virtuelle Umgebungen beeinflussen können.

2. 2
   C(2025) 5053 final, Rn. 11„Maschinengestützt“ auslegen

   KI-Systeme werden mithilfe von Maschinen entwickelt und auf ihnen betrieben. Nach den Leitlinien der Kommission vom 29.07.2025 umfasst die Maschine Hardware (Verarbeitungseinheiten, Speicher, Netzwerkeinheiten, Ein- und Ausgabeschnittstellen) und Software (u. a. Quellcode, Betriebssysteme, Anwendungen).

3. 3
   Art. 3 Nr. 2 DORAIn DORA einordnen

   KI-Systeme sind damit ein Unterfall der Netzwerk- und Informationssysteme. Gemeint ist eine Kombination aus IKT-Assets und IKT-Infrastruktur, in die ein komplexes mathematisches Modell implementiert ist; das Modell selbst ist ein IKT-Asset (Software).

Nicht betrachtet werden die KI-VO-Merkmale Autonomie und Anpassungsfähigkeit sowie die mathematische Modellmethodik einschließlich der verwendeten Daten, ihrer Entwicklung und Validierung. Die Orientierungshilfe fragt also nicht, wie gut ein Modell rechnet, sondern wie sicher und resilient das System ist, in dem es läuft. Art und Umfang eines KI-Systems sind einzelfallabhängig und müssen insbesondere dem Geschäftszweck, der Risikosituation und dem Sachzusammenhang entsprechen.

Versteckte KI: wenn Software unbemerkt zum KI-System wird

Kap. III.2 beschreibt die Herausforderung, beim Testen zu erkennen, ob Anwendungen externe KI-Modelle etwa über APIs einbinden — eine ursprünglich als Nicht-KI-Anwendung geplante Software kann so zum KI-System werden. Kap. III.1 ergänzt, dass KI-generierter Code dem Nutzer unbekannte KI-Funktionen aufrufen kann. Laut Fallstudie (Variante 3) werden KI-Assistenten aus Standardsoftware ggf. ohne Kenntnis der Nutzer aufgerufen; die Schlussbetrachtung hält fest, dass sie häufig in Standardsoftware enthalten sind.

Die Konsequenz für das Inventar: Für das Management von Informations- und IKT-Assets sind eine Richtlinie und Verfahren Pflicht (Art. 8 Abs. 4 DORA i. V. m. Art. 4 und 5 RTS RMF). Laut Kap. IV.1 sind auch die Komponenten von KI-Systemen zu ermitteln, zu klassifizieren, zu dokumentieren und kontinuierlich zu überwachen. Wer nur „KI-Projekte“ inventarisiert, übersieht die KI, die mit dem nächsten Update einer Standardsoftware oder über eine API ins Haus kommt.

Zitierhinweis: In Textauszügen der deutschen PDF erscheint bei den Kommissionsleitlinien „Rn. 116“ — gemeint ist Rn. 11 mit Fußnote 6.

Warum der Lebenszyklus der bessere Ordnungsrahmen ist

Laut Kap. I.2 stehen spezifische IKT-Risiken in keinem Zusammenhang mit der Verortung eines KI-Systems in der Wertschöpfungskette; sie ergeben sich aus seiner Einbindung in die IKT-Landschaft. Deshalb folgt die Orientierungshilfe dem KI-Lebenszyklus — von der Datenbeschaffung über Modellentwicklung und Bereitstellung bis zu laufendem Betrieb und Stilllegung. In jeder Phase soll die Sicherheit und Resilienz des KI-Systems gewährleistet sein, und KI-Systeme sind im bestehenden IKT-Risikomanagementrahmen zu berücksichtigen. Abbildung 1 ordnet fünf Angriffsvektoren zu: Daten und KI-Modell (Kap. III), Input, Output und das IKT-System selbst (Kap. IV); Cyber- und Datensicherheit wirken übergreifend (Kap. V).

Einsatzfelder laut Kap. I

Proportionalität nach Art. 4 DORA

Art. 4 DORA verpflichtet zur verhältnismäßigen Anwendung des IKT-Risikomanagements nach Größe, Gesamtrisikoprofil sowie Art, Umfang und Komplexität der Dienste und Tätigkeiten. Die Orientierungshilfe übersetzt das für KI: Anwendungen, die in kritische oder wichtige Funktionen integriert sind, benötigen umfangreichere Sicherheits- und Kontrollmaßnahmen als etwa KI-basierte Self-Service-Assistenten, die vollständig unter menschlicher Überwachung stehen und nicht in Entscheidungsprozesse eingebunden sind (Kap. I.2). Bewertet werden KI-Systeme wie IKT-Systeme nach Risikoprofil, Komplexität und unterstützten Funktionen (Kap. II.1). Ausdrücklich nach Kritikalität stuft die Orientierungshilfe an diesen Stellen ab:

• KI-Strategie: gewinnt an Gewicht, wenn KI kritische oder wichtige Funktionen unterstützt (Kap. II.2).
• Kontrollfunktionen und interne Revision: Beteiligung bei der Einführung abhängig von der Kritikalität des KI-Systems (Kap. II.2).
• Tests: Umfang angemessen zur Kritikalität (Art. 16 Abs. 2 RTS RMF); Adversarial Testing und Stresstests „je nach Kritikalität“ (Kap. III.2).
• Erkennung: risikobasierte Protokollierung; Schwellenwerte und Indikatoren für Fehlverhalten bei kritischen oder wichtigen Funktionen (Kap. IV.1).
• Cloud: SLAs, Exit-Strategie, Notfalltests und lückenlose Prüfrechte bei Unterstützung kritischer oder wichtiger Funktionen (Kap. IV.2).

KI-Strategie und Technologie-Roadmap

Finanzunternehmen erstellen laut Kap. II.2 „oftmals“ eine KI-Strategie, die an Gesamt-, Risiko- und ggf. IKT- sowie DOR-Strategie ausgerichtet ist, und lassen sie vom Leitungsorgan genehmigen — eigenständig oder integriert in eine übergeordnete Strategie. Ihr Gewicht wächst vor allem, wenn KI kritische oder wichtige Funktionen unterstützt. Grundlage kann eine Technologie-Roadmap sein, die IKT-Ressourcen, -Kapazitäten und -Investitionen für den KI-Einsatz festlegt; ein kontinuierliches Innovationsmanagement hilft, neue KI-Technologien zu bewerten. Es bietet sich an, alle Schritte von der Strategie über die Entwicklung bis zur Stilllegung entlang eines Prozesses abzudecken und zu dokumentieren. Wichtig ist laut Orientierungshilfe, vor der Implementierung zu prüfen, ob die relevanten Prozesse für KI ausgelegt sind und eine Sensibilisierung zum Umgang mit Informationswerten besteht.

Pflicht und Praxis im Überblick

Hilfreich ist laut Kap. II.2, allgemeine Vorgaben zu formulieren, die im Einklang mit der DOR-Strategie und den Leit- und Richtlinien zur Informationssicherheit stehen. Spezifische Regelungen für IKT-Drittdienstleister und deren Dienstleistungen sollten idealerweise eine Risikobewertung, Hinweise des Dienstleisters und eigene Maßnahmen zur Risikoreduktion berücksichtigen. Die allgemeinen Anforderungen sollten auf den Anwendungsfall bezogen werden, verbunden mit der Prüfung, ob zusätzliche KI-spezifische Maßnahmen notwendig sind.

Kompetenz-Anker: Die Orientierungshilfe stützt Kompetenzanforderungen auf Art. 5 Abs. 4 und Art. 13 Abs. 6 DORA, nicht auf Art. 4 KI-VO. Die KI-Kompetenzregel der KI-Verordnung gilt seit 02.02.2025 parallel; die VO (EU) 2026/1744 hat sie weicher gefasst: Statt nach besten Kräften ein ausreichendes Maß an KI-Kompetenz sicherzustellen, sind Maßnahmen zu ergreifen, um die Entwicklung der KI-Kompetenz zu unterstützen.

Art. 6 Abs. 1 DORA verlangt einen soliden, umfassenden und gut dokumentierten IKT-Risikomanagementrahmen als Teil des Gesamtrisikomanagementsystems. Die Orientierungshilfe hebt diese Norm als Zitat-Kasten hervor und zählt als Bestandteile des Rahmens u. a. auf: Identifizierung, Schutz und Prävention, Erkennung, Reaktion und Wiederherstellung, Lernprozesse und Weiterentwicklung sowie Kommunikation (Art. 8 bis 11, 13 und 14 DORA). Die Integration der KI-Systeme umfasst danach die Ermittlung von Schwachstellen etwa im Modelltraining, in Datenpipelines oder bei der Inferenz sowie die Bewertung quantitativer und qualitativer Risikokriterien (Kap. II.3).

Was die Orientierungshilfe je DORA-Baustein ableitet

Wichtig für die Abgrenzung: Halluzinationen ordnet die Fallstudie als nicht unmittelbar IKT-relevant ein (Phase 4). Von den Aspekten der Datenqualität ist nur die Integrität ein Schutzziel von DORA; für die übrigen enthält die Verordnung keine Regelungen (Kap. V.2). Die Überwachung von Modelldrift taucht als zu dokumentierende Behandlungsmaßnahme auf, nicht als eigenständiges IKT-Risiko. Vorgaben zur Datenqualität verortet die Orientierungshilfe als typischen Bestandteil der Governance-Strukturen für KI — eine hohe Datenqualität vor allem bei Trainingsdaten bleibt wesentliche Voraussetzung für den KI-Einsatz.

Jährliche Überprüfung und Bericht

Pflicht ist die Überprüfung des IKT-Risikomanagementrahmens mindestens jährlich sowie nach schwerwiegenden IKT-bezogenen Vorfällen, aufsichtlichen Anweisungen oder Feststellungen aus Tests und Prüfungen (Art. 6 Abs. 5 DORA). Auf Anfrage der zuständigen Behörde ist ein Bericht über die Überprüfung vorzulegen; Art. 27 RTS RMF schreibt dafür ein durchsuchbares elektronisches Format vor. Zu den Pflichtinhalten nach Art. 27 Abs. 2 RTS RMF gehören u. a. eine Zusammenfassung zum aktuellen und kurzfristigen IKT-Risikoprofil und zur Bedrohungslage, das Datum der Genehmigung durch das Leitungsorgan, Feststellungen samt Schweregrad sowie Abhilfemaßnahmen mit Terminen und Verantwortlichen. Die Orientierungshilfe ergänzt, dass der Bericht bei Bedarf um spezifische Informationen zu KI-Systemen angereichert werden kann.

Kompetenzen: wer was können muss

Beschäftigte mit KI-Aufgaben stehen laut Kap. III.1 vor der Herausforderung, Kompetenzen zur Funktionsweise der KI-Systeme, zu ihren Risiken und zu den Besonderheiten von Cloud- und On-Premise-Betrieb zu erwerben; je technischer die Aufgabe, desto spezifischer das Wissen. Wegen des rasanten Fortschritts hält die Orientierungshilfe regelmäßige Schulungen und eine kontinuierliche Beobachtung der Entwicklungsdynamik für erforderlich. Für Leitungsorgan und Management verweist sie auf Art. 5 Abs. 4 und Art. 13 Abs. 6 DORA. Wo Fachbereiche mithilfe von KI-Assistenten eigene Anwendungen bauen, zitiert sie Art. 16 Abs. 9 RTS RMF — tragend ist diese Norm für die Gleichbehandlung von End-User-Computing, die Kompetenzpflichten selbst folgen aus DORA.

Pflicht und Praxis im Entwicklungsprozess

Trainingsprozess: vier Vorgehensweisen, die sich laut Orientierungshilfe als hilfreich erwiesen haben

• Trainings- und Testdaten stammen aus vertrauenswürdigen Quellen.
• Im Training genutzte (Open-Source-)Bibliotheken und Softwarepakete enthalten keine bekannten Schwachstellen.
• Der gesamte Trainingsprozess wird dokumentiert und versioniert.
• Sicherheitsanalysen decken versteckte Manipulationen im Modell oder in den Trainingsdaten auf.

Open-Source-Bibliotheken — im äußersten Fall ein Open-Source-Modell, das auf eigener Hardware implementiert, trainiert und betrieben wird — bringen laut Kap. III.1 zwei Zusatzrisiken: eingeschleusten Schadcode und Bibliotheken, die nach einigen Jahren nicht mehr gepflegt werden und identifizierte, aber nicht behobene Schwachstellen hinterlassen. Für KI-generierten Code gelten dieselben Regeln wie für menschlichen. Die Herausforderung liegt darin zu prüfen, ob er dem Nutzer unbekannte KI-Funktionen aufruft; das lässt sich u. a. per statischer Codeanalyse ermitteln (Art. 16 Abs. 3 RTS RMF). Tiefere Quellcode-Analysen können zusätzliche Sicherheit geben, eine angemessene Dokumentation hat sich für das nachfolgende Testen als empfehlenswert erwiesen.

Was der RTS RMF verbindlich regelt

Finanzunternehmen müssen Tests entwickeln, dokumentieren und implementieren. Der Testumfang muss der Kritikalität der betroffenen Geschäftsprozesse und IKT-Assets angemessen sein und prüfen, ob neue IKT-Systeme — und damit KI-Systeme — ihrer geplanten Bestimmung angemessen sind (Art. 16 Abs. 2 RTS RMF). Quellcode ist vor dem produktiven Einsatz mit statischen und dynamischen Verfahren auf Anomalien zu prüfen, einschließlich Sicherheitstests internetfähiger Systeme (Art. 16 Abs. 3 RTS RMF). Proprietäre Software sowie nach Möglichkeit Quellcode von IKT-Drittdienstleistern und aus Open-Source-Projekten ist vor der Inbetriebnahme zu analysieren und zu testen (Art. 16 Abs. 8 RTS RMF).

Drei KI-spezifische Herausforderungen (Kap. III.2)

Testbausteine nach Kritikalität

Die Betriebsprozesse sollen den gesamten Lebenszyklus abdecken — Entwicklung, Installation, Betrieb und Deinstallation — und alle Betriebsaktivitäten dokumentieren, etwa Logfiles von Modellinferenzprozessen (Art. 8 RTS RMF). Informations- und IKT-Assets einschließlich der KI-Komponenten sind zu ermitteln, zu klassifizieren, zu dokumentieren und kontinuierlich zu überwachen (Art. 8 Abs. 4 DORA i. V. m. Art. 4 und 5 RTS RMF; siehe Kapitel 2). Rollenbasierte Zugriffsrechte auf KI-Modelle und Trainingsdaten bezeichnet die Orientierungshilfe als wirksames Werkzeug, das regelmäßig zu prüfen und zu dokumentieren ist; Art. 21 RTS RMF verlangt Least Privilege und eine Überprüfung der Rechte mindestens jährlich, bei Systemen kritischer oder wichtiger Funktionen mindestens alle sechs Monate.

Die Betriebsbausteine im Überblick

Wie viel davon Pflicht und wie viel Praxis ist, zeigt der Wortlaut: Die Pläne „müssen“ mindestens jährlich getestet werden (Art. 11 Abs. 6 lit. a DORA), und Art. 10 RTS RMF schreibt automatisierte Schwachstellenscans für Assets kritischer oder wichtiger Funktionen mindestens wöchentlich vor. Kontinuierliches Monitoring, lückenlose Protokollierung von KI-Entscheidungen und KI-spezifische Schwellenwerte für Fehlverhalten beschreibt die Orientierungshilfe dagegen als sinnvoll, empfehlenswert oder vorteilhaft — die allgemeine Pflicht zu Erkennungsmechanismen mit Alarmschwellen (Art. 10 Abs. 1 und 2 DORA) bleibt davon unberührt. Die Fallstudie ergänzt für Betrieb und Wartung eines KI-Assistenten (Phasen 4 und 5) eine situationsbezogene Überwachung der KI-Interaktionen, automatisierte Updates, einen Sicherheitsvorfall-Reaktionsplan (SIRP) und ein Compliance-Dashboard mit Modellversion, Risikobewertungen und Verantwortlichkeiten. Die Deinstallation behandelt Kapitel 9.

Nachweise, die Sie vorlegen können (VamiSec)

• KI-Inventar mit Komponenten, Kritikalität, Eigentümer, Datenherkunft und Support-Enddaten der Anbieter einschließlich Abkündigungsterminen von Modellversionen
• Kapazitätsplanung und Monitoring-Auswertungen der KI-Infrastruktur
• Protokollierungskonzept mit Schwellenwerten und Nachweis der Wirksamkeitsprüfung
• Rezertifizierung der Zugriffsrechte auf Modelle und Trainingsdaten
• Testprotokolle der Geschäftsfortführungspläne mit KI-Ausfallszenarien

Das Risiko benennt die Orientierungshilfe bereits in Kap. II.1: Unkontrollierte Weiterverwendung oder unsichere Entsorgung von KI-Anwendungen gefährdet sensible Modell- oder Unternehmensdaten. Die Fallstudie wird konkreter — historische Daten und Modelle können missbraucht oder unbeabsichtigt öffentlich verfügbar werden. Sie folgert, dass die Stilllegung von LLMs und zugehörigen Datenquellen „wie bei allen IKT-Assets“ zu planen ist. Schon Kap. II.2 regt an, alle KI-relevanten Schritte von der Strategie bis zur Stilllegung entlang eines Prozesses abzudecken und zu dokumentieren.

Pflicht, Praxis, Empfehlung — sauber getrennt

Ein KI-System hinterlässt mehr als eine Anwendung. Zu den Informations- und IKT-Assets zählt die Orientierungshilfe u. a. Trainingsdatensätze, Implementierungen von Modellen, Softwarebibliotheken, Hardware sowie selbst und fremd erstellte Software (Kap. IV.1); für die Löschung nennt die Fallstudie zusätzlich die historischen KI-Interaktionen. Aus unserer Praxis gehören RAG-Wissensbasen, Modellkopien in Backups sowie API-Schlüssel und Service-Konten auf dieselbe Liste.

Stilllegungs-Runbook (VamiSec-Empfehlung)

1. 1
   Auslöser und Umfang festlegen

   Stilllegung, Versions- und Anbieterwechsel lösen denselben Prozess aus. Aus dem KI-Inventar alle Artefakte ableiten: Modellversionen, Trainingsdaten, Wissensbasen, Logs, Schnittstellen, Konten.

2. 2
   Abhängigkeiten kappen

   Schnittstellen, Service-Konten und API-Schlüssel deaktivieren, Benutzerzugänge sperren (Art. 21 RTS RMF). Veraltete Modellversionen gezielt deaktivieren, nicht nur aus dem Routing nehmen.

3. 3
   Aufbewahrung gegen Löschung abwägen

   Für Protokolle gelten die nach Art. 12 RTS RMF festgelegten Aufbewahrungsfristen, für personenbezogene Interaktionen die DSGVO. Den Konflikt vor der Löschung dokumentiert auflösen.

4. 4
   Unwiederbringlich löschen

   Modelle, Daten und Kopien löschen — auch in Backups und beim Dienstleister; wo möglich kryptografisches Löschen durch Vernichtung der Schlüssel (Art. 7 RTS RMF).

5. 5
   Nachweisen und Inventar schließen

   Löschprotokoll und Bestätigung des Dienstleisters ablegen, Inventarstatus auf „stillgelegt“ setzen, Erkenntnisse in die IKT-Risikobewertung zurückspielen.

Die Maßnahmen der Fallstudie sind beispielhaft; verbindlich ist die Deinstallationsvorgabe des RTS RMF. Bei Cloud-KI gehört die Löschung beim Anbieter aus unserer Sicht in die Exit-Planung (Kapitel 10).

Gliederungsvorlage ist die Aufsichtsmitteilung zu Auslagerungen an Cloud-Anbieter — die gemeinsame Einschätzung von BaFin und Deutscher Bundesbank, überarbeitete Fassung der Orientierungshilfe von November 2018. Einige ihrer Aspekte „können … auch auf KI-Systeme übertragen werden“ (Kap. IV.2). Ein Begriffsunterschied bleibt: Die Aufsichtsmitteilung denkt in (wesentlichen) Auslagerungen, DORA in kritischen oder wichtigen Funktionen.

Wo die Pflicht beginnt

Verbindlich ist DORA selbst: Vor jeder Vereinbarung über IKT-Dienstleistungen sind Risiken zu bewerten und Sorgfaltspflichten zu erfüllen (Art. 28 Abs. 4 DORA); die Mindestinhalte nach Art. 30 Abs. 2 DORA gelten für alle Verträge. Zusätzliche Vertragsinhalte (Art. 30 Abs. 3), Ausstiegsstrategien (Art. 28 Abs. 8) und die RTS Untervergabe greifen nur bei kritischen oder wichtigen Funktionen. Ein Schreibassistent ohne Entscheidungsbeteiligung braucht aus unserer Sicht daher ein schlankeres Vertragsset als ein Scoring-Modell in einer kritischen oder wichtigen Funktion — die Einstufung ist trotzdem zu dokumentieren (Art. 8 Abs. 1 DORA).

Drei Zitier-Feinheiten

• Art. 3 Abs. 6 ITS Informationsregister regelt die Kennung der Unterauftragnehmer (LEI oder EUID); die Erfassungspflicht steht in Art. 3 Abs. 2 lit. b.
• Art. 28 Abs. 8 UAbs. 3 DORA betrifft Tests von Ausstiegsplänen; Notfalltests ausgelagerter kritischer oder wichtiger Funktionen trägt genauer Art. 11 Abs. 4 DORA, zitiert in Kap. IV.1 (Auslegung VamiSec).
• Für Datenrückgabe und -format trägt Art. 30 Abs. 2 lit. d DORA genauer; die BaFin zitiert ihn nicht (Auslegung VamiSec).

Ausgangspunkt ist Art. 9 Abs. 2 DORA: Finanzunternehmen konzipieren, beschaffen und implementieren IKT-Sicherheitsrichtlinien, -verfahren, -protokolle und -tools. Laut Orientierungshilfe sollen KI-Systeme darin angemessen berücksichtigt werden — mit Maßnahmen zur Netzwerksicherheit, zur Datenübermittlung (Art. 2 Abs. 1 RTS RMF) und zum Schutz vor Datenmissbrauch. Für KI heißt das: Neben den Modellzugängen ist der Datenaustausch zwischen Trainingsdaten, Modellkomponenten und Endanwendern abzusichern.

Fünf bewährte Maßnahmen für KI-Systeme

• Kontinuierliche Echtzeit-Überwachung auf anomales Verhalten, z. B. unerwartete Entscheidungsmuster
• Schutzmechanismen gegen adversarielle Eingaben, etwa Filtermechanismen
• Protokollierung des relevanten Outputs und der API-Aufrufe für spätere Analysen
• Regelmäßige Updates des KI-Systems gegen neue Bedrohungen
• Notfallplan für Sicherheitsvorfälle im KI-System

Für die Nachweisführung wichtig: Diese fünf Maßnahmen nennt die Orientierungshilfe als bewährte Praxis im Anschluss an den Verweis auf Art. 24 und 25 DORA — mit diesen Artikeln belegt sind sie nicht. Pflicht ist das Testprogramm; wie es für KI ausgestaltet wird, ist Praxis. Die harten Taktungen stehen im Rechtstext:

Die Orientierungshilfe betrachtet KI vor allem als Angriffsziel. Mit der ESRB-Warnung ESRB/2026/3 vom 25.06.2026 und dem EZB-Schreiben vom 07.07.2026 rückt KI zusätzlich als Angriffswerkzeug in den Blick: Die ESRB beschreibt Frontier-Modelle, die Schwachstellen finden und funktionierende Exploits erzeugen; die EZB hat die bedeutenden Institute aufgefordert, bis 31.10.2026 einen Aktionsplan beim Joint Supervisory Team einzureichen. Beides zielt aus unserer Sicht vor allem auf ein Feld, das Art. 10 RTS RMF bereits regelt — Schwachstellen- und Patch-Management, nur in deutlich höherem Tempo.

Die Klassifikation nach Vertraulichkeit, Integrität und Verfügbarkeit ist laut Orientierungshilfe die „wichtigste Grundlage“ für sichere Verarbeitung und Speicherung: Sie bestimmt, wie und wo Daten verarbeitet und gespeichert werden können — laut Kap. V.2 eine sinnvolle Ergänzung für den Betrieb von KI in der Cloud. Zitiert werden Art. 5 Abs. 2 lit. b und Art. 11 Abs. 2 lit. k RTS RMF. Genau genommen regelt lit. b Kriterien für die Kritikalitätsbewertung von Assets und lit. k Anforderungen an von IKT-Drittdienstleistern betriebene Assets; die allgemeine Klassifizierungspflicht für Informations- und IKT-Assets steht nach unserer Lesart in Art. 8 Abs. 1 DORA.

Bewährte Verhaltensweisen — unternehmensindividuell anpassbar

• Verschlüsselung und Signierung von Modellen gegen unautorisierte Änderungen
• Betrieb in sicheren Umgebungen, z. B. Containern
• Zero-Trust-Modell für den Zugriff auf KI-Dienste
• Absicherung gegen Injection-Angriffe, Rate-Limiting gegen Denial-of-Service

Für LLM-Assistenten setzt die Fallstudie den Schutz schon an der Quelle an: automatisierte Erkennung vertraulicher Daten, Differential Privacy gegen Rückschlüsse aus Mehrfachabfragen, Tokenisierung sensibler Daten vor der Verarbeitung — und für Variante 3 eine geringere Datenfreigabe, die Nutzer nicht eigenmächtig überschreiten können (Fallstudie, Phase 1 und Variante 3).

Datenqualität: Nur die Integrität ist DORA-Schutzziel

Datenqualität umfasst laut Orientierungshilfe typischerweise Vollständigkeit, Genauigkeit, Gültigkeit, Konsistenz, Angemessenheit bzw. Repräsentativität und Integrität. Nur die Integrität ist ein Schutzziel von DORA; für die übrigen Aspekte enthält die Verordnung keine Regeln. Trotzdem hängen Genauigkeit, Verlässlichkeit und Leistung von KI davon ab, vor allem bei Trainingsdaten — Vorgaben zur Datenqualität gehören deshalb typischerweise in die KI-Governance. Passend dazu zählt die Fallstudie Halluzinationen zu den Herausforderungen, die nicht unmittelbar IKT-relevant sind.

Kap. V.2 stützt sich ausschließlich auf den RTS RMF (Art. 5, 6, 7, 11, 14); DORA-Artikel zitiert die Orientierungshilfe in diesem Abschnitt nicht.

Die Zahlen stammen aus der BaFin-Analyse der IKT-Vorfälle 2025 im DORA-Meldewesen und aus dem BaFinJournal-Beitrag „Vernetzung vervielfacht IT-Risiken“ vom 16.07.2026, der diese Analyse vorstellt. Sie umfassen alle gemeldeten IKT-Vorfälle; KI-spezifische Zahlen weist die BaFin nicht aus. Lehrreich ist der Drittanteil trotzdem: Wer ein Modell per API bezieht, hängt aus unserer Sicht auch an der Vorfalllage seines Anbieters.

Nicht jeder IKT-bezogene Vorfall in einem KI-System ist meldepflichtig — erfasst werden muss jeder (Art. 17 DORA). Ob ein Vorfall schwerwiegend ist, bestimmen die Klassifizierungskriterien nach Art. 18 DORA, den die Orientierungshilfe selbst nicht zitiert. Erhebliche Cyberbedrohungen können freiwillig gemeldet werden (Art. 19 DORA).

Bewährte Maßnahmen laut Orientierungshilfe

1. 1
   KI-spezifische Bedrohungen identifizieren

   KI-spezifische Bedrohungen gezielt identifizieren, z. B. die Manipulation von Trainingsdaten.

2. 2
   KI-Vorfälle erkennen

   Modellfehler, Datenverlust oder Performance-Probleme so erkennen, dass unmittelbar gehandelt werden kann.

3. 3
   Auswirkung analysieren, Schwere einstufen

   Auswirkungsanalyse, etwa auf Datenverlust, und Einstufung der Schweregrade.

4. 4
   In das Incident-Response-Konzept integrieren

   Vorfälle aus KI-Systemen in das allgemeine Incident-Response-Konzept integrieren — mit den Rollen, Kommunikations- und Eskalationswegen, die Art. 17 DORA ohnehin vorschreibt.

5. 5
   Ursachen analysieren und lernen

   Detaillierte Ursachenanalyse, um systematische Schwachstellen in Modellen und Prozessen zu beheben und Wiederholungen nachhaltig zu verhindern.

Für KI in der Cloud empfiehlt die Orientierungshilfe zusätzlich Vereinbarungen zur Meldung von IKT-Vorfällen, die in KI-Systemen entstehen, sowie ausreichende, qualifizierte interne Ressourcen zur Bewertung und Reaktion. Die Fallstudie ergänzt für KI-Assistenten einen Sicherheitsvorfall-Reaktionsplan (SIRP) und simulierte Cyberangriffe, die die Reaktionszeiten testen (Phase 5).

Ausblick: Der Digital-Omnibus-Vorschlag der Kommission vom 19.11.2025 (COM(2025) 837 final) — nicht zu verwechseln mit der bereits in Kraft getretenen Digital-Omnibus-Verordnung zur KI, VO (EU) 2026/1744 — sieht u. a. vor, Meldungen nach Art. 19 Abs. 1 DORA über einen Single Entry Point zu leiten. Es handelt sich um einen Vorschlag; maßgeblich bleibt Art. 19 DORA in der geltenden Fassung.

Untersucht werden drei Infrastrukturvarianten (Abbildung 2): On-Premise, Cloud mit KI-Anwendung im eigenen Tenant und Cloud mit KI-Anwendung außerhalb des eigenen Tenants. Mischformen sind ausdrücklich möglich; die Risikodiskussion ist dann anzupassen. Investitions- und laufende Kosten betrachtet die Fallstudie nicht. Umsetzen sollen Finanzunternehmen die Maßnahmen, die für ihre spezifische Risikosituation am besten geeignet sind.

Sechs Phasen: Risiken, die in jeder Variante gelten

Drei Varianten, drei Risikoprofile

Fallstudie und Kap. VI enthalten keine DORA-Fundstelle. Wer die Maßnahmen der Fallstudie mit Rechtsankern verbindet, nimmt eine eigene Zuordnung vor — die Pflichten selbst ergeben sich aus DORA und RTS RMF.

KI-VO und KI-MIG: wo Banken und Versicherer konkret betroffen sind

Hochrisiko sind nach Anhang III Nr. 5 lit. b KI-VO Systeme zur Kreditwürdigkeitsprüfung und Bonitätsbewertung natürlicher Personen — ausgenommen solche zur Aufdeckung von Finanzbetrug — und nach lit. c Systeme zur Risikobewertung und Preisbildung für natürliche Personen in der Lebens- und Krankenversicherung. Die Hochrisiko-Pflichten (Kapitel III Abschnitte 1–3 KI-VO) gelten für diese Systeme nach der Digital-Omnibus-Verordnung zur KI (VO (EU) 2026/1744) ab 02.12.2027 statt ursprünglich ab 02.08.2026.

Die BaFin überwacht nach § 2 Abs. 3 KI-MIG KI-Systeme, die in direktem Zusammenhang mit einer regulierten Finanztätigkeit stehen und von beaufsichtigten Unternehmen in Verkehr gebracht, in Betrieb genommen oder verwendet werden — laut BaFin etwa Kunden-Chatbots, Kreditwürdigkeitsprüfung und Risikobewertung in der Lebens- und Krankenversicherung. KI im Personalwesen bleibt bei der Bundesnetzagentur. Im Blick hat die BaFin dabei verbotene Praktiken (Art. 5), Transparenzpflichten (Art. 50) und KI-Kompetenz (Art. 4 KI-VO); ab 02.12.2027 kommen die Hochrisiko-Systeme nach Anhang III Nr. 5 lit. b und c hinzu. Im BaFinJournal-Interview zum KI-MIG vom 29.07.2026 verweist die BaFin ausdrücklich auf die Orientierungshilfe.

EU-Aufsicht: gleiche Richtung, eigene Akzente

• EIOPA, Opinion vom 06.08.2025 (EIOPA-BoS-25-360): erläutert den nationalen Aufsichtsbehörden risikobasiert und proportional, wie IDD, Solvency II und DORA auf KI bei Versicherern anzuwenden sind — ohne neue Anforderungen; verbotene und Hochrisiko-KI nach KI-VO ausgenommen.
• EBA, Factsheet vom 21.11.2025: Abgleich der Hochrisiko-Anforderungen der KI-VO (Schwerpunkt Kreditwürdigkeit) mit CRD/CRR, DORA und weiterem Bankenaufsichtsrecht: keine wesentlichen Widersprüche, neue EBA-Leitlinien hält die EBA nicht für nötig.
• ESMA, Public Statement vom 30.05.2024: KI in Wertpapierdienstleistungen für Privatkunden muss den MiFID-II-Pflichten genügen; die Verantwortung bleibt beim Leitungsorgan.
• EBA, EIOPA und ESMA, Statement JC 2026 25 vom 31.07.2026: DORA und KI-VO als tragfähige Grundlage gegen IKT-Risiken aus Frontier-KI-Modellen; zur Prävention gehört ein vollständiges Asset-Inventar einschließlich KI/ML-Komponenten.

Die Erklärbarkeitsanforderung für KI-Modelle ist keine Neuerung der 9. MaRisk-Novelle; sie stand inhaltsgleich bereits in AT 4.3.5 der 7. Novelle (RS 05/2023 (BA)).

1. 1
   Phase 0 · Monat 1Mandat und Geltung klären

   Leitungsorgan bestätigt seine Letztverantwortung (Art. 5 Abs. 2 lit. a DORA) und stellt Budget bereit; prüfen, ob Art. 5–15 oder der vereinfachte Rahmen nach Art. 16 DORA gilt; Verantwortliche für KI-Ergebnisse je Funktion benennen.

2. 2
   Phase 1 · Monate 1–3Transparenz schaffen

   KI-Inventar aufbauen — inklusive KI per API und in Standardsoftware (Art. 8 Abs. 4 DORA i. V. m. Art. 4, 5 RTS RMF); je System Kritikalität, Infrastrukturvariante, Datenklassen und Eigentümer erfassen.

3. 3
   Phase 2 · Monate 3–6Rahmen anpassen

   KI-Strategie oder KI-Abschnitt der DOR-Strategie; KI in IKT-RMF, Sicherheitsrichtlinien (Art. 9 Abs. 2 DORA), Vorfallrichtlinie (Art. 22 RTS RMF) und Drittparteienverträge (Art. 28–30 DORA) verankern.

4. 4
   Phase 3 · Monate 6–9Härten und testen

   Tests vor Produktivsetzung, deren Umfang der Kritikalität entspricht (Art. 16 Abs. 2 RTS RMF), bei KI in kritischen oder wichtigen Funktionen ergänzt um Adversarial Testing; Schwellenwerte für Fehlverhalten von KI in kritischen oder wichtigen Funktionen (Art. 10 Abs. 1 UAbs. 2 i. V. m. Abs. 2 DORA); Governance Shield für Variante 3; Geschäftsfortführungspläne testen (Art. 11 Abs. 6 lit. a DORA, Art. 25 RTS RMF).

5. 5
   Phase 4 · Monate 9–12Wirksamkeit nachweisen

   Jährliche Überprüfung des IKT-RMF (Art. 6 Abs. 5 DORA) mit KI-Abschnitt im Bericht nach Art. 27 RTS RMF; Lessons Learned einspeisen (Art. 13 Abs. 3 DORA); Exit-Pläne testen (Art. 28 Abs. 8 DORA); Schulungen nachweisen (Art. 5 Abs. 4, Art. 13 Abs. 6 DORA).

Kennzahlen, die der Vorstand versteht

Proportionalität gilt auch für den Fahrplan: Ein KI-basierter Self-Service-Assistent, der vollständig unter menschlicher Überwachung steht und nicht in Entscheidungsprozesse eingebunden ist, braucht nicht dieselbe Kontrolltiefe wie KI in einer kritischen oder wichtigen Funktion (Art. 4 DORA, Kap. I.2). Wer mit dem Inventar beginnt, kann diese Tiefe begründet staffeln — und die Begründung dokumentieren.

Die Orientierungshilfe ist eine nicht verpflichtende Hilfestellung und keine verbindliche DORA-Auslegung der BaFin. Verbindlich sind DORA, RTS RMF und RTS Untervergabe. Der Fahrplan ist eine Empfehlung von VamiSec und keine Rechtsberatung.