Die Cloud-Debatte in Banken und Versicherern galt als entschieden: Die Richtung stimmt, die Governance steht, DORA hat die Spielregeln kodifiziert. Dann kam AI – und macht die Cloud-Auslagerung neu auf. Denn AI-Workloads sind die anspruchsvollste Auslagerung, die ein Finanzhaus derzeit eingehen kann: rechenintensiv, datenintensiv, anbieterkonzentriert und in Prozessen unterwegs, die schnell kritisch oder wichtig im Sinne der Verordnung werden.
Cloud-Auslagerung unter DORA: Der Rahmen steht – AI testet ihn
Seit Januar 2025 gilt DORA unmittelbar, und der Kern für die Cloud-Frage steht in den Artikeln 28 bis 30: Management des IKT-Drittparteirisikos, vollständiges Informationsregister, vertragliche Mindestinhalte – verschärft für kritische oder wichtige Funktionen, inklusive Auditrechten und Exit-Strategien. Neu ist daran nichts. Neu ist, was AI daraus macht.
Drei Verschiebungen. Erstens die Kritikalität: Ein Chatbot für interne FAQ ist unkritisch – ein Agent in der Schadenregulierung oder Kreditbearbeitung liegt schnell in einer kritischen oder wichtigen Funktion, mit allen verschärften Vertragsanforderungen. Die Einstufung wandert mit dem Use Case, nicht mit der Technologie. Zweitens das Konzentrationsrisiko: AI-Workloads bündeln sich bei wenigen Hyperscalern und Modellanbietern – genau die Konstellation, für die DORA das Konzentrationsrisiko ins Register und in die Analyse zwingt. Drittens die Datenfrage: Prompts und Kontexte von AI-Systemen enthalten oft genau die personenbezogenen und geschäftskritischen Daten, die vorher nie das Haus verlassen haben. Datenresidenz wird damit vom Datenschutz-Thema zum Architekturprinzip – lösbar etwa über EU-Deployments wie AWS Bedrock in Frankfurt, bei denen Modelle in der Region laufen und Daten sie nicht verlassen.
Unsere Einordnung: Die richtige Reaktion ist nicht Cloud-Skepsis – sie wäre die teuerste aller Antworten, weil moderne AI ohne Cloud-Skalierung nicht wirtschaftlich zu betreiben ist. Die richtige Reaktion ist Präzision: AI-Workloads als das behandeln, was sie sind – Auslagerungen mit eigenem Risikoprofil, eigenem Vertragsbedarf und eigener Exit-Logik.
Exit-Fähigkeit ist bei AI eine Architekturentscheidung
Der Punkt, an dem klassische Cloud-Governance bei AI versagt, ist der Exit. Bei einer ausgelagerten Anwendung heißt Exit: Daten migrieren, Betrieb verlagern – aufwendig, aber bekannt. Bei einem AI-System hängt am Anbieter mehr: das Modell selbst, die Prompts und Skills, die darauf abgestimmt sind, die Evaluationsdaten, die Qualität belegen. Wer das alles fest mit einem Anbieter verdrahtet, hat eine Exit-Strategie auf dem Papier und keine in der Praxis.
Die Antwort ist dieselbe, die wir architektonisch immer geben, hier aber mit aufsichtsrechtlichem Gewicht: modell-agnostisch bauen. Eine Orchestrierungsschicht, unter der sich Modelle und Anbieter wechseln lassen, ist nicht nur technische Hygiene – sie ist die einzige Exit-Strategie, die ein Prüfer ernst nehmen kann. Dazu gehören dokumentierte Regressions-Tests für den Anbieterwechsel und SLA-Metriken, die den Nachweis der Wiederherstellungs- und Wechselfähigkeit tragen – dieselbe Disziplin, die auch der EU AI Act an Protokollierung und Aufsicht verlangt. Regulierung ist hier kein Blocker: Ein Haus, das Exit-Fähigkeit real gebaut hat, verhandelt mit jedem Anbieter aus einer stärkeren Position. Sie ist der Moat – auch kommerziell.
Das Prüfprogramm für die eigene AI-Cloud-Landschaft
Drei Arbeitspakete. Erstens das Register vervollständigen: Jeder AI-Workload gehört ins Informationsregister – mit Funktion, Kritikalitätseinstufung, Anbieter, Subdienstleistern und Datenkategorien; die Schatten-Nutzung der Fachbereiche eingeschlossen. Zweitens die Verträge nachziehen: Auditrechte, Datenresidenz-Zusagen, Subunternehmer-Transparenz und Exit-Unterstützung explizit für AI-Dienste – nicht als Anhang an den alten Cloud-Rahmenvertrag. Drittens den Exit einmal üben: einen unkritischen Workload testweise auf ein zweites Modell oder einen zweiten Anbieter schwenken. Eine Exit-Strategie, die nie getestet wurde, ist eine Vermutung.
Die Cloud-Frage ist 2026 keine Ja-Nein-Frage mehr. Sie ist eine Wie-genau-Frage – und AI hat den Einsatz erhöht. Wenn Sie Ihre AI-Workloads DORA-fest aufstellen wollen: Sprechen Sie uns an.
Häufige Fragen zur Cloud-Auslagerung unter DORA
Was verlangt DORA bei Cloud-Auslagerungen?
DORA regelt das IKT-Drittparteirisiko in den Artikeln 28 bis 30: ein vollständiges Informationsregister aller IKT-Dienstleister, Analyse von Konzentrationsrisiken und vertragliche Mindestinhalte – für kritische oder wichtige Funktionen verschärft um Auditrechte, Subunternehmer-Transparenz und Exit-Strategien. Die Verordnung gilt seit Januar 2025 unmittelbar.
Warum ändern AI-Workloads die Cloud-Risikobewertung?
Aus drei Gründen: Die Kritikalitätseinstufung wandert mit dem Use Case – ein Agent in der Schadenregulierung liegt schnell in einer wichtigen Funktion. Das Konzentrationsrisiko steigt, weil sich AI-Workloads bei wenigen Hyperscalern und Modellanbietern bündeln. Und Prompts transportieren personenbezogene und geschäftskritische Daten, was Datenresidenz zum Architekturprinzip macht.
Wie sieht eine glaubwürdige Exit-Strategie für AI-Systeme aus?
Modell-agnostisch bauen: eine Orchestrierungsschicht, unter der sich Modelle und Anbieter wechseln lassen, dokumentierte Regressions-Tests für den Wechselfall – und mindestens ein real geübter Schwenk eines unkritischen Workloads. Eine Exit-Strategie, die nur auf dem Papier existiert, hält weder einer Prüfung noch einem Ernstfall stand.
