Design Tokens und der EU Data Act: Datenportabilität als Rechtsanspruch

Eine unbemerkte Kollision

Juristen, die den EU Data Act kommentieren, denken an IoT-Geräte, Maschinendaten und Cloud-Migration. Design-Engineers, die über Token-Portabilität sprechen, denken an Style Dictionary, Figma Variables und JSON-Export-Plugins. Die beiden Diskussionen haben sich bislang nicht getroffen.

Das ist ein Problem — weil sie dasselbe Thema beschreiben.

Design Tokens, die in einem SaaS-Tool wie Figma angelegt und verwaltet werden, sind im rechtlichen Sinne Daten. Der Dienst, der sie speichert und verarbeitet, ist ein Datenverarbeitungsdienst im Sinne des Data Act. Und das Recht auf maschinenlesbaren Export dieser Daten in einem interoperablen Format — das ist seit dem 12. September 2025 kein Goodwill eines Anbieters mehr, sondern ein durchsetzbarer Rechtsanspruch.

Der rechtliche Rahmen in drei Schritten

Schritt 1: Ist Figma ein Datenverarbeitungsdienst?

Die Verordnung (EU) 2023/2854 definiert „Datenverarbeitungsdienst” in Artikel 2 Absatz 8 über das NIST-Referenzmodell für Cloud Computing — es umfasst SaaS, PaaS und IaaS. Figma beschreibt die eigene Infrastruktur ausdrücklich als „Multi-Tenant Hosted Environment”. Alle einschlägigen Rechtsgutachten — von Greenberg Traurig, Latham & Watkins und Bird & Bird — bestätigen: SaaS-Dienste mit EU-Kunden fallen in den Anwendungsbereich, unabhängig davon, wo der Anbieter seinen Sitz hat. Der Data Act gilt extraterritorial.

Ergebnis: Figma ist ein Datenverarbeitungsdienst im Sinne des Data Act.

Schritt 2: Sind Design Tokens „Daten”?

Artikel 2 Absatz 1 definiert „Daten” als jede digitale Darstellung von Handlungen, Tatsachen oder Informationen. Eine Design-Token-Datei — { "color-primary": "#0057FF", "spacing-base": "16px" } — ist eine digitale Darstellung von Gestaltungsentscheidungen. Es gibt keinen vernünftigen Grund, warum Token-Werte nicht unter diese Definition fallen sollten.

Präziser greift Artikel 2 Absatz 38: „Exportierbare Daten” sind Input- und Output-Daten, die ein Nutzer durch die Nutzung des Dienstes erzeugt hat — explizit ausgenommen ist lediglich Inhalt, an dem der Anbieter selbst Schutzrechte hält. Design Tokens werden vom Nutzer angelegt und gepflegt. Das intellektuelle Eigenteil liegt beim Nutzer, nicht bei Figma.

Ergebnis: Design Tokens in Figma sind exportierbare Daten im Sinne des Data Act.

Schritt 3: Was schuldet der Anbieter?

Artikel 30 ist das operative Herzstück. Absatz 5 verpflichtet Datenverarbeitungsdienste, den Export in einem „strukturierten, gängigen und maschinenlesbaren Format” zu ermöglichen — sofern keine harmonisierten technischen Normen existieren. Absatz 2 ergänzt: Die Schnittstellen für den Datenzugang müssen für alle Kunden kostenlos bereitstehen, nicht nur für bestimmte Preisstufen.

Artikel 33 fordert, dass Datenformate öffentlich zugänglich und konsistent beschrieben sind. Artikel 25 regelt die operativen Parameter: maximal 30 Tage Übergangszeitraum, maximal zwei Monate Kündigungsfrist, 30 Tage Datenabruf nach Vertragsende.

W3C DTCG als Art.-30-konformes Format

Artikel 30 Absatz 5 verlangt ein Format, das drei Eigenschaften gleichzeitig erfüllt: strukturiert, gängig, maschinenlesbar. Die W3C Design Tokens Specification 2025.10 erfüllt alle drei.

Strukturiert: Das Format definiert eine verbindliche Dokumentstruktur mit den Pflichtfeldern $value und den optionalen Feldern $type, $description, $extensions und $deprecated. Token-Gruppen können hierarchisch verschachtelt werden. Die Semantik der Felder ist eindeutig spezifiziert.

Gängig: Das Format wird von Adobe, Amazon, Google, Figma, Microsoft, Meta, Salesforce, Shopify, Tokens Studio und Penpot unterstützt oder ist in deren Roadmaps verankert. Es ist der de-facto-Standard für plattformübergreifende Token-Distribution und hat breite Akzeptanz in der Branche erreicht.

Maschinenlesbar: Die Spezifikation definiert den MIME-Typ application/design-tokens+json und die Dateiendungen .tokens bzw. .tokens.json. JSON ist ein ISO-anerkanntes Format.

Zusätzlich erfüllt das W3C-Format die Anforderung aus Artikel 33, weil die Spezifikation unter offener Lizenz veröffentlicht ist und kein einzelner Anbieter Kontrolle über ihre Weiterentwicklung hat.

Wo Figma heute steht

Figma exportiert seit der Einführung von Variables eine JSON-Darstellung der Token-Struktur. Das Bild ist differenziert.

Positiv: Der Variablen-Export existiert, ist dokumentiert, und Figma arbeitet aktiv an erweiterter DTCG-Kompatibilität. Für Farb-Tokens, Number-Tokens und String-Tokens ist die Abbildung auf das W3C-Format weitgehend möglich.

Kritisch: Die Variables API, über die ein vollständiger programmatischer Export möglich ist, war bis zuletzt nur für Enterprise-Kunden zugänglich. Artikel 30 Absatz 2 des Data Act ist eindeutig: Schnittstellen für den Datenzugang müssen für alle Kunden kostenlos bereitstehen. Eine Beschränkung auf Enterprise-Tarife ist mit dieser Anforderung schwer zu vereinbaren.

Außerdem werden komplexere Token-Typen — Typografie-Styles, Schatten, Verläufe — in Figma als „Styles” verwaltet, nicht als Variables. Ob und wie diese in das DTCG-Format exportierbar sind, bleibt unklar. Eine Token-Architektur, die nur Farben portabel hält, den Rest aber nicht, ist keine vollständige Compliance.

Figma hat zum Zeitpunkt der Recherche keine öffentliche Stellungnahme zur Data-Act-Compliance veröffentlicht.

Was das für die eigene Token-Architektur bedeutet

Der Data Act gibt Unternehmen nicht nur ein Recht — er verändert auch die Risikostruktur. Wer Token-Infrastruktur aufbaut, die ausschließlich über proprietäre Anbieter-Mechanismen exportierbar ist, geht ein messbares rechtliches und operatives Risiko ein.

Die Konsequenzen sind praktisch:

Token-Format als Architekturentscheidung. Die Speicherung von Tokens im W3C DTCG Format — unabhängig davon, welches Tool sie verwaltet — ist die einzige Methode, die langfristige Portabilität und Data-Act-Konformität gleichzeitig sichert. Das Format sollte in der Infrastruktur vorkommen, bevor es in Tools relevant wird.

Source-of-Truth außerhalb des SaaS-Tools. Eine Token-Architektur, in der Figma die maßgebliche Quelle für Token-Werte ist und diese in JSON-Dateien im Repository gespiegelt werden, ist robuster als eine, in der der Export nur bei Bedarf manuell angestoßen wird. Git als Token-Repository und Figma als Bearbeitungsoberfläche — nicht umgekehrt.

Vendor-Abhängigkeit bewusst gestalten. Tools wie Tokens Studio (Penpot-kompatibel, Open Source) oder direkte DTCG-JSON-Dateien im Repository erlauben es, den SaaS-Layer zu wechseln, ohne die Token-Architektur zu migrieren. Das ist keine theoretische Vorsichtsmaßnahme mehr — es ist die Konsequenz aus dem, was der Data Act als Normalzustand definiert.

Die Architektur einer datenschutzkonformen Token-Infrastruktur

Eine Token-Infrastruktur, die den Anforderungen des Data Act entspricht, hat eine klare Schichtung:

Designtool (Figma / Penpot)
       ↓  bidirektionale Synchronisation
Token-Repository (Git, DTCG-Format)
       ↓  automatisierte Transformation
Style Dictionary / Transformation Pipeline
       ↓  plattformspezifische Ausgabe
CSS Custom Properties / Swift / Kotlin / ...

Die maßgebliche Quelle ist das Git-Repository — nicht das Designtool. Das Designtool ist eine Bearbeitungsschicht mit bidirektionaler Synchronisation. Bei einem Anbieterwechsel bleibt das Repository unverändert; nur die Bearbeitungsschicht wird ausgetauscht.

// tokens/color.tokens.json — DTCG-konformes Format im Repository
{
  "$schema": "https://www.designtokens.org/tr/2025.10/",
  "color": {
    "$type": "color",
    "interactive": {
      "$value": "#0057FF",
      "$description": "Primäre Interaktionsfarbe",
      "$extensions": {
        "com.figma": { "scopes": ["FRAME_FILL", "TEXT_FILL"] }
      }
    },
    "surface": {
      "base": { "$value": "#F8F9FA" },
      "elevated": { "$value": "#FFFFFF" }
    }
  }
}

Die Figma-spezifischen Extensions in $extensions sind optional und ignorierbar — jedes andere Tool, das die Spezifikation korrekt implementiert, muss Extensions, die es nicht kennt, unverändert erhalten. Das Format ist damit additive: Anbieter-spezifische Metadaten können enthalten sein, ohne die Interoperabilität zu gefährden.

Das Normenumfeld entwickelt sich

Der Data Act verweist mehrfach auf technische Normen, die er nicht selbst festlegen will. Artikel 35 skizziert ein zentrales europäisches Repository für interoperable Datenformate. Die Europäische Kommission hat begonnen, sektorspezifische Interoperabilitätsnormen zu konsolidieren.

Ob die W3C Design Tokens Specification dort explizit verankert wird, ist offen. Ihre strukturellen Eigenschaften — offene Lizenz, kein Single-Vendor-Control, nachgewiesene Branchenakzeptanz — entsprechen genau dem Profil, das der Data Act für konforme Formate voraussetzt.

Was sich bereits abzeichnet: Der Marktdruck in Richtung standardisierter Token-Formate steigt. Unternehmenskunden, die Data-Act-Compliance dokumentieren müssen, werden von ihren Designtool-Anbietern Klarheit über Exportformate verlangen. Anbieter, die darauf keine Antwort haben, verlieren im Enterprise-Segment.

Der Data Act formuliert nichts Neues für Teams, die Token-Infrastruktur bereits nach Best Practices aufbauen: DTCG-Format, Git als Source of Truth, werkzeugunabhängige Transformation. Er macht es jedoch zur Rechtspflicht der Anbieter, diese Infrastruktur zu unterstützen — und gibt Unternehmen ein Instrument, diese Pflicht durchzusetzen.

Wer Design Tokens heute als Betriebsmittel und nicht als Designtool-Feature begreift, ist nicht nur technisch besser aufgestellt. Er steht auch auf der richtigen Seite des Gesetzes.

Weiterführende Ressourcen

• Verordnung (EU) 2023/2854 (Data Act): EUR-Lex
• W3C Design Tokens Specification 2025.10: designtokens.org/tr/2025.10
• Greenberg Traurig, Cloud Switching under the EU Data Act (Sep. 2025): gtlaw.com
• Latham & Watkins, EU Data Act — What Businesses Need to Know (Sep. 2025): lw.com
• Bird & Bird, EU Data Act Overview: twobirds.com
• eu-data-act.com: Artikel 30