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. Das nutzende Finanzunternehmen muss sie dann nach den Artikeln 28 bis 30 steuern: Informationsregister, Vertragsanforderungen, Konzentrationsrisiko-Steuerung. Stufen die Europäischen Aufsichtsbehörden (ESAs: EBA, EIOPA, ESMA) einen Anbieter als kritisch ein, unterliegt er selbst dem Überwachungsrahmen nach Art. 31 ff.

• 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 nach eigener Aussage eine nicht verpflichtende Hilfestellung und definiert keine aufsichtlichen Erwartungen. Sie soll Finanzunternehmen helfen, die DORA-Anforderungen beim Einsatz von KI umzusetzen. 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 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). Er steht in Art. 31 ff. und ist damit vom Pflichtenkanon der Finanzunternehmen in Art. 28 bis 30 getrennt. Am 18. November 2025 haben die ESAs erstmals 19 CTPPs designiert, darunter AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix und Bloomberg (Liste der ESAs).

Nach der Designation unterliegen diese Anbieter der direkten Aufsicht auf EU-Ebene. Für jeden CTPP ist eine der drei ESAs (EBA, EIOPA oder ESMA) als federführende Überwachungsbehörde (Lead Overseer) zuständig (Art. 31 Abs. 1 lit. b). Sie wird von einem gemeinsamen Untersuchungsteam (Joint Examination Team, Art. 40) unterstützt und kann Empfehlungen aussprechen (Art. 35). Diese Empfehlungen sind rechtlich nicht bindend. Der Anbieter muss aber binnen 60 Kalendertagen mitteilen, ob er ihnen folgt, oder begründen, warum nicht. Bleibt die Antwort aus oder reicht die Begründung nicht, macht die federführende Überwachungsbehörde das öffentlich. Als letztes Mittel können die nationalen Aufsichtsbehörden Finanzunternehmen verpflichten, den Dienst auszusetzen (Art. 42).

Wichtig für die KI-Diskussion: Die meisten produktiven KI-/LLM-Workloads laufen heute auf designierten Hyperscalern wie AWS, Microsoft Azure oder Google Cloud. 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.

Wann ein Anbieter als kritisch gilt

Die ESAs designieren nach vier Kriterien aus Art. 31 Abs. 2 DORA: systemische Auswirkung eines großflächigen Ausfalls auf die Finanzdienstleistungen, Systemrelevanz der abhängigen Finanzunternehmen (etwa global systemrelevante und andere systemrelevante Institute, G-SRI und A-SRI), Abhängigkeit kritischer oder wichtiger Funktionen vom Anbieter und Substituierbarkeit. Die Delegierte Verordnung (EU) 2024/1502 macht daraus ein zweistufiges Verfahren. In Stufe 1 muss ein Anbieter alle quantitativen Schwellen erreichen. Eine davon: Er stützt kritische oder wichtige Funktionen bei mindestens 10 % der Finanzunternehmen einer Kategorie, und diese halten zusammen mindestens 10 % der Vermögenswerte dieser Kategorie. Nur wer alle Schwellen erreicht, wird in Stufe 2 qualitativ bewertet. Datenbasis sind die Informationsregister der Finanzunternehmen.

Auf der ersten Liste steht kein Anbieter, dessen Kerngeschäft KI-Modelle sind, etwa OpenAI, Anthropic oder Mistral. Unsere Einschätzung: Reine KI- und LLM-Anbieter erreichen die Schwellen derzeit selten, weil ihre Dienste bei Banken und Versicherern noch wenige kritische oder wichtige Funktionen stützen und oft über die Plattformen der Hyperscaler bezogen werden. Ein Anbieter, der nicht auf der Liste steht, kann nach Art. 31 Abs. 11 selbst beantragen, als kritisch designiert zu werden. Gruppeninterne IKT-Dienstleister und Anbieter, die nur in einem Mitgliedstaat für ausschließlich dort tätige Finanzunternehmen arbeiten, werden nicht designiert (Art. 31 Abs. 8).

Konzentrationsrisiko und Exit-Strategie

Das Konzentrationsrisiko ist im KI-Kontext besonders ausgeprägt. Wenn nahezu jede Bank in der EU 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. Vor einem Vertrag über IKT-Dienste für kritische oder wichtige Funktionen prüfen sie, ob der Anbieter schwer ersetzbar ist oder ob sich Verträge beim selben Anbieter häufen (Art. 29). Für solche Dienste brauchen sie Exit-Strategien. Die Exit-Pläne müssen umfassend und dokumentiert sein und ausreichend getestet und regelmäßig überprüft werden (Art. 28 Abs. 8). Einen festen Turnus gibt DORA dafür nicht vor, anders als bei den IKT-Geschäftsfortführungsplänen, die mindestens jährlich zu testen sind (Art. 11 Abs. 6).

In der Praxis bleibt eine systematische Multi-Cloud-KI-Architektur 2026 technisch und kommerziell anspruchsvoll. Zwischen einem Exit-Plan auf dem Papier und einem tatsächlich durchführbaren Anbieterwechsel klafft deshalb oft eine Lücke.

Auslagerungs- und Vertragsanforderungen (Art. 30)

DORA Art. 30 definiert einen verpflichtenden Vertragsklauselkanon für IKT-Dienste. Damit überlagern DORA Art. 28–30 für diese Dienste die EBA-Leitlinien zu Auslagerungen (EBA/GL/2019/02) und die entsprechenden ESMA-Leitlinien. Kernelemente der Klauseln:

• Leistungsbeschreibung mit den Bedingungen für die Vergabe an Unterauftragnehmer (Sub-Processoren) (Abs. 2 lit. a)
• Orte der Leistungserbringung und Datenverarbeitung, inklusive Speicherort, und Vorabinformation bei geplanten Änderungen (Abs. 2 lit. b)
• Service-Level-Beschreibungen (Abs. 2 lit. e), bei kritischen oder wichtigen Funktionen mit präzisen quantitativen und qualitativen Leistungszielen (Abs. 3 lit. a)
• Kündigungsrechte (Abs. 2 lit. h), bei kritischen oder wichtigen Funktionen zusätzlich Exit-Strategien mit verpflichtender Übergangsfrist (Abs. 3 lit. f)
• Bei kritischen oder wichtigen Funktionen uneingeschränkte Zugangs-, Prüf- und Audit-Rechte für Finanzunternehmen und Aufsicht (Abs. 3 lit. e)

Zusagen zu Latenz oder Rechenkapazität schreibt DORA nicht ausdrücklich vor. Ob du sie brauchst, ergibt sich aus den Leistungszielen der jeweiligen Funktion.

Nach unserer Einschätzung sind diese Klauseln bei Hyperscalern 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 Verarbeitungsorte endet der Auswahlprozess bei Finanzunternehmen in der EU oft vor der finalen Runde.

Übersicht: Pflicht, Wer betroffen, Rechtsgrundlage

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-Strategie mit Übergangsfrist, Bedingungen für Unterauftragnehmer, festgelegte Orte der Leistungserbringung und Datenverarbeitung (die Bank wählt hier die EU) und SLA mit quantitativen Leistungszielen.
4. Konzentrationsrisiko bewerten: Liegt eine kritische Funktion auf einem einzigen Hyperscaler? Exit-Plan dokumentieren und regelmäßig 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.stützt_kritische_funktion:
Vertrag.prüfen(Art30_Klauseln) # Audit, Exit, SLA, Sub-Processor
ExitPlan.test(intervall="regelmäßig")
Konzentrationsrisiko.bewerten(anbieter, funktion)
Vorfall.meldepfad_aktivieren(schwere="major")
```

Die Artikelangaben beziehen sich auf den Verordnungstext von DORA, der CTPP-Status auf die Liste der ESAs vom 18. November 2025. 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 ihrer Verankerung in Auslagerungs- und Vendor-Prozessen, damit deine KI-Initiative im Finanzsektor überhaupt in die finale Auswahlrunde kommt. Die rechtliche Einzelfallprüfung holst du ergänzend bei fachkundiger Beratung ein.