DORA IKT-Drittparteienrisiko: Wann KI-Anbieter als kritische IKT-Dienstleister gelten

Das DORA IKT-Drittparteienrisiko bezeichnet die Pflicht von Finanzunternehmen, Risiken aus ausgelagerten IKT-Diensten aktiv zu steuern. Nach der Verordnung (EU) 2022/2554 (DORA, anwendbar seit 17. Januar 2025) können KI- und LLM-Anbieter als IKT-Drittdienstleister erfasst sein und lösen dann den Pflichtenkanon der Artikel 28 bis 30 aus: Informationsregister, Vertragsanforderungen, Konzentrationsrisiko-Steuerung und gegebenenfalls den Überwachungsrahmen für kritische Anbieter.

• Wer ist betroffen? DORA adressiert Finanzunternehmen (u. a. CRR-Institute, Solvency-II-Versicherer), nicht KI-Anbieter direkt. Der KI-Dienst wird über das Finanzunternehmen erfasst.
• Warum KI? Die BaFin-Orientierungshilfe vom 18. Dezember 2025 ordnet KI-Systeme als Unterfall der "Netzwerk- und Informationssysteme" gem. Art. 3 Nr. 2 DORA ein und zieht damit den vollen DORA-Pflichtenkanon in die KI-Governance.
• Kernpflicht zuerst: Jeder vertragliche IKT-Dienst – auch ein produktiv genutzter LLM-Dienst – gehört ins Informationsregister, das den Aufsichtsbehörden bereitgestellt wird.

Warum KI-/LLM-Anbieter zu IKT-Dienstleistern werden

DORA reguliert nicht KI als Technologie, sondern die digitale operationale Resilienz von Finanzunternehmen. Der entscheidende Hebel ist die weite Definition von IKT-Diensten und Netzwerk- und Informationssystemen. Sobald ein Finanzunternehmen einen KI-Dienst – etwa ein gehostetes Sprachmodell, eine Fraud-Scoring-API oder einen Cloud-basierten Dokumentenassistenten – produktiv einsetzt, ist dieser Dienst Teil seines IKT-Drittparteienrisikos.

Die BaFin-Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen vom 18. Dezember 2025 macht diesen Zusammenhang in der deutschen Aufsichtspraxis explizit: KI-Systeme sind ein Unterfall der "Netzwerk- und Informationssysteme" gemäß Art. 3 Nr. 2 DORA. Damit greifen für KI-gestützte Workloads die DORA-Pflichten zum IKT-Risikomanagement (Art. 5–15), zu Resilienztests einschließlich Threat-Led Penetration Testing (Art. 24–27) sowie zum IKT-Drittparteienrisiko (Art. 28–30). Die Orientierungshilfe ist formal unverbindlich, kehrt in der Aufsichtspraxis aber materiell die Beweislast um: Wer ihr nicht folgt, muss bei BaFin-Prüfungen die Gleichwertigkeit alternativer Maßnahmen dokumentieren. Adressaten sind primär CRR-Institute und Solvency-II-Versicherer.

Praktische Konsequenz: Ein KI-Anbieter unterliegt DORA nicht "automatisch". Erfasst wird der Dienst über das nutzende Finanzunternehmen – und dieses muss seinen Anbieter so steuern, vertraglich binden und dokumentieren, dass die DORA-Anforderungen erfüllbar sind.

Das Informationsregister (Register of Information)

Zentrales Steuerungsinstrument des IKT-Drittparteienrisikos ist das Informationsregister. Finanzunternehmen müssen ein vollständiges Verzeichnis aller vertraglichen Vereinbarungen über IKT-Dienste führen und den zuständigen Aufsichtsbehörden bereitstellen. Dieses Register erfasst, welche Funktion ein Dienst stützt, ob er eine kritische oder wichtige Funktion unterstützt, wer der Anbieter ist und welche Unterauftragnehmer eingebunden sind.

Für KI bedeutet das: Ein produktiv genutzter LLM- oder ML-Dienst ist kein "Tool unter Marketing-Budget", sondern ein registerpflichtiger IKT-Dienst, sobald er einer vertraglichen Auslagerung entspricht. Das Register ist zugleich die Datenbasis, auf der die European Supervisory Authorities (ESAs) erkennen, welche Anbieter sektorweit so verbreitet sind, dass sie als kritisch einzustufen sind.

Kritische IKT-Drittdienstleister (CTPP) und der Überwachungsrahmen

DORA etabliert einen eigenen Überwachungsrahmen (Oversight Framework) für kritische IKT-Drittdienstleister (Critical ICT Third-Party Providers, CTPP). Am 18. November 2025 haben die ESAs erstmals 19 CTPPs designiert – darunter AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix und Swift. Diese Anbieter unterliegen ab 2026 direkter EU-Aufsicht. Das DORA Joint Oversight Forum führt im Verlauf 2026 erste umfassende Prüfungen durch und spricht voraussichtlich bindende Empfehlungen aus.

Wichtig für die KI-Diskussion: Die meisten produktiven KI-/LLM-Workloads laufen heute auf genau diesen Hyperscalern. Auch wenn ein KI-Startup selbst (noch) nicht als CTPP designiert ist, sitzt es technisch oft auf einem designierten Anbieter auf. Die Aufsicht über den darunterliegenden Hyperscaler ändert dabei nichts an der Eigenverantwortung des Finanzunternehmens für Auslagerung, Exit-Fähigkeit und Konzentrationsrisiko.

Konzentrationsrisiko und Exit-Strategie

Das Konzentrationsrisiko ist im KI-Kontext besonders ausgeprägt. Wenn nahezu jede DACH-Bank für KI-Workloads auf einen der wenigen designierten Hyperscaler oder auf zentrale Verbundlösungen angewiesen ist, entsteht ein systemischer Klumpen. DORA verlangt deshalb, dass Finanzunternehmen ihre Abhängigkeit aktiv managen: Exit-Pläne sind jährlich zu testen, und Multi-Cloud- bzw. Substituierbarkeits-Strategien werden faktisch erzwungen. Laut Research bleibt eine systematische Multi-Cloud-KI-Architektur 2026 technisch und kommerziell anspruchsvoll – die Lücke zwischen "symbolischem Exit-Plan" und tatsächlich übbarem Anbieterwechsel ist ein reales Aufsichtsthema.

Auslagerungs- und Vertragsanforderungen (Art. 30)

DORA Art. 30 definiert einen verpflichtenden Vertragsklauselkanon für IKT-Dienste, der bestehende Outsourcing-Regime ablöst bzw. überlagert. Die EBA Outsourcing Guidelines (EBA/GL/2019/02) sowie die ESMA-Outsourcing-Guidelines (ESMA50-164-4285) wurden durch DORA Art. 28–30 substantiell modifiziert. Kernelemente der Klauseln:

• Verpflichtende Audit- und Zugangsrechte für Finanzunternehmen und Aufsicht
• Exit-Klauseln mit geordnetem Ausstiegspfad
• Kontrolle von Unterauftragnehmern (Sub-Processoren)
• Service-Level-Vereinbarungen mit Datenresidenz-, Latenz- und Rechenkapazitätszusagen

Laut Research sind diese Klauseln bei Hyperscalern aktuell weitgehend Standardtext, bei KI-Startups dagegen ein häufiger Procurement-Blocker. Für KI-Vendoren ohne belastbare Audit-Rechte, ohne Sub-Processor-Transparenz und ohne dokumentierte Datenresidenz endet der Auswahlprozess in DACH-Finanzhäusern oft vor der finalen Runde.

Übersicht: Pflicht, Wer betroffen, Bezug

Praxisbeispiel: LLM-Assistent in einer Regionalbank

Eine mittelgroße Bank führt einen LLM-gestützten internen Wissensassistenten ein, der über die API eines KI-Anbieters läuft, der seinerseits auf Microsoft Azure hostet. DORA-relevante Schritte:

1. Klassifizieren: Stützt der Assistent eine kritische oder wichtige Funktion? Falls ja, verschärfen sich die Anforderungen.
2. Registrieren: Vertrag und Dienst werden ins Informationsregister aufgenommen – inklusive des Unterauftragnehmers Azure (designierter CTPP).
3. Vertraglich absichern (Art. 30): Audit-Rechte, Exit-Klausel, Sub-Processor-Transparenz, SLA mit Datenresidenz in der EU.
4. Konzentrationsrisiko bewerten: Liegt eine kritische Funktion auf einem einzigen Hyperscaler? Exit-Pfad definieren und jährlich testen.
5. Vorfallprozess: Schwerwiegende IKT-Vorfälle des Dienstes – etwa halluzinierte regulatorische Zitate als materielles Operational-Risk-Ereignis – sind nach DORA meldepflichtig.

Pseudocode der Governance-Logik:

```
wenn KI_Dienst.ist_vertragliche_Auslagerung:
Register.eintragen(KI_Dienst, sub_processoren=[Hyperscaler])
wenn KI_Dienst.stuetzt_kritische_funktion:
Vertrag.pruefen(Art30_Klauseln) # Audit, Exit, SLA, Sub-Processor
ExitPlan.test(intervall="jaehrlich")
Konzentrationsrisiko.bewerten(anbieter, funktion)
Vorfall.meldepfad_aktivieren(schwere="major")
```

Die genannten Artikelnummern, Daten und der CTPP-Status stammen aus der zugrunde liegenden Research bzw. gesichertem DORA-Wissen. Dieser Beitrag ist keine Rechtsberatung; ob und wie DORA auf einen konkreten KI-Dienst anwendbar ist, bedarf einer Einzelfallprüfung durch fachkundige rechtliche und aufsichtliche Beratung.

Für Agenturen und B2B-Entscheider

Für Marketing-Agenturen und Dienstleister, die KI-Funktionen an Banken, Versicherer oder andere Finanzunternehmen liefern, ist DORA ein hartes Vertriebskriterium, kein Beiwerk. Wer LLM-gestützte Lösungen in den regulierten Finanzsektor verkaufen will, sollte Audit-Fähigkeit, Sub-Processor-Transparenz, EU-Datenresidenz und einen belastbaren Exit-Pfad von Anfang an mitdenken – sonst scheitert das Projekt nicht an der Modellqualität, sondern am Procurement. Blck Alpaca unterstützt bei der DORA-konformen Konzeption von KI-Workflows und der Einbettung in Auslagerungs- und Vendor-Prozesse, damit Ihre KI-Initiative im Finanzsektor überhaupt in die finale Auswahlrunde kommt. Die rechtliche Einzelfallprüfung holen Sie ergänzend bei fachkundiger Beratung ein.