KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

Teil 6 von 7 unserer DORA-Serie: Die Abhängigkeit von KI-Anbietern ist kein Fernrisiko für einen späteren Beschaffungszyklus. Sie entsteht heute, wenn Modelle, Cloud-Zugang, Datenanbindung, Guardrails und Betriebswissen ohne Wechselperspektive zusammenwachsen. Auf die Beiträge zum DORA-Exit-Plan, zur Cloud-Abhängigkeit europäischer Banken und zum Informationsregister folgt deshalb die Frage: Wie wird aus einer nützlichen Modellintegration ein Konzentrationsrisiko – und wie bleibt sie steuerbar?

Nicht das Modell allein erzeugt die Abhängigkeit

Eine Bank kauft bei KI nicht nur ein Modell. In einer typischen Nutzungskette treffen Modell-API, Cloud-Infrastruktur, Vektorsuche oder andere Datenkomponenten, Sicherheitsmechanismen, Prompt- und Evaluierungslogik sowie die Einbindung in Fachprozesse zusammen. Je stärker diese Ebenen auf einen Anbieter und dessen proprietäre Schnittstellen zugeschnitten sind, desto höher werden die Wechselkosten. Die Abhängigkeit ist damit technisch, vertraglich und organisatorisch zugleich.

DORA liefert dafür einen breiten Begriffsrahmen, aber keine pauschale Etikettierung jeder KI-Lösung. Art. 3 Nr. 21 definiert IKT-Dienstleistungen als digitale und Datendienste, die dauerhaft über IKT-Systeme für interne oder externe Nutzer bereitgestellt werden; ausgenommen sind nur analoge Telefondienste. Ob eine konkrete KI-Leistung und ihre Nutzung darunter fällt, ist deshalb anhand der konkreten Ausgestaltung und der unterstützten Funktion zu bewerten. Eine ausdrückliche ESA-Aussage, die KI- oder ML-Dienste generell so einordnet, ist hierfür nicht erforderlich und liegt aus den herangezogenen Quellen nicht vor (DORA, Art. 3).

Entscheidend ist die Wirkung der Abhängigkeit. DORA definiert ein IKT-Konzentrationsrisiko als Exponierung gegenüber einzelnen oder mehreren verbundenen kritischen IKT-Drittdienstleistern, durch die eine Abhängigkeit entsteht und ein Ausfall oder eine Störung kritische oder wichtige Funktionen gefährden kann. Die Einordnung einer Funktion – nicht das Label „KI“ – ist somit der regulatorische Schalter. Teil 7 der Serie ordnet diese Frage für kritische und wichtige Funktionen ein (DORA, Art. 3).

Die Konzentration nimmt messbar zu

Die Warnung ist nicht abstrakt. Der Financial Stability Board nennt Drittanbieterabhängigkeiten und Dienstleisterkonzentration, Marktgleichlauf, Cyberrisiken sowie Modellrisiko, Datenqualität und Governance als KI-bezogene Schwachstellen mit Potenzial für systemische Risiken. Die Risikokarte umfasst damit nicht nur Modellfehler, sondern auch die gemeinsame technische Basis vieler Institute (Financial Stability Board, 14 November 2024).

Besonders deutlich ist der Befund zur Anbieterkonzentration. Auf Basis einer BoE/FCA-Umfrage stieg der Anteil der drei größten Modellanbieter von 18 % im Jahr 2022 auf 44 % im Jahr 2024. Gleichzeitig nahm der Anteil von Drittanbietern implementierter KI-Anwendungsfälle im britischen Finanzsektor von 17 % auf 33 % zu; Foundation-Model-Anwendungsfälle lagen 2024 bei 17 %. Diese Werte beschreiben nicht den europäischen Gesamtmarkt, sind aber ein belastbarer Frühindikator dafür, wie schnell sich externe Modellabhängigkeiten verdichten können (FSB Monitoring Report).

Die Konzentration endet nicht beim Modell. Der FSB betrachtet Hardware, Cloud, Trainingsdaten und Foundation Models als relevante Ebenen und beschreibt Hardware als den konzentriertesten Teil der KI-Lieferkette. Vertikale Integration kann Wechselkosten zusätzlich erhöhen. Für das Risikomanagement folgt daraus: Eine bloße Liste von Modellnamen unterschätzt die Abhängigkeit, wenn Modell, Hosting, Identitätsdienst, Datenzugang und Betrieb in derselben Lieferkette liegen (FSB Monitoring Report).

Auch die EZB trennt zwei Dimensionen: technologische Durchdringung und Lieferantenkonzentration. Wenn neue KI-Werkzeuge breit eingesetzt werden und Lieferanten konzentriert sind, können laut EZB operationelle Risiken einschließlich Cyberrisiken, Marktkonzentration und Too-big-to-fail-Externalitäten zunehmen. Sie warnt zudem, dass eine übermäßige Abhängigkeit von wenigen Anbietern das operationelle Rückgrat des Finanzsystems fragiler machen kann – bis hin zu Single-Point-of-Failure-Risiken (EZB Financial Stability Review, Mai 2024).

Vier Ebenen, die jedes Institut getrennt bewerten sollte

Eine brauchbare Steuerung beginnt mit einer einfachen Zerlegung. Nicht jede Ebene hat denselben Eigentümer, denselben Exit-Weg oder dieselbe Risikowirkung.

Diese Zerlegung schützt vor einem verbreiteten Denkfehler: Multi-Model-Nutzung ist nicht automatisch Resilienz. Zwei Modelle beim gleichen Cloud- oder Integrationsanbieter können weiterhin dieselbe Störungs- oder Vertragsabhängigkeit teilen. Umgekehrt kann ein einzelnes Modell in einer klar getrennten Architektur leichter ersetzbar sein als mehrere Modelle in einem unentwirrbaren Workflow.

Der Prüfpfad sollte daher mit der unterstützten Funktion beginnen. Welche Kundenerfahrung, Entscheidung oder interne Tätigkeit hängt an der KI-Komponente? Was passiert bei Ausfall, Qualitätsabfall, Preis- oder Vertragsänderung? Welche Daten und Konfigurationen müssen exportiert werden? Und welche Alternativen wurden unter realistischen Qualitäts-, Sicherheits- und Latenzanforderungen geprüft? Dieses Vorgehen verbindet Modellrisiko mit der Exit-Logik aus Teil 2 und der Lieferkettenperspektive aus Teil 5, anstatt beides in getrennten Gremien zu behandeln.

Modell-agnostisch ist ein Architekturprinzip, kein Freifahrtschein

Eine modell-agnostische Architektur kann Abhängigkeiten reduzieren, weil sie Modelle austauschbar hält und Wissen, Kontexte sowie Konfigurationen nicht an einen einzelnen Modellanbieter bindet. Sie ersetzt jedoch weder eine Risikoanalyse noch Tests. Die Wechseloption muss anhand repräsentativer Aufgaben, Schutzmaßnahmen und Betriebsprozesse nachvollziehbar sein; ein bloßer Konnektor zu mehreren Modellen reicht nicht.

Als Anbieterbeispiel beschreibt Acceleraid seinen GenAI-Ansatz ausdrücklich als „model-agnostic“ und „No vendor lock-in“. Die Plattform nennt die Anbindung vorhandener Azure- oder Google-Cloud-Verträge, beliebiger LLMs sowie Open-Source-Modelle wie Llama und Mistral auf eigener Infrastruktur. Für Banken ist das eine relevante Gestaltungsoption: Die Schnittstelle zur Fachlogik, die Datenaufbereitung und die Governance können von der konkreten Modellwahl getrennt werden. Es ist keine Zusage, dass ein Wechsel in jedem Anwendungsfall ohne Aufwand gelingt; vielmehr schafft die Architektur die Voraussetzung, einen Wechsel überhaupt planbar zu testen (Acceleraid GenAI Enablement).

Der Beitrag über KI-Personalisierung, EU AI Act, DSGVO und MaRisk vertieft die Governance-Perspektive für kundennahe KI. Ergänzend zeigt Teil 3 zur Cloud-Abhängigkeit, dass ein Modellwechsel nicht genügt, wenn die umgebende Infrastruktur konzentriert bleibt. Architekturentscheidungen müssen daher Modell- und Cloud-Ebene gemeinsam dokumentieren.

Verträge, Tests und der AI Act gehören in dieselbe Roadmap

Wenn eine Auslagerung eine kritische oder wichtige Funktion unterstützt und als IKT-Dienstleistung einzuordnen ist, verlangt Art. 30 Abs. 3 DORA unter anderem vollständige Servicelevel-Beschreibungen mit quantitativen und qualitativen Leistungszielen, Notfallpläne, laufende Überwachung und Ausstiegsstrategien mit verbindlichem angemessenem Übergangszeitraum. Diese Anforderungen lassen sich für KI nur wirksam erfüllen, wenn das Institut die technischen Abhängigkeiten vor Vertragsabschluss kennt und dokumentiert (DORA, Art. 30).

Ein sinnvoller Test ist kein theoretisches Vertragsreview. Er sollte für priorisierte Anwendungsfälle prüfen, ob Daten und Konfigurationen exportierbar sind, ob ein Alternativmodell über dieselben Schutzschichten erreichbar ist und ob die fachlichen Qualitäts- und Sicherheitskriterien weiterhin eingehalten werden. Die Ergebnisse gehören in das Auslagerungs- und Registermodell: Anbieter, unterstützte Funktion, Unterauftragnehmer, Datenstandort, Substituierbarkeit, Testdatum und festgestellte Einschränkungen.

Parallel entsteht mit dem EU AI Act eine zweite Governance-Zeitleiste. Die Verordnung gilt grundsätzlich ab 2. August 2026; Kapitel V zu General-Purpose AI gilt bereits seit 2. August 2025. Art. 53 verlangt unter anderem technische Dokumentation, Informationen für nachgelagerte Anbieter, eine Copyright-Policy und eine Zusammenfassung der Trainingsdaten. Bei systemischem Risiko ergänzt Art. 55 Modellbewertung, Red-Teaming, Meldung schwerwiegender Vorfälle und Cybersicherheitsmaßnahmen (EU AI Act, Art. 113, 53 und 55).

Für Bankverantwortliche bedeutet das: DORA und der AI Act sind keine konkurrierenden Listen. DORA richtet den Blick auf die betriebliche Widerstandsfähigkeit und Drittanbieterabhängigkeit; der AI Act strukturiert Transparenz, Dokumentation und Pflichten rund um General-Purpose AI. Ein gemeinsames Inventar der Modelle, Anbieter, Datenflüsse, Funktionen und Kontrollen vermeidet doppelte Arbeit – und macht die echte Konzentration sichtbar.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet (dieser Beitrag)

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.