Wem gehört Ihre Infrastruktur: technologische Abhängigkeit als Betriebsrisiko

Über technologische Souveränität wird in Europa vor allem als geopolitische Frage gesprochen. Für einen COO oder CTO ist es jedoch eine einfachere und dringlichere Frage: Was passiert mit meinem Unternehmen, wenn sich die Bedingungen, der Preis oder das rechtliche Umfeld eines Anbieters ändern, auf dem es aufbaut? Diese Frage lässt sich ohne Politik beantworten, mit demselben Vorgehen wie bei jedem anderen Betriebsrisiko.

Abhängigkeit von außereuropäischen Anbietern ist an sich kein Fehler. Ein Fehler ist eine Abhängigkeit, die das Unternehmen nicht kennt, nicht beziffert hat und aus der es keinen Ausweg hat.

Wie groß die Abhängigkeit ist

Laut Synergy Research Group hielten europäische Anbieter 2024 rund 15 % des europäischen Markts für Cloud-Infrastruktur, also für IaaS, PaaS und gehostete Private-Cloud-Dienste. 2017 waren es 29 %. Seit 2022 ist der Anteil stabil. Amazon, Microsoft und Google kommen zusammen auf etwa 70 % des Markts. Die europäischen Anbieter stehen dabei nicht still: Sie haben ihren Umsatz auf dem Heimatmarkt zwischen 2017 und 2024 mehr als verdreifacht. Der europäische Gesamtmarkt ist im selben Zeitraum jedoch um das Sechsfache gewachsen, auf 61 Mrd. € im Jahr 2024.

Wie tief Standardentscheidungen reichen, zeigt ein kleines Beispiel. Die Rhine Group, ein Kreis von Ökonomen und Unternehmern unter der Führung von Mario Draghi und Patrick Collison, der sich seit August 2026 für eine stärkere europäische Wettbewerbsfähigkeit einsetzt, betreibt ihre Website auf der US-Plattform Webflow, ausgeliefert über das US-Unternehmen Cloudflare. Das ist kein Vorwurf. Für eine kleine Website ist das eine vernünftige Wahl. Es zeigt aber, dass Abhängigkeit meist nicht durch eine Entscheidung entsteht. Sie entsteht durch eine Voreinstellung, die niemand hinterfragt hat.

Bei einer Website spielt das kaum eine Rolle. Bei Buchhaltung, Produktion, Kundendaten oder den Identitäten der Mitarbeitenden schon.

Vier Risiken, die aus der Abhängigkeit folgen

1. Rechtsraum. Entscheidend ist der Sitz des Anbieters, nicht der Standort des Rechenzentrums. Der US-amerikanische CLOUD Act (18 U.S.C. § 2713) legt fest: Verlangt eine US-Behörde auf gesetzlicher Grundlage Daten, muss der Cloud-Anbieter sie sichern oder herausgeben, wenn sie sich in seinem „Besitz, Gewahrsam oder unter seiner Kontrolle“ befinden, und zwar unabhängig davon, ob sie in den USA oder außerhalb gespeichert sind. Die europäische Datenverordnung (Data Act, Art. 32) verpflichtet Anbieter dagegen, den Zugriff von Regierungen aus Drittstaaten auf in der EU gespeicherte nicht-personenbezogene Daten zu verhindern, wenn er gegen Unionsrecht oder nationales Recht verstoßen würde. Ein Anbieter mit Sitz in den USA kann so zwischen zwei Rechtsordnungen geraten. Ein Unternehmen, das seinen Dienst nutzt, sollte wissen, welche Daten es damit preisgibt.

2. Konzentration. Wenn Rechenleistung, Speicher, Identitätsverwaltung und E-Mail an einem einzigen Anbieter hängen, trifft dessen Ausfall oder Fehler alles gleichzeitig. Dasselbe gilt, wenn der Anbieter einen Dienst einstellt oder so verändert, dass er nicht mehr passt.

3. Preis und Bedingungen. Preise und Lizenzbedingungen ändert der Anbieter, nicht der Kunde. Je tiefer die Integration, desto schwächer die Verhandlungsposition bei der Vertragsverlängerung.

4. Kosten und Dauer des Ausstiegs. Ein Ausstieg kostet Geld (Datenübertragung, Parallelbetrieb zweier Umgebungen, Arbeitszeit) und Zeit. Am teuersten sind meist proprietäre verwaltete Dienste, an die Automatisierung und Anwendungslogik angebunden sind. Daten sind in Tagen übertragen, das Umschreiben von Integrationen dauert Monate.

Was sich an den Regeln geändert hat

Seit dem 12. September 2025 gilt die europäische Datenverordnung, und ihr Kapitel VI verankert das Recht des Kunden, zu einem anderen Cloud-Anbieter oder zurück in die eigene Infrastruktur zu wechseln. Der Vertrag muss Folgendes enthalten:

• eine Kündigungsfrist für die Einleitung des Wechsels von höchstens zwei Monaten (Art. 25 Abs. 2 Buchst. d),
• einen Übergangszeitraum von höchstens 30 Kalendertagen, in dem der Anbieter den Dienst weiter erbringt, beim Wechsel hilft und die Datensicherheit gewährleistet (Art. 25 Abs. 2 Buchst. a),
• mindestens 30 Tage für den Abruf der Daten nach Ende des Übergangszeitraums (Art. 25 Abs. 2 Buchst. g),
• die Pflicht des Anbieters, die Ausstiegsstrategie des Kunden zu unterstützen, auch durch Bereitstellung aller relevanten Informationen (Art. 25 Abs. 2 Buchst. b).

Bis zum 12. Januar 2027 darf der Anbieter Wechselentgelte nur in Höhe der Kosten verlangen, die unmittelbar mit dem Wechsel zusammenhängen. Ab dem 12. Januar 2027 darf er gar keine mehr verlangen (Art. 29). Eine Ausnahme gilt für Dienste, die für einen einzelnen Kunden maßgeschneidert sind und die der Anbieter nicht in seinem regulären Katalog anbietet (Art. 31).

Für den Finanzsektor gilt zusätzlich die DORA-Verordnung. Nach Art. 28 Abs. 8 müssen Finanzunternehmen für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, Ausstiegsstrategien haben. Die Ausstiegspläne müssen umfassend, dokumentiert und ausreichend getestet sein und regelmäßig überprüft werden. Ein Unternehmen muss den Vertrag beenden können, ohne den Betrieb zu stören, ohne die Einhaltung regulatorischer Pflichten einzuschränken und ohne die Kontinuität der Dienste für seine Kunden zu beeinträchtigen.

Die Datenverordnung beseitigt also die vertraglichen Hindernisse für einen Ausstieg. Die technischen überlässt sie dem Kunden. Die Frist von 30 Tagen hilft nur einem Unternehmen, das weiß, was es überträgt, und das ein Ziel hat.

Wie Sie Ihre Abhängigkeit erfassen

Eine Bestandsaufnahme muss kein großes Projekt sein. Es genügt eine Tabelle, in der jedes System, auf dem das Unternehmen betrieblich aufbaut, eine Antwort auf sechs Fragen hat:

• Wo die Daten liegen und wer der Anbieter ist. Sowohl der Standort des Rechenzentrums als auch der Sitz des Anbieters und seiner Muttergesellschaft, wegen des Rechtsraums.
• Was Standard ist und was proprietär. Proprietär ist ein Dienst, dessen Schnittstelle nur ein einziger Anbieter implementiert: Beim Ausstieg müssen Code und Automatisierung, die damit arbeiten, neu geschrieben werden. Typische Beispiele sind Serverless-Funktionen, Datenbanken mit eigener Abfrageschnittstelle oder Message Queues ohne Gegenstück anderswo. Kubernetes, PostgreSQL oder Objektspeicher mit S3-Schnittstelle lassen sich dagegen mit kleinen Anpassungen übertragen.
• Wer die Schlüssel hält. Liegen die Verschlüsselungsschlüssel beim Anbieter oder in eigener Verwaltung? Wer verwaltet die Identitäten und die Anmeldung der Mitarbeitenden?
• Was der Vertrag sagt. Kündigungsfrist, Unterstützung beim Ausstieg, Exportformat, Gebühren. Bei Verträgen, die vor der Datenverordnung geschlossen wurden, prüfen Sie, was vom neuen Rahmen gilt.
• Was der Ausstieg kosten würde. Eine grobe Schätzung von Kosten und Zeit. Die Größenordnung genügt: Wochen oder Monate?
• Wer im Unternehmen Bescheid weiß. Ein System, das nur eine Person versteht, ist für sich schon eine Abhängigkeit.

Das Ergebnis ist kein Urteil „bleiben“ oder „gehen“. Das Ergebnis ist ein Überblick, welche Abhängigkeiten das Unternehmen bewusst eingeht und welche es bloß geerbt hat.

Ein Ausstiegsplan, der funktioniert

Ein Ausstiegsplan, den niemand ausprobiert hat, ist ein Dokument, kein Plan. Praktisch heißt das:

• Regelmäßiger Datenexport in offenen Formaten an einen Ort, der nicht demselben Anbieter gehört. Nicht einmalig vor dem Ausstieg, sondern laufend.
• Infrastruktur als Code. Eine Umgebung, die in Terraform, Helm-Charts oder Ansible beschrieben ist, lässt sich anderswo neu aufbauen. Eine in der Konsole zusammengeklickte Umgebung nicht.
• Portable Schichten, wo es sinnvoll ist. Setzen Sie einen proprietären Dienst dort ein, wo er echten Mehrwert bringt, und zwar bewusst. Wo eine Standardlösung genügt, wählen Sie sie.
• Schlüssel und Identitäten außerhalb des Anwendungsanbieters, soweit machbar. Wer die Anmeldung kontrolliert, kontrolliert den Zugriff auf die Daten.
• Eine Ausstiegsprobe. Stellen Sie von Zeit zu Zeit ein ausgewähltes System aus Backups und Exporten in einer anderen Umgebung wieder her. Messen Sie, wie lange es gedauert hat und was gefehlt hat. Das ist die einzige Zahl, die etwas über einen Ausstiegsplan aussagt.

Was daraus nicht folgt

Daraus folgt nicht, dass Unternehmen US-Anbieter massenhaft verlassen sollten. Manche Abhängigkeiten sind rational, und ihr Nutzen überwiegt das Risiko. Daraus folgt nur, dass Abhängigkeit ein Posten im Risikoregister ist wie jeder andere. Sie braucht einen Verantwortlichen, eine Schätzung der Auswirkungen und ein getestetes Vorgehen für den Fall, dass sich die Bedingungen ändern.