Der Ausgang aus der Wolke: Warum dir die Daten deiner Maschinen gehören, was eine Cloud-Migration ab Januar kosten darf – und weshalb das eine juristische Frage mit sehr technischen Konsequenzen ist

Der Aufhänger: Die Rechnung, die den Umzug verhindert

Stell dir eine Situation vor, die in den letzten fünfzehn Jahren in europäischen Unternehmen tausendfach vorgekommen ist. Ein mittelständisches Unternehmen betreibt seine Datenplattform bei einem großen Hyperscaler. Die Verträge laufen, die Kosten steigen langsam, aber stetig, und irgendwann legt jemand eine Rechnung vor: Bei einem anderen Anbieter wäre derselbe Workload spürbar günstiger. Also beginnt die Prüfung eines Umzugs. Und dann kommt der Moment, in dem jemand im Architekturteam die Zahl ausrechnet, die alles kippt: die Kosten für den Datenabfluss. Achtzig Terabyte Data Lake auszuleiten kostet, je nach Tarif und Region, einen fünfstelligen Betrag – nur dafür, dass die eigenen Daten das Rechenzentrum verlassen dürfen, in dem sie liegen. Dazu kommt, dass ein Teil der Anwendungen auf proprietären, verwalteten Diensten aufsetzt, für die es beim Ziel kein Gegenstück gibt. Die Migration wäre nicht nur teuer, sondern auch ein Umbau. Das Projekt wird vertagt. Für immer.

Dieses Muster hat einen Namen: Vendor Lock-in. Ökonomisch betrachtet ist es eine Wechselkostenbarriere, und Wechselkostenbarrieren sind für einen Markt das, was Reibung für ein mechanisches System ist. Sie sorgen dafür, dass eine einmal getroffene Entscheidung länger Bestand hat, als sie es verdient. Wenn genug Kunden festhängen, verliert der Preiswettbewerb seine disziplinierende Wirkung – nicht weil der Anbieter gut wäre, sondern weil das Weggehen teurer ist als das Bleiben.

Die Europäische Union hat auf dieses Muster mit einer Verordnung geantwortet, die deutlich weniger Aufmerksamkeit bekommen hat als die DSGVO oder der AI Act, die aber in ihrer praktischen Wirkung auf die IT-Landschaft eines Unternehmens womöglich einschneidender ist: dem Data Act, formal der Verordnung (EU) 2023/2854 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung. Sie wurde am 22. Dezember 2023 im Amtsblatt veröffentlicht, trat am 11. Januar 2024 in Kraft und gilt seit dem 12. September 2025.

Zwei Daten machen diesen Text gerade jetzt aktuell. Das erste liegt elf Tage zurück: Seit dem 12. September 2026 gilt für alle neu in Verkehr gebrachten vernetzten Produkte die Pflicht zum Access by Design – Maschinen müssen so konstruiert sein, dass ihre Nutzer an die Daten kommen, die sie selbst erzeugen. Das zweite liegt knapp vier Monate voraus: Ab dem 12. Januar 2027 darf ein Cloud-Anbieter für den Wechsel zu einem Konkurrenten oder zurück ins eigene Rechenzentrum gar nichts mehr verlangen. Keine Egress-Gebühr, kein Migrationsentgelt, nichts.

Der Data Act ist damit einer der seltenen Fälle, in denen ein Gesetzgeber nicht ein Verhalten verbietet, sondern eine Marktreibung abschafft. Er ist Wirtschaftsrecht, das wie Systemarchitektur gedacht ist. Dieser Artikel führt durch die gesamte Verordnung: durch die Logik des Datenzugangs bei vernetzten Produkten, durch die Grenzen, die Geschäftsgeheimnisse und Sicherheitsanforderungen setzen, durch das Wechselregime für Cloud- und Edge-Dienste mit all seinen Fristen, durch den Schutz vor Drittstaatenzugriffen, durch die deutsche Durchsetzungsarchitektur – und schließlich durch die Frage, was von alldem nach dem Digital Omnibus übrig bleiben wird.

Teil 1: Das Kernkonzept – Daten als Ko-Produkt

Wem gehört ein Sensorwert?

Die juristisch interessanteste Eigenschaft von Daten ist, dass an ihnen kein Eigentum besteht. Das klingt banal, hat aber enorme Folgen. Ein Sachgegenstand hat einen Eigentümer; ein Text hat einen Urheber; eine Erfindung hat einen Patentinhaber. Ein Temperaturmesswert aus einem Kühlaggregat hat nichts davon. Er ist kein Werk, keine Erfindung, keine Sache. Er ist schlicht eine Tatsache, und Tatsachen kann man rechtlich nicht besitzen.

In der Praxis führte das über Jahre zu einer einfachen Regel: Wer die Daten tatsächlich hat, entscheidet über sie. Nicht kraft Eigentums, sondern kraft technischer Kontrolle. Der Hersteller einer Landmaschine, eines Aufzugs, einer Werkzeugmaschine oder eines vernetzten Fahrzeugs baute die Sensoren ein, betrieb die Telemetrie-Pipeline, speicherte die Daten in seiner Cloud – und konnte in den Vertragsbedingungen bestimmen, was der Kunde davon zu sehen bekommt. Häufig war das: eine Weboberfläche, ein Dashboard, ein paar PDF-Berichte. Was der Kunde nicht bekam, war der Rohdatenstrom in maschinenlesbarer Form. Und ohne diesen Rohdatenstrom konnte er keinen unabhängigen Wartungsdienstleister beauftragen, der Predictive Maintenance macht, keine eigene Flottenanalyse bauen, keinen Versicherer mit nutzungsbasierten Tarifen bedienen.

Der Data Act setzt hier an, und er tut es mit einem begrifflichen Trick, der die ganze Konstruktion trägt: Er spricht von ko-generierten Daten. Ein Sensorwert entsteht weder allein durch das Gerät noch allein durch den Nutzer, sondern durch die Benutzung des Geräts durch den Nutzer. Der Hersteller hat die Messfähigkeit gebaut; der Nutzer hat das Ereignis verursacht, das gemessen wurde. Aus dieser Doppelurheberschaft leitet die Verordnung keinen Eigentumsanspruch ab, sondern etwas Pragmatischeres: ein Zugangsrecht. Der Nutzer bekommt kein Recht an den Daten, aber ein Recht auf die Daten.

Das ist ein Muster, das man in der europäischen Digitalregulierung immer wieder findet. Statt neue Eigentumsrechte zu schaffen – juristisch heikel, dogmatisch umstritten, praktisch schwer abzugrenzen –, schafft der Gesetzgeber Zugangs-, Portabilitäts- und Wechselrechte. Dasselbe Prinzip trägt Artikel 20 DSGVO (Datenübertragbarkeit), die Interoperabilitätspflichten des Digital Markets Act und, wie wir sehen werden, das gesamte Kapitel VI des Data Act.

Die vier Rollen

Um mit der Verordnung arbeiten zu können, muss man vier Rollen sauber trennen. Sie sind der Grund, warum viele Projekte bei der Data-Act-Analyse ins Stolpern geraten.

Wichtig ist: Diese Rollen sind vertraglich determiniert, nicht technisch. Wer Dateninhaber ist, ergibt sich aus dem Vertragsgeflecht rund um das Produkt und den verbundenen Dienst – nicht daraus, auf wessen Servern die Daten zufällig liegen. In der Praxis können mehrere Dateninhaber nebeneinander existieren: der Hersteller des vernetzten Kühlschranks und der Anbieter der App, die dessen Temperatur regelt, sind beide Dateninhaber, während es nur einen Nutzer gibt.

Was in den Anwendungsbereich fällt – und was nicht

Kapitel II erfasst alle Roh- und vorverarbeiteten Daten, die bei der Nutzung eines vernetzten Produkts oder verbundenen Dienstes entstehen und dem Dateninhaber ohne unverhältnismäßigen Aufwand verfügbar sind – einschließlich der relevanten Metadaten, die nötig sind, um die Daten zu interpretieren. Personenbezogene wie nicht personenbezogene Daten sind erfasst.

Nicht erfasst sind abgeleitete und angereicherte Daten. Das ist die zentrale Grenze und zugleich die größte Auslegungsbaustelle der Verordnung. Der Rohmesswert eines Beschleunigungssensors ist erfasst. Der daraus per Modell berechnete Verschleißindex, in den das Ingenieurswissen des Herstellers eingeflossen ist, ist es nicht. Die Kommission illustriert die Grenze mit einem eingängigen Beispiel: Wenn jemand auf einem vernetzten Fernseher einen Film schaut, ist der Film selbst nicht erfasst – die Daten zur Bildschirmhelligkeit sehr wohl.

Für jeden, der Systeme baut, ist das die entscheidende Designfrage: Wo genau verläuft in meiner Pipeline die Linie zwischen „vorverarbeitet" und „abgeleitet"? Ein Median-Filter über einem Sensorsignal ist Vorverarbeitung. Ein trainiertes Modell, das aus zwanzig Signalen eine Restlebensdauer schätzt, ist Ableitung. Dazwischen liegt eine breite Grauzone – Aggregationen, Resampling, Kalibrierungen, Einheitenkonversionen –, in der die Einordnung von der konkreten Ausgestaltung abhängt und in der sich die Rechtsprechung der nächsten Jahre abspielen wird.

Teil 2: Kapitel II in der Praxis – Access by Design

Die Stichtagslogik

Kapitel II hat eine gestaffelte Anwendung, die man sauber auseinanderhalten muss, weil sie in der Praxis ständig verwechselt wird.

Seit dem 12. September 2025 gelten die Zugangs- und Bereitstellungspflichten grundsätzlich – auch für Bestandsprodukte, die bereits im Feld sind. Wer ein vernetztes Produkt betreibt, kann Zugang zu den anfallenden Daten verlangen; der Dateninhaber muss sie unverzüglich, in derselben Qualität wie ihm selbst verfügbar, einfach, sicher, unentgeltlich, in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format bereitstellen. Für Bestandsflotten bedeutet das in vielen Fällen: Ein Bereitstellungsweg muss geschaffen werden, notfalls über eine API oder einen Exportmechanismus.

Seit dem 12. September 2026 – also seit elf Tagen – kommt die schärfere Pflicht hinzu, die in der Literatur Access by Design heißt. Artikel 3 Absatz 1 verlangt, dass vernetzte Produkte, die nach diesem Stichtag in Verkehr gebracht werden, so konstruiert und hergestellt und verbundene Dienste so gestaltet und erbracht werden, dass die Produktdaten standardmäßig einfach, sicher und unentgeltlich zugänglich sind – und, soweit relevant und technisch machbar, direkt zugänglich. „Direkt" heißt: nicht über den Umweg der Herstellercloud, sondern am Gerät selbst, über eine lokale Schnittstelle.

Der Unterschied zwischen diesen beiden Stufen ist der Unterschied zwischen einer Nachrüstpflicht und einer Konstruktionspflicht. Die erste lässt sich mit einem Exportendpunkt erledigen. Die zweite greift in die Produktentwicklung ein: Wer heute ein vernetztes Gerät spezifiziert, muss im Lastenheft beantworten, welche Daten anfallen, wie sie strukturiert sind, über welche Schnittstelle der Nutzer sie abruft, wie dabei authentifiziert wird und wie die Schnittstelle abgesichert ist. Man wartet nicht mehr, bis ein Kunde fragt.

Wer das mit der Brille eines Security-Architekten liest, sieht sofort das Spannungsfeld: Eine verpflichtende, lokal erreichbare Datenschnittstelle an jedem Gerät ist eine neue Angriffsfläche. Genau hier verzahnt sich der Data Act mit dem Cyber Resilience Act, der für dieselbe Geräteklasse Sicherheitsanforderungen über den gesamten Lebenszyklus vorschreibt (siehe Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts). Die beiden Verordnungen bearbeiten dasselbe Gerät aus zwei Richtungen: Der Data Act verlangt, dass Daten herauskommen; der CRA verlangt, dass nichts Falsches hineinkommt. Ein Unternehmen, das beides getrennt behandelt, baut zwangsläufig widersprüchliche Anforderungen.

Informationspflichten vor dem Kauf

Der Data Act setzt schon vor dem Vertragsschluss an. Der Verkäufer oder Vermieter muss den Nutzer in klarer, verständlicher Form darüber informieren, welche Art von Daten das Produkt erzeugt, in welchem Volumen und mit welcher Frequenz, ob die Erzeugung kontinuierlich oder in Echtzeit erfolgt, wie die Daten gespeichert werden, ob der Hersteller selbst darauf zugreift und wie der Nutzer an sie herankommt.

Das ist mehr als Bürokratie. Es ist der Versuch, die Datenfrage aus dem Kleingedruckten in die Kaufentscheidung zu holen – nach demselben Muster, mit dem Energielabels den Stromverbrauch aus dem Datenblatt ins Regal geholt haben. Und es hat einen praktischen Nebeneffekt: Ein Unternehmen, das einkauft, kann Data-Act-Konformität ab sofort als Beschaffungskriterium formulieren. Für jeden, der Ausschreibungen schreibt, gehört ab jetzt eine Zeile zu Artikel 3 in den Kriterienkatalog.

Die Schranken: Geschäftsgeheimnis und Sicherheit

Zugangsrechte ohne Grenzen wären eine Enteignung des Ingenieurswissens. Die Verordnung zieht deshalb zwei Schranken.

Die erste sind Geschäftsgeheimnisse. Der Dateninhaber kann verlangen, dass Nutzer oder Dritter angemessene Vertraulichkeitsmaßnahmen vereinbaren; werden sie nicht eingehalten, darf er die Bereitstellung aussetzen. Eine vollständige Verweigerung ist nach der geltenden Fassung nur möglich, wenn er nachweist, dass ihm mit hoher Wahrscheinlichkeit ein schwerer wirtschaftlicher Schaden droht – eine hohe Hürde, die als Ausnahmefall konzipiert ist.

Die zweite ist die Sicherheit des Produkts. Wenn die Offenlegung bestimmter Daten die Sicherheitsanforderungen des Produkts unterlaufen und dadurch schwere Beeinträchtigungen für Gesundheit, Sicherheit oder Schutz von Personen entstehen könnten, dürfen Dateninhaber und Nutzer die Bereitstellung begrenzen. Diese Anforderungen müssen allerdings in Unionsrecht oder nationalem Recht verankert sein – es reicht nicht, dass der Hersteller sie für wichtig hält.

In beiden Fällen gilt eine Meldepflicht an die zuständige nationale Behörde, und der Nutzer kann die Entscheidung gerichtlich, bei der Behörde oder vor einer zertifizierten Streitbeilegungsstelle angreifen.

Die entscheidende Nutzungsschranke

Es gibt eine Begrenzung, die technisch unscheinbar wirkt und wettbewerbsrechtlich den größten Sprengstoff enthält: Die erlangten Daten dürfen nicht zur Entwicklung eines konkurrierenden vernetzten Produkts verwendet werden. Wettbewerb bei verbundenen Diensten und im Aftermarket – Wartung, Reparatur, Versicherung, Analytik – ist ausdrücklich erlaubt und sogar Zweck der Verordnung. Wettbewerb beim Produkt selbst nicht.

Diese Linie ist der Kompromiss, der das ganze Gebäude trägt. Ohne sie hätte kein Hersteller mehr einen Anreiz, Sensorik und Datenverarbeitung zu entwickeln, weil jeder Wettbewerber daraus lernen könnte. Mit ihr bleibt die Innovationsrendite beim Hersteller, während die Servicemärkte geöffnet werden. Ob die Grenze zwischen „konkurrierendes Produkt" und „Aftermarket-Dienst" in der Praxis so scharf ist, wie sie im Text klingt, ist offen – bei softwaredefinierten Produkten, deren Funktion durch Updates entsteht, wird sie zwangsläufig verschwimmen.

Schließlich: Der Dateninhaber darf nicht personenbezogene Daten, die durch das Produkt erzeugt werden, nicht ohne Zustimmung des Nutzers verwenden. Das ist eine bemerkenswerte Umkehrung. Für nicht personenbezogene Daten gab es bis dahin keine vergleichbare Schranke; sie entsteht hier allein aus der vertraglichen Beziehung zum Nutzer.

Teil 3: Kapitel III bis V – Der institutionelle Rahmen

Kapitel III: Wenn das Gesetz zur Datenteilung zwingt

Kapitel III regelt nicht, ob geteilt werden muss, sondern wie, wenn eine andere Norm – der Data Act selbst oder ein sektorales Gesetz – eine Bereitstellungspflicht anordnet. Der Maßstab sind faire, angemessene und nichtdiskriminierende Bedingungen (FRAND), ein Prinzip, das aus dem Standardessenzpatentrecht stammt.

Als Gegenleistung darf der Dateninhaber eine angemessene Vergütung verlangen, die die Kosten der Bereitstellung und die technischen Kosten für Verbreitung und Speicherung abdecken darf. Gegenüber Kleinstunternehmen, KMU und gemeinnützigen Forschungsorganisationen ist die Vergütung auf die reinen Bereitstellungskosten gedeckelt – eine bewusste Umverteilung zugunsten der kleineren Marktteilnehmer, die sich durch die gesamte Verordnung zieht.

Kapitel IV: Missbrauchskontrolle zwischen Unternehmen

Kapitel IV ist juristisch der radikalste Teil, weil er in die B2B-Vertragsfreiheit eingreift – ein Bereich, in dem das europäische Recht traditionell zurückhaltend ist. Der Anknüpfungspunkt ist die einseitig gestellte Klausel: eine Bedingung zu Datenzugang und Datennutzung, die eine Partei der anderen ohne echte Verhandlungsmöglichkeit auferlegt, das klassische take it or leave it.

Die Verordnung enthält eine nicht abschließende Liste von Klauseln, die stets missbräuchlich sind (etwa der Ausschluss der Haftung für Vorsatz und grobe Fahrlässigkeit), und eine Liste von Klauseln, die als missbräuchlich vermutet werden (etwa unangemessene Beschränkungen der Rechtsbehelfe bei Nichterfüllung). Eine missbräuchliche Klausel ist unwirksam und fällt, wo möglich, aus dem Vertrag heraus; bei der Vermutung kann der Verwender den Gegenbeweis führen.

Wer schon einmal Cloud-Rahmenverträge verhandelt hat, weiß, wie viel Gewicht dieser Abschnitt hat. Er bedeutet, dass die Standardbedingungen eines übermächtigen Anbieters nicht mehr allein deshalb gelten, weil sie unterschrieben wurden.

Kapitel V: Der Staat im Ausnahmefall

Kapitel V erlaubt öffentlichen Stellen, Daten privater Unternehmen anzufordern, wenn eine außergewöhnliche Notwendigkeit besteht. Die Verordnung unterscheidet zwei Szenarien: Im öffentlichen Notstand – Naturkatastrophe, Pandemie, schwerer Cybervorfall – dürfen vorrangig nicht personenbezogene Daten und, wenn das nicht ausreicht, auch personenbezogene Daten angefordert werden, die nach Möglichkeit zu anonymisieren sind. In Nicht-Notstandslagen dürfen ausschließlich nicht personenbezogene Daten angefordert werden, und nur, wenn die Stelle nachweist, dass sie die Daten nicht anderweitig beschaffen konnte.

Die Anforderungen müssen spezifisch, transparent und verhältnismäßig sein, Geschäftsgeheimnisse sind zu wahren, und die Daten sind nach Zweckerfüllung zu löschen. Ein elegantes Detail ist das Once-only-Prinzip: Dieselben Daten dürfen nicht mehrfach von verschiedenen Behörden angefordert werden, weshalb alle Anfragen vom nationalen Datenkoordinator veröffentlicht werden.

Die Vergütungslogik folgt wieder der Größenstaffelung:

Teil 4: Kapitel VI – Das Wechselregime, technisch gelesen

Für jeden, der Cloud-Architekturen baut oder verantwortet, ist Kapitel VI der Kern der Verordnung. Es umfasst die Artikel 23 bis 31 und richtet sich an Anbieter von Datenverarbeitungsdiensten – also Diensten, die allgegenwärtigen, bedarfsgesteuerten Netzzugang zu einem gemeinsam genutzten Pool konfigurierbarer, skalierbarer und elastischer Rechenressourcen ermöglichen. Diese Definition deckt IaaS, PaaS und SaaS ab.

Die Scope-Falle

Bevor man in die Pflichten einsteigt, lohnt die unangenehme Frage: Ist mein Dienst überhaupt ein Datenverarbeitungsdienst?

Bei virtuellen Maschinen und Objektspeichern ist das trivial zu bejahen. Bei einem fachlichen SaaS – einem Projektmanagementwerkzeug, einem CRM, einer branchenspezifischen Planungssoftware – ist es alles andere als klar. Solche Dienste beziehen ihren Wert aus der fachlichen Funktionalität, nicht daraus, dass sie dem Kunden Zugang zu Rechenressourcen verschaffen. Die herrschende Beratungspraxis empfiehlt deshalb eine Einzelfallprüfung je Dienst – und wer ein Portfolio aus dreißig SaaS-Produkten betreibt, hat damit eine Inventarisierungsaufgabe, die selten an einem Nachmittag erledigt ist.

Artikel 23: Das Hindernisverbot

Der Grundsatz steht in Artikel 23 und ist bewusst weit formuliert: Anbieter dürfen keine vorkommerziellen, kommerziellen, technischen, vertraglichen oder organisatorischen Hindernisse errichten oder aufrechterhalten, die Kunden daran hindern,

• den Vertrag zu beenden,
• einen Vertrag mit einem anderen Anbieter zu schließen,
• exportierbare Daten und digitale Vermögenswerte zu portieren,
• Funktionsäquivalenz beim Zielanbieter zu erreichen,
• einzelne Dienste aus einem Bündel herauszulösen.

Der letzte Punkt verdient Aufmerksamkeit. Das Entbündelungsgebot trifft eine der wirksamsten Bindungsstrategien überhaupt: das Paket, in dem der günstige Preis nur gilt, solange man alles zusammen bezieht.

Flankiert wird das Ganze von einer Pflicht zur Zusammenarbeit nach Treu und Glauben, die ausdrücklich beide Anbieter trifft – Quell- wie Zielanbieter. Das ist bemerkenswert, weil der Zielanbieter mit dem Kunden zum Zeitpunkt der Migration meist noch gar keinen vollwertigen Vertrag hat.

Artikel 25: Die Fristenmechanik

Der operativ wichtigste Artikel beschreibt einen Ablauf, den man am besten als Zustandsautomaten liest:

1. Kündigungs- bzw. Ankündigungsfrist: maximal zwei Monate. Der Vertrag darf keine längere Frist für die Einleitung des Wechsels vorsehen. Sie beginnt, wenn der Kunde den Wechselwunsch mitteilt.
2. Übergangsfrist: maximal 30 Kalendertage, beginnend mit dem Ende der Kündigungsfrist. In dieser Zeit muss der Anbieter angemessene Unterstützung leisten, die Geschäftskontinuität wahren, klar über Kontinuitätsrisiken informieren und ein hohes Sicherheitsniveau aufrechterhalten.
3. Ausnahme bei technischer Unmöglichkeit: Ist die 30-Tage-Frist technisch nicht machbar, muss der Anbieter den Kunden innerhalb von 14 Arbeitstagen informieren, dies ordnungsgemäß begründen und eine Alternativfrist von höchstens sieben Monaten benennen. Die Pflicht zur Service-Kontinuität bleibt bestehen.
4. Abruffrist: mindestens 30 Kalendertage nach dem Ende der Übergangsfrist, in denen der Kunde seine Daten noch abrufen kann.
5. Löschgarantie: Nach Ablauf der Abruffrist müssen alle exportierbaren Daten und digitalen Vermögenswerte des Kunden vollständig gelöscht werden.

Dazu kommt eine abschließende Spezifikation aller Kategorien von Daten und digitalen Vermögenswerten, die portiert werden können – ausdrücklich einschließlich derjenigen Kategorien, die wegen Geschäftsgeheimnisrisiken ausgenommen sind. Diese Liste gehört in den Vertrag, nicht in eine Wissensdatenbank.

Rechnet man den Worst Case durch, ergibt sich ein Fenster von zwei Monaten Ankündigung plus sieben Monaten Übergang plus einem Monat Abruf: zehn Monate. Das ist kein Sprint. Aber es ist ein definierter, einklagbarer, planbarer Zeitraum – und damit das Gegenteil dessen, was vorher galt.

Wer Exit-Strategien für regulierte Branchen schreibt, erkennt hier sofort die Verwandtschaft zu DORA, das für den Finanzsektor Ausstiegsstrategien, Vertragsmindestinhalte und Konzentrationsrisikoanalysen verlangt (siehe Wenn die IT nicht ausfallen darf: DORA und die digitale operationale Resilienz des Finanzsektors). DORA verlangt, dass ein Finanzinstitut einen Ausstieg planen kann; der Data Act sorgt dafür, dass der Ausstieg überhaupt möglich und bezahlbar ist. Die beiden Regelwerke greifen ineinander wie zwei Zahnräder.

Artikel 29: Das Ende der Wechselentgelte

Der finanziell folgenreichste Artikel hat eine zweistufige Mechanik:

Zwei Abgrenzungen sind entscheidend. Erstens: Wechselentgelte sind nicht dasselbe wie reguläre Nutzungsentgelte. Der laufende Preis für Speicher, Rechenleistung und Traffic im Normalbetrieb bleibt unberührt. Verboten wird der Aufschlag, der nur deshalb anfällt, weil der Kunde geht. Zweitens: Vertragsstrafen für vorzeitige Kündigung bei Festlaufzeiten sind davon zu unterscheiden und bleiben grundsätzlich möglich.

Die wirtschaftliche Wirkung dieser Regel ist erheblich, denn Egress-Gebühren waren nicht nur eine Einnahmequelle, sondern vor allem ein Preissignal, das jede Architekturentscheidung in Richtung „alles bleibt drin" verschoben hat. Wenn dieser Ausgangszoll entfällt, ändert sich die Kalkulation von Multi-Cloud-, Backup- und Archivstrategien grundlegend: Ein Zweitanbieter für kalte Daten oder eine geografisch verteilte Ablage mit Erasure Coding (siehe Elf Neunen: Erasure Coding, Reed-Solomon und wie die Cloud Daten praktisch unverlierbar macht) war bisher oft nicht an den Speicherkosten gescheitert, sondern am Transfer.

Artikel 30: Funktionsäquivalenz und offene Schnittstellen

Der technisch anspruchsvollste Teil differenziert nach Dienstmodell:

• IaaS-Anbieter müssen Maßnahmen ergreifen, damit ein Kunde beim Wechsel zu einem Dienst desselben Typs Funktionsäquivalenz erreicht: Auf dieselbe Eingabe hin soll er bei gemeinsamen Merkmalen ein materiell vergleichbares Ergebnis erhalten. Die Kommission nennt als Beispiel Werkzeuge, mit denen sich Rechenlasten von einer Virtualisierungstechnologie auf eine andere verschieben lassen.
• PaaS- und SaaS-Anbieter müssen offene Schnittstellen bereitstellen und die Daten mindestens in einem gängigen, maschinenlesbaren Format exportieren.

Der Unterschied ist ehrlich: Bei IaaS ist Äquivalenz ein realistisches Ziel, weil die Abstraktionsebene – Rechenkerne, Blockspeicher, Netzwerk – zwischen Anbietern grundsätzlich vergleichbar ist. Bei PaaS und SaaS ist sie es nicht. Eine verwaltete Datenbank mit proprietären Erweiterungen oder eine Workflow-Engine mit eigener Ausdruckssprache hat bei keinem anderen Anbieter ein funktionsgleiches Gegenstück. Deshalb verlangt die Verordnung dort nur die Datenherausgabe in offener Form – die Rekonstruktion der Funktionalität bleibt Aufgabe des Kunden.

Man kann das als Schwäche lesen. Ich bin der Meinung, dass es eher realistisch ist: Der Gesetzgeber verlangt, was technisch erzwingbar ist, und verzichtet auf das, was er nicht verordnen kann. Ein Gesetz, das Funktionsäquivalenz für jedes SaaS verlangte, wäre entweder unerfüllbar oder ein Innovationsverbot.

Hinzu kommen Transparenzpflichten nach Artikel 26 und 28: Anbieter müssen ein aktuelles Online-Register aller relevanten Datenstrukturen, Formate und Interoperabilitätsspezifikationen führen und offenlegen, welcher Jurisdiktion ihre IKT-Infrastruktur unterliegt und welche Maßnahmen sie gegen unrechtmäßigen ausländischen Behördenzugriff ergriffen haben.

Artikel 31: Ausnahmen

Ausgenommen sind vor allem Dienste, deren wesentliche Merkmale individuell für einen einzelnen Kunden maßgefertigt wurden und nicht in großem kommerziellem Maßstab angeboten werden. Auch diese Dienste bleiben allerdings an einen Teil der Pflichten aus Kapitel VI gebunden – die Ausnahme ist keine Freistellung.

Teil 5: Kapitel VII und VIII – Souveränität und Interoperabilität

Der Schutz vor unrechtmäßigem Drittstaatenzugriff

Kapitel VII adressiert ein Problem, das jeden beschäftigt, der europäische Daten in Systemen internationaler Anbieter speichert: Was passiert, wenn eine Behörde außerhalb der EU auf nicht personenbezogene Daten zugreifen will, die in der Union verarbeitet oder gespeichert werden?

Die Verordnung verbietet grenzüberschreitende Datenflüsse nicht. Sie stellt sicher, dass der in der EU geltende Schutz die Daten begleitet. Existiert kein internationales Abkommen, das den Zugriff regelt, darf übertragen oder zugegriffen werden nur unter spezifischen Bedingungen – die Entscheidung der Drittstaatsbehörde muss begründet und verhältnismäßig sein, das Rechtssystem des Drittstaats muss bestimmte Garantien aufweisen, und der Anbieter kann die zuständige nationale Stelle zur Bewertung einschalten. Anbieter müssen zudem alle angemessenen technischen, organisatorischen und rechtlichen Maßnahmen ergreifen – Verschlüsselung, Audits, Zertifizierungen –, um einen solchen Zugriff zu verhindern, und diese Maßnahmen veröffentlichen.

Dieses Kapitel ist die nicht personenbezogene Schwester der Debatte, die für personenbezogene Daten seit Jahren unter dem Namen Schrems geführt wird (siehe Der Mann, der drei Abkommen kippte: Max Schrems, der transatlantische Datentransfer und das Rätsel der Angemessenheit). Bemerkenswert ist der Perspektivwechsel: Während die DSGVO den Betroffenen schützt, schützt Kapitel VII das Unternehmen – und damit ein Interesse, das eher unter „wirtschaftliche Souveränität" als unter „Grundrechte" fällt.

Wer hier technisch vorsorgen will, landet schnell bei der Frage, wie man Daten so vorhält, dass ein Zugriff auf das System nicht automatisch ein Zugriff auf die Inhalte ist – kundenseitiges Schlüsselmanagement, Confidential Computing, Isolationsmodelle auf Hypervisor-Ebene (siehe Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas).

Interoperabilität

Kapitel VIII legt wesentliche Anforderungen für Teilnehmer an gemeinsamen europäischen Datenräumen fest: Beschreibungen von Datenstrukturen, Formaten und Vokabularen müssen öffentlich zugänglich sein, und die Interoperabilität von Datenteilungsvereinbarungen – etwa über Smart Contracts – ist sicherzustellen. Für Anbieter von Smart Contracts gibt es eigene Anforderungen: korrekte Ausführung der vereinbarten Bedingungen, Robustheit gegen Manipulation, Möglichkeit zur kontrollierten Beendigung.

Zugleich bereitet das Kapitel den Boden für harmonisierte Standards und offene Interoperabilitätsspezifikationen für Cloud-Dienste. Die Kommission kann europäische Normungsorganisationen mit der Erarbeitung beauftragen und, falls das scheitert, gemeinsame Spezifikationen als Auffanglösung erlassen. Ohne diese Standardisierungsschiene bliebe Artikel 30 ein Versprechen ohne Werkzeug.

Teil 6: Durchsetzung – und was der Digital Omnibus ändern will

Die deutsche Architektur

Die Durchsetzung liegt bei den Mitgliedstaaten. Jeder benennt eine oder mehrere zuständige Behörden; gibt es mehrere, muss eine davon als Datenkoordinator die zentrale Anlaufstelle sein.

Deutschland hat sich Zeit gelassen und im Frühjahr 2026 geliefert: Der Bundestag verabschiedete das Durchführungsgesetz am 26. März 2026; das Datenverordnung-Anwendungs- und -Durchsetzungs-Gesetz (DADG) trat am 30. Mai 2026 in Kraft. Es etabliert ein zweigleisiges Modell: Die Bundesnetzagentur ist die zuständige Behörde und der Datenkoordinator, während die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit für Fragen des Personenbezugs zuständig bleibt. Der Bußgeldrahmen der BNetzA reicht bis 500.000 Euro; greift die Datenschutzaufsicht in ihrer Zuständigkeit ein, gilt der DSGVO-Rahmen.

Der Vergleich lohnt: In Irland sind ComReg und die CCPC benannt, mit Sanktionen bis zu 4 % des EU-Jahresumsatzes für Unternehmen; in den Niederlanden kann die ACM Bußgelder bis 1.030.000 Euro oder 10 % des EU-weiten Jahresumsatzes verhängen, je nachdem, welcher Betrag höher ist. Artikel 40 verlangt lediglich Sanktionen, die „wirksam, verhältnismäßig und abschreckend" sind – eine unionsweite Obergrenze wie bei der DSGVO fehlt.

Das Ergebnis ist eine Durchsetzungslandschaft mit erheblichem Gefälle. Für Unternehmen mit europaweiter Präsenz bedeutet das, dass sich das Risiko nicht am mildesten Standort bemisst. Für die Regulierungstheorie ist es ein bekanntes Muster: Der Brüssel-Effekt wirkt über den Marktzugang, nicht über die Bußgeldhöhe.

Der Digital Omnibus

Am 19. November 2025 hat die Kommission im Rahmen ihres Vereinfachungspakets Digital Omnibus Änderungen am Data Act vorgeschlagen. Die für die Praxis wichtigsten:

• Geschäftsgeheimnisse: Die Verweigerungsmöglichkeit soll erleichtert werden. Der Zusatz „außergewöhnliche Umstände" soll entfallen, und der Wahrscheinlichkeitsmaßstab soll von „mit hoher Wahrscheinlichkeit" auf „wahrscheinlich" abgesenkt werden. Außerdem soll ausdrücklich verweigert werden dürfen, wenn ein hohes Risiko unrechtmäßiger Nutzung oder Offenlegung gegenüber Drittstaatenakteuren besteht.
• Maßgefertigte Dienste: Die Ausnahme vom Wechselregime soll für Verträge, die am oder vor dem 12. September 2025 geschlossen wurden, auf maßgefertigte Dienste außerhalb von IaaS ausgeweitet werden.
• KMU und kleine Midcaps: Für Nicht-IaaS-Dienste solcher Anbieter soll ein leichteres Regime gelten, inklusive der Möglichkeit, bei Festlaufzeitverträgen Vertragsstrafen für vorzeitige Beendigung vorzusehen.

Parallel hat die Kommission am selben Tag einen Entwurf für unverbindliche Standardvertragsklauseln (SCC) für Cloud-Verträge und Mustervertragsklauseln (MCT) für Datenzugang und -nutzung veröffentlicht – modulare Klauseln zu Wechsel und Exit, Kündigung, Sicherheit und Geschäftskontinuität, Haftung und Änderungsschutz.

Man sollte den Omnibus nüchtern lesen. Er ist weder eine Rücknahme noch eine bloße Redaktion. Er verschiebt eine Grenze: Die Verweigerung aus Geheimnisschutz wird von der Ausnahme zum verfügbaren Werkzeug. Ob dadurch der Zweck von Kapitel II ausgehöhlt wird, hängt vollständig davon ab, wie die Behörden den neuen Maßstab anwenden. Ich bin der Meinung, dass dies der Punkt ist, an dem sich die praktische Wirksamkeit des Data Act in den nächsten fünf Jahren entscheiden wird – mehr als an den Fristen des Kapitels VI, die technisch eindeutig und damit leicht zu prüfen sind.

Da es sich um einen Vorschlag handelt, der das ordentliche Gesetzgebungsverfahren noch durchlaufen muss, gilt bis auf Weiteres die geltende Fassung.

Teil 7: Ein Framework für die Praxis

Wer im Unternehmen für Architektur, Beschaffung oder Compliance verantwortlich ist, kann die Verordnung auf fünf Fragen herunterbrechen.

1. Rollenklärung. Bin ich bei diesem Produkt oder Dienst Nutzer, Dateninhaber, Dritter – oder mehreres gleichzeitig? Die Antwort steht im Vertrag, nicht im Systemdiagramm. Sie gehört in ein Inventar, das je Produktlinie und je Dienst geführt wird.

2. Datenklassifikation. Welche Datenströme sind roh oder vorverarbeitet (erfasst), welche abgeleitet (nicht erfasst)? Diese Grenze sollte im Datenmodell dokumentiert sein, nicht in einem Anwaltsgutachten – und sie sollte begründet sein, weil sie im Streitfall verteidigt werden muss.

3. Schnittstellenpflicht. Für vernetzte Produkte, die nach dem 12.09.2026 in Verkehr gebracht werden: Gibt es einen direkten, abgesicherten Zugangsweg? Ist er dokumentiert, authentifiziert, versioniert, und ist er gemeinsam mit den CRA-Anforderungen entworfen worden?

4. Exit-Fähigkeit. Kenne ich für jeden meiner Datenverarbeitungsdienste die Antwort auf: Welche Daten und digitalen Vermögenswerte sind exportierbar? In welchem Format? Über welche Schnittstelle? In welcher Zeit? Und – die Frage, die am seltensten gestellt wird – habe ich das jemals getestet?

5. Vertragsabgleich. Enthalten meine Cloud-Verträge die Pflichtinhalte des Artikels 25: Kündigungsfrist höchstens 2 Monate, Übergangsfrist höchstens 30 Tage, abschließende Datenkategorien, Abruffrist mindestens 30 Tage, Löschgarantie? Und ist die Entgeltklausel so formuliert, dass sie ab dem 12.01.2027 automatisch auf null geht?

Der vierte Punkt verdient eine Bemerkung, weil er der einzige ist, den keine Behörde für einen erledigt. Ein Exit-Plan, der nie ausgeführt wurde, ist ein Dokument, keine Fähigkeit. Die Verwandtschaft zum Wiederanlauftest nach einem Ausfall ist offensichtlich: Ein Backup, das nie zurückgespielt wurde, ist kein Backup. Der Data Act gibt einem ab Januar 2027 das Recht, ohne Ausgangszoll zu gehen. Ob man es ausüben kann, entscheidet nicht die Verordnung, sondern die eigene Architektur.

Erkenntnis zum Mitnehmen

Der Data Act ist in seinem Kern kein Datenschutzgesetz und kein Verbotsgesetz. Er ist ein Gesetz zur Reduktion von Wechselkosten – und damit ein Eingriff, der aus der Wettbewerbsökonomie kommt und in der Systemarchitektur ankommt.

Die praktische Erkenntnis lässt sich in einen Satz fassen: Wer heute ein System entwirft, entwirft immer auch dessen Ausgang. Bisher war der Ausgang ein Restrisiko, das man in den Anhang einer Risikoanalyse schrieb. Ab dem 12. Januar 2027 ist er ein einklagbares Kundenrecht mit definierten Fristen und einem Preis von null. Das verändert zwei Dinge gleichzeitig: Für Anbieter wird Portabilität von einem Verkaufsargument zu einer Pflicht; für Kunden wird die Frage „Wie komme ich hier wieder raus?" von einer theoretischen Übung zu einer, auf die es eine belastbare, getestete Antwort geben muss.

Der konkrete Handlungsanstoß ist deshalb klein und unbequem: Nimm dir in den nächsten Wochen einen einzigen produktiven Dienst und führe einen Exit-Probelauf durch. Nicht den ganzen Stack – einen Dienst. Exportiere die Daten über die offizielle Schnittstelle, miss die Dauer, protokolliere die Formate, versuche den Import beim Zielsystem und schreibe auf, woran es scheitert. Das Ergebnis dieses einen Nachmittags sagt mehr über die tatsächliche Wechselfähigkeit des Unternehmens aus als jede Vertragsprüfung. Und es liefert die Liste der Dinge, die bis Januar zu klären sind.

Reflexionsfrage

Der Data Act geht davon aus, dass Wechselkosten das zentrale Hindernis für Wettbewerb im Cloud-Markt sind, und beseitigt deshalb den Preis des Wechsels. Aber die eigentliche Bindung eines modernen Systems entsteht selten durch Egress-Gebühren – sie entsteht durch Abhängigkeit von proprietären verwalteten Diensten, durch das Wissen der Mitarbeiter, durch Integrationen, die über Jahre gewachsen sind, durch Zertifizierungen und Betriebsprozesse, die auf eine Plattform zugeschnitten sind.

Angenommen, dein Unternehmen betreibt eine Plattform, deren Migration technisch machbar, aber mit achtzehn Monaten Umbau verbunden wäre: Ändert die Abschaffung der Wechselentgelte dann tatsächlich etwas an deiner Verhandlungsposition – oder verschiebt sie das Lock-in nur von einer sichtbaren Rechnungsposition in eine unsichtbare Architekturentscheidung? Und wenn Letzteres zutrifft: Welche Entscheidung in deinem aktuellen Stack würdest du heute anders treffen, wenn du wüsstest, dass du sie in fünf Jahren rückgängig machen musst?

Querverweise im Vault

• Wenn die IT nicht ausfallen darf: DORA und die digitale operationale Resilienz des Finanzsektors – Ausstiegsstrategien, Vertragsmindestinhalte und Konzentrationsrisiko: DORA verlangt die Planbarkeit des Ausstiegs, der Data Act macht ihn bezahlbar.
• Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts – dieselbe Geräteklasse aus der Gegenrichtung: Der Data Act öffnet Schnittstellen, der CRA muss sie absichern.
• Der Mann, der drei Abkommen kippte: Max Schrems, der transatlantische Datentransfer und das Rätsel der Angemessenheit – die personenbezogene Schwester des Kapitels VII über unrechtmäßigen Drittstaatenzugriff.
• Die Pyramide des Risikos: Wie der EU AI Act künstliche Intelligenz bändigt – und warum das die ganze Welt betrifft – das Schwesterregelwerk der europäischen Digitalgesetzgebung, ebenfalls vom Digital Omnibus erfasst.
• Der Algorithmus als Richter: Artikel 22 DSGVO, das SCHUFA-Urteil und das Recht auf eine menschliche Entscheidung – die Schnittstelle zwischen Data Act und DSGVO, wo ko-generierte Daten personenbezogen sind.
• Der Ausweis, der schweigt: eIDAS 2.0, die EU-Identitäts-Wallet und die Kunst, nur das Nötigste preiszugeben – dasselbe regulatorische Grundmuster: Zugangs- und Portabilitätsrechte statt neuer Eigentumsrechte.
• NIS2 und was sie für mittelständische IT-Beratungsunternehmen in Deutschland wirklich bedeutet – die Durchsetzungsarchitektur im deutschen Mittelstand und das Muster der nationalen Umsetzungsverzögerung.
• Elf Neunen: Erasure Coding, Reed-Solomon und wie die Cloud Daten praktisch unverlierbar macht – warum der Wegfall der Egress-Gebühren geografisch verteilte Speicherstrategien wirtschaftlich verändert.
• Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas – Isolationsmodelle als technische Antwort auf die Souveränitätsfrage aus Kapitel VII.
• Der Zufall, der die Privatsphäre schützt: Differential Privacy und die Kunst, nichts über den Einzelnen zu verraten – ein Werkzeug für die Anonymisierung, die Kapitel V im Notstandsfall verlangt.

Quellen

1. Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates vom 13. Dezember 2023 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung (Datenverordnung / Data Act), ABl. L vom 22.12.2023. Konsolidierter Text: EUR-Lex (deutsche Fassung)
2. Europäische Kommission, Generaldirektion CNECT: Data Act explained (Fact Page, letzte Aktualisierung 15. Dezember 2025) – Kapitelübersicht, Anwendungsbereich, Kompensationstabellen und die Darstellung der Wechselentgelt-Staffelung. Shaping Europe's digital future
3. Europäische Kommission: Frequently Asked Questions about the Data Act sowie Draft Recommendation on non-binding Model Contractual Terms (MCTs) and Standard Contractual Clauses for cloud computing contracts (SCCs), veröffentlicht am 19. November 2025. Kommissionsbibliothek
4. Maples Group (Claire Morrissey), The EU Data Act's Switching Framework – A Practical Overview, 17. April 2026 – detaillierte Darstellung der Fristenmechanik des Artikels 25 (zwei Monate Ankündigung, 30 Tage Übergang, 14 Arbeitstage Begründung, sieben Monate Alternativfrist, 30 Tage Abruf) und der Ausnahmen. Maples Group
5. Europäische Kommission: Digital Omnibus Regulation – Proposal, 19. November 2025 – vorgeschlagene Änderungen am Data Act zu Geschäftsgeheimnissen, maßgefertigten Diensten sowie KMU und kleinen Midcaps. Kommissionsbibliothek
6. Bundesnetzagentur: Bundesnetzagentur wird zuständige Behörde für den Data Act in Deutschland, Pressemitteilung vom 30. Mai 2026, sowie das Fachportal Datenzugang und Datennutzung. Pressemitteilung; Fachportal
7. Deutscher Bundestag: Bundestag verabschiedet EU-Vorgaben zum Datenzugang und zur Datennutzung, Textarchiv zur Sitzung vom 26. März 2026 (Datenverordnung-Anwendungs- und -Durchsetzungs-Gesetz, DADG). Bundestag
8. heise online: Data Act: Access by Design wird ab Herbst 2026 zur Pflicht – Einordnung des Stichtags 12. September 2026 und der Konstruktionspflicht aus Artikel 3 Absatz 1. heise online
9. Bird & Bird / White & Case: Analysen zum Digital Omnibus Package und den vorgeschlagenen Data-Act-Änderungen, November/Dezember 2025. Bird & Bird; White & Case
10. DLA Piper: Germany's Data Act enforcement architecture: what practitioners need to know now, März 2026 – Zweigleisigkeit von Bundesnetzagentur und BfDI. DLA Piper

← All articles