This article is also available in English

Dieser Artikel ist Teil einer Reihe.

  • Teil 1: Digitale Souveränität – Ein Definitionsversuch
  • Teil 2: CIO-Fragestellungen zur digitalen Souveränität
  • Teil 3: Digitale Souveränität: Warum die Architektur zählt und wie Sie Ihr Unternehmen resilient machen
  • Teil 4: EU-Datenverordnung: Der Anfang vom Ende der Cloud-Monokultur? (dieser Artikel)
  • Teil 5: Dateninventare im EU Data Act: Die Demokratisierung der IoT-Geräte

Das nächste Thema, welches die Gemüter erhitzen dürfte, ist die EU-Datenverordnung (Verordnung (EU) 2023/2854, auch EU Data Act)[1]. Er wird strategische Bedeutung für europäische Unternehmen haben – und für alle, die in Europa wirtschaften wollen.

Wer 2025 Cloud-Infrastruktur in Europa betreibt, sitzt in der Regel auf amerikanischem Fundament. AWS, Azure (Microsoft) und Google Cloud kontrollieren große Teile der europäischen Unternehmens-IT – tief integriert, teils bewusst in Kauf genommen, teils zunehmend als Risiko erkannt.[2] Ein Anbieterwechsel ist technisch aufwändig, teuer oder schlicht unrealistisch.

Genau hier setzen jene Teile der EU-Datenverordnung an, die wir uns näher anschauen wollen: der Kampf gegen Cloud-Lock-ins und strukturelle Abhängigkeit von US-Hyperscalern.

Vorweg: Ja, es wird reguliert. Ja, es wird Aufwand bedeuten – vor allem für die Großen. Aber darum soll es hier nicht gehen. Uns interessiert: Was könnte der Data Act positiv verändern – die negativen Seiten werden wahrscheinlich mit reichlich Flaschendeckelvergleichen auf LinkedIn besprochen.

Von Föderation zu Konzentration: Was schiefgelaufen ist

Die ursprüngliche Erwartung des Internets war ein Netzwerk vieler Rechner, betrieben von vielen Akteuren – technisch dezentral, offen, föderiert. Unternehmen setzten tatsächlich eine Zeit lang auf eigene Infrastruktur, betrieben Rechenzentren, Server und Netzwerke selbst – nicht aus Überzeugung, sondern weil es keine echte Alternative gab. Erst mit dem Aufstieg der Hyperscaler und ihren attraktiven Komplettangeboten verlagerte sich der Fokus: weniger Betrieb, mehr Fachlichkeit.

Heute ist die Public Cloud der Standard – nicht nur, weil sie den Betrieb vereinfacht, sondern weil ihre Angebote für Startups ebenso attraktiv sind wie für große Unternehmen: zum Start günstig, skalierbar, sofort verfügbar. Die Kosten sind oft minutiös aufgeschlüsselt – aber trotzdem selten intuitiv vorhersehbar. Kaum jemand baut heute freiwillig alles selbst – oft auch, weil das Know-how dafür fehlt.

Der Preis der Bequemlichkeit

Im europäischen Cloud-Markt dominieren heute im Wesentlichen drei US-Anbieter: AWS, Azure und Google Cloud. Viele Unternehmen nutzen deren Angebote seit Jahren, weil sie leistungsfähig, schnell verfügbar und gut integriert sind. Vendor-Lock-in wurde dabei oft bewusst in Kauf genommen.

Auch wenn zu Beginn auf offene Standards oder bekannte Open-Source-Produkte gesetzt wurde, schleichen sich über die Zeit proprietäre Dienste ein. Services wie AWS Lambda, Googles BigQuery oder Azure App Services sind bequem – aber schwer zu ersetzen, sobald sie Teil der Systemarchitektur sind. Ein Wechsel ist technisch möglich, aber selten realistisch, da aufwändig und vom Aufwand schwer abschätzbar.

Und selbst bei Diensten wie Amazon S3, das oft als portabel gilt, weil es zahlreiche S3-kompatible Nachimplementierungen gibt, entsteht Abhängigkeit auf einem anderen Weg: über das Preismodell. Wer große Datenmengen abziehen will, zahlt hohe Egress-Kosten. Das allein reicht in vielen Fällen, um den Wechsel wirtschaftlich unattraktiv zu machen[3].

Von Lock-in zu Exit-ready – regulatorisch verpflichtend

Genau an diesem Punkt greift die EU-Datenverordnung ein. Ziel ist es unter anderem, strukturelle Abhängigkeiten von einzelnen Cloud-Anbietern abzubauen – über verbindliche Rahmenbedingungen, deren Einhaltung auch durch Sanktionen durchgesetzt wird[4]. Die Verordnung schreibt vor, dass Anbieter Interoperabilität sicherstellen müssen und technische Hürden für einen Wechsel aktiv beseitigen sollen.

Lock-in durch proprietäre Formate, inkompatible APIs oder absichtlich unklare Migrationspfade sollen damit nicht mehr möglich sein – jedenfalls nicht legal. Bestehende Hindernisse müssen laut Artikel 23 nachgebessert werden[5]

Mehr noch: Wenn die technischen Voraussetzungen für eine Migration gegeben sind, müssen Anbieter die Wechselkosten gering halten – und ab dem 12. Januar 2027 sogar vollständig darauf verzichten[6].

Für viele Entscheider:innen dürfte das genau zur richtigen Zeit kommen. Mit der neuen US-Regierung machte sich zu Beginn eine spürbare Unruhe breit – die oft völlige Abhängigkeit von US-Hyperscalern wurde plötzlich als echtes Risiko wahrgenommen.

Wahrscheinlich sind auch 2027 nicht alle APIs portabel, nicht alle Systeme austauschbar. Aber wer heute neue Services einführt, sollte sich fragen: Wie tief ist diese Lösung mit proprietären Mechanismen der Plattform verknüpft? Gibt es realistische Migrationspfade? Die Datenverordnung verpflichtet zwar künftig zur Interoperabilität – aber wie viel davon später nutzbar ist, hängt maßgeblich von den Architekturentscheidungen ab, die heute getroffen werden.

Wenn Infrastruktur beweglich wird – entstehen neue Spielräume

Mittelfristig bis langfristig könnten die neuen Vorgaben besonders für regulierte Unternehmen zum echten Vorteil werden. Finanzaufsichten verlangen seit Jahren, dass Exit-Szenarien technisch und organisatorisch vorbereitet sind.[7] Bisher war das schwer umzusetzen – unter anderem, weil viele technische Voraussetzungen auf Seiten der Anbieter schlicht fehlten. Die EU-Datenverordnung schafft hier Klarheit: Anbieter werden verpflichtet, den Wechsel ihrer Kunden technisch zu ermöglichen und wirtschaftlich tragbar zu gestalten. Für CTOs bedeutet das: Wo Wechsel technisch möglich werden, rücken Exit-Fähigkeit und standardisierte Schnittstellen wieder in den Fokus – auch als Architektur-Entscheidung, nicht nur als langfristige Theorie.

Auch Multi-Cloud-Strategien könnten dadurch realistischer werden. Was heute oft an Schnittstellen, Inkompatibilitäten oder fehlender Portabilität scheitert, dürfte in Zukunft leichter lösbar sein. Für POs bedeutet das: Anbieterwechsel oder hybride Deployments könnten in Zukunft nicht nur technisch machbar sein – sondern auch roadmap-fähig.

Und wer jetzt selbst vor der Aufgabe steht, Data-Act-Anforderungen umzusetzen, sollte das nicht nur als Compliance-Projekt sehen. Es lohnt sich, die technischen Grundlagen zu nutzen, um intern sinnvolle Datenprodukte zu bauen – ein echter Mehrwert, nicht nur auf dem Papier.

Das betrifft auch Governance-Strukturen: Wenn Anbieterwechsel zukünftig nicht nur erlaubt, sondern durchsetzbar sind, müssen Ausschreibungen, Vertragslaufzeiten und Exit-Regeln neu gedacht werden – auch auf CIO-Ebene.

Vielleicht sorgt die EU-Datenverordnung am Ende nicht nur für weniger Lock-in, sondern auch dafür, dass europäische Cloud-Anbieter wie IONOS, OHVcloud oder Open Telecom Cloud endlich mehr sind als nette Alternativen in Fußnoten, da ein Wechsel einfacher geworden ist.

Viele technische Details des Data Acts sind noch offen. Was genau gilt als „Rohdaten“? Wer entscheidet, ob ein Anbieter technisch wirklich wechselbar ist – oder nicht? Auch das deutsche Durchführungsgesetz existiert bislang nur als Referentenentwurf der vorherigen Regierung. Einige Vorgaben greifen erst 2027, andere warten noch auf Präzisierung. Aber: wer jetzt wartet, verpasst die Chance, Systeme so zu gestalten, dass spätere Handlungsfähigkeit möglich ist – ohne panische Umbauten.

tl;dr – Was gilt, was kommt, was zu tun ist

Kostentreiber identifizieren und Alternativen prüfen.

Viele Cloud-Dienste sind über die Jahre zu festen Bestandteilen der Systemlandschaft geworden – oft aus wirtschaftlicher und technischer Vernunft, bislang jedoch kaum mit Blick auf Wechselbarkeit, weil ein Anbieterwechsel in der Praxis zu viele Hürden hatte. Jetzt ist ein sinnvoller Zeitpunkt, große Abhängigkeiten und Kostenpunkte sichtbar zu machen und zu bewerten, ob sich mittelfristig Alternativen lohnen könnten. Die Datenverordnung schafft erstmals einen regulatorischen Rahmen, der solche Überlegungen realistisch macht.

Cloud-Verträge auf Wechselhürden prüfen.

Viele bestehende Verträge enthalten Klauseln, die einen späteren Anbieterwechsel erschweren – etwa eingeschränkten Datenzugang, unklare Exit-Regelungen oder die ausschließliche Nutzung proprietärer Formate. Die Datenverordnung stärkt die Position von Kunden und schafft absehbar mehr Durchsetzungskraft, wenn solche Hürden den Wechsel faktisch verhindern.[8]

Wichtige Termine:

  • 2. Januar 2024: Inkrafttreten der EU Datenverordnung / Verordnung (EU) 2023/2854
  • 12. September 2025
    • die EU-Datenverordnung gilt offiziell
    • Kapitel IV[9] regelt missbräuchliche Vertragsklauseln beim Datenzugang und der Datennutzung zwischen Unternehmen – diese Vorgaben gelten ab sofort für alle neuen Verträge.
    • Kapitel III[10] beschreibt die Pflichten von Dateninhabern, wenn sie laut Unionsrecht zur Bereitstellung von Daten verpflichtet sind – relevant ab jetzt für alle neuen Gesetze, die solche Pflichten enthalten.
  • 12. September 2026: Alle vernetzten Produkte und die dazugehörigen Dienste müssen die Vorgaben aus Artikel 3 Absatz 2[11] erfüllen. Das heißt: Nutzerinnen und Nutzer müssen vor Vertragsabschluss klar darüber informiert werden, welche Daten erzeugt werden können – inklusive Art, Format, Umfang, Echtzeitfähigkeit, Speicherort und -dauer, Zugriffsrechte, Löschmöglichkeiten sowie über die dafür vorgesehenen technischen Mittel und Nutzungsbedingungen.
  • 12. September 2027: Kapitel IV[12] gilt auch für bestehende Verträge, die am oder vor dem 12. September 2025 abgeschlossen wurden – wenn sie unbefristet sind oder mindestens bis zum 11. Januar 2034 laufen.
  1. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L_202302854  ↩

  2. https://www.security–insider.de/us–zugriff–europaeische–cloud–daten–microsoft–digitale–souveraenitaet–a–0e0d349084423354aa06e191f535cbe4/ bzw. https://www.google.com/url?q=https://www.senat.fr/compte–rendu–commissions/20250609/cecommandepublique.html&sa=D&source=docs&ust=1753887314367675&usg=AOvVaw3uSOhHUIwBJSI3k_eSd2gp  ↩

  3. https://assets.publishing.service.gov.uk/media/67976c3acbd1e3a508a22c74/AppendixQ2.pdf  ↩

  4. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#art40  ↩

  5. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#art23  ↩

  6. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#art29  ↩

  7. siehe z.B. BaFin  ↩

  8. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#art50  ↩

  9. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#cptIV  ↩

  10. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#cptIII  ↩

  11. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#art3  ↩

  12. https://eur–lex.europa.eu/legal–content/DE/TXT/HTML/?uri=OJ:L202302854#cptIV  ↩