DORA und KI-Verträge: Was Banken bei OpenAI & Co. nachverhandeln müssen

Warum OpenAI und Anthropic seit Januar 2025 als kritische ICT-Drittparteien gelten

Seit dem 17. Januar 2025 ist DORA scharf. Für Banken, Versicherer, Asset-Manager und Wertpapierfirmen in der EU gilt damit ein einheitliches Regime für das Management von ICT-Drittparteienrisiko. Das ist relevant, weil sich die KI-Landschaft in den Häusern in den letzten 18 Monaten dramatisch verändert hat. Was im Sommer 2023 ein Pilotprojekt war, ist heute oft produktiv eingebunden in Onboarding-Prozesse, Compliance-Workflows oder Client-Reporting.

DORA Artikel 31 definiert, wann ein ICT-Drittanbieter als kritisch einzustufen ist. Die Einordnung folgt vier Kriterien: systemische Bedeutung für die Stabilität, Anzahl und Bedeutung der Finanzunternehmen, die den Anbieter nutzen, Substituierbarkeit des Dienstes und Verflechtung mit dem Finanzsystem. Die formale Designation als kritischer ICT-Drittanbieter durch die ESAs ist das eine. Das andere ist die institutsinterne Klassifikation: Auch wenn die ESA-Liste noch nicht alle KI-Anbieter erfasst, müssen Sie als Finanzunternehmen selbst bewerten, welche Ihrer ICT-Dienste eine kritische oder wichtige Funktion unterstützen. Genau diese interne Klassifikation triggert die Pflichten nach Artikel 28 und 30.

Welche KI-Dienste fallen typischerweise darunter? Ein paar Konstellationen, die in der Praxis immer wieder auftauchen:

• Eine LLM-API von OpenAI oder Anthropic, die in der KYC-Dokumentenprüfung den Sachbearbeiter unterstützt. Sobald das Modell Teil des regulatorisch vorgeschriebenen AML-Prozesses ist, unterstützt es eine kritische Funktion.
• Ein Copilot-Setup in Microsoft 365, das standardmäßig in Loan-Underwriting-Workflows mitläuft und Empfehlungen zur Bonität generiert.
• Eine KI-gestützte Risikomodell-Komponente eines Fintech-Anbieters, der wiederum auf einer LLM-API aufsetzt.
• Robo-Advisor-Komponenten, die Allokationsvorschläge oder automatisierte Kundenmitteilungen generieren.

Für all diese Konstellationen gilt: Sobald der Dienst eine kritische oder wichtige Funktion unterstützt, greifen die verschärften Vertragspflichten aus Artikel 30. Und genau da fängt das Problem an. Die Standard-AGBs der großen US-KI-Anbieter sind nicht für regulierte Finanzdienstleister geschrieben. Sie sind für SaaS-Massenmarkt geschrieben.

Die sieben Pflichtklauseln nach DORA Artikel 30 und was Standard-AGBs liefern

Artikel 30 DORA listet die Mindestinhalte für Verträge mit ICT-Drittanbietern, die kritische oder wichtige Funktionen unterstützen. Sieben Bereiche sind besonders relevant, und für jeden gibt es eine Lücke zur Vertragsrealität bei OpenAI, Anthropic und Co.

Klausel 1: Audit- und Inspektionsrechte. DORA fordert in Artikel 30 Absatz 3 lit. e vollständige Zugangs-, Inspektions- und Auditrechte für das Finanzunternehmen, für interne Revisoren und für die zuständige Aufsichtsbehörde. In der OpenAI Business Terms-Welt finden Sie das nicht. Was Sie finden, ist ein Verweis auf SOC 2 Type II-Berichte und ähnliche Zertifikate. Das ist nicht dasselbe. Ein Audit-Recht ist ein vertraglich verankerter Anspruch, vor Ort oder remote zu prüfen. Ein Drittanbieter-Zertifikat ist eine Momentaufnahme aus dritter Hand.

Klausel 2: Subunternehmer-Offenlegung. Artikel 30 Absatz 2 lit. a verlangt eine vollständige Beschreibung der Dienstleistung inklusive der Subunternehmer-Kette, soweit diese kritische oder wichtige Funktionen unterstützen. Bei einem LLM-Anbieter heißt das: Auf welcher Cloud-Infrastruktur läuft das Modell? Welche Annotation-Dienstleister waren am Training beteiligt? Welche Sicherheitspartner haben Zugriff auf Logs? Die Standard-AGBs sind hier sehr generisch. „Wir nutzen branchenübliche Cloud-Anbieter” reicht für DORA nicht.

Klausel 3: Datenspeicherort und Datenportabilität. Hier überlappt sich DORA mit der DSGVO, geht aber darüber hinaus. DORA fordert in Artikel 30 Absatz 2 lit. b die klare Angabe der Standorte, an denen Daten verarbeitet werden, und Mechanismen für die Datenrückgabe bei Vertragsende. Bei LLM-APIs ist die Datenportabilität strukturell schwierig. Was genau geben Sie zurück, wenn Sie kündigen? Die Prompts? Die Embeddings? Die Fine-Tuning-Daten? In den Standard-AGBs steht dazu oft nur, dass Daten nach Vertragsende gelöscht werden. Das ist keine Portabilität.

Klausel 4: Business-Continuity-Pflichten. Artikel 30 Absatz 2 lit. d fordert dokumentierte Service-Level mit Recovery-Time-Objectives und Recovery-Point-Objectives. Die Standard-API-Terms der KI-Anbieter enthalten meist Best-Effort-Klauseln und allenfalls vage Verfügbarkeitsziele. Konkrete RTO- und RPO-Werte? In der Regel nicht. Wer einen verbindlichen SLA mit Pönalen will, muss in den Enterprise-Vertrag wechseln und auch dann hart verhandeln.

Klausel 5: Kündigungsrechte und Übergangsfristen. DORA verlangt in Artikel 30 Absatz 2 lit. h klare Kündigungsrechte und ausreichende Übergangsfristen für einen geordneten Exit. Standard-AGBs sehen oft eine Kündigung mit 30 Tagen Frist vor. Für einen geordneten Exit aus einer produktiv eingebundenen LLM-API mit Fine-Tuning-Setup und Prompt-Engineering-Investitionen ist das viel zu kurz.

Klausel 6: Incident-Reporting. Artikel 30 Absatz 2 lit. e fordert, dass der ICT-Drittanbieter das Finanzunternehmen über Vorfälle informiert, die die Dienstleistung beeinträchtigen. Bei DORA-relevanten Major-Incidents müssen Sie als Finanzunternehmen innerhalb knapper Fristen an die Aufsicht melden. Wenn Ihr Anbieter Sie erst zwei Tage später informiert, halten Sie diese Fristen nicht ein. Die Standard-AGBs regeln das oft gar nicht oder nur sehr weich.

Klausel 7: Kooperation mit Aufsichtsbehörden. Artikel 30 Absatz 3 lit. e zweiter Halbsatz verlangt, dass der Anbieter mit den zuständigen Aufsichtsbehörden kooperiert, einschließlich Vor-Ort-Inspektionen. Für einen US-Anbieter, der weder Tochter in der EU hat noch einer EU-Aufsicht untersteht, ist das vertraglich schwierig durchsetzbar. Genau darum gibt es ja die DORA-Designation kritischer ICT-Drittanbieter mit direkter Aufsicht durch die ESAs. Solange diese Designation für Ihren konkreten Anbieter nicht greift, müssen Sie es vertraglich regeln.

Die Exit-Strategie: Pflicht auf dem Papier, Chaos in der Praxis

Artikel 28 Absatz 8 DORA verlangt eine dokumentierte, getestete Exit-Strategie für jeden ICT-Dienst, der eine kritische oder wichtige Funktion unterstützt. „Getestet” ist hier das harte Wort. Sie müssen plausibel machen, dass der Exit nicht nur auf dem Papier funktioniert.

Bei klassischen Cloud-Diensten ist das schon nicht trivial, aber machbar. Sie migrieren von AWS zu Azure, von einer SaaS-Lösung zu einer anderen. Bei LLM-APIs ist die Lage strukturell anders. Drei Gründe:

Modell-Lock-in. GPT-4, Claude 3.5 Sonnet und Gemini 1.5 verhalten sich nicht identisch. Ein Prompt, der unter GPT-4 zu reproduzierbaren, sauberen Outputs führt, kann unter Claude völlig andere Ergebnisse liefern. Stichwort: das gesamte Prompt-Tuning ist anbieterspezifisch.

Fine-Tuning-Daten. Wenn Sie ein Modell auf eigenen Daten feingetuned haben, gehört das adaptierte Modell oft dem Anbieter. Sie können die Trainingsdaten mitnehmen, aber nicht das fertige Modell. Sie müssen beim neuen Anbieter neu fine-tunen, was Zeit und Geld kostet.

Eingebettete Workflows. Die kritische Frage ist nicht „Können wir den API-Endpoint austauschen?”, sondern „Wie viele Geschäftsprozesse hängen am spezifischen Output-Format und Verhalten des aktuellen Modells?” Bei einem Wealth-Reporting-System, das auf bestimmte JSON-Strukturen aus Claude konditioniert ist, ist der Wechsel ein Migrationsprojekt.

Was muss eine DORA-konforme Exit-Strategie für KI-Dienste mindestens enthalten? Aus meiner Sicht diese Bausteine:

• Eine konkrete Liste alternativer Anbieter inklusive On-Premise-Optionen wie Llama oder Mistral-Modelle im eigenen Tenant.
• Eine Schätzung der Migrationsdauer pro Anwendungsfall, realistisch in Monaten, nicht in Wochen.
• Ein dokumentiertes Test-Szenario, idealerweise einmal pro Jahr mit einem Parallelbetrieb auf einem zweiten Anbieter.
• Klare Verantwortlichkeiten: Wer im Haus entscheidet wann den Exit, wer führt die technische Migration, wer informiert die Aufsicht.
• Mindestens 90, besser 180 Tage Übergangsfrist vertraglich abgesichert.

Verhandlungshebel? Die längere Übergangsfrist ist erfahrungsgemäß durchsetzbar, weil sie den Anbieter wenig kostet. Vollständige Datenportabilität inklusive eines exportierbaren Fine-Tuning-Artefakts ist deutlich schwieriger. Hier müssen Sie alternative Architekturen mitdenken: Wer eine kritische Funktion auf einer einzigen LLM-API aufbaut, hat schon strukturell ein DORA-Problem.

Subunternehmer-Ketten: Der blinde Fleck

Artikel 30 Absatz 2 lit. a in Verbindung mit lit. f fordert die Offenlegung wesentlicher Subunternehmer und ein Mitspracherecht bei Änderungen der Subunternehmer-Kette. Das ist bei klassischen IT-Outsourcings eingeübt. Bei KI-Anbietern wird es interessant.

Die Realität: Ein LLM-Anbieter wie OpenAI nutzt Azure-Infrastruktur. Anthropic nutzt unter anderem AWS und Google Cloud. Das wissen Sie. Was Sie meistens nicht wissen: Welche externen Annotation-Dienstleister waren am Reinforcement Learning beteiligt? Welche Sicherheitsdienstleister haben Zugriff auf Audit-Logs? Welche Compliance-Tools laufen über die Modell-Outputs?

DORA Artikel 29 adressiert zusätzlich das Konzentrationsrisiko. Wenn Sie als Bank fünf verschiedene KI-Dienste einsetzen und alle laufen letztlich auf Azure-OpenAI, dann ist Ihr tatsächliches Konzentrationsrisiko auf Microsoft viel höher als der Vertragsbestand suggeriert. Bei einer Aufsichtsprüfung müssen Sie diese Verflechtungen kennen.

Die praktische Empfehlung: In jeden DORA-konformen KI-Vertrag gehört eine Klausel zur Meldepflicht bei Subunternehmer-Wechsel, idealerweise mit einer Veto-Möglichkeit für das Finanzunternehmen, zumindest aber mit einem Sonderkündigungsrecht. Bei den großen US-Anbietern ist das in der Enterprise-Variante verhandelbar. In der Standard-API-Welt nicht.

Audit-Rechte zwischen regulatorischem Anspruch und Anbieter-Realität

Hier liegt einer der größten Reibungspunkte. Artikel 30 Absatz 3 lit. e DORA verlangt vollständigen Zugang, Inspektion und Audit. Die Standard-Antwort der US-Anbieter: SOC 2 Type II, ISO 27001, manchmal ein gesondertes Compliance-Paket. Was ist davon akzeptabel?

Die BaFin hat in ihrer Verwaltungspraxis zu MaRisk-Auslagerungen seit Jahren das Pooled-Audit-Konzept akzeptiert, bei dem mehrere Finanzunternehmen gemeinsam einen Auditor beauftragen. Für DORA-relevante Sachverhalte gilt im Grundsatz dasselbe. Drittanbieter-Zertifikate als alleiniges Argument sind dünn. Sie müssen mindestens nachweisen, dass Sie als Finanzunternehmen ein vertragliches Recht hätten, ein eigenes Audit durchzuführen, auch wenn Sie es de facto über Pooled Audits oder anerkannte Zertifikate ausüben.

Ein praktikabler Mustertext für eine Audit-Klausel umfasst drei Elemente: erstens das uneingeschränkte Auditrecht, zweitens die Möglichkeit, dieses Recht über einen unabhängigen Dritten auszuüben, und drittens die explizite Akzeptanz aktueller Zertifikate als Erfüllungsoption für Routinefälle. Außerordentliche Audits, etwa nach einem Major-Incident, müssen aber jederzeit möglich bleiben.

Was die Aufsicht nicht akzeptiert: Ein bloßer Verweis auf einen SOC 2-Bericht ohne vertragliches Auditrecht ist zu wenig. Spätestens bei der nächsten Sonderprüfung wird das aufschlagen.

Nachverhandlung bestehender KI-Verträge: Ein pragmatischer Fahrplan

Wenn Sie heute noch nicht systematisch durchgegangen sind, hier eine pragmatische Reihenfolge.

Schritt 1: Bestandsaufnahme. Listen Sie alle KI-Dienste auf. Nicht nur die offiziellen, sondern auch die Shadow-AI-Nutzung in den Fachbereichen. ChatGPT-Pro-Accounts einzelner Mitarbeiter zählen dazu, wenn darin Kunden- oder Geschäftsdaten verarbeitet werden. Für jeden Eintrag: Unterstützt der Dienst eine kritische oder wichtige Funktion im Sinne von DORA? Wenn ja, gelten die Pflichten aus Artikel 28 und 30.

Schritt 2: Gap-Analyse gegen Artikel 30. Pro klassifiziertem Dienst: Welche der sieben Pflichtklauseln sind im aktuellen Vertrag erfüllt, welche nicht? Priorisieren Sie nach Risikopotenzial. Ein LLM, das im AML-Prozess mitläuft, hat höhere Priorität als ein Marketing-Copilot.

Schritt 3: Verhandlungsreihenfolge. Sprechen Sie zuerst die Anbieter an, bei denen Sie als großer Kunde Verhandlungsmacht haben. Microsoft Azure-OpenAI ist hier oft zugänglicher als OpenAI direkt, weil Microsoft schon lange im regulierten Markt unterwegs ist und entsprechende Enterprise-Verträge anbietet. Anthropic hat 2024 Enterprise-Verträge nachgeschärft. Bei kleineren Fintech-Lieferanten, die ihrerseits LLM-APIs nutzen, ist die Lage komplexer, weil die Subunternehmer-Kette weiterläuft.

Schritt 4: Eskalation. Wenn ein Anbieter zentrale DORA-Klauseln nicht akzeptiert und der Dienst eine kritische Funktion unterstützt, ist das eine Entscheidungssituation. Drei Optionen: alternativer Anbieter, On-Premise-Lösung mit Open-Source-Modellen, oder Reduktion des Anwendungsfalls auf nicht-kritische Funktionen. Die vierte Option, einfach weiterzumachen und auf Aufsichtsnachsicht zu hoffen, ist seit Januar 2025 keine Option mehr.

Zeithorizont: Wer heute beginnt, hat realistisch sechs bis zwölf Monate, um die kritischen Verträge auf Stand zu bringen. Bei BaFin-Sonderprüfungen wird das Thema definitiv kommen.

DORA trifft AI Act: Doppelbelastung oder synergetische Compliance?

Der EU AI Act tritt mit den Hochrisiko-Pflichten erst im August 2026 voll in Kraft. DORA ist seit Januar 2025 scharf. Trotzdem sollten Sie beide Regime zusammendenken.

Überschneidungen gibt es bei der Dokumentationspflicht, der Risikobewertung und den Governance-Strukturen. Wer für ein Kreditscoring-Modell die AI-Act-Anhang-IV-Dokumentation erstellt, hat einen großen Teil der DORA-relevanten Vendor-Dokumentation gleich miterledigt. Umgekehrt: Die Subunternehmer-Offenlegung nach DORA Artikel 30 hilft bei der AI-Act-Pflicht, die Datenherkunft nachzuvollziehen.

Mein Rat: Bauen Sie kein zweites Compliance-Silo. Ein integriertes KI-Vendor-Management-Framework, das DORA- und AI-Act-Anforderungen gemeinsam abbildet, spart Aufwand und vermeidet widersprüchliche Aussagen gegenüber der Aufsicht. Das setzt allerdings voraus, dass Compliance, IT-Governance und die Fachbereiche an einem Tisch sitzen. Genau das ist in den meisten Häusern der eigentliche Engpass, nicht der Vertragstext.