2 Posts getaggt mit "Data Act"

Am 1. Dezember 2025 wurde im Deutschen Bundestag der deutsche Data-Act-Umsetzungsentwurf (Drucksache 21/2998) eingebracht.
Mit diesem nationalen Durchführungsgesetz legt die Bundesregierung fest, wie der EU Data Act ab 2025 in Deutschland überwacht, durchgesetzt und sanktioniert wird.

Damit wird erstmals konkret, welche Aufsichtsstrukturen, Bußgelder, Dokumentationspflichten und technischen Anforderungen auf Hersteller vernetzter Produkte, IoT-Anbieter und Dateninhaber zukommen. Der Entwurf macht deutlich: Data-Act-Compliance wird ein zentraler Bestandteil der Unternehmensführung.

---

1. Warum Deutschland ein Data-Act-Durchführungsgesetz benötigt​

Der EU Data Act definiert umfassende materielle Pflichten für Dateninhaber, Hersteller, Nutzer und Datenempfänger. Dazu gehören unter anderem:

• Bereitstellung von Daten aus vernetzten Produkten,
• Weitergabe von Daten an Dritte,
• Transparenzanforderungen,
• Interoperabilitäts- und Standardisierungsaspekte,
• Fairnesspflichten in Verträgen,
• sowie Datenzugriffe durch öffentliche Stellen in Notlagen.

Was die EU-Verordnung nicht regelt, ist wer in den Mitgliedstaaten diese Pflichten überwacht und durchsetzt.

Der deutsche Gesetzentwurf schließt genau diese Lücke: Er definiert Zuständigkeiten, Verfahren, Aufsichtsbefugnisse und Sanktionen, um den Data Act in Deutschland rechtsverbindlich operationalisierbar zu machen.

1.1. Struktur und Aufbau des deutschen Durchführungsgesetzes​

Der vorliegende Gesetzentwurf umfasst 14 Paragraphen, die sich in drei zentrale Themenblöcke gliedern:

1. Allgemeine Bestimmungen (§§ 1–3) – regeln Zweck, Anwendungsbereich und Definitionen.
2. Aufsicht und Befugnisse (§§ 4–10) – umfassen Zuständigkeiten der Bundesnetzagentur, Ermittlungsinstrumente, Koordinationsmechanismen und Dokumentationspflichten.
3. Sanktionen und Verfahren (§§ 11–14) – enthalten Bußgeldtatbestände, Zwangsgelder und Verfahrensvorschriften.

Diese Struktur verdeutlicht, dass der Schwerpunkt des Gesetzes auf der operationalen Durchsetzbarkeit der EU-Verordnung liegt und weniger auf der materiellen Regelung neuer Pflichten, die bereits durch den Data Act selbst vorgegeben sind.

2. Die wichtigsten Regelungen im deutschen Data-Act-Umsetzungsentwurf​

2.1. Bundesnetzagentur als zentrale Aufsichts- und Durchsetzungsbehörde​

Die Bundesnetzagentur (BNetzA) wird zur nationalen Leitbehörde für den Data Act. Sie fungiert als:

• Anlaufstelle für Nutzer, Unternehmen und Behörden,
• Aufsichtsbehörde für alle Data-Act-Pflichten,
• Beschwerdestelle nach Artikel 38 der EU-Verordnung,
• Koordinatorin im Austausch mit EU-Kommission und Mitgliedstaaten,
• Zulassungsbehörde für Streitbeilegungsstellen.

Deutschland setzt damit auf Zentralisierung, wie man sie bereits aus Telekommunikations- und Energierecht kennt. Domänen in denen Regulierung nicht unbedingt als "sanft" gilt.

2.2. Erweiterte Ermittlungs- und Eingriffsbefugnisse​

Der Entwurf verleiht der BNetzA ein umfangreiches Instrumentarium, darunter:

• Auskunftsverlangen,
• Vorlagepflichten technischer und organisatorischer Unterlagen,
• Vernehmung von Zeugen und Sachverständigen,
• Vor-Ort-Prüfungen und Augenscheinnahmen,
• vorläufige Anordnungen zur Sicherung von Pflichten.

2.3. Bußgelder und Zwangsgelder im nationalen Kontext​

Der Gesetzentwurf enthält einen konkreten Bußgeldkatalog, unter anderem:

• bis 500.000 € bei Verstößen gegen Transparenz- oder Bereitstellungspflichten,
• bis 5 Mio. € bei besonders schwerwiegenden Verstößen,
• bis zu 2 % des weltweiten Jahresumsatzes für Unternehmen über 250 Mio. € Jahresumsatz (z. B. im Kontext von Art. 5 Abs. 3 Data Act),
• Zwangsgelder bis 500.000 € zur Durchsetzung behördlicher Anordnungen.

Deutschland nutzt seinen Handlungsspielraum damit konsequent am oberen Ende. Wenn man bisher dachte, der Data Act sei „eher symbolisch“, dann ist hier der Moment, in dem dieser Gedanke leise den Raum verlässt.

2.4. Verpflichtung zur Bereitstellung „geheimnisfreier“ Dokumentenversionen​

Eine Besonderheit des deutschen Entwurfs:
Unternehmen müssen bei vertraulichen Dokumenten zwei Versionen vorlegen:

1. die vollständige Fassung,
2. eine geschwärzte, geheimnisfreie Zweitversion.

Diese Parallelstruktur wird in der EU-Verordnung nicht ausdrücklich verlangt und wird neue Prozesse insbesondere in Rechtsabteilungen und Produktorganisationen erfordern.

2.5. Zusammenarbeit zwischen Bundesnetzagentur und Datenschutzaufsicht​

Der Entwurf regelt das Zusammenspiel klar:

• Der BfDI ist zuständig für Aspekte personenbezogener Daten.
• Die BNetzA bleibt führende Behörde und ist an datenschutzrechtliche Bewertungen des BfDI gebunden.

Damit entsteht eine duale Aufsicht, die Unternehmen organisatorisch berücksichtigen müssen.

3. In welchen Bereichen Deutschland den Data Act verschärft​

Der deutsche Gesetzgeber geht in mehreren Punkten über den EU-Rahmen hinaus:

(1) Konkreter Bußgeldkatalog
Die Bußgelder sind detailliert an einzelne Tatbestände gekoppelt.

(2) Hohe Zwangsgelder
Diese Anreize sind aus der Telekommunikationsaufsicht bekannt und sie sind wirksam.

(3) Pflicht zur geheimnisfreien Zweitversion
Mehr Transparenz, mehr Aufwand.

(4) Umfangreiche Ermittlungsinstrumente
Der Maßnahmenkatalog entspricht im Stil kartellrechtlichen Befugnissen.

4. Wo der Gesetzentwurf Unternehmen entlastet​

(1) Klare Zuständigkeit der Bundesnetzagentur
Statt fragmentierter Zuständigkeiten gibt es eine zentrale Behörde.

(2) Förderung freiwilliger Vereinbarungen
Die Behörde soll Kooperationen zwischen Hersteller, Nutzer und Dritten erleichtern.

(3) Zulassung von Streitbeilegungsstellen
Weniger Konfliktkosten, mehr Rechtssicherheit.

5. Was der Data Act für Hersteller vernetzter Produkte und IoT-Anbieter bedeutet​

Der Data Act wird 2025 zu einem strukturellen Compliance-Thema, technisch wie organisatorisch.

5.1. Technische Anforderungen an Data-Act-konforme Schnittstellen​

Unternehmen benötigen künftig:

• sichere, skalierbare APIs zur Datenbereitstellung,
• Echtzeit- oder Near-Real-Time-Zugänge,
• fein granuliertes Rechte- und Berechtigungsmanagement für Nutzer und Dritte,
• vollständige Audit-Logs,
• automatisierte Prozesse zur Bearbeitung von Datenanfragen,
• maschinenlesbare Datenformate,
• technische Nachweisdokumentation für Behörden.

Für viele IoT-Architekturen entsteht hier eine deutliche Reifegradlücke.

5.2. Organisatorische Konsequenzen​

Unternehmen müssen:

• standardisierte Anfrageprozesse etablieren,
• Dokumentationspflichten erfüllen (einschließlich Ablehnungen),
• technische Informationen transparent bereitstellen,
• Geschäftsgeheimnisse sauber klassifizieren,
• interne Rollen und Verantwortlichkeiten definieren.

Ein Großteil der Compliance ist prozessual, nicht technisch.

5.3. Rechtliche Risikosteuerung​

Mit den im Gesetzentwurf definierten Sanktionsinstrumenten entsteht:

• ein quantifizierbares finanzielles Risiko,
• ein Reputationsrisiko durch mögliche öffentliche Entscheidungen,
• ein Haftungsrisiko bei unzureichender oder widersprüchlicher Datenbereitstellung.

Die strategische Priorisierung von Compliance wird dadurch unausweichlich.

5.4. Markt- und Wettbewerbsdynamik​

Unternehmen, die Data-Act-Konformität frühzeitig sicherstellen, schaffen sich einen Vorteil:

• bessere Verhandlungsposition gegenüber OEMs,
• schnellere Integration in Ökosysteme,
• höhere Attraktivität für datenbasierte Geschäftsmodelle,
• geringeres regulatorisches Risiko.

Data-Act-Readiness wird bereits 2025 ein Beschaffungs- und Partnerschaftskriterium werden.

6. Was der Gesetzentwurf für Data-Act-Technologielösungen bedeutet​

Durch die klare nationale Umsetzung steigt die Nachfrage nach:

• standardisierten APIs,
• Data-Act-konformen Datenaustauschplattformen,
• automatisierten Nutzer- und Drittempfängerportalen,
• technischer Compliance-Dokumentation,
• Audit-Logs,
• Reporting-Modulen für Behörden,
• Tools zur Verwaltung und Klassifizierung von Geschäftsgeheimnissen.

Viele Anbieter werden hier ihre Lösungen erweitern und für den Data Act rüsten müssen, was zusätzliche Investitionen und laufende Kosten bedeutet. Um zusätzliche Ausgaben für das Erreichen der Data Act Compliance zu verhinder können Hersteller auf spezielle Anbieter von Data-Act-Technologie (wie z.B. das Data Act Kit) setzen.

7. Fazit: Der deutsche Gesetzentwurf macht die Data-Act-Pflichten verbindlich – und drängt Unternehmen zum Handeln​

Mit der Drucksache 21/2998 schafft die Bundesregierung die Grundlage für eine konsequente, zentralisierte und rechtlich robuste Durchsetzung des EU Data Act.

Für Unternehmen bedeutet dies:

• klare Zuständigkeiten,
• präzise Sanktionsmechanismen,
• hohe Bußgeldrisiken,
• umfassende Transparenzanforderungen,
• erweiterte behördliche Befugnisse,
• und vor allem: keine Zeit zu verlieren.

Die technische und organisatorische Umsetzung der Data-Act-Pflichten ist anspruchsvoll, aber sie eröffnet zugleich neue Potenziale für datengetriebene Innovationen.

Unternehmen, die frühzeitig handeln, reduzieren nicht nur regulatorische Risiken, sondern gewinnen einen strategischen Vorteil in einem zunehmend vernetzten und datenbasierten Markt.

---

FAQ zum deutschen Data-Act-Umsetzungsentwurf​

Wann tritt der Data Act in Deutschland in Kraft?​

Der EU Data Act gilt ab dem 12. September 2025 unmittelbar, unabhängig des deutschen Durchführungsgesetzes. Das deutsche Durchführungsgesetz regelt die nationale Aufsicht und Durchsetzung.

Welche Behörde überwacht den Data Act in Deutschland?​

Die Bundesnetzagentur wird zentrale Aufsichts- und Durchsetzungsbehörde.

Welche Bußgelder drohen?​

Je nach Verstoß bis zu 500.000 €, in schweren Fällen bis 5 Mio. € oder 2 % des weltweiten Jahresumsatzes.

Wer ist vom Data Act besonders betroffen?​

Hersteller vernetzter Produkte, IoT-Anbieter, Dateninhaber, Nutzer und Dritte, die Daten anfordern oder erhalten.

Welche technischen Anforderungen stellt der Data Act?​

Unternehmen müssen Data-Act-konforme APIs, Rechteverwaltung, Audit-Logs und automatisierte Anfrageprozesse bereitstellen.

Was bedeutet die Pflicht zur geheimnisfreien Dokumentversion?​

Unternehmen müssen künftig eine geschwärzte, nicht-vertrauliche Version sensibler Unterlagen zusätzlich zur Vollversion bereitstellen.

⸻

The EU Data Act is set to create significant new rules for the digital economy, particularly for data generated by connected products-the Internet of Things (IoT). From smart appliances and wearables to industrial machinery and vehicles, these devices produce a constant stream of valuable information. At the very heart of this regulation is Article 4, a provision that redefines the relationship between the users of these products and the companies that manufacture or service them (the "data holders").

Article 4 establishes a clear right for users to access the data they help create. For a long time, this data was often treated as the exclusive property of the manufacturer, locked away in proprietary systems. This regulation changes that, mandating that data holders make this information available to the user. This isn't just about transparency; it's about enabling users-who can be individuals or businesses-to use their data for third-party services, like independent repair, analytics, or switching providers. This post will break down what Article 4 demands and explore the practical steps for implementing a system that is secure, compliant, and user-friendly.

---

What Article 4 Demands: The User's Right to Access​

Article 4, Paragraph 1, lays down the fundamental new right. It states that when a user cannot directly access data from their connected product, the data holder must make that data available. This isn't a vague suggestion; the law is highly specific about the conditions for this access. The data must be provided "without undue delay" and "free of charge." This implies that data holders cannot create long waiting periods or erect paywalls that would make access difficult.

Furthermore, the data provided must be of the "same quality as is available to the data holder" and must include the "relevant metadata necessary to interpret and use" it. This is a critical point. It prevents a data holder from offering the user a lower-quality, summarized, or incomplete dataset while keeping the high-value, detailed data for themselves. The format is also specified: "comprehensive, structured, commonly used and machine-readable." This requirement moves us beyond simple, non-usable data dumps and pushes for formats that can be easily processed by other software, such as through an API or a structured file export (like JSON or CSV). Where technically feasible, this access should even be continuous and in real-time.

From Legal Text to User Interface: Building the Data Access Journey​

Complying with Article 4 isn't just a backend legal challenge; it's a front-end design challenge. The regulation puts the user's experience at the center of the process. In practice, this begins with a clearly defined activation process for a new product. From the very start, the user's journey should include transparent notifications about what data is being collected and their new rights to access it. This means integrating data access options directly into the product's user interface, whether that's a mobile app, a web portal, or another customer touchpoint.

This is where Article 4, Paragraph 4, becomes directly relevant. This provision effectively bans "dark patterns." It states that data holders "shall not make the exercise of choices or rights... unduly difficult," for example, by "subverting or impairing the autonomy, decision-making or choices of the user." This means the design must be clear and neutral. Hiding the "data export" button in an obscure menu or using confusing language to discourage a user from sharing their data with a third party is explicitly forbidden. The entire journey-from activation to data sharing to revoking access-must be coherent, intuitive, and straightforward.

Delivering the Data: Secure, Configurable, and Auditable Channels​

Once a user requests their data, how should it be delivered? Article 4(1) requires a "simple request through electronic means." This points to the need for robust, accessible export tools. Users should be met with clear instructions, not technical jargon, ensuring they can get their data without friction. These tools must operate through secure, interoperable channels. For many data holders, this will mean developing APIs that allow users (or third parties they authorize) to pull data in a structured, continuous way. For other use cases, simple file downloads or direct batch exports might be more appropriate.

The key is offering configurable access options. A user should be able to manage the frequency and scope of their data sharing. They might want a one-time file download of their smart thermostat's history, or they might want to grant near real-time API access to a third-party energy optimization service. This flexibility allows users to tailor data sharing to their specific needs while respecting the principle of data minimization. On the backend, this entire system must be governed by strong access controls, detailed usage logs, and audit-ready records. This is essential not only for proving compliance to regulators but also for maintaining security and trust with the user.

Balancing Access: Security, Personal Data, and Trade Secrets​

Article 4 does not create an unconditional, absolute right to all data. It provides important and necessary exceptions to protect other legitimate interests. The first major exception is for product security. Paragraph 2 allows a data holder to "restrict or prohibit" data access if that access "could undermine security requirements... resulting in a serious adverse effect on the health, safety or security of natural persons." This is a high bar and is not a blanket excuse to deny access. Any such refusal must be documented and notified to the relevant national authority.

The second major consideration is personal data. If the user requesting the data (e.g., a company owning a fleet of vehicles) is not the data subject (e.g., the employee driving the vehicle), Paragraph 12 makes it clear that GDPR rules apply. Any personal data can only be shared if there is a valid legal basis for processing it under GDPR. This reinforces that the Data Act works alongside, not in place of, existing data protection laws.

The most complex balance, however, is with trade secrets. Paragraphs 6 through 9 deal with this directly. Data holders can, and should, protect their trade secrets. But they cannot use "trade secrets" as a simple excuse to deny all data access. Instead, the law creates a process of "cooperation." The data holder must first identify which data is protected as a trade secret. Then, the data holder and the user must "agree on... necessary measures to preserve [their] confidentiality." This could involve confidentiality agreements (NDAs) or specific technical protocols that limit how the data can be used or seen. Only if the user fails to implement these measures, or in "exceptional circumstances" where the holder can prove a high likelihood of "serious economic damage" despite the measures, can the holder refuse the request.

New Rules for Both Sides: User and Data Holder Obligations​

Finally, Article 4 introduces new rules of engagement that apply to both the user and the data holder, creating a more level playing field. For the user, Paragraph 10 provides a key limitation: a user who obtains data cannot use it "to develop a connected product that competes with the connected product from which the data originate." This rule is designed to prevent a company from simply buying a competitor's machine, extracting all its operational data via an Article 4 request, and using that data to reverse-engineer their own competing product.

On the other side, data holders face a similar and equally important restriction. Paragraph 13 states that a data holder cannot use the user's non-personal data "to derive insights about the economic situation, assets and production methods of... the user" in a way that "could undermine the commercial position of that user." For example, a manufacturer of industrial smart-factory machines cannot analyze the output data from its clients' factories to then enter the market and compete directly with those clients. Furthermore, data holders are generally prohibited from sharing this data with other third parties for their own commercial purposes. These "dual-restraint" clauses are intended to ensure that the data access right is used for its intended purpose-user benefit and third-party services-not as a weapon for anti-competitive behavior.