Data Act ab 12. September 2026: Access by Design ist eine ERP-Frage

Drei Monate vor Markteinführung sitzt der IT-Leiter eines Maschinenbauers im Hunsrück in einer Runde mit Entwicklung und Vertrieb, dazu der Lieferant der Maschinensteuerung. Auf dem Tisch liegt eine neue, vernetzte Anlagengeneration, die im Herbst in den Markt geht. Jemand fragt nach dem Data Act und dem 12. September. Der Steuerungs-Lieferant winkt ab: “Access by Design? Machen wir auf der SPS.” Alle nicken, das Thema wandert ins Protokoll, Zeile 14, Verantwortlicher: extern. Die Frage, die in diesem Raum niemand stellt: Wer berechtigt den Nutzer-Zugriff auf die Maschinendaten, wenn dieselbe Anlage in drei Jahren ans neue ERP angebunden wird?

Der Stichtag steht, und er ist näher als die meisten denken

Ab dem 12. September 2026 greift Artikel 3(1) der Verordnung (EU) 2023/2854, des EU Data Act, für jedes vernetzte Produkt, das nach diesem Datum erstmals in Verkehr gebracht wird. Der Wortlaut ist nüchtern und folgenreich zugleich: Der Nutzer muss standardmäßig und einfach auf die vom Produkt erzeugten Daten zugreifen können. Sicher muss dieser Zugriff sein und in einem gängigen, strukturierten, maschinenlesbaren Format erfolgen, wo technisch machbar direkt am Produkt oder über einen verbundenen Dienst.

Das ist keine bloße Anregung, sondern eine Gestaltungspflicht, die vor der Auslieferung erfüllt sein muss.

Die DIHK ordnet die Stufe ab 12. September 2026 so ein: Geräte müssen so gestaltet sein, dass Daten direkt und automatisch verfügbar sind, ohne Umweg über den Hersteller. Genau dieser Halbsatz, “ohne Umweg über den Hersteller”, verschiebt das Thema aus der Firmware heraus. Denn ein direkter, berechtigter, strukturierter Zugriff entsteht nicht an einem Sensor. Er entsteht an einer Schnittstelle, einem Berechtigungsmodell und einem Format-Standard, also genau dort, wo im Mittelstand das ERP, das MES und die Integrationsplattform sitzen.

Die Schublade, in der die Pflicht gerne verschwindet

In der Praxis landet Access by Design reflexhaft beim Steuerungs-Lieferanten. Die Logik wirkt zwingend: Die Daten entstehen an der Maschine, also regelt sie der, der die Maschine baut. Diese Zuordnung ist bequem, weil sie eine ungeliebte Pflicht aus dem Haus schiebt, und sie ist teuer, weil sie die Pflicht im falschen System verankert.

Eine SPS misst und steuert. Was sie nicht kann, ist ein dauerhaftes Berechtigungsregime über mehrere Produktgenerationen, mehrere Kunden und mehrere Backend-Wechsel hinweg führen. Wer im September eine Anlage ausliefert und die Zugriffslogik in der Steuerung verdrahtet, hat das Problem nur eingefroren, statt es zu lösen. Beim nächsten ERP-Wechsel, bei der nächsten MES-Ablösung, bei jeder Plattform-Integration muss dieselbe Pflicht erneut nachgebaut werden. Das ist die unsichtbare Wiederholungsrechnung, die in keinem Pflichtenheft des Steuerungs-Lieferanten auftaucht.

In meiner Beratungspraxis sehe ich diese Fehlzuordnung regelmäßig bei genau den Häusern, die ihre Integration über offene Schnittstellen ohnehin schon als Dauerbaustelle führen. Die Data-Act-Pflicht setzt sich auf einen Datenbackbone, der oft selbst noch nicht sauber definiert ist.

Warum die Pflicht am Backend hängt, nicht an der Steuerung

Artikel 3(1) verlangt strukturierte, sichere, maschinenlesbare Bereitstellung an den Nutzer. Jedes dieser drei Wörter beschreibt eine Backend-Aufgabe.

Strukturierte Bereitstellung braucht ein definiertes Datenmodell und einen Format-Standard statt eines Roh-Telemetrie-Dumps. Sicher wird die Bereitstellung erst durch ein Berechtigungskonzept, das entscheidet, wer was sehen darf, samt der Schranke für Geschäftsgeheimnisse. Und maschinenlesbar ist sie nur über eine dokumentierte Schnittstelle, über die ein Nutzer oder ein von ihm beauftragter Dritter die Daten abruft.

Die Artikel 4 und 5 der Verordnung (EU) 2023/2854 machen das noch deutlicher. Sie setzen die Geschäftsgeheimnis-Schranke. Es geht eben nicht um alle Unternehmensdaten, sondern um die vom vernetzten Produkt und zugehörigen Dienst erzeugten Produkt- und Servicedaten, und auch die nur unter dem Vorbehalt schützenswerter Geheimnisse. Diese Filterung, dieses “wer darf was unter welcher Bedingung”, ist ein Berechtigungs- und Governance-Problem. Es lebt im Rollen- und Rechtemodell des ERP oder MES, nicht in der Firmware einer Steuerung.

Wer das Schichten-Modell der ERP-Datenarchitektur kennt, erkennt das Muster sofort: Die Zugriffsschicht ist die teuerste, weil sie über alle Anwendungen hinweg konsistent sein muss. Eine in der SPS vergrabene Berechtigung ist genau das Gegenteil von konsistent.

Der harte Termin, sauber von 2025 getrennt

An dieser Stelle entsteht regelmäßig Verwirrung, weil zwei Daten im Umlauf sind. Die allgemeine Anwendbarkeit des Data Act begann am 12. September 2025. Die hier entscheidende Gestaltungspflicht aus Artikel 3(1) greift erst am 12. September 2026, und sie greift nur für vernetzte Produkte, die nach diesem Datum erstmals in Verkehr gebracht werden. Die Kanzlei Greenberg Traurig hat im September 2025 genau diese Trennung herausgearbeitet: Bestandsmaschinen im Feld fallen nicht unter die Design-Pflicht, es gibt keinen Nachrüst-Zwang.

Für die Durchsetzung sorgt das deutsche Recht. Das Datenverordnung-Anwendungs-und-Durchsetzungs-Gesetz, kurz DADG, hat der Bundestag am 26. März 2026 beschlossen, in Kraft getreten ist es am 30. Mai 2026. Zentrale Durchsetzungs- und Koordinierungsbehörde ist die Bundesnetzagentur. Der Bußgeldkatalog in § 15 DADG sieht Geldbußen bis zu 500.000 Euro vor, soweit die Zuständigkeit der BNetzA reicht.

Die Rechnung für den Maschinenbauer im Hunsrück ist damit einfach gestellt. Die nächste vernetzte Anlagengeneration, die nach dem 12. September ausgeliefert wird, braucht die Zugriffs-Architektur vorher, als Auslieferungsvoraussetzung und nicht als nachgereichtes Update.

Was bis zur Markteinführung zu tun ist

Drei Dinge gehören in den Projektplan, und zwar mit einem Owner aus der IT, nicht allein beim externen Lieferanten.

Zuerst die Zuordnung. Spätestens zwölf Wochen vor Markteinführung muss feststehen, wer im Haus die Artikel-3-Datenbereitstellung verantwortet. Das ist eine Rolle für den ERP- oder Daten-Owner, weil die Pflicht über die Lebensdauer der Maschine hinweg im Backend gepflegt wird. Der Steuerungs-Lieferant liefert dabei zu, ohne die Pflicht selbst zu verantworten.

Dann die Schnittstellen-Architektur im Backbone. Es muss dokumentiert sein, wo die geforderten Daten entstehen, wo sie strukturiert vorgehalten werden und welche API sie maschinenlesbar an den Nutzer liefert. Diese Festlegung gehört vor die Auslieferung, nicht in eine spätere Wartungsrunde. Sauberer Datenbackbone heißt hier auch sauberer Ausgangszustand, weshalb Datenqualität die Vorbedingung jeder Bereitstellungspflicht ist und nicht ihr Nebenprodukt.

Bleibt die Schranke, und sie entscheidet über die Folgekosten. Die Geschäftsgeheimnis-Logik aus Artikel 4 und 5 gehört ins Berechtigungsmodell des ERP oder MES abgebildet, nicht in die Firmware. Genau hier entscheidet sich, ob die Pflicht einmal sauber gebaut wird oder bei jeder Integration doppelt gepflegt werden muss.

Was das IoT-Etikett verdeckt

Wer die Architektur-These als Zuständigkeits-Streit zwischen IT und Anlagenbau liest, verfehlt den Punkt. Niemand will dem Steuerungs-Lieferanten die Arbeit wegnehmen; die Daueranforderung gehört schlicht dorthin verankert, wo sie über Produktgenerationen hinweg lebt, und das ist der Datenbackbone.

Der ernsthafte Einwand bleibt: Manche vernetzten Produkte erzeugen Daten tatsächlich primär in der Steuerung, und für eine erste, einfache Bereitstellung kann eine SPS-nahe Lösung am Markteinführungstag genügen. Das stimmt für den Tag der Auslieferung. Es stimmt nicht mehr beim ersten Backend-Wechsel, denn dann hängt eine gesetzliche Pflicht an einem System, das gar nicht dafür gebaut ist, Berechtigungen über Jahre zu führen. Die These wird dadurch nicht weicher, sie wird präziser: Eine SPS-Lösung ist erlaubt, sobald die Berechtigungs- und Bereitstellungslogik trotzdem im Backbone dokumentiert und migrierbar bleibt.

Der zweite Einwand lautet: “Wir bauen keine vernetzten Produkte, also betrifft uns das nicht.” Diese Annahme trägt nur so lange, wie kein Produkt mit Sensorik, Telemetrie oder einem verbundenen Dienst ausgeliefert wird. Im Maschinen- und Anlagenbau ist genau das die Regel geworden, nicht die Ausnahme. Wer die eigene Produktpalette daraufhin nicht geprüft hat, sollte das vor dem 12. September tun, nicht danach. Wer ohnehin über Daten-Hoheit im eigenen Backbone nachdenkt, hat hier einen zusätzlichen, regulatorisch getriebenen Grund.

Häufige Fragen zum Data Act und Access by Design

Gilt der Data Act auch für unsere bereits verkauften Maschinen?

Nein. Die Access-by-Design-Pflicht aus Artikel 3(1) der Verordnung (EU) 2023/2854 gilt ausschließlich für vernetzte Produkte, die nach dem 12. September 2026 erstmals in Verkehr gebracht werden. Bestandsmaschinen im Feld fallen nicht darunter, einen Nachrüst-Zwang gibt es für sie also nicht; die allgemeine Anwendbarkeit des Data Act ab 12. September 2025 betrifft andere Pflichten, etwa den Zugang zu bereits verfügbaren Daten auf Anfrage, und nicht die Gestaltungspflicht aus Artikel 3(1).

Liegt die Pflicht beim Steuerungs-Lieferanten oder bei uns?

Die Daten entstehen an der Maschine, aber Artikel 3(1) verlangt strukturierte, sichere, maschinenlesbare Bereitstellung an den Nutzer. Das ist eine Berechtigungs- und Schnittstellen-Logik im Backend aus ERP und MES, kein Firmware-Feature. Wer die Pflicht allein beim Steuerungs-Lieferanten parkt, verankert eine Daueranforderung im falschen System und pflegt sie bei jeder Integration neu.

Müssen wir wirklich alle Daten herausgeben, auch Geschäftsgeheimnisse?

Nein. Es geht um die vom vernetzten Produkt und zugehörigen Dienst erzeugten Produkt- und Servicedaten, nicht um sämtliche Unternehmensdaten. Artikel 4 und 5 der Verordnung (EU) 2023/2854 setzen die Geschäftsgeheimnis-Schranke; ein pauschales Verweigern ist nur in eng begrenzten Ausnahmen zulässig. Genau diese Schranke gehört ins Berechtigungsmodell des Backends, nicht in die Steuerung.

Was muss Access by Design technisch konkret leisten?

Der Nutzer muss standardmäßig, einfach, sicher, kostenfrei und in einem gängigen, strukturierten, maschinenlesbaren Format auf die erzeugten Daten zugreifen können, wo technisch machbar direkt am Produkt oder über einen verbundenen Dienst, so der Wortlaut von Artikel 3(1). Praktisch heißt das: eine dokumentierte Schnittstelle, ein Berechtigungskonzept und ein festgelegter Format-Standard, alles definiert vor Markteinführung.

Wer setzt den Data Act in Deutschland durch, und was droht bei Verstoß?

Das Datenverordnung-Anwendungs-und-Durchsetzungs-Gesetz (DADG) ist am 30. Mai 2026 in Kraft getreten, beschlossen hat es der Bundestag am 26. März 2026. Zentrale Durchsetzungs- und Koordinierungsbehörde ist die Bundesnetzagentur. § 15 DADG sieht einen Ordnungswidrigkeiten-Katalog mit Bußgeldern bis zu 500.000 Euro vor, soweit die Zuständigkeit der BNetzA reicht.

Nächster Schritt

Bei welchem Ihrer nächsten Produktanläufe sitzt die Access-by-Design-Pflicht heute in der Steuerung statt im Backbone?

Wenn Sie vor dem 12. September eine vernetzte Produktgeneration ausliefern, schaue ich mir mit Ihnen die Architektur-Zuordnung im konkreten Produkt- und ERP-Kontext an, kostenfrei und ohne Pflichtenheft-Theater. Eine halbe Stunde reicht, um zu klären, ob die Pflicht im richtigen System sitzt.

Schreiben Sie mir für ein kostenfreies Erstgespräch. Wenn Sie zuerst weiterlesen wollen, finden Sie die Grundlagen unter IT-Strategie und Systemauswahl.

Quellen und Links: VO (EU) 2023/2854, Art. 3(1)/4/5/50 · DIHK: Data Act, nächste Stufe ab 12. September 2026 · EU-Kommission: Data Act FAQ · Greenberg Traurig: Action Required for Providers of Connected Devices (09/2025) · Heuking: Bundestag beschließt DADG (26.03.2026) · Haufe: DADG verabschiedet und verkündet (30.05.2026) · HÄRTING: § 15 DADG, Bußgeld bis 500.000 Euro · KPMG: Data Act, Governance für vernetzte Produkte

Weiter lesen auf pfisterer.xyz: SAP-API-Policy und Integration über offene Schnittstellen · Schichten-Modell der ERP-Datenarchitektur · Datenqualität als Vorbedingung · Daten-Hoheit im eigenen Backbone