EU Data Act: Was bedeutet das für IoT-Systemarchitekten?

Der EU Data Act (Verordnung (EU) 2023/2854) gibt dem Nutzer eines vernetzten Produkts ein gesetzliches Recht auf die Daten, die dieses Produkt erzeugt, und das Recht, sie auf Anfrage mit einem Dritten seiner Wahl zu teilen. Für einen Flottenbetreiber, der Ihre Gateways einsetzt, heißt das: Messwerte, Betriebsstundenzähler und Ereignisprotokolle der Maschine gehören ihm, er darf darauf zugreifen und sie verlagern. Für den OEM oder Integrator, der das System gebaut hat, heißt das: Der von Ihnen entworfene Datenpfad ist jetzt eine Compliance-Fläche, nicht nur eine technische.

Die für Architekten entscheidenden Pflichten sind konkret: Daten müssen dem Nutzer, soweit technisch machbar, direkt und in Echtzeit zur Verfügung stehen; sie müssen sich in einem gängigen, maschinenlesbaren Format mit Dritten teilen lassen; und ein Wechsel zu einem neuen Dienstanbieter darf weder vertraglich noch durch das Design blockiert werden. Wenn Ihre einzige Möglichkeit, ein Jahr CAN-Bus-Telemetrie zu exportieren, ein CSV-Export ist, den ein Anbieter quartalsweise für Sie ausführt, erfüllen Sie diese Vorgabe nicht.

Der Anwendungsbereich ist enger, als die Schlagzeilen vermuten lassen, und ihn richtig zu verstehen erspart Ihnen Mehraufwand. Der Data Act erfasst Daten, die durch die Nutzung eines vernetzten Produkts und seines verbundenen Dienstes entstehen: Sensorwerte, GPS-Positionen, Trommeldrehzahlen, Betriebsstundenzähler, Fehlercodes, der Diagnosestrom, den eine Maschine im Normalbetrieb abgibt. Er gibt nicht Ihre proprietären Algorithmen, Ihre Anreicherungsmodelle oder Daten heraus, die Sie nachgelagert durch erhebliche Investitionen ableiten. Rohe und leicht verarbeitete Gerätedaten fallen darunter, Ihr Analytics-Know-how nicht.

Nutzer ist, wer das Produkt besitzt, mietet oder least, nicht zwingend die Partei, die es gebaut hat. Bei einem geleasten Kran oder einem finanzierten Fahrmischer kann der Betreiber, der die Anlage einsetzt, Zugang verlangen, obwohl der OEM die Telematik installiert hat. Architekten, die annahmen, dass der Hersteller der Box auch die Daten aus der Box kontrolliert, müssen diese Annahme überdenken, denn die Verordnung teilt sie nicht.

"Dem Nutzer, soweit technisch machbar, direkt und in Echtzeit zur Verfügung": An dieser Vorgabe scheitert geschlossene Telematik. Wenn Gerätedaten nur in einer proprietären Cloud landen und der Nutzer sie über ein vom Anbieter kontrolliertes Portal sieht, ist direkter Echtzeitzugang etwas, das man erbitten muss, und genau dieses Erbitten macht der Data Act überflüssig.

Die Architektur, die das erfüllt, ist dieselbe, auf die solide Edge-Technik ohnehin zusteuert. Terminieren Sie Protokolle an einem offenen Gateway: J1939 am Antriebsstrang, Modbus an einer Hilfspumpe, OPC-UA an einer Liniensteuerung. Normalisieren Sie auf dem Gerät und publizieren Sie über MQTT mit Store-and-Forward-Pufferung, damit eine abgerissene Verbindung keine Daten verliert. Von dort kann derselbe Strom ohne zweite Integration sowohl zu Ihrer Plattform als auch zu einem nutzereigenen Endpunkt verzweigen. Echtzeitzugang ist dann keine Anfrage an den Anbieter mehr, sondern ein Topic-Abonnement, das der Nutzer bereits hält.

Die Wechselbestimmungen des Data Act zielen genau auf Lock-in. Ein Nutzer kann zu einem anderen Anbieter wechseln, und der bisherige Anbieter muss diesen Wechsel unterstützen, in einem strukturierten, gängigen, maschinenlesbaren Format, ohne Strafgebühren und innerhalb festgelegter Kündigungsfristen. Der praktische Test ist einfach: Wenn Ihr Kunde morgen bei einem Wettbewerber unterschriebe, wie viel seiner Daten, seiner Historie und seiner Gerätekonfiguration könnte er mitnehmen, und wie schnell?

Bauen Sie von Anfang an für diese Antwort. Halten Sie Telemetrie in offener Zeitreihenspeicherung (PostgreSQL mit TimescaleDB statt einer geschlossenen Cloud-Tabelle, die Sie nicht in großem Umfang exportieren können). Definieren Sie das Übertragungsformat explizit: zeitgestempeltes JSON oder ein dokumentiertes Schema über MQTT, kein undurchsichtiges Binärformat, das nur Ihr Decoder versteht. Versionieren Sie die Gerätekonfiguration in git, damit das Verhalten eines Gateways für jeden reproduzierbar ist, der das Repository besitzt. Nichts davon ist exotisch. Es ist der Unterschied zwischen Portabilität als Klausel, die Sie erfüllen, und einer Migration, die Sie tatsächlich durchführen können.

Am wenigsten für den Data Act werden die Teams ausgeben, deren Systeme ohnehin schon offen waren. Wenn das Gateway ein Linux ausführt, das Sie kontrollieren, der Broker Mosquitto ist, der Speicher Ihnen gehört und der Quellcode in git versioniert und übergeben ist, sind die meisten Forderungen der Verordnung bereits als Nebeneffekt der Bauweise erfüllt. Zugang, Portabilität und ein sauberer Ausstieg sind keine Nachrüstungen, sondern das, was ein offener Edge-Stack standardmäßig leistet.

Geschlossene Plattformen kehren das um. Jedes Recht, das der Data Act dem Nutzer gewährt, wird zum Feature-Wunsch an einen Anbieter, der ein kommerzielles Interesse daran hat, ihn zu verzögern, oft pro Gerät oder pro Export bepreist. Die Verordnung ist faktisch eine Frist für eine Entscheidung, die viele Architekten aufgeschoben hatten: ob die Feld-Datenschicht etwas ist, das Ihnen gehört, oder etwas, das Sie mieten. Jetzt für Nutzerzugang und Portabilität zu entwerfen, ist günstiger, als beides später einem proprietären Stack aufzuzwingen, und es hinterlässt Ihnen eine Architektur, die schon aus eigenem Recht besser ist.