Seit dem 12. September 2025 gilt Kapitel VI der Verordnung (EU) 2023/2854 — der EU Data Act — unmittelbar in allen Mitgliedstaaten. Für Nutzer von SaaS-Tools bedeutet das ein einklagbares Recht auf Anbieterwechsel. Für Anbieter wie Figma oder Vercel bedeutet es konkrete Vertragspflichten gegenüber ihren EU-Kunden. Vendor Lock-in ist damit kein strategisches Risiko mehr allein — es ist ein Compliance-Thema.
Was Kapitel VI regelt — und warum es für Design-Teams relevant ist
Der Data Act richtet sich an „Datenverarbeitungsdienste” — eine Kategorie, die explizit IaaS, PaaS und SaaS umfasst. Wer also ein Deployment-Tool wie Vercel nutzt, ein Kollaborationstool wie Figma, ein Monitoring-Tool oder ein Design-Token-Management-System, arbeitet mit Diensten, die unter diese Verordnung fallen — vorausgesetzt, es handelt sich um standardisierte „One-to-Many”-Angebote und keine vollständig maßgeschneiderten Individuallösungen.
Die Grundregel findet sich in Artikel 23: Anbieter von Datenverarbeitungsdiensten müssen alle „vorkommerziellen, kommerziellen, technischen, vertraglichen und organisatorischen Hindernisse” beseitigen, die einem Wechsel im Weg stehen. Vertragsklauseln mit unangemessenen Kündigungsfristen oder verschachtelten Exportprozessen, die faktisch Wechsel verhindern, sind damit unzulässig.
Das ist keine weiche Formulierung. Es ist eine Anforderung an das Vertragsdesign — rückwirkend für alle bestehenden Verträge, nicht nur für Neuabschlüsse nach dem Stichtag.
Die konkreten Pflichten aus Art. 23–31
Wechselrecht und Kündigungsfristen (Art. 23, 25)
Kunden haben ein vertraglich zu verankertes Recht auf Wechsel zu einem anderen Anbieter — oder in die eigene IT-Infrastruktur (On-Premises). Die maximale Kündigungsfrist beträgt zwei Monate. Für den eigentlichen technischen Wechselprozess gilt eine Übergangsfrist von maximal 30 Tagen; bei nachgewiesenen technischen Komplexitäten kann diese auf bis zu sieben Monate verlängert werden. Automatische Vertragsverlängerungen ohne aktive Zustimmung sind unzulässig.
Wichtig für die Praxis: Artikel 23 nennt „unternehmensinterne IT-Infrastruktur” ausdrücklich als zulässiges Wechselziel. Das stärkt die Position von Unternehmen, die von einem gehosteten SaaS-Dienst auf eine selbst betriebene Lösung migrieren wollen — dieser Schritt kann nicht mehr vertraglich blockiert werden.
Wechselgebühren — und ihr Ende (Art. 29)
Bis zum 12. Januar 2027 dürfen Anbieter beim Wechsel ausschließlich die tatsächlich entstandenen Kosten in Rechnung stellen — keine Servicegebühren, keine Strafentgelte. Ab dem 12. Januar 2027 sind Wechselentgelte vollständig verboten. Davon zu unterscheiden sind Kündigungsentschädigungen bei vorzeitiger Vertragsauflösung: Diese bleiben unter bestimmten Bedingungen erlaubt, sofern sie im Vorfeld transparent kommuniziert wurden.
Transparenz- und Informationspflichten (Art. 26, 28)
Anbieter müssen Kunden vor Vertragsabschluss schriftlich informieren über: die verfügbaren Verfahren für Datenmigration und Wechsel, die unterstützten Datenformate und Schnittstellen, bekannte technische Einschränkungen sowie die anfallenden Gebühren während des Übergangszeitraums. Diese Informationen müssen online zugänglich sein und aktuell gehalten werden.
Technische Anforderungen: offene Schnittstellen (Art. 30)
Für SaaS- und PaaS-Dienste schreibt Artikel 30 vor, dass Anbieter kostenlose, offene Schnittstellen bereitstellen müssen — mit ausreichender Dokumentation, damit kompatible Software entwickelt werden kann. Sind keine spezifischen Interoperabilitätsstandards vorgegeben, müssen Daten mindestens in einem „strukturierten, gängigen und maschinenlesbaren Format” exportierbar sein. Für IaaS-Dienste gilt die weitergehende Anforderung der „funktionalen Äquivalenz” — der Wechsel soll eine vergleichbare Funktionalität beim neuen Anbieter sicherstellen.
Ausnahmen (Art. 31)
Vollständig maßgeschneiderte Dienste, die nicht in großem Maßstab kommerziell angeboten werden, sowie temporäre Test- oder Beta-Versionen sind von den umfassenden Wechselpflichten ausgenommen. Selbst in diesen Fällen müssen Anbieter jedoch offene Schnittstellen bereitstellen und Datenexport in maschinenlesbaren Formaten ermöglichen. Die Ausnahmen greifen nicht automatisch — Anbieter müssen Kunden vor Vertragsschluss aktiv informieren, wenn ein Dienst unter eine Bereichsausnahme fällt.
Kapitel VI im Überblick
Was das für Figma, Vercel und Co. konkret bedeutet
Figma
Figma ist ein standardisiertes SaaS-Angebot für die EU-Kunden — damit fällt es grundsätzlich unter Kapitel VI. Die Konsequenzen sind praktisch: Figma muss Exportformate und Schnittstellen bereitstellen, die einen vollständigen Datentransfer ermöglichen — Designs, Bibliotheken, Tokens, Kommentare. Eine Kündigung darf maximal zwei Monate Vorlauf erfordern. Der tatsächliche Migrationsprozess (Daten exportieren, neues Tool einrichten, Bibliotheken übertragen) muss innerhalb von 30 Tagen möglich sein. Wechselgebühren darf Figma bis Januar 2027 nur in Höhe der tatsächlichen Migrationskosten erheben — danach keine mehr.
Das ist relevant für Organisationen, die über einen Wechsel zu europäischen Alternativen wie Penpot nachdenken: Die Verordnung stärkt ihre Position gegenüber Figma im Kündigungsprozess erheblich.
Vercel
Vercel positioniert sich als PaaS/IaaS-Angebot — hier gelten die strengsten Anforderungen des Data Act. Neben offenen Schnittstellen ist „funktionale Äquivalenz” beim Zielanbieter sicherzustellen. Konkret: Deployment-Konfigurationen, Build-Einstellungen und Infrastrukturparameter müssen so dokumentiert und exportierbar sein, dass ein Wechsel zu einem vergleichbaren Anbieter — etwa Netlify, Render oder einem europäischen Hosting-Dienst wie Hetzner oder STACKIT — ohne proprietären Lock-in möglich ist.
Vercels vercel.json-Konfigurationsformat ist nicht standardisiert. Die Anforderung nach maschinenlesbaren Exportformaten und offenen Schnittstellen erhöht den Druck, Migration zu dokumentieren und zu unterstützen.
npm-Registries und CDN-Infrastruktur
Öffentliche Package-Registries wie npm oder jsDelivr sind komplexer einzuordnen: Sie bieten keinen typischen B2B-SaaS-Vertrag und fallen damit möglicherweise nicht unter die unmittelbaren Wechselpflichten von Kapitel VI. Aber der Risikorahmen bleibt — npm liegt unter Microsoft, jsDelivr unter Cloudflare. Wer Frontend-Infrastruktur auf private Registries oder EU-hosted Mirrors umstellt, tut dies aus Souveränitätsgründen, nicht weil der Data Act es erzwingt. Der Unterschied: Der Data Act regelt das Verhältnis zwischen Kunden und Anbietern von Datenverarbeitungsdiensten, nicht die Nutzung öffentlicher Infrastruktur.
Extraterritoriale Wirkung: auch US-Anbieter sind betroffen
Der Data Act gilt für alle Anbieter, die Dienstleistungen für EU-Kunden erbringen — unabhängig von deren Sitz. Figma (San Francisco), Vercel (San Francisco), Atlassian (Sydney), Notion (San Francisco): Alle müssen für ihre EU-Kunden compliant sein. Das Gesetz hat damit eine ähnliche extraterritoriale Wirkung wie die DSGVO.
Die Bundesnetzagentur ist in Deutschland als zuständige Aufsichtsbehörde bestimmt. Verstöße können mit Bußgeldern bis zu 4 % des weltweiten Jahresumsatzes geahndet werden.
Was bleibt offen
Zwei Fragen sind in der Praxis noch nicht abschließend geklärt.
Erstens: Gilt die Verordnung für Verträge, die vor dem 12. September 2025 geschlossen wurden? Die Bundesnetzagentur hat klargestellt, dass ab dem Stichtag sowohl neue als auch bestehende Verträge den Vorgaben entsprechen müssen. Die genaue Auslegung für langfristige Enterprise-Verträge mit abweichenden Laufzeiten ist noch nicht durch Gerichtsentscheide präzisiert.
Zweitens: Wie werden Ausnahmen für kundenspezifische Implementierungen abgegrenzt? Ein Standard-SaaS-Angebot mit ausgeprägten Custom-Integrationen könnte argumentieren, dass maßgeschneiderte Teile nicht unter die Vollpflichten fallen. Diese Grauzone wird in den nächsten Jahren durch Behördenpraxis und Rechtsprechung konkretisiert werden.
Was das für die Design-System-Architektur bedeutet
Der Data Act liefert die rechtliche Grundlage für eine Entscheidung, die sorgfältig geplante Design-Systeme schon immer aus technischen Gründen getroffen haben: keine proprietäre Bindung an Tool-interne Formate.
Design Tokens im W3C-DTCG-Format sind keine ideologische Haltung zur Offenheit — sie sind jetzt die Architektur, die dem Wechselrecht entspricht. Tokens, die in Figma-proprietären Variablen leben und nirgends anders exportierbar sind, schaffen faktisch jenen Vendor Lock-in, den der Data Act zu beseitigen verlangt. Tokens, die als YAML oder JSON in einem versionierten Repository liegen und per Style Dictionary in jedes Zielsystem transformiert werden, sind per Definition exit-fähig.
Das gleiche gilt für Komponentenbibliotheken: Framework-agnostische Webkomponenten oder framework-agnostisch aufgebaute Tokens-Schichten sind dem Wechselrecht näher als Bibliotheken, die tief in React-spezifische oder Angular-spezifische Conventions eingebettet sind.
Exit-Fähigkeit ist damit kein Nice-to-have mehr. Sie ist die architektonische Konsequenz einer Verordnung, die seit September 2025 gilt.
