Frontier-AI-Modelle werden von europäischen und internationalen Aufsichts- und Zentralbankinstitutionen nicht als völlig neue Risikokategorie eingeordnet. Ihr wesentlicher Effekt liegt vielmehr in der Beschleunigung bekannter Cyber-, IKT- und operationeller Risiken: Schwachstellen können schneller identifiziert, Exploits schneller entwickelt und Angriffe breiter skaliert werden. Für Finanzunternehmen verschiebt sich damit vor allem das verfügbare Zeitfenster zwischen Offenlegung, Bewertung, Eindämmung und möglicher Ausnutzung.
Unter DORA entsteht daraus keine eigenständige „Frontier-AI-Pflicht“. Die Entwicklung ist jedoch ein gewichtiger Anlass, bestehende Prozesse für IKT-Risikomanagement, Schwachstellenbehebung, Drittparteiensteuerung, Business Continuity und Recovery auf ein höheres Bedrohungstempo auszurichten. Entscheidend ist dabei nicht nur der eigene Einsatz von KI. Auch die indirekte Exponierung über Cloud-, Software-, API-, Daten-, SOC- oder Entwicklungsdienstleister kann relevant sein.
Frontier AI verändert das Tempo, nicht den Grundcharakter des IKT-Risikos
Der Europäische Ausschuss für Systemrisiken bewertet Frontier-AI-Modelle mit Cyberfähigkeiten als materielle Veränderung der Risikolandschaft für das EU-Finanzsystem. Sie können die Suche nach Schwachstellen, die Entwicklung funktionierender Exploits sowie die Durchführung von Angriffen schneller, präziser und in größerem Umfang ermöglichen. Besonders bedeutsam ist der mögliche Verlust defensiver Zeitpuffer zwischen Schwachstellenentdeckung und deren praktischer Ausnutzung.
Die BIS weist zugleich auf eine operative Asymmetrie hin: KI kann sowohl Angriffe als auch Verteidigung unterstützen. Die defensive Remediation umfasst aber weitere, nicht beliebig beschleunigbare Schritte. Dazu gehören die Zuordnung einer Schwachstelle zu Assets und Geschäftsservices, die Priorisierung, sichere Tests, kontrollierte Produktionseinführungen und gegebenenfalls Rückabwicklungen. Eine hohe Zahl neu bekannter Schwachstellen kann deshalb Patch- und Change-Prozesse stärker belasten, als reine Automatisierung zunächst vermuten lässt.
Vom einzelnen Exploit zum korrelierten Störungsereignis
Das zentrale Risiko liegt nicht allein in einem einzelnen erfolgreichen Angriff. Gemeinsame technische Komponenten können aus einem lokalen Sicherheitsproblem ein korreliertes Störungsereignis machen. Betroffen sein können mehrere Institute gleichzeitig, wenn sie etwa dieselben Cloud-Services, Modell- oder API-Anbieter, Identitätsdienste, Softwarebibliotheken, Managed Services oder weit verbreitete Open-Source-Komponenten nutzen.
Nach der Bank of England können schnelleres Auffinden und Ausnutzen von Schwachstellen systemweite Folgen haben, weil wichtige Finanzdienstleistungen auf komplexer digitaler Infrastruktur und gemeinsamen Dritttechnologien beruhen. Zusätzlich erhöht ein größerer Patch-Bedarf die Frequenz von Validierungen und Änderungen. Fehlerhafte oder unzureichend getestete Änderungen können ihrerseits Ausfälle und Störungen in vernetzten Systemen verursachen. Cyberresilienz verlangt daher, Angriff und Remediation als zusammenhängendes Betriebsrisiko zu steuern.
Konzentrationsrisiko als technische Abhängigkeitskette bewerten
DORA verlangt bei kritischen oder wichtigen Funktionen eine vorgelagerte Bewertung von IKT-Konzentrationsrisiken. Zu berücksichtigen sind insbesondere schwer substituierbare Anbieter, Mehrfachbeziehungen zu demselben oder verbundenen Anbietern sowie komplexe Unterbeauftragungsstrukturen. Das ergibt sich aus der DORA-Verordnung und wird für vertragliche Vorkehrungen durch die einschlägige delegierte Verordnung konkretisiert.
Für Frontier-AI-bezogene Risiken reicht eine Lieferantenliste allein regelmäßig nicht aus. Erforderlich ist eine technische Sicht auf die Abhängigkeitskette: Welcher Modellanbieter wird genutzt? Auf welcher Cloud-Region und Inferenz- oder API-Schicht beruht der Dienst? Welche Datenquellen, Bibliotheken, Identitätsdienste und Unterauftragnehmer unterstützen ihn? Und welche kritischen oder wichtigen Funktionen wären bei einer Störung, einer Schwachstelle oder einer kurzfristig notwendigen Änderung beeinträchtigt?
Diese Kartierung soll keine abstrakte Vollständigkeitsübung sein. Sie dient dazu, gemeinsame Fehlerdomänen zu erkennen: Mehrere formal unterschiedliche Dienstleister können auf derselben Cloud-Plattform, derselben Softwarekomponente oder demselben Modell-Ökosystem beruhen. Gerade diese verdeckten Gemeinsamkeiten sind für Konzentration, Substituierbarkeit, Exit-Fähigkeit und Krisenplanung relevant.
Was DORA bereits verlangt – und was die neuen Stellungnahmen einordnen
DORA verpflichtet Finanzunternehmen im Anwendungsbereich unter anderem zu einem dokumentierten IKT-Risikomanagement, zur fortlaufenden Identifikation von IKT-Risikoquellen, Cyberbedrohungen und Schwachstellen sowie zur Dokumentation IKT-gestützter Funktionen, Assets, Abhängigkeiten und Verbindungen zu IKT-Drittdienstleistern. Das Leitungsorgan definiert, genehmigt und überwacht die IKT-Risikomanagementvorkehrungen; es trägt die letztendliche Verantwortung für das IKT-Risikomanagement und die IKT-Risikotoleranz.
Die gemeinsame Erklärung der Europäischen Aufsichtsbehörden schafft ausdrücklich keine zusätzlichen Anforderungen. Sie ordnet Frontier-AI-bedingte Risiken in bestehende DORA-Bereiche ein und strukturiert mögliche Maßnahmen entlang von Prävention, Erkennung und Management. Genannt werden aktuelle Inventare einschließlich APIs sowie KI/ML-Komponenten, kontinuierlichere Überwachung, risikobasierte Patch-Prozesse, Lieferkettenkontrollen und Szenarien für KI-gestützte Mehrsystemausfälle.
Davon zu unterscheiden ist das Schreiben der EZB-Bankenaufsicht vom 7. Juli 2026. Es richtet sich im SSM-Kontext an bedeutende Institute und fordert eine Bewertung der veränderten Bedrohungslage sowie Maßnahmenpläne bis zum 31. Oktober 2026. Diese aufsichtliche Erwartung und Frist gelten nicht pauschal als gesetzliche DORA-Frist für sämtliche Finanzunternehmen.
Vulnerability und Patch Management auf verkürzte Zeitfenster ausrichten
Die DORA-RTS zum IKT-Risikomanagement verlangen dokumentierte Verfahren für das Schwachstellenmanagement. Sie umfassen automatisierte Scans und Assessments in risikoorientierter Frequenz, die Nachverfolgung von Dritt- und Open-Source-Bibliotheken, Informationen von IKT-Drittdienstleistern zu kritischen Schwachstellen und Trends sowie priorisierte, überwachte Remediation. Für Assets, die kritische oder wichtige Funktionen unterstützen, ist mindestens eine wöchentliche automatisierte Schwachstellenprüfung vorgesehen.
Praktisch sollte das Betriebsmodell insbesondere folgende Fragen beantworten:
- Welche Triage-Zeiten gelten für kritische, internetexponierte oder bereits aktiv ausgenutzte Exposures?
- Welche Notfall-Change-Pfade ermöglichen schnelle Mitigation, ohne Mindestanforderungen an Tests und Freigaben aufzugeben?
- Sind Testkapazitäten, gestaffelte Rollouts, Monitoring nach dem Deployment und Rollback-Verfahren für einen erhöhten Änderungsdurchsatz ausreichend?
- Werden Backup-, Disaster-Recovery- und Administrationsumgebungen in Schwachstellen- und Patch-Prozesse einbezogen?
Die Steuerung sollte Patch-Geschwindigkeit nicht gegen Betriebsstabilität ausspielen. Angemessen sind risikobasierte Entscheidungen mit nachvollziehbaren Ausnahmen, kompensierenden Maßnahmen und klaren Eskalationswegen. Überfällige kritische Schwachstellen sind dabei nicht nur technische Tickets, sondern ein potenzielles Risiko für Geschäftsservices und die festgelegte IKT-Risikotoleranz.
Resilienztests auf Mehrsystem- und Lieferkettenszenarien erweitern
Die DORA-RTS verlangen bei Business-Continuity-Tests schwere, aber plausible Störungsszenarien. Dabei können auch IKT-Drittservices, Redundanz-, Backup- und Wiederanlaufszenarien einzubeziehen sein; festgestellte Mängel sind zu behandeln und dem Leitungsorgan zu berichten. Für die Frontier-AI-Perspektive sind Szenarien besonders aussagekräftig, die nicht von einem isolierten Systemausfall ausgehen.
Naheliegend sind etwa die gleichzeitige Ausnutzung einer Schwachstelle in mehreren Systemen, ein fehlerhafter Massenpatch, der Ausfall eines gemeinsamen Cloud- oder Modellanbieters oder eingeschränkte Dienstleisterunterstützung während der Wiederherstellung. Solche Tests sollten klären, ob Prioritäten für kritische Geschäftsservices, Entscheidungsbefugnisse, Kommunikationswege und Wiederanlauffähigkeit auch unter hoher Änderungs- und Incident-Last funktionieren.
Management-Reporting: Geschwindigkeit, Exponierung und Abhängigkeiten sichtbar machen
Das Leitungsorgan benötigt keine reine Fülle operativer Kennzahlen, sondern eine verdichtete Sicht auf Risikoentwicklung und Handlungsfähigkeit. Geeignet sind beispielsweise die Zeit von Disclosure bis Triage oder Mitigation für kritische Exposures, der Bestand überfälliger kritischer Schwachstellen nach Geschäftsservice, Patch-Erfolgs- und Rollback-Raten sowie der Anteil nicht inventarisierter oder internetexponierter Assets.
Ergänzend sollten Konzentrationsindikatoren berichten, welcher Anteil kritischer Services von gemeinsamen technischen Abhängigkeiten geprägt ist, welche risikorelevanten Lieferantenfeststellungen offen sind und wie belastbar Exit- oder Übergangsoptionen bewertet wurden. Eine getestete Recovery-Fähigkeit, einschließlich festgestellter Lücken, verbindet diese Perspektive mit der tatsächlichen Resilienz des Instituts.
Pragmatischer Umsetzungsplan für DORA-Programme
Ein sinnvoller erster Schritt ist eine gezielte Bestandsaufnahme: KI-bezogene und indirekte technische Abhängigkeiten sollten den kritischen oder wichtigen Funktionen zugeordnet werden. Darauf aufbauend lassen sich Risiko- und Lieferantenbewertungen um beschleunigte Disclosure-, Patch- und Mitigation-Szenarien ergänzen. Parallel sollten Schwachstellen-, Change- und Recovery-Prozesse auf Kapazitätsengpässe, sichere Notfallverfahren und Rückfallfähigkeit geprüft werden.
Den Abschluss bildet kein einmaliges Projekt, sondern ein belastbarer Test- und Berichtszyklus. Wenn Finanzunternehmen technische Konzentration, Remediation-Leistung und Wiederherstellungsfähigkeit gemeinsam betrachten, bleibt Frontier AI dort verortet, wo das Thema nach den aktuellen Veröffentlichungen hingehört: als Beschleuniger bestehender IKT- und Resilienzrisiken, der konsequente Governance und betriebliche Belastbarkeit erfordert.