Regulatorik 4 min read

Der EU Data Act: Was er für vernetzte Produkte und IoT bedeutet

Die September-2026-Frist des EU Data Act zwingt IoT- und Hersteller vernetzter Produkte zum Umdenken. Technische Anforderungen und Vorbereitung.

BrotCode
Der EU Data Act: Was er für vernetzte Produkte und IoT bedeutet

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, ist der 12. September 2026 Ihre nächste harte Frist. Ab diesem Datum müssen alle neuen vernetzten Produkte auf dem EU-Markt “Access by Design”-Prinzipien integrieren.

Der EU Data Act (Verordnung 2023/2854) trat im Januar 2024 in Kraft, mit gestaffelter Umsetzung. Die September-2026-Frist markiert den Punkt, ab dem Produktdesign-Anforderungen verpflichtend werden. 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.

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.

Vorbereitung auf September 2026

Jetzt (Q1 2026): Alle vernetzten Produkte auditieren, die Sie in der EU verkaufen. Datengenerierung jedes Produkts erfassen. Lücken identifizieren.

Q2 2026: Datenzugriffs-APIs entwerfen und bauen. Authentifizierung, Autorisierung und Drittanbieter-Delegation implementieren. Export-Pipelines aufbauen.

Q3 2026: Datenzugriff mit echten Nutzern und simulierten Drittanbieter-Integrationen testen. Produktdokumentation und Datenschutzhinweise aktualisieren.

12. September 2026: Alle neuen Produkte auf dem EU-Markt müssen konform sein.

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.

Artikel teilen
Compliance DSGVO Sicherheit Architektur

Verwandte Artikel

DSGVO-konforme Softwarearchitektur von Anfang an
Regulatorik 5 min read

DSGVO-konforme Softwarearchitektur von Anfang an

Wie Sie Software entwickeln, die standardmäßig DSGVO-konform ist — Datenminimierung, Einwilligungsmanagement, Recht auf Löschung und Privacy-First-Architekturmuster.

Brauchen Sie Hilfe beim Bauen?

Wir verwandeln komplexe technische Herausforderungen in produktionsreife Lösungen. Sprechen wir über Ihr Projekt.