EU Data Act 2026: Was Hersteller und Cloud-Anbieter entscheiden müssen

Was ist der EU Data Act? — In Kürze

Der EU Data Act (offiziell: Verordnung (EU) 2023/2854 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung) ist die zentrale Verordnung der Europäischen Union zur Datenwirtschaft. Sie steht neben — nicht über — der DSGVO und greift überall dort, wo Daten zwischen vernetzten Produkten, Nutzer:innen, Datenempfängern und Cloud-Diensten ausgetauscht werden. Die Verordnung trat am 11.01.2024 in Kraft und ist seit dem 12.09.2025 grundsätzlich anwendbar.

Drei Punkte tragen das Verständnis der gesamten Verordnung:

Drei Kern-Regelungsbereiche: Datenzugriffsrechte für Nutzer:innen vernetzter Produkte (Kapitel II–III, Artikel 3–12), Anbieter-Wechsel-Rechte für Cloud- und Edge-Dienste (Kapitel VI, Artikel 23–31) sowie der Zugriff öffentlicher Stellen auf private Daten in Ausnahmesituationen (Kapitel V, Artikel 14–22). Hinzu kommen Anforderungen an Smart Contracts für Datenteilungs-Vereinbarungen (Artikel 36) und an Interoperabilität (Kapitel VIII).
Breiter Adressatenkreis: Hersteller vernetzter Produkte (Maschinenbau, Industrie 4.0, IoT, Smart Home), Anbieter zugehöriger Dienste, Cloud- und Edge-Service-Anbieter, Datenempfänger und öffentliche Stellen — alle, die in der EU tätig sind oder Produkte/Dienste in der EU bereitstellen, unabhängig vom Sitz.
Gestaffelte Anwendbarkeit, separates Strafmaß je Mitgliedstaat: Designpflicht für vernetzte Produkte ab 12.09.2026, vollständiger Wegfall der Cloud-Wechsel-Entgelte ab 12.01.2027, Anwendung auf Bestandsverträge ab 12.09.2027. Die Bußgeld-Höhe legt jeder Mitgliedstaat selbst fest — Deutschland regelt sie im Datendurchführungsgesetz (DADG, vom Bundestag am 26.03.2026 verabschiedet).

Wer prüfen möchte, ob er betroffen ist, findet die Antwort in Artikel 1 (Anwendungsbereich) und Artikel 2 (Begriffsbestimmungen) der Verordnung sowie in der laufend aktualisierten FAQ der EU-Kommission (Stand Mai 2026: Version 1.4 vom 22.01.2026).

Warum der Data Act 2026 auf die Geschäftsführungs-Agenda gehört

Wenn Ihr Unternehmen ein vernetztes Produkt herstellt — eine Maschine mit Cloud-Anbindung, einen IoT-Sensor, ein Industriegerät mit Telemetrie — oder Cloud- bzw. Edge-Dienste in der EU anbietet, dann legt die Verordnung 2023/2854 fest, was Ihr Produkt-Portfolio und Ihre Vertragsarchitektur ab gestaffelten Stichtagen erfüllen müssen. Es geht nicht um eine technische Detailfrage. Es geht darum, ob Sie weiterhin auf dem EU-Markt liefern können, ob Ihre Kunden Sie über bestehende Verträge zur Datenherausgabe verpflichten können — und welches Bußgeld bei Verstößen droht.

Die Verordnung ist seit dem 12.09.2025 grundsätzlich anwendbar. Das heißt: Datenzugriffsrechte für Nutzer:innen vernetzter Produkte, das Recht auf Cloud-Anbieter-Wechsel und der öffentlich-rechtliche Datenzugriff in Ausnahmesituationen gelten heute. Bis zum 12.09.2026 müssen alle neu in den Verkehr gebrachten vernetzten Produkte so konstruiert sein, dass die Datenzugriffspflicht aus Artikel 3(1) ohne nachträgliche Anpassung erfüllbar ist. Bis zum 12.01.2027 müssen Cloud-Anbieter die Wechsel-Entgelte vollständig abgeschafft haben. Die Entscheidungen, die Sie 2026 treffen, bestimmen, ob Sie zum Stichtag liefern oder unter Zeitdruck nachrüsten — und ob Sie das Datenmodell einmal sauber bauen oder zweimal flicken.

Dieser Artikel beschreibt, was der Data Act tatsächlich verlangt — Stand der konsolidierten Fassung in EUR-Lex, der EU-Kommissions-FAQ und des deutschen Durchführungsgesetzes — und macht klar, welche Architekturentscheidungen jetzt anstehen. Kein juristischer Leitfaden. Eine Entscheidungs-Handreichung für Geschäftsführung, IT-Leitung und Produktverantwortung — mit der technischen Tiefe, mit der Sie die Aufwandsschätzungen Ihres Engineering-Teams einordnen können.

Wer ist betroffen — und wer überrascht ist

Der Anwendungsbereich des Data Act (Artikel 1) ist breiter als der vieler älterer EU-Verordnungen. Er erfasst Hersteller vernetzter Produkte (von der einzelnen Industrie-Sensorik bis zur cloud-angebundenen Werkzeugmaschine), Anbieter zugehöriger Dienste (Apps, Wartungs-Cloud, Analytics-Plattformen), Datenempfänger (z. B. unabhängige Werkstätten, die im Auftrag der Kund:innen Maschinendaten anfordern), Cloud- und Edge-Service-Anbieter aller Schichten (IaaS, PaaS, SaaS) sowie öffentliche Stellen, die im Ausnahmefall Daten anfordern können. Maßgeblich ist nicht der Sitz des Unternehmens, sondern, ob Produkte oder Dienste in der EU bereitgestellt oder Nutzer:innen in der EU bedient werden.

Eine Größenschwelle wie bei der NIS2-Richtlinie kennt der Data Act nicht — die Pflichten greifen grundsätzlich unabhängig von Mitarbeiterzahl oder Umsatz. Allerdings sieht Artikel 7 eine bedeutsame Ausnahme für Klein- und Kleinstunternehmen vor: Die Datenherausgabepflichten der Kapitel II und III gelten nicht für Daten aus Produkten oder Diensten, die von einem Kleinst- oder Kleinunternehmen hergestellt bzw. erbracht werden — sofern dieses Unternehmen nicht zu einer größeren Gruppe gehört. „Kleinstunternehmen“ und „Kleinunternehmen“ definiert die Verordnung über die Verweisung auf die EU-Empfehlung 2003/361/EG: weniger als 50 Beschäftigte und höchstens 10 Mio. € Jahresumsatz oder Bilanzsumme. Mittelgroße Unternehmen genießen eine einjährige Übergangsfrist nach Markteinführung des Produkts. Wer Teil eines Konzerns ist oder wer als Subunternehmen eines größeren Akteurs agiert, fällt aus der Ausnahme heraus.

Wenig diskutiert, aber strategisch entscheidend: Wenn Sie als Mittelständler ein vernetztes Produkt liefern, das ein größerer Kunde in seine Wertschöpfungskette einbindet, werden Sie über Verträge in die Datenherausgabe-Architektur Ihres Kunden hineingezogen — auch ohne eigene direkte Pflicht. Die Frage „Wie liefern wir Maschinendaten an die Wartungspartner unserer Kunden, in welchem Format, mit welcher Authentifizierung?“ landet damit auf Ihrem Tisch, ob die Verordnung Sie selbst zwingt oder nicht.

Was der Data Act tatsächlich verlangt

Die Verordnung gliedert sich in elf Kapitel und 50 Artikel. Vier Themenbereiche sind aus Architektursicht entscheidend.

Datenzugriffsrechte für Nutzer:innen vernetzter Produkte (Artikel 3–12)

Nutzer:innen eines vernetzten Produkts haben Anspruch auf einfachen, sicheren, kostenfreien und unmittelbaren Zugriff auf die Produktdaten und zugehörigen Dienste-Daten, die durch ihre Nutzung erzeugt werden. Artikel 3(1) verlangt darüber hinaus, dass das Produkt so konstruiert und entworfen ist, dass dieser Zugriff ohne unverhältnismäßigen Aufwand möglich ist — sprich: nicht erst durch nachträgliche Datenexporte, sondern strukturell. Diese Designpflicht greift erst für Produkte, die nach dem 12.09.2026 erstmals in den Verkehr gebracht werden.

Nutzer:innen können außerdem verlangen, dass der Datenhalter die Daten an einen Datenempfänger ihrer Wahl weiterreicht — zum Beispiel an eine unabhängige Werkstatt, einen Datenanalyse-Anbieter oder einen Wettbewerber. Der Datenhalter muss diese Anfrage erfüllen; er darf nur einen begrenzten Vergütungsanspruch (FRAND-konform) gegenüber dem Datenempfänger erheben, und er darf die Daten nicht für eigene Zwecke nutzen, die in Wettbewerb zum Empfänger treten.

Cloud-Anbieter-Wechsel (Artikel 23–31)

Anbieter von Datenverarbeitungs-Diensten — IaaS, PaaS, SaaS — müssen den Wechsel zu einem anderen Anbieter aktiv ermöglichen. Konkret: Vertragliche Kündigungsfrist von höchstens zwei Monaten, anschließende Übergangsphase mit Standardlänge von 30 Tagen (in Ausnahmefällen bis zu sieben Monaten), strukturelle Pflicht zur Bereitstellung exportierbarer Daten und Metadaten in einem allgemein gebräuchlichen, maschinenlesbaren Format. Bis zum 12.01.2027 dürfen Anbieter noch kostendeckende Wechsel-Entgelte erheben — danach müssen Wechsel-Entgelte und Datenausgangs-Gebühren vollständig entfallen. Das betrifft auch die viel diskutierten „Egress Fees“ der großen Hyperscaler.

Zugriff öffentlicher Stellen (Artikel 14–22)

In Ausnahmesituationen — etwa bei Naturkatastrophen, Pandemien oder anderen außergewöhnlichen Ereignissen — können öffentliche Stellen privater Unternehmen zur Herausgabe nicht-personenbezogener Daten verpflichten. Das ist ein eng umgrenzter Mechanismus mit hohen formalen Hürden, aber wer im Bereich kritischer Infrastruktur, Energie, Transport oder Gesundheit aktiv ist, sollte die Vorschrift kennen.

Smart Contracts für Datenteilungs-Vereinbarungen (Artikel 36)

Wer Smart Contracts für die Ausführung von Datenteilungs-Vereinbarungen einsetzt oder anbietet, muss bestimmte wesentliche Anforderungen erfüllen: Robustheit gegen funktionale Fehler und Manipulation, Zugangskontrolle, sichere Beendigung und Unterbrechung, Datenarchivierung und Auditierbarkeit, Konsistenz mit den vertraglichen Bedingungen, Schutz vor Konformitätsbruch. Für Smart Contracts, die nach harmonisierten Normen umgesetzt werden — sobald die EU-Kommission entsprechende Normungsaufträge an CEN/CENELEC erteilt und die Normen im Amtsblatt veröffentlicht sind —, gilt eine Konformitätsvermutung. Die harmonisierten Normen liegen Stand Mai 2026 noch nicht vor; bis dahin trägt der Anbieter die Beweislast über alternative Pfade. Der Artikel hat in der Branche für Diskussion gesorgt, weil die Anforderung „sichere Beendigung“ mit unveränderlichen Public-Blockchain-Architekturen schwer vereinbar ist.

Verhältnis zur DSGVO

Artikel 1(5) stellt klar: Wo personenbezogene Daten oder unauflöslich verbundene Mischdaten verarbeitet werden, gehen die Bestimmungen der DSGVO vor. Der Data Act ergänzt die DSGVO, ersetzt sie aber nicht. Praktisch heißt das: Eine Datenherausgabe-Pflicht aus Artikel 4 Data Act befreit Sie nicht von der Rechtsgrundlagen-Prüfung nach Art. 6 DSGVO. Wenn Maschinendaten Personenbezug haben (z. B. Bedienprofile von Werkern), brauchen Sie für die Weitergabe an einen Datenempfänger eine eigene DSGVO-Rechtsgrundlage — typischerweise die Einwilligung der Nutzer:in oder eine Vertragspflicht.

Architektur-Implikationen — wo das tatsächlich ankommt

Der Data Act ist keine Compliance-Übung, die sich am Ende mit einem PDF erschlagen lässt. Er verändert, was eine vernetzte Plattform leisten muss. Fünf Punkte sind aus Architektursicht entscheidend.

Datenzugriffs-API als Produktbestandteil, nicht als Anhang

Artikel 3(1) verlangt, dass das Produkt so entworfen ist, dass die Datenzugriffspflicht „einfach, sicher, unentgeltlich und unmittelbar“ erfüllbar ist. Aus Architektur-Sicht heißt das: Ein dediziertes API-Surface (idealerweise REST/JSON oder gRPC mit OpenAPI-Spezifikation), eine Authentifizierung, die zwischen Endnutzer und Datenempfänger sauber trennt (OIDC mit Token-Delegation), Rate-Limits und Audit-Logging der Datenabrufe. Die alte Excel-Export-Funktion „auf Anfrage“ reicht nicht. Auch nicht die proprietäre Cloud-Konsole, in die nur Sie selbst hineinschauen. Der Anspruch der Verordnung ist, dass Nutzer:innen ihre Daten ohne Ihren manuellen Zwischenschritt abrufen können.

Datenmodell — strukturierte Eventlogs statt opaker Telemetrie

Die Datenzugriffspflicht bezieht sich auf „Produktdaten“ und „verbundene Dienste-Daten“. Was das konkret bedeutet, hängt vom Produkt ab — die Verordnung beschränkt sich auf Funktions- und Nutzungsdaten, ausgenommen sind sensible Geschäftsgeheimnisse und KI-Modell-Gewichte. In der Praxis heißt das: Ihre Telemetrie muss strukturiert vorliegen, nicht als binärer Blob, den nur Ihre eigene Auswertungs-Software lesen kann. Append-only Eventlogs in der Plattform-Datenbank, mit klarer Schema-Definition pro Event-Typ, Zeitstempel, Geräte-ID und semantischen Feldern, bilden hier die Grundlage. Dasselbe Datenmodell, das den Audit-Trail für CRA, NIS2 und ISO 9001 trägt, kann auch den Datenzugriffs-Anspruch des Data Act bedienen — wenn Sie es einmal sauber bauen.

Cloud-Portabilität — Datenmodell und Schnittstellen, nicht Marketing-Folie

Die Pflicht zum Anbieter-Wechsel zwingt Cloud-Anbieter, ihre Daten- und Metadaten-Strukturen so zu öffnen, dass Kund:innen die Migration tatsächlich durchführen können. Das ist mehr als ein Datenexport — es umfasst Konfigurationen, Identity-Mappings, Service-Topologien, Vertragsdaten. Wer als SaaS-Anbieter heute eine eigene proprietäre Datenstruktur pflegt, muss bis spätestens 12.01.2027 (Wegfall der Wechsel-Entgelte) eine Export-Strategie entwickelt haben, die mit branchenüblichen Standards kompatibel ist. Wer als Kunde eines Cloud-Anbieters operiert und seine Architektur zwischen Anbieter-spezifischen Diensten und portablen Open-Source-Komponenten geschickt austariert hat, hat hier weniger Sorgen — und für genau diese Architektur-Disziplin ist der Data Act ein Rückenwind. Datensouveränität in jeder Schicht der Architektur, nicht erst im Marketing.

Smart Contracts — wer sie einsetzt, dokumentiert die Lebenszyklus-Mechanik

Wenn Sie Smart Contracts für die Ausführung von Datenteilungs-Vereinbarungen verwenden — etwa für die automatisierte Abrechnung der Datenherausgabe an einen Datenempfänger — verlangt Artikel 36, dass Sie Robustheit, Zugangskontrolle, sichere Beendigung und Auditierbarkeit nachweisen. Das schließt Public Permissionless Blockchains de facto aus, sofern sie keine Beendigungs-Mechanik bieten. Praktikabel sind Permissioned-Ledger-Architekturen (Hyperledger, Corda) oder klassische, signierte Off-Chain-Vereinbarungen mit nachweislicher Logging-Pipeline. Wer Smart Contracts neu einführt, sollte bis zur Veröffentlichung der harmonisierten Normen die eigene Lösung gegen die in Artikel 36 explizit genannten Anforderungen messen und dokumentieren.

Konvergenz mit CRA, NIS2 und AI Act — eine Datenschicht für vier Verordnungen

Der Data Act steht nicht allein. Er trifft auf den Cyber Resilience Act (Anwendung ab 11.12.2027 — vernetzte Produkte mit Cybersicherheits-Pflichten), die NIS2-Richtlinie (in Deutschland seit 06.12.2025 in Kraft — Risiko-Management und Incident-Reporting), den AI Act (gestaffelte Anwendung, ab 02.08.2026 für Hochrisiko-Systeme) und die DSGVO. Vier Regelwerke, die auf dasselbe Datenmodell zugreifen — Telemetrie aus dem Feld, Nutzungsdaten, Wartungs-Logs, Modell-Inputs. Eine Plattform, die diese Pflichten nachträglich zusammenstrickt, baut sich Schulden ein. Eine Plattform, die Datenherkunft, Zweckbindung, Retentions-Politik, Zugriffsrechte und Audit-Trail als Felder im Datenmodell führt, kann auf alle vier antworten, ohne sich neu zu erfinden. Compliance in Datenmodell und API-Schicht verankert — nicht als nachgelagerte Korrektur.

Stand der EU-Anwendbarkeit (Mai 2026)

Die Verordnung trat am 11.01.2024 in Kraft (Artikel 50). Die gestaffelten Anwendungsdaten lauten:

12.09.2025: Allgemeine Anwendbarkeit — Datenzugriffsrechte (Kapitel II, Artikel 4–5), Wechsel-Pflichten der Cloud-Anbieter (Kapitel VI, Artikel 23 ff., mit Übergangsregelungen für Wechsel-Entgelte), Vorgaben für Datenteilungs-Verträge (Kapitel IV) und alle weiteren Kernpflichten
12.09.2026: Designpflicht aus Artikel 3(1) — gilt für vernetzte Produkte und zugehörige Dienste, die nach diesem Datum erstmals in den Verkehr gebracht werden
12.01.2027: Vollständiger Wegfall der Cloud-Wechsel-Entgelte und Egress-Gebühren (vorher: kostendeckende Berechnung zulässig)
12.09.2027: Erstreckung von Kapitel IV (Bestimmungen zu unfairen Vertragsklauseln) auf Bestandsverträge mit unbestimmter Laufzeit oder Restlaufzeit von mindestens 10 Jahren ab Inkrafttreten

Die harmonisierten Normen für Smart Contracts (Artikel 36) sind Stand Mai 2026 noch nicht im Amtsblatt veröffentlicht. Die EU-Kommission hat den Standardisierungsauftrag an CEN/CENELEC erteilt; mit Veröffentlichung wird im Lauf der nächsten 12–18 Monate gerechnet. Bis dahin tragen Anbieter die Beweislast über alternative Konformitäts-Pfade.

Die FAQ der EU-Kommission wird laufend aktualisiert (Stand Mai 2026: Version 1.4 vom 22.01.2026) und ist als praktischer Auslegungs-Leitfaden zu empfehlen. Eine offizielle Auslegungs-Verbindlichkeit hat sie nicht — die Letztentscheidung liegt bei den nationalen Aufsichtsbehörden und beim Europäischen Gerichtshof.

Stand der deutschen Umsetzung (Mai 2026)

Deutschland hat die Anwendbarkeit nicht abgewartet, aber die nationale Durchführung mit deutlicher Verzögerung umgesetzt. Das Gesetz zur Durchführung der Verordnung (EU) 2023/2854 (Datendurchführungsgesetz, DADG) wurde vom Bundestag am 26.03.2026 beschlossen. Es regelt Zuständigkeiten und das Bußgeld-Regime nach Artikel 40 der Verordnung.

Zentrale Aufsichtsbehörde ist die Bundesnetzagentur (BNetzA) — sie ist als zentrale Anlaufstelle und alleinige zuständige Behörde nach Artikel 37 Absatz 1 Data Act benannt und übernimmt Marktüberwachung, Beschwerdebearbeitung und Bußgeld-Verfahren. Eine besondere Rolle hat der/die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI): Wo personenbezogene Daten betroffen sind, ist der/die BfDI zuständig für die datenschutzrechtliche Bewertung und kann eigene Sanktionen nach DSGVO-Maßgabe verhängen. BNetzA und BfDI arbeiten kooperativ — die BfDI-Bewertung kann nicht isoliert angefochten werden, sondern nur mit der BNetzA-Gesamtentscheidung.

Das Bußgeld-Regime des DADG ist gestaffelt: Bis zu 5 Mio. € oder 2 % des weltweiten Jahresumsatzes für Unternehmen oberhalb 250 Mio. € Umsatz bei den schwersten Verstößen (insbesondere bei Umgehungs-Tatbeständen aus Artikel 6 in Verbindung mit Pflichten der Artikel 8–11), bis zu 500.000 € für Verstöße gegen die Kernpflichten, bis zu 100.000 € für Informations- und Mitwirkungspflichten, bis zu 50.000 € für leichtere Ordnungswidrigkeiten. Hinzu kommt — abweichend vom typischen DSGVO-Muster — die ausdrückliche Empfehlung des Gesetzgebers, wirtschaftliche Vorteile aus Verstößen über § 17 Absatz 4 OWiG abzuschöpfen. Wer mit Datenherausgabe-Verweigerung Wettbewerbsvorteile erzielt hat, riskiert die Abschöpfung des daraus erwachsenen Gewinns zusätzlich zum Bußgeld.

Was 2026 konkret zu tun ist

Für ein Greenfield-Projekt ist die Antwort klar: Bauen Sie das Datenmodell, die Zugriffs-API und die Cloud-Portabilität von Anfang an so, dass Sie Artikel 3(1) erfüllen, ohne nachzurüsten. Das heißt: strukturierte Eventlogs mit klarem Schema, dediziertes Datenzugriffs-API mit OIDC-basierter Authentifizierung, dokumentiertes Daten-Schema im OpenAPI-Format, Audit-Logging der Datenabrufe revisionssicher, ein dokumentierter Export-Pfad zwischen Cloud-Schichten. Das ist kein neuer Aufwand — es ist saubere Plattform-Architektur, die unter dem Data Act zur Pflicht wird.

Für Bestandssysteme — der Normalfall im Mittelstand — ist der Data Act ein Refactor-Trigger. Das Gesetz schreibt nicht vor, dass Sie ein 15 Jahre altes Telemetrie-Backend neu bauen. Es schreibt vor, dass Sie spätestens für Produkte, die Sie nach dem 12.09.2026 auf den Markt bringen, die Designpflicht erfüllen — und dass Sie für alle Bestandsprodukte ab 12.09.2025 die Datenzugriffs-Pflicht (auch ohne strukturelle Anpassung) operativ erfüllen können. Pragmatisch: Identifizieren Sie die Datenzugriffs-Lücke konkret. Welche Daten erfasst Ihr Produkt heute, in welcher Form sind sie verfügbar, was fehlt für ein API-First-Erlebnis? Erfahrungsgemäß sind die Top-Drei-Themen im Mittelstands-Setup ein fehlendes Authentifizierungs-Modell für Datenempfänger, ein nicht-strukturiertes Telemetrie-Format und eine fehlende Audit-Logging-Schicht. Refactor + Erweiterung schlägt in fast jedem Fall den Komplett-Neubau.

Für Cloud- und Edge-Anbieter ist die strategische Aufgabe klar: Bis 12.01.2027 müssen die Wechsel-Mechanik, Datenexport-Schnittstellen und Vertragsklauseln stehen. Das ist mehr als Marketing-Sprache — es ist ein operativer Migrations-Pfad, den Kund:innen testen werden. Wer das vorbereitet, erhält ein belastbares Differenzierungsmerkmal gegenüber Mitbewerbern, die unter Termindruck nachrüsten. Wer es nicht vorbereitet, riskiert nicht nur Bußgelder, sondern die Erosion der Vertragsbasis — Kunden können Verträge mit zwei Monaten Frist beenden, ohne dass die alten Lock-in-Mechanismen greifen.

Wie wir das angehen

Wir verkaufen keine „EU-Data-Act-Compliance-as-a-Service“. Compliance ist kein Produkt — sie ist die Konsequenz einer sauber gebauten Architektur. Was wir tun: Wir bauen Plattformen für vernetzte Produkte, in denen die Pflichten aus Data Act, CRA, NIS2 und DSGVO nicht nachträglich angeschraubt werden, sondern in Datenmodell und API-Schicht verankert sind. Datenzugriffs-API mit Token-Delegation, Append-only Eventlog pro Geräte-Instanz, dokumentiertes Daten-Schema, Audit-Trail revisionssicher, Cloud-Portabilität als Architektur-Prinzip — als konkret umgesetzte Architekturmuster.

Das B2B-IoT-Projekt LITE BLOX ist ein praktisches Beispiel: vernetzte Industrieeinheiten im Feld, Lifecycle-Datenmodell mit unveränderlichem Geburts-Snapshot pro Einheit, Append-only Eventlog für sicherheitsrelevante und Nutzungs-Ereignisse, Hosting in der EU bzw. der Schweiz. Wenn Sie ein vergleichbares Vorhaben verantworten — neue Plattform oder Refactor eines Bestandssystems unter Data-Act-Pflichten — sprechen wir gerne über die Architektur, bevor das Pflichtenheft den ersten Sprint erreicht.

Ressourcen

EU-Verordnung 2023/2854 (Data Act), konsolidierte Fassung: eur-lex.europa.eu/eli/reg/2023/2854
EU-Kommission, Data Act – Policy-Übersicht: digital-strategy.ec.europa.eu/en/policies/data-act
EU-Kommission, FAQ zum Data Act (Version 1.4 vom 22.01.2026): digital-strategy.ec.europa.eu — Data Act FAQ
EU-Kommission, Data Act erklärt: digital-strategy.ec.europa.eu/en/factpages/data-act-explained
BMDS, Data-Act-Durchführungsgesetz (Gesetzgebungsverfahren): bmds.bund.de — Gesetz zur Durchführung des Data Act
Deutscher Bundestag, Verabschiedung des DADG am 26.03.2026: bundestag.de — Bundestag verabschiedet EU-Vorgaben zum Datenzugang und zur Datennutzung
BfDI, Datenschutz und EU Data Act: bfdi.bund.de

Stand: Mai 2026. Die Auslegung einzelner Artikel kann sich durch Durchführungsrechtsakte, harmonisierte Normen für Smart Contracts (Artikel 36) und sektor-spezifische Verordnungen weiter ändern. Für eine rechtsverbindliche Beurteilung Ihres konkreten Falls verweisen wir auf qualifizierte Rechtsberatung.