Lock-in ist seit dem 12. September 2025 kein kaufmännisches Problem mehr, sondern ein Rechtsanspruch. Ausüben kann ihn trotzdem kaum jemand.

Was hat sich am 12. September 2025 juristisch wirklich verschoben?

Wer in den letzten zehn Jahren aus einer Cloud herauswollte, hat das als Rechenaufgabe behandelt. Migrationsaufwand gegen Restlaufzeit, Egress-Gebühren gegen Rabattzusage. Am Ende stand fast immer die Verlängerung, weil der Ausstieg teurer war als das Bleiben. Das war kein Versehen, sondern die Funktion der Konstruktion.

Die Verordnung (EU) 2023/2854, der Data Act, ist am 11. Januar 2024 in Kraft getreten und seit dem 12. September 2025 anwendbar. Ihr Kapitel VI umfasst die Artikel 23 bis 31 und trägt die Überschrift “Switching between data processing services” (Garrigues). Aus der Rechenaufgabe wird damit ein Anspruch. Nicht: der Anbieter sollte den Wechsel ermöglichen. Sondern: er muss die Hindernisse beseitigen, er muss die Fristen einhalten, und er darf ab einem festen Stichtag nichts mehr dafür verlangen. Der Anwendungsbereich umfasst IaaS, PaaS und SaaS ebenso wie Storage- und Datenbankdienste (Alston & Bird), also nicht nur den Hyperscaler-Vertrag, sondern auch das CRM, das Data Warehouse und den verwalteten Suchindex.

Das Problem ist nicht die Norm. Ein Rechtsanspruch auf funktionale Äquivalenz ist nichts wert, wenn die eigene Architektur keine funktionale Äquivalenz zulässt. Der Anbieter schuldet dir einen Export. Er schuldet dir nicht, dass dein System danach läuft.

Fristen-Realität

Die Verordnung ist seit dem 12. September 2025 anwendbar. Die Wechselentgelte laufen nach Art. 29 Abs. 1 zum 12. Januar 2027 auf null aus. Dazwischen erlaubt Art. 29 Abs. 2 reduzierte Entgelte, die nach Absatz 3 die dem Anbieter unmittelbar durch den Wechsel entstandenen Kosten nicht überschreiten dürfen. Wer heute einen Dreijahresvertrag unterschreibt, unterschreibt über den Stichtag hinweg.

Artikel 23 zählt fünf Hindernisse, nicht vier

Die verbreitete Kurzfassung lautet, der Data Act verbiete kommerzielle, technische, vertragliche und organisatorische Wechselhindernisse. Das ist eine Kategorie zu wenig. Art. 23 nennt ausdrücklich “pre-commercial, commercial, technical, contractual and organisational” Hindernisse. Vorkommerziell heißt: auch das, was vor Vertragsschluss passiert, zählt.

Diese fünfte Kategorie verschiebt den Zeitpunkt, an dem Lock-in entsteht. Lock-in wird nicht im Kündigungsparagrafen erzeugt, sondern im Onboarding: in dem SDK, das der Anbieter als schnellsten Weg empfiehlt, und in der Referenzarchitektur, die drei proprietäre Dienste in den kritischen Pfad legt, weil sie am Tag eins Zeit spart.

Artikel 23 beschreibt in den Buchstaben (a) bis (e), was am Ende funktionieren muss: Beendigung des Vertrags nach Ablauf der Kündigungsfrist, Abschluss eines neuen Vertrags mit einem anderen Anbieter, Portierung der exportierbaren Daten und digitalen Assets, funktionale Äquivalenz beim neuen Anbieter und Entbündelung von Diensten, soweit technisch machbar.

Buchstabe (d), die funktionale Äquivalenz, ist der Punkt, an dem die meisten Migrationen scheitern. Nicht weil die Daten fehlen, sondern weil das Verhalten fehlt. Ein Export enthält Zeilen. Er enthält nicht die Retry-Semantik einer Warteschlange, nicht die Konsistenzgarantie eines verwalteten Datenspeichers und nicht die Berechtigungsauflösung eines anbietereigenen IAM.

Die 30 Tage sind nicht die Frist, die du im Kopf hast

Die Zahl, die in jeder Zusammenfassung steht, lautet 30 Kalendertage. Sie stimmt, beschreibt aber nur ein Segment einer Kette. Art. 25 Abs. 2 lit. a spricht von einem “mandatory maximum transitional period of 30 calendar days”. Der entscheidende Halbsatz steht daneben: Dieser Übergang wird “initiated after the maximum notice period referred to in point (d)” ausgelöst, und Buchstabe (d) erlaubt eine Ankündigungs- beziehungsweise Kündigungsfrist von bis zu zwei Monaten. Realistisch reden wir also nicht über einen Monat, sondern über rund drei. Wer die 30 Tage rückwärts vom Vertragsende rechnet, hat sich um acht Wochen verkalkuliert.

Schritt	Rechtsgrundlage	Dauer	Anker
Ankündigungs- und Kündigungsfrist	Art. 25 Abs. 2 lit. d	bis zu zwei Monate	Wechselanfrage des Kunden
Übergangsfrist im Regelfall	Art. 25 Abs. 2 lit. a	maximal 30 Kalendertage	Ende der Ankündigungsfrist
Übergangsfrist bei technischer Undurchführbarkeit	Art. 25 Abs. 4	höchstens sieben Monate	Begründung binnen 14 Arbeitstagen ab Wechselanfrage
Einmalige Verlängerung durch den Kunden	Art. 25	vom Kunden als angemessen bemessen	unabhängig vom Anbietergrund
Mindestabrufzeitraum für die Daten	Art. 25 Abs. 2 lit. g	mindestens 30 Kalendertage	Ende der Übergangsfrist

Zwei Zeilen werden regelmäßig übersehen. Die erste ist die technische Undurchführbarkeit: Nach Art. 25 Abs. 4 muss der Anbieter den Kunden binnen 14 Arbeitstagen nach der Wechselanfrage benachrichtigen, die Undurchführbarkeit begründen und eine alternative Übergangsfrist nennen, die sieben Monate nicht überschreitet. Das ist keine Ausrede, sondern ein Verfahren mit Begründungspflicht und harter Obergrenze. Wer es nicht kennt, akzeptiert eine formlose Absage, obwohl ihm eine schriftliche Begründung und ein Enddatum zustehen.

Die zweite ist die Verlängerung auf Kundenseite. Art. 25 gibt dem Kunden das Recht, die Übergangsfrist einmalig um einen von ihm für angemessen gehaltenen Zeitraum zu verlängern, unabhängig vom Anbietergrund.

Wechselentgelte laufen auf null, Kündigungsstrafen nicht

Art. 29 Abs. 1 ist in seiner Formulierung eindeutig: “From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process.” Bis dahin gilt Absatz 2, der von 11. Januar 2024 bis 12. Januar 2027 reduzierte Entgelte erlaubt, begrenzt durch Absatz 3 auf die dem Anbieter unmittelbar durch den Wechsel entstandenen Kosten. Ein Tagessatz für Migrationsunterstützung, der die eigene Marge enthält, ist davon nicht gedeckt.

Entscheidend ist die Definition. Art. 2 Nr. 36 fasst Wechselentgelte eng: “charges, other than standard service fees or early termination penalties, imposed by a provider of data processing services on a customer for the actions mandated by this Regulation for switching”. Vorzeitige Kündigungsstrafen sind also definitorisch keine Wechselentgelte und fallen nicht unter das Verbot ab 2027. Der Wechselvorgang wird kostenlos, die Restlaufzeit bleibt geschuldet.

Ähnlich differenziert ist die Lage bei den Datenausgangsentgelten. Art. 2 Nr. 35 definiert sie separat als Transfergebühren für die Extraktion von Daten zu einem anderen Anbieter oder ins eigene Rechenzentrum. Erwägungsgrund 99 stellt klar, dass Egress-Gebühren für die Parallelnutzung mehrerer Dienste, also Multicloud ohne Wechselabsicht, auch nach drei Jahren ab Inkrafttreten weiter erhoben werden dürfen, begrenzt auf die entstandenen Kosten. Die Nullstellung betrifft den Wechsel, nicht den laufenden Multicloud-Betrieb.

Der Markt hat übrigens früher reagiert als die Anwendbarkeit es verlangte. Google strich als erster im Januar 2024 die Egress-Gebühren beim Anbieterwechsel, AWS und Microsoft Azure zogen im März 2024 nach (CIO Dive). Am 10. September 2025, zwei Tage vor dem Anwendungsbeginn, kündigte Google Cloud die “Data Transfer Essentials” an: kostenloser Multicloud-Datentransfer für Kunden in EU und UK, also auch für den Parallelbetrieb. Das geht weiter, als die Verordnung verlangt.

Kein Bestandsschutz: warum der Altvertrag dich nicht schützt

Das häufigste Missverständnis in Renewal-Gesprächen ist die Annahme, ein vor dem 12. September 2025 geschlossener Vertrag laufe unter altem Recht weiter. Art. 50 enthält Übergangsregeln ausdrücklich nur für Kapitel III und Kapitel IV. Kapitel IV gilt für nach dem 12. September 2025 geschlossene Verträge und erst ab dem 12. September 2027 für Altverträge unbefristeter Dauer oder mit einem Laufzeitende frühestens zehn Jahre ab dem 11. Januar 2024. Für Kapitel VI fehlt eine solche Ausnahme vollständig. Die Wechselpflichten gelten damit ohne Schonfrist auch für Cloud-Verträge, die lange vor dem Anwendungsbeginn unterschrieben wurden (Addleshaw Goddard).

Damit verschiebt sich die Statik der Verhandlung. Die Wechselklausel im Bestandsvertrag ist nicht mehr die maßgebliche Regel, sondern bestenfalls eine Beschreibung dessen, was der Anbieter freiwillig zugesagt hat. Bisher hast du um Wechselrechte gebeten und dafür bezahlt, meist mit längerer Laufzeit. Jetzt verhandelst du nur noch über die Umsetzung und prüfst jede Klausel danach, ob sie hinter dem gesetzlichen Mindeststandard zurückbleibt.

Verhandlungspunkt	Was Kapitel VI hergibt	Was im Bestandsvertrag oft steht
Übergangsfrist	Art. 25 Abs. 2 lit. a: maximal 30 Kalendertage	”angemessene Unterstützung nach Aufwand”
Kündigungsfrist	Art. 25 Abs. 2 lit. d: höchstens zwei Monate	sechs Monate zum Laufzeitende
Exportformat	Art. 30: strukturiert, gängig, maschinenlesbar	anbietereigenes Backup-Format
Wechselentgelt	Art. 29 Abs. 2 und 3: nur unmittelbar entstandene Kosten	Tagessätze für Migrationsunterstützung
Egress beim Wechsel	Art. 29 Abs. 1: ab 12. Januar 2027 null	Listenpreis pro Terabyte
Datenabruf nach dem Wechsel	Art. 25 Abs. 2 lit. g: mindestens 30 Kalendertage	Löschung mit Vertragsende
Vorzeitige Kündigung	Art. 2 Nr. 36: kein Wechselentgelt, bleibt zulässig	Restlaufzeit in voller Höhe fällig

Was Artikel 30 dir gibt und was nicht

Art. 30 unterscheidet nach Diensttyp. Anbieter von Infrastrukturdiensten schulden “all reasonable measures in their power”, damit der Kunde funktionale Äquivalenz erreicht, also eine Bemühenspflicht, keinen Erfolg. Alle übrigen Anbieter, also PaaS und SaaS, schulden offene Schnittstellen, allen Kunden gleichermaßen und kostenlos. Fehlen harmonisierte Normen, gilt der Export aller exportierbaren Daten in einem strukturierten, gängigen, maschinenlesbaren Format. Für die Einhaltung gemeinsamer Spezifikationen räumt die Verordnung mindestens zwölf Monate nach deren Veröffentlichung im zentralen Unionsnormenverzeichnis ein.

“Strukturiert, gängig, maschinenlesbar” ist ein präziser juristischer Standard und eine unzureichende technische Zielbeschreibung. Ein Zip-Archiv mit 400 CSV-Dateien erfüllt ihn, ein laufendes System ist es nicht. Der Anbieter schuldet die Extraktion, die Wiederherstellung schuldet dir niemand. Wenn der Anspruch ausübbar sein soll, muss deine Seite so gebaut sein, dass eine Extraktion ausreicht.

Vier Architekturentscheidungen, die den Anspruch ausübbar machen

Das Datenmodell gehört dir, nicht dem Dienst

Wenn Geschäftsobjekte, Beziehungen und Zustände nur in der internen Repräsentation eines verwalteten Dienstes existieren, ist der Export eine Übersetzung, und Übersetzungen verlieren. Liegt dasselbe Modell in deiner eigenen relationalen Datenbank und arbeitet der Dienst darauf, ist der Export ein Dump. Praktisch heißt das: keine anbieterspezifischen Spaltentypen im Schema des kritischen Pfads, keine Geschäftslogik in gespeicherten Prozeduren eines proprietären Dialekts, und Identifikatoren, die außerhalb des Dienstes stabil bleiben.

Exportformate werden getestet, nicht dokumentiert

Ein Exportpfad, den niemand jemals eingelesen hat, ist eine Behauptung. Die einzige belastbare Prüfung ist ein regelmäßiger Wiederherstellungsversuch auf einem neutralen Stack. Derselbe Gedanke wie beim Backup: Nicht das Schreiben ist der Test, sondern das Zurückspielen.

# .github/workflows/exit-drill.yml (Auszug)
# Läuft monatlich, nicht erst nach der Kündigung.
name: exit-drill
on:
  schedule:
    - cron: "0 3 1 * *"

jobs:
  restore-on-neutral-stack:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
      objectstore:
        image: minio/minio
    steps:
      - name: Export über die dokumentierte Schnittstelle anstoßen
        run: ./scripts/export.sh --target ./artifacts

      - name: Formatprüfung, kein anbietereigenes Binärformat
        run: ./scripts/assert-open-format.sh ./artifacts

      - name: Import in die neutrale Zielumgebung
        run: ./scripts/restore.sh --from ./artifacts --into "$NEUTRAL_DB_URL"

      - name: Funktionale Äquivalenz prüfen
        run: pytest tests/equivalence -q --maxfail=1

Der letzte Schritt ist der eigentliche. tests/equivalence prüft nicht die Zeilenzahl, sondern ob die fachlichen Invarianten nach dem Import noch gelten: dieselben Berechtigungen, dieselben Aggregate, dieselben Ergebnisse für eine Handvoll produktionsnaher Abfragen. Wer diesen Lauf einmal grün hat, hat die funktionale Äquivalenz aus Art. 23 lit. d nicht nur gefordert, sondern gemessen. Sinnvollerweise hängt er an derselben kontinuierlichen Überwachung wie der Rest des Betriebs, damit ein stillschweigend geändertes Exportformat sofort auffällt.

Infrastructure as Code ist Voraussetzung, nicht Kür

Der zweite große Verlustposten bei einer Migration sind nicht die Daten, sondern die Konfiguration: Netzwerkregeln, IAM-Rollen, Warteschlangen, Zertifikate, Skalierungsparameter. Wenn dieser Zustand über Jahre in einer Weboberfläche entstanden ist, existiert er nirgendwo in lesbarer Form.

Der Data Act ändert daran nichts. Er verpflichtet den Anbieter, deine Daten und digitalen Assets portierbar zu machen, nicht, dir eine Bauanleitung für deine eigene Umgebung zu liefern. Deklarative Infrastruktur ist deshalb die Bedingung dafür, dass die 30-Tage-Frist realistisch ist. Wer beim Wechsel erst herausfinden muss, wie die Zielumgebung aussehen soll, verliert die Frist an der Planung, nicht an der Übertragung.

Proprietäre Managed Services gehören nicht in den kritischen Pfad

Die vierte Entscheidung ist die unbequemste, weil sie Geschwindigkeit gegen Optionalität tauscht. Ein verwalteter Dienst spart am Tag eins Wochen. Im kritischen Pfad kostet er beim Wechsel Monate, weil es beim Ziel kein Äquivalent gibt und die Semantik nachgebaut werden muss.

Baustein im kritischen Pfad	Was beim Wechsel passiert	Vorarbeit
Container auf Standard-Images	Neuaufbau in Tagen	Images im eigenen Registry-Spiegel
Relationale Datenbank, offener Dialekt	Dump und Restore	keine anbieterspezifischen Erweiterungen im Schema
Proprietärer verwalteter Datenspeicher	kein Eins-zu-eins-Ziel beim neuen Anbieter	Abstraktionsschicht oder Ersatz vor dem Renewal
Serverless-Funktionen an Anbieter-Events	Ereignismodell nicht übertragbar	Ereignisbus als eigene Schicht
IAM und Netzregeln in der Konsole gepflegt	Rekonstruktion aus Erinnerung	deklarative Konfiguration als einzige Quelle
Verwaltete Suche mit eigenem Abfragedialekt	Abfragen müssen neu geschrieben werden	Abfragen in der Anwendungsschicht kapseln

Das ist keine Empfehlung, alles selbst zu betreiben, sondern eine Empfehlung, die Entscheidung bewusst zu treffen. Außerhalb des kritischen Pfads ist ein proprietärer Dienst oft die richtige Wahl. Für die Bausteine, ohne die das Geschäft steht, ist er eine Wette auf die Vertragsverlängerung. Wer diese Abwägung systematisch führen will, findet in der Gegenüberstellung von Eigenbetrieb und Zukauf den Rahmen und im SaaS-Friedhof die Erinnerung daran, dass Anbieter auch ohne dein Zutun verschwinden.

Die Ausnahmen, die dir den Anspruch nehmen können

Zwei Dinge gehören in jede ehrliche Bestandsaufnahme. Das erste ist Art. 31, und er enthält zwei unterschiedlich weite Ausnahmen. Absatz 1 betrifft Dienste, deren Mehrheit der Hauptfunktionen kundenindividuell gebaut ist und die nicht im Servicekatalog breit kommerziell angeboten werden: Für sie gelten Art. 23 lit. d, Art. 29 sowie Art. 30 Abs. 1 und Abs. 3 nicht. Absatz 2 geht deutlich weiter: Für Nicht-Produktivversionen, die zu Test- und Evaluationszwecken für begrenzte Zeit bereitgestellt werden, gelten die Pflichten des gesamten Kapitels VI nicht. Das sind echte Ausnahmen, keine Auslegungsfragen. Der Anbieter muss vorvertraglich darüber informieren, welche Pflichten nicht gelten. Fehlt diese Information, ist das ein Anhaltspunkt.

Das zweite ist der Digital-Omnibus-Vorschlag der Kommission vom 19. November 2025. Er würde Kapitel VI spürbar entschärfen: Neue Absätze 1a und 1b in Art. 31 sollen kundenindividuelle Dienste sowie sämtliche KMU- und Small-Mid-Cap-Anbieter von Nicht-Infrastrukturdiensten für vor dem 12. September 2025 geschlossene Verträge von nahezu allen Wechselpflichten ausnehmen, ohne Nachverhandlungspflicht bis zum Vertragsende. Zusätzlich sollen verhältnismäßige Vorfälligkeitsstrafen in befristeten Verträgen ausdrücklich zulässig sein. Der Konsolidierungstext des Rates ist mit Stand 15. Juli 2026 weiterhin Verhandlungsgegenstand und nicht geltendes Recht (Greenberg Traurig, Volltext der Analyse, Bird & Bird zu den neuen Absätzen in Art. 31).

Daraus folgt eine unangenehme Asymmetrie: Der Rechtsanspruch gilt heute, könnte aber für einen Teil der Verträge rückwirkend entfallen. Die Architekturarbeit, die ihn ausübbar macht, behält ihren Wert in beiden Szenarien. Eine Verhandlungsposition, die sich ausschließlich auf die Norm stützt, nicht.

Wer setzt das durch, und was ist bisher passiert?

Die Aufsicht ist national organisiert, und Deutschland war spät dran. Der Bundestag beschloss das Data Act-Durchführungsgesetz (DADG) am 26. März 2026. Seit dem 30. Mai 2026, zeitgleich mit dessen Inkrafttreten, ist die Bundesnetzagentur zentrale deutsche Aufsichtsbehörde für den Data Act und überwacht ausdrücklich auch die Regeln zur Vereinfachung des Cloud-Anbieterwechsels. Das sind rund acht Monate Rückstand auf den Anwendungsbeginn.

Art. 40 gibt den Sanktionsrahmen vor: Die Mitgliedstaaten mussten ihre Sanktionsregeln bis zum 12. September 2025 melden, die Sanktionen müssen wirksam, verhältnismäßig und abschreckend sein. Bei Verstößen mit Personenbezug, also gegen die Kapitel II, III und V, können Aufsichtsbehörden Geldbußen bis zur Obergrenze des Art. 83 Abs. 5 DSGVO verhängen. Konkrete Durchsetzungsfälle wegen Verstößen gegen die Wechselpflichten sind bis Ende Juli 2026 nicht belegt; Beobachter erwarten den Anstieg der Durchsetzungstätigkeit erst in der zweiten Jahreshälfte 2026.

Die Anbieterseite hat sich unabhängig davon bewegt. CISPE veröffentlichte im November 2024 gemeinsam mit Gaia-X ein “Cloud Switching Framework” mit fünf Säulen: Transparenz über Verfahren, Kosten und Grenzen, definierte Meldekanäle, Exportschnittstellen und Migrationswerkzeuge, ein geordnetes Kündigungsverfahren und die vertragliche Bestätigung des Multicloud-Rechts. AWS ist seit 2017 CISPE-Mitglied und hat ein eigenes EU Data Act Addendum veröffentlicht, Google Cloud unterhält eine Data-Act-Compliance-Seite. Diese Dokumente sind der Ausgangspunkt jeder Renewal-Verhandlung, nicht deren Ergebnis.

Marktlage

Synergy Research zählte am 24. Juli 2025 für europäische Cloud-Anbieter einen Anteil von 15 Prozent am europäischen Markt, nach 29 Prozent im Jahr 2017 und einem Absturz auf 15 Prozent bis 2022, seither stabil. AWS, Microsoft und Google halten zusammen 70 Prozent. Der europäische Cloud-Infrastrukturmarkt lag 2024 bei 61 Milliarden Euro, für 2025 wurden rund 24 Prozent Wachstum erwartet. Stärkste europäische Anbieter sind SAP und Deutsche Telekom mit je 2 Prozent.

Diese Zahlen erklären, warum Kapitel VI existiert und warum es allein nicht reichen wird. Ein Recht auf Wechsel verändert Marktanteile erst, wenn der Wechsel technisch in der vorgesehenen Zeit durchführbar ist.

Was du in diesem Quartal entscheidest

Der Data Act hat den Verhandlungstisch verschoben, nicht deine Systemlandschaft. Drei Entscheidungen bringen beides zusammen.

Erstens: Nimm die Fristenkette aus Art. 25 in jede laufende Renewal-Vorbereitung auf und prüfe die Bestandsklauseln gegen die Tabelle oben. Alles, was hinter dem gesetzlichen Mindeststandard zurückbleibt, ist kein Verhandlungserfolg des Anbieters, sondern eine offene Frage.

Zweitens: Führe eine ehrliche Bestandsaufnahme der proprietären Dienste im kritischen Pfad. Nicht, um sie alle zu ersetzen, sondern um zu wissen, welche davon die 30-Tage-Frist unmöglich machen. Diese Liste ist die Grundlage jeder Integrationsarbeit, die den Anspruch ausübbar macht.

Drittens: Lass den Exit-Drill einmal laufen. Nicht als Konzept, sondern als grünen oder roten Lauf. Alles andere ist eine Behauptung über die eigene Portabilität.

Am Rande gehört in denselben Kalender der 12. September 2026, ab dem die Zugangspflicht des Art. 3 Abs. 1 für neu in Verkehr gebrachte vernetzte Produkte gilt. Wer Hardware baut, hat parallel eine zweite Uhr laufen. Wenn du wissen willst, wie diese Prüfung in einer gewachsenen Systemlandschaft konkret aussieht, sprich mit uns.

Quellen

Hinweis zur Quellenlage: Der Volltext der Verordnung (EU) 2023/2854 war über EUR-Lex beim Abruf nicht maschinell verfügbar; die Artikelzitate stammen aus den Volltext-Spiegeln data-act-law.eu und eu-data-act.com. Für rechtsverbindliche Aussagen ist ausschließlich die im Amtsblatt veröffentlichte Fassung maßgeblich. Eine verbreitete Darstellung, wonach bereits ab dem 12. Januar 2026 eine eigene Zwischenstufe für Wechselstrafen und Migrationsgebühren gelte, findet im Normtext keine Entsprechung und steht im Widerspruch zu Art. 29 Abs. 2; sie wird hier bewusst nicht wiedergegeben. Konkrete Bußgeldhöhen für Verstöße gegen Kapitel VI in Deutschland ließen sich an keiner Primärquelle bestätigen. Der Verhandlungsstand des Digital-Omnibus-Pakets bezieht sich auf den belegten Stand vom 15. Juli 2026. Dieser Artikel ist keine Rechtsberatung; für die Bewertung deiner konkreten Verträge ziehe qualifizierten Rechtsrat hinzu.

Kernaussagen