Ihre Nutzer besitzen ihre Daten. Die EU stellt das sicher.
Wenn Sie vernetzte Produkte, Smart Devices oder IoT-Systeme bauen, die in der EU verkauft werden, liegt die Frist, auf die Sie hingearbeitet haben, bereits hinter Ihnen. Produkte, die nach dem 12. September 2026 auf den EU-Markt gebracht werden, müssen “Access by Design”-Prinzipien integrieren.
Das ist keine Empfehlung. Das ist geltendes Recht.
Der EU Data Act (Verordnung 2023/2854) trat im Januar 2024 in Kraft und gilt gestaffelt. Der größte Teil ist seit dem 12. September 2025 anwendbar. Seitdem greift die Herausgabepflicht: Wenn Ihr vernetztes Produkt Daten während der Nutzung generiert, müssen Nutzer diese Daten “einfach, sicher, kostenlos, in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format, kontinuierlich und in Echtzeit” abrufen können.
Der 12. September 2026 hat die schwierigere Hälfte hinzugefügt. Produkte, die danach auf den Markt kommen, müssen so konzipiert sein, dass die Daten standardmäßig direkt zugänglich sind, nicht erst auf Anfrage über irgendein Backoffice.
Jedes Wort in diesem Zitat ist eine technische Anforderung.
Was betroffen ist
Der Data Act umfasst “vernetzte Produkte”: jeden materiellen Gegenstand, der Daten über seine Nutzung oder Umgebung erhebt, generiert oder sammelt und diese übermitteln kann. Das ist breit gefasst.
Smart-Home-Geräte. Vernetzte Fahrzeuge. Industriemaschinen. Wearables. Intelligente Haushaltsgeräte. Landwirtschaftliche Sensoren. Energiemonitoring-Systeme. Vernetzte Medizinprodukte. Grundsätzlich alles mit einem Sensor und einer Netzwerkverbindung.
“Verbundene Dienste” sind ebenfalls betroffen. Die App, die Ihr smartes Thermostat steuert. Die Cloud-Plattform, die die Daten Ihres vernetzten Fahrzeugs speichert.
Die Verordnung umfasst sowohl personenbezogene als auch nicht-personenbezogene Daten. Rohe Sensorausgaben. Vorverarbeitete Informationen. Metadaten. Alles.
Die Kernanforderungen
Access by Design
Produkte, die nach dem 12. September 2026 auf den Markt gebracht werden, müssen von Grund auf so konzipiert sein, dass sie Nutzerdatenzugriff ermöglichen. Das ist eine Architekturanforderung, kein nachträglicher Patch.
Was “maschinenlesbar” in der Praxis bedeutet: JSON, CSV, XML oder jedes strukturierte Format, das programmatisch verarbeitet werden kann. Kein PDF-Bericht. Kein Dashboard-Screenshot.
Datenweitergabe an Dritte
Nutzer können verlangen, dass ihre Daten an Dritte weitergegeben werden. Wenn Ihr Kunde die Daten seines vernetzten Fahrzeugs an eine unabhängige Werkstatt senden möchte, müssen Sie das ermöglichen.
Der Dritte darf die Daten nicht verwenden, um ein konkurrierendes vernetztes Produkt zu entwickeln. Aber er kann sie für kompatible Dienste, Wartung, Reparaturen und Analysen nutzen.
Kein Gatekeeping
Sie dürfen den Datenzugriff nicht an die Nutzung Ihres proprietären Dienstes knüpfen. Sie dürfen die Leistung des vernetzten Produkts nicht verschlechtern, wenn der Nutzer Daten über Drittanbieter-Tools abruft. Sie dürfen keinen Aufpreis für den Datenzugriff verlangen.
Geschäftsmodell-Implikationen
Für manche Unternehmen wird es hier unbequem.
Wenn Ihr Umsatzmodell darauf basiert, Nutzer in Ihr Daten-Ökosystem einzusperren (Premium-Analytics, API-Zugang, Export der eigenen Daten kostenpflichtig), erzwingt der Data Act ein Umdenken. Nutzergenerierte Daten aus vernetzten Produkten sind nicht mehr Ihr proprietäres Gut.
Das trifft besonders das industrielle IoT. Maschinenhersteller, die “Data-as-a-Service” auf vernetzte Geräte aufsetzen, müssen den Maschinendatenzugriff von Mehrwert-Analytik trennen.
Nutzer bekommen die Rohdaten kostenlos. Ihre Analytik-Schicht darüber kann weiterhin ein kostenpflichtiger Service sein. Aber die zugrundeliegenden Daten dürfen nicht als Geisel gehalten werden.
Die Geschäftschance ist allerdings real. Unternehmen, die Datenoffenheit begrüßen, können sich durch die Qualität ihrer Analytik differenzieren. Geschlossene Systeme sind eine Belastung. Offene Plattformen gewinnen.
Technische Umsetzung
Datenzugriffs-APIs
RESTful APIs oder GraphQL-Endpunkte bauen, die produktgenerierte Daten für authentifizierte Nutzer bereitstellen. Standard-Authentifizierung (OAuth 2.0), strukturierte Antworten (JSON), Paginierung für große Datensätze, Echtzeit-Streaming für kontinuierliche Daten (WebSockets oder Server-Sent Events).
Datenformat-Standards
Wo branchenspezifische Standards existieren, nutzen Sie diese. MQTT für IoT-Messaging. OPC UA für industrielle Automatisierung. Matter für Smart-Home-Interoperabilität.
Echtzeitzugriff
“Kontinuierlich und in Echtzeit” bedeutet: Ihre Architektur muss Streaming-Datenzugriff unterstützen. Für Sensordaten, die jede Sekunde aktualisiert werden, reichen tägliche Batch-Exporte nicht.
Event-driven Architekturen funktionieren hier gut. Sensorwerte gehen in einen Message Broker (Kafka, RabbitMQ, MQTT Broker). Nutzer abonnieren ihre Datenströme.
Drittanbieter-Autorisierung
OAuth 2.0 mit begrenzten Tokens ist der Standardansatz. Nutzer gewähren bestimmten Dritten Zugang zu bestimmten Datenkategorien für eine definierte Dauer. Widerruf muss sofort wirksam sein.
Datenportabilität
Nutzer können einen vollständigen Export ihrer historischen Daten anfordern. Bauen Sie eine Export-Pipeline, die alle Daten aus dem Produktlebenszyklus aggregiert und in einem Standardformat liefert.
Was ist mit Geschäftsgeheimnissen?
Der Data Act schützt Geschäftsgeheimnisse. Sie müssen keine proprietären Algorithmen, Modellgewichte oder Fertigungsprozesse offenlegen. Aber die Daten, die das Produkt während der Nutzung generiert, gehören dem Nutzer.
In der Praxis: Die rohen Temperaturmesswerte eines vernetzten Industrieofens sind Nutzerdaten. Der Predictive-Maintenance-Algorithmus, der diese Messwerte analysiert, ist Ihr Geschäftsgeheimnis.
Dokumentieren Sie klar, was bei Ihnen ein Geschäftsgeheimnis ist und warum. Aufsichtsbehörden werden zu weit gefasste Geheimnisansprüche hinterfragen, mit denen der Datenzugriff eingeschränkt wird.
Pflichten für Cloud-Anbieter
Der Data Act adressiert auch Cloud-Lock-in. Anbieter von Datenverarbeitungsdiensten müssen Werkzeuge für Datenexport und Anbieterwechsel bereitstellen.
Zum 12. Januar 2027 fallen die Wechselentgelte vollständig weg. Bis dahin dürfen sie die Kosten nicht übersteigen, die dem Anbieter durch den Wechsel tatsächlich entstehen.
Wenn Sie eine cloudbasierte IoT-Plattform anbieten, gilt das auch für Ihren Dienst. Nutzer müssen ihre Daten und Produktkonfigurationen zu einer anderen Plattform migrieren können.
Entweder Sie haben geliefert oder nicht
Einen Vorbereitungsplan können wir Ihnen nicht mehr anbieten. Der 12. September 2026 ist vorbei, Sie lesen das also aus einer von zwei Positionen.
Wenn Access by Design ausgeliefert ist, ist der nächste Termin kein Architekturthema. Kapitel IV verbietet unfaire Vertragsklauseln, die ein Unternehmen einem anderen einseitig auferlegt, und erfasst jeden Vertrag, der nach dem 12. September 2025 geschlossen wurde.
Am 12. September 2027 greift es rückwirkend. Verträge, die am oder vor dem 12. September 2025 geschlossen wurden, fallen dann ebenfalls darunter, sofern sie unbefristet laufen oder frühestens zehn Jahre nach dem 11. Januar 2024 enden.
Holen Sie diese Verträge jetzt hervor und lesen Sie die Datenklauseln.
Und wenn nicht ausgeliefert wurde? Weniger dramatisch als befürchtet, aber auch weniger nachsichtig als erhofft.
Entscheidend ist, woran die Pflicht überhaupt anknüpft. Artikel 2 Nummer 22 definiert das Inverkehrbringen als die erstmalige Bereitstellung eines vernetzten Produkts auf dem Unionsmarkt, und das passiert genau einmal. Niemand zwingt Sie, die Geräte nachzurüsten, die bereits bei Ihren Nutzern stehen, und ein Firmware-Update bringt diese Geräte nicht erneut in Verkehr.
Diese Atempause ist dünner, als sie klingt. Zwei Gründe.
Erstens deckt sie nur die Designpflicht ab. Artikel 4 und 5 gelten seit dem 12. September 2025 für Ihre vernetzten Produkte, unabhängig davon, wann sie ausgeliefert wurden.
Kommt der Nutzer nicht direkt am Produkt an seine Daten, müssen Sie sie auf Anfrage herausgeben und an jeden Dritten weitergeben, den er benennt.
Ein Portal. Ein Export-Endpunkt. Ein Support-Kanal, der tatsächlich antwortet. Irgendetwas.
Zweitens ist die Atempause bereits aufgebraucht. Alles, was Sie ab jetzt erstmals auf dem EU-Markt bereitstellen, fällt vom ersten Tag an darunter.
Die Arbeit bleibt also dieselbe, nur ohne Kalender. Auditieren Sie jedes vernetzte Produkt, das Sie in der EU verkaufen, und erfassen Sie die Daten, die es generiert. Finden Sie die Lücke zwischen dem, was ein Nutzer heute erreichen kann, und dem, was die Artikel 3, 4 und 5 verlangen.
Dann bauen Sie die Zugriffsschicht: Authentifizierung, Drittanbieter-Delegation, Export-Pipelines. Testen Sie sie mit echten Nutzern und einer simulierten Drittanbieter-Integration. Aktualisieren Sie Produktdokumentation und die vorvertraglichen Angaben nach Artikel 3 Absatz 2, und sorgen Sie dafür, dass Ihr Support eine Data-Act-Anfrage erkennt.
Für die breitere EU-Regulierungslandschaft siehe unseren Pillar-Guide zur EU-Compliance für Softwareteams. Wenn Ihre vernetzten Produkte personenbezogene Daten verarbeiten, ist unser DSGVO-Architektur-Leitfaden Pflichtlektüre. Für Datenresidenz-Fragen: Wo Sie Ihre EU-Daten speichern sollten.
Vernetzte Produkte für den EU-Markt bauen? Lassen Sie uns Ihre Datenzugriffs-Architektur gemeinsam gestalten. Wir helfen IoT-Teams, Data-Act-Anforderungen zu erfüllen, ohne Wettbewerbsvorteile aufzugeben.
