Finanzdienstleister in Deutschland und in der gesamten EU bewegen sich in zwei überlappenden Regulierungsrahmen, die unmittelbar beeinflussen, wie AI-Tools eingesetzt werden können: MaRisk (Mindestanforderungen an das Risikomanagement), der BaFin-Mindeststandard für das Risikomanagement, der deutsche Banken und Finanzinstitute regelt, und DORA (Digital Operational Resilience Act), die EU-weite Verordnung mit Geltung ab Januar 2025, die das ICT-Risiko über alle regulierten Finanzunternehmen hinweg regelt.
Keine der beiden Regelungen definiert „AI-Governance" ausdrücklich. Doch beide schaffen Pflichten, die unmittelbar an die Nutzung von AI-Tools anknüpfen — rund um ICT-Risikomanagement, Kontrollen für Drittanbieter, Audit-Trails und operationale Resilienz —, die viele Finanzdienstleister bislang nicht erfüllen.
Dieser Artikel richtet sich an Compliance-Verantwortliche, CISOs und IT-Risikomanager bei Banken, Vermögensverwaltern, Versicherungen und Zahlungsinstituten, die der deutschen oder EU-weiten Finanzdienstleistungsregulierung unterliegen.
Das regulatorische Gesamtbild
MaRisk
MaRisk wird von der BaFin herausgegeben und legt die Mindestanforderungen an das Risikomanagement deutscher Finanzinstitute (Kreditinstitute und andere beaufsichtigte Unternehmen) fest. Die jüngste Novelle (MaRisk 7.0, 2023) adressiert das Modellrisikomanagement und das Technologierisiko ausdrücklich in einer Weise, die die Nutzung von AI-Tools erfasst.
Für AI relevante Schlüsselmodule:
AT 7.2 (Technisch-organisatorische Ausstattung): Institute müssen über eine angemessene IT-Infrastruktur und entsprechende Prozesse verfügen, um ihre Geschäftstätigkeit zu unterstützen. In Geschäftsprozessen eingesetzte AI-Tools sind Teil dieser Infrastruktur. Wenn Mitarbeitende AI-Tools ohne dokumentierte Risikobewertungen, Zugriffskontrollen oder Überwachung nutzen, ist AT 7.2 berührt.
AT 7.3 (IT-Risikomanagement): AI-Anbieter, die Daten des Instituts erhalten, sind externe IT-Dienstleister. Das Modul verlangt, dass Institute das Risiko von durch Dritte erbrachten IT-Dienstleistungen steuern — einschließlich Datenschutz, Verfügbarkeit und Verarbeitungsintegrität.
AT 9 (Auslagerung): Wenn AI-Tools Daten verarbeiten, die für den Geschäftsbetrieb wesentlich sind — insbesondere wenn sie Entscheidungen beeinflussen, kundengerichtete Inhalte erzeugen oder Kundendaten verarbeiten könnten —, kann die BaFin sie als Auslagerungen einstufen, die einen strengeren vertraglichen und überwachungsbezogenen Rahmen erfordern. Dazu gehören dokumentierte Service-Level-Agreements, Prüfungsrechte und Exit-Strategien.
BT 3 (Modellrisiko): Die MaRisk-Novellen zum Modellrisikomanagement verlangen von Instituten, Modelle, die in risikorelevanten Entscheidungen verwendet werden, zu identifizieren, zu bewerten und zu überwachen. AI-Tools, die für Kreditbeurteilung, Betrugserkennung, Kundenkommunikation oder das aufsichtsrechtliche Berichtswesen eingesetzt werden, fallen in diesen Anwendungsbereich.
DORA
DORA (Verordnung EU 2022/2554) ist am 17. Januar 2025 in die Anwendung getreten. Sie gilt für ein breites Spektrum von Finanzunternehmen — Kreditinstitute, Wertpapierfirmen, Versicherungsunternehmen, Zahlungsinstitute, Anbieter von Krypto-Dienstleistungen und deren ICT-Drittdienstleister.
DORA schafft vier zentrale Pflichten, die AI-Governance unmittelbar betreffen:
Rahmen für das ICT-Risikomanagement (Artikel 5–16): Finanzunternehmen müssen einen umfassenden Rahmen für das ICT-Risikomanagement umsetzen. AI-Tools sind ICT-Tools. Ungesteuerte AI-Nutzung — Mitarbeitende, die Geschäftsdaten ohne dokumentierte Kontrollen an externe Modelle übermitteln — ist ein ICT-Risiko, das der Rahmen adressieren muss.
Management des ICT-Drittparteienrisikos (Artikel 28–44): AI-Modellanbieter — OpenAI, Anthropic, Google, Microsoft — sind ICT-Drittdienstleister, wenn sie Daten im Auftrag des Finanzunternehmens verarbeiten. DORA verlangt eine vorvertragliche Risikobewertung, einen schriftlichen Vertrag mit bestimmten Mindestklauseln (Datenstandort, Prüfungsrechte, Kündigungsrechte, Sicherheitsstandards) sowie eine laufende Überwachung. Für von den ESAs benannte „kritische ICT-Drittdienstleister" gilt eine zusätzliche Aufsicht.
ICT-Vorfallmeldung (Artikel 17–23): Wenn ein AI-Anbieter einen Ausfall, eine Datenschutzverletzung oder ein Modellversagen erleidet, das die ICT-Systeme oder Geschäftsprozesse des Instituts beeinträchtigt, greifen die Klassifizierungs- und Meldepflichten für Vorfälle nach DORA. Institute benötigen eine Überwachung, um solche Ereignisse zu erkennen und darauf zu reagieren.
Testen der digitalen operationalen Resilienz (Artikel 24–27): Institute müssen die Resilienz ihrer ICT-Systeme testen, einschließlich AI-abhängiger Prozesse. Für die TLPT-Anforderungen (Threat-Led Penetration Testing) von DORA können AI-Systeme, die in kritische Prozesse eingebettet sind, in den Anwendungsbereich fallen.
Die drei Lücken, die die meisten Finanzdienstleister heute haben
Lücke 1: AI-Anbieter stehen nicht im ICT-Drittparteienregister
MaRisk AT 9 und DORA Artikel 28 verlangen beide, dass Institute ein Register über ICT-Drittparteienvereinbarungen führen. Wenn AI-Tools wie ChatGPT, Microsoft Copilot oder Claude von Mitarbeitenden zu Geschäftszwecken genutzt werden, sind die Anbieter (OpenAI, Microsoft, Anthropic) ICT-Drittdienstleister, die institutionelle Daten erhalten.
Die meisten Institute verfügen über umfassende Lieferantenregister für klassische IT-Anbieter — Cloud-Plattformen, Kernbankensysteme, Zahlungsdienstleister. AI-Tools, die 2023–2025 hinzukamen, umgingen das Lieferantenmanagement häufig vollständig: Mitarbeitende führten sie von unten her ein, und sie gelangten nie ins Register.
Die Folge: keine vorvertragliche Risikobewertung, kein schriftlicher Vertrag mit den von DORA geforderten Klauseln, keine Überwachungsvereinbarung, keine Exit-Strategie. Sowohl unter MaRisk als auch unter DORA ist dies eine Compliance-Lücke.
Was diese Lücke schließt: Ein formales AI-Tool-Inventar, das in das Drittparteienregister integriert ist. Für jeden AI-Anbieter, der institutionelle Daten erhält, eine dokumentierte Risikobewertung und eine Auftragsverarbeitungsvereinbarung, die die Mindestklauseln nach DORA Artikel 30 abdeckt.
Lücke 2: Kein Audit-Trail für AI-gestützte Entscheidungen
Beide Rahmenwerke verlangen, dass Institute die Grundlage von Entscheidungen nachvollziehbar rekonstruieren können — insbesondere in Bereichen wie Kredit, Betrug, Kundenkommunikation und aufsichtsrechtlichem Berichtswesen. Wenn AI-Tools zu diesen Entscheidungen beitragen (Entwurf eines Kreditmemos, Markierung einer Transaktion, Erstellung einer Kundenkommunikation), muss die Rolle der AI prüfbar sein.
Anbieterseitige Protokolle (OpenAI-Nutzungs-Dashboards, Azure-AI-Logs) sind aus zwei Gründen unzureichend: Sie werden möglicherweise nicht für den vom Institut geforderten Zeitraum aufbewahrt, und sie erfassen nicht die eigenen Richtlinienentscheidungen des Instituts — ob eine bestimmte Nutzung autorisiert war, welche Datenklassifizierung galt, ob eine menschliche Prüfung stattfand.
Ein Institut, das sich allein auf Anbieterprotokolle stützt, kann der BaFin oder einer Aufsichtsbehörde nicht nachweisen, dass AI-gestützte Entscheidungen im Einklang mit seinem internen Kontrollrahmen gesteuert wurden.
Was diese Lücke schließt: Ein vom Institut kontrolliertes Audit-Log, das je AI-Interaktion erfasst: die Nutzeridentität, das verwendete Tool und Modell, einen Zeitstempel, die Datenklassifizierung des Inhalts, die angewandte Richtlinienentscheidung sowie jeden Schritt menschlicher Prüfung oder Freigabe. Aufbewahrt für den standardmäßigen Aufbewahrungszeitraum des Instituts (typischerweise 5–10 Jahre für deutsche Finanzinstitute nach HGB und bankspezifischen Anforderungen).
Lücke 3: Keine technische Durchsetzung der Datenhandhabungs-Richtlinie
Unter MaRisk AT 7.2 und den ICT-Risikomanagement-Anforderungen von DORA müssen Institute nachweisen, dass Kontrollen wirksam funktionieren — nicht nur, dass sie dokumentiert sind. Eine Richtlinie, die besagt „Mitarbeitende dürfen keine Kundendaten an externe AI-Modelle übermitteln", ist keine Kontrolle. Sie ist eine erklärte Absicht.
Die Frage, die Prüfer und Aufseher stellen werden, lautet: „Was hindert einen Mitarbeitenden daran, dies zu tun?" Wenn die Antwort „Schulung und Sensibilisierung" lautet, ist das die Dokumentation eines Risikos, nicht der Nachweis einer Minderung.
Was diese Lücke schließt: Eine technische Kontrolle — ein AI-Gateway oder eine Prompt-Prüfungsschicht —, die Datenklassifizierungsregeln auf Infrastrukturebene durchsetzt. Wenn ein Nutzer einen Prompt mit identifizierten sensiblen Mustern übermittelt (Kundennamen, Kontonummern, personenbezogene Daten), fängt das Gateway den Inhalt ab, schwärzt ihn oder blockiert ihn, bevor er das externe Modell erreicht. Dies ist ein Nachweis auf Infrastrukturebene, dass die Richtlinie wie vorgesehen funktioniert.
Was DORA-Artikel-30-Verträge mit AI-Anbietern enthalten müssen
Für AI-Anbieter, die unter DORA als ICT-Drittdienstleister eingestuft werden, legt Artikel 30 Mindestvertragsbedingungen fest. Institute sollten überprüfen, dass ihre Vereinbarungen mit AI-Anbietern Folgendes abdecken:
- Datenstandort: Wo werden Daten verarbeitet? Wo werden Modell-Inferenzanfragen ausgeführt? Welche EU-/Nicht-EU-Übermittlungen finden statt, und auf welcher Rechtsgrundlage (Standardvertragsklauseln, Angemessenheitsbeschluss oder andere)?
- Sicherheitsstandards: Welche Sicherheitszertifizierungen besitzt der Anbieter (ISO 27001, SOC 2 Type II)? Wie lauten seine Incident-Response-SLAs?
- Prüfungsrechte: Kann das Institut den Anbieter prüfen oder auf Prüfberichte (z. B. SOC-2-Berichte, Bescheinigungen Dritter) zugreifen?
- Kündigungsrechte: Wie sind die Kündigungsrechte und die Pflichten zur Datenlöschung geregelt? Kann das Institut Daten und Prozesse mit angemessener Frist migrieren?
- Unterauftragsverarbeitung: Wer sind die Unterauftragsverarbeiter des Anbieters? Werden sie offengelegt? Welche vertraglichen Pflichten werden weitergereicht?
- Vorfallmeldung: Wie benachrichtigt der Anbieter das Institut über Sicherheitsvorfälle, Ausfälle oder wesentliche Änderungen des Dienstes?
Die meisten großen AI-Anbieter bieten Auftragsverarbeitungsvereinbarungen (AVV) an, die die Anforderungen der DSGVO abdecken. Nicht alle decken den vollständigen Satz der DORA-Artikel-30-Mindestbedingungen ab. Eine Gap-Analyse zwischen der Standard-AVV des Anbieters und den Anforderungen von DORA ist ein notwendiger Schritt, bevor die Vereinbarung als konform dokumentiert werden kann.
Der MaRisk-Modellrisiko-Aspekt
BT 3 der MaRisk verlangt von Instituten, Modelle, die in risikorelevanten Prozessen verwendet werden, zu identifizieren, zu validieren und zu überwachen. Die Definition von „Modell" in BT 3 ist weit gefasst: eine quantitative Methode, ein System oder ein Verfahren, das Eingaben verarbeitet und Ausgaben erzeugt, die Geschäftsentscheidungen beeinflussen.
AI-Modelle, die in den folgenden Bereichen eingesetzt werden, fallen typischerweise in den Anwendungsbereich:
- Kreditbeurteilung: AI-Tools, die bei der Risikoeinschätzung, dem Scoring oder der Erstellung von Kreditmemos unterstützen
- Betrug und Geldwäschebekämpfung (AML): AI-basierte Transaktionsüberwachung oder Anomalieerkennung
- Aufsichtsrechtliches Berichtswesen: AI-Tools, die bei der Erstellung aufsichtsrechtlicher Meldungen unterstützen
- Kundenkommunikation: AI-Tools, die kundengerichtete Inhalte in Bereichen erzeugen oder maßgeblich entwerfen, in denen Genauigkeit wesentlich ist (z. B. Anlageberatung, Kontobedingungen)
Für Modelle im Anwendungsbereich verlangt BT 3: Modelldokumentation, unabhängige Validierung vor dem Produktiveinsatz, laufende Performance-Überwachung, Versionskontrolle sowie einen Prozess für das Management von Modelländerungen.
Wenn ein Institut ein AI-Modell eines Drittanbieters (z. B. GPT-4, Claude) als Komponente in einem risikorelevanten Prozess ohne dokumentierte Modellrisikobewertung einsetzt, hat es eine BT-3-Lücke — unabhängig davon, ob der AI-Anbieter selbst im Drittparteienregister geführt wird.
Compliance in der Praxis aufbauen
Der praktische Weg zur MaRisk- und DORA-Konformität für die AI-Nutzung umfasst drei Phasen:
Phase 1: Inventarisierung und Klassifizierung
Identifizieren Sie alle AI-Tools, die im Institut aktiv genutzt werden. Bestimmen Sie für jedes: Erhält dieses Tool institutionelle Daten? Wird es in einem risikorelevanten Prozess eingesetzt? Welche Datenkategorien verarbeitet es?
Das Ergebnis ist ein AI-Tool-Inventar mit Risikoklassifizierung, integriert in das ICT-Drittparteienregister. Als ICT-Drittparteienvereinbarungen eingestufte Tools erfordern Verträge, die gegen DORA Artikel 30 geprüft wurden. Tools in risikorelevanten Prozessen erfordern eine Modellrisikobewertung nach BT 3.
Phase 2: Kontrollen und Dokumentation
Setzen Sie für jedes AI-Tool im Inventar um:
- Eine dokumentierte Datenhandhabungs-Richtlinie: welche Datenkategorien von wem und zu welchen Zwecken übermittelt werden dürfen
- Technische Durchsetzung: ein AI-Gateway oder eine Inhaltsprüfungsschicht, die die Richtlinie auf Infrastrukturebene durchsetzt
- Ein vom Institut kontrolliertes Audit-Log: das Nutzeridentität, Tool, Zeitstempel, Datenklassifizierung, Richtlinienentscheidung und Schritte menschlicher Prüfung erfasst
- Vertragliche Dokumentation: AVV und DORA-Artikel-30-Bedingungen mit jedem Anbieter bestätigt
Phase 3: Überwachung und Testen
Setzen Sie eine laufende Überwachung der AI-Tool-Nutzung um: automatisierte Warnungen bei Richtlinienverstößen, regelmäßige Überprüfung des Audit-Logs durch eine Compliance- oder Risikofunktion sowie die Einbeziehung AI-bezogener ICT-Risiken in das jährliche DORA-Resilienztestprogramm.
Dokumentieren Sie den Überwachungsprozess — Datum der letzten Überprüfung, wer geprüft hat, was festgestellt wurde — in einer Form, die der BaFin oder anderen Aufsichtsbehörden auf Anfrage vorgelegt werden kann.
Die aufsichtsrechtliche Richtung
Die BaFin hat Leitlinien zu AI und maschinellem Lernen in Finanzdienstleistungen veröffentlicht, die mit den EBA-Leitlinien zur internen Governance und der EBA-Roadmap zu AI im Einklang stehen. Die aufsichtsrechtliche Erwartung ist eindeutig: AI ist keine Ausnahme von bestehenden Governance- und Risikomanagement-Rahmenwerken — sie unterliegt ihnen, mit zusätzlichen Anforderungen in Bereichen wie Modellerklärbarkeit und Konzentrationsrisiko bei Drittparteien.
Institute, die AI-Governance als getrennt von bestehenden ICT-Risiko- und Modellrisiko-Rahmenwerken behandeln, schaffen sich mehr Arbeit, nicht weniger. Der effizienteste Weg ist, bestehende MaRisk- und DORA-Compliance-Prozesse auf AI auszuweiten: AI-Tools ins Drittparteienregister aufnehmen, den Modellrisikorahmen auf AI-Komponenten ausdehnen und AI-spezifische Kontrollen in den ICT-Risikomanagement-Rahmen aufnehmen.
Die Frage, die die BaFin stellen wird, lautet nicht „Haben Sie eine AI-Richtlinie?" Sie lautet „Erfüllt Ihre AI-Nutzung Ihre bestehenden MaRisk- und DORA-Pflichten?" Die Antwort muss nachweisbar sein, nicht nur behauptet.
Qadar AI Shield ist für Finanzdienstleistungsteams konzipiert, die AI-Governance unter MaRisk und DORA umsetzen: vom Institut kontrolliertes Audit-Logging, Prompt-Prüfung und Durchsetzung der Datenklassifizierung sowie vertragsfertige Dokumentation für ICT-Drittparteienrisikobewertungen. Mehr erfahren.
