Data Act und Verkörperte KI: Wem gehören die Daten vernetzter Roboter?

Roboterdaten sind der zentrale Rohstoff für Physical AI, moderne Robotik und datengetriebene Geschäftsmodelle. Mit dem Data Act schafft die Europäische Union erstmals ein einheitliches Regelwerk für den Zugang zu und die Nutzung von Daten vernetzter Produkte. Für Hersteller, Betreiber und Integratoren von Robotern stellt sich damit die entscheidende Frage, wer auf Roboterdaten zugreifen darf, wie sich Datennutzungsrechte vertraglich absichern lassen und welche Anforderungen künftig für Datenzugang, Datenlizenzen und „Access by Design“ gelten.

In unserem Serien-Auftakt haben wir gezeigt, dass ein einziger vernetzter Roboter gleichzeitig Pflichten aus mehreren Rechtsgebieten auslösen kann. Diesen Beitrag widmen wir der ersten Säule, dem Datenrecht – und der Frage: Wem gehören die Daten, die eine Maschine im Betrieb erzeugt, und wer darf sie nutzen?

Daten als Rohstoff für Robotik und Verkörperte KI

Das KI-Start-up „Shift" (hinter dem die Aachener MicroAGI GmbH steht) hat in New York ein bemerkenswertes Angebot gemacht: Es reinigt Wohnungen kostenlos. Die Reinigungskräfte tragen dabei Aufnahmegeräte; aus den Aufnahmen entstehen Trainingsdaten für künftige Haushaltsroboter. Ausdrücklich erwünscht sind besonders anspruchsvolle Umgebungen; gerade stark verschmutzte oder unaufgeräumte Wohnungen seien besonders wertvoll, weil schwierige Szenen die nützlichsten Daten liefern. (Quelle: Computerwoche, 02.06.2026.) Der eigentliche Vorgang ist hier nicht die Reinigung, sondern die Datengewinnung: Eine Dienstleistung wird verschenkt, um an etwas Knapperes und Wertvolleres zu gelangen, nämlich an reale, verkörperte Daten.

Dasselbe Grundmuster zeigt sich in zahlreichen weiteren Anwendungsbereichen: Betreiber großer Intralogistik-Flotten nutzen Betriebsdaten zur Optimierung von Wegeplanung und Wartung, vernetzte und automatisierte Fahrzeuge verbessern ihre Systeme auf Grundlage von Fahr- und Umgebungsdaten, Land- und Baumaschinen generieren Erkenntnisse für effizientere Arbeitsabläufe, und in der Medizinrobotik entstehen wertvolle Daten aus der Nutzung medizinischer Geräte.

Allen Beispielen ist gemeinsam, dass die Maschine kontinuierlich Daten erzeugt und der wirtschaftliche Wert zunehmend nicht mehr allein im physischen Produkt, sondern im fortlaufenden Datenfluss und dessen Auswertung liegt. Da hochwertige Daten aus der physischen Welt nur begrenzt verfügbar sind und mit erheblichem Aufwand erhoben werden müssen, gelten sie zunehmend als strategische Ressource.

Warum Physical AI Daten braucht – und klassische Robotik nicht

Um zu verstehen, warum Daten heute zum eigentlichen Rohstoff werden, lohnt der Blick auf den technischen Bruch.

Früher: programmiert, nicht trainiert. Klassische Industrierobotik war über Jahrzehnte deterministisch. Eine Maschine führte in einer abgeschirmten Zelle eine fest codierte Bahn aus – denselben Schweißpunkt, denselben Greifvorgang. Programmiert wurde sie mittels Steuerungslogik; jede Position war vorab definiert. Die Umgebung wurde an den Roboter angepasst (Vorrichtungen, exakte Teilelage, Bodenmarkierungen), nicht umgekehrt. Wich ein Werkstück oder die Einsatzumgebung ab, stand die Anlage still. Das „Wissen" der Maschine steckte im Code und im darin enthaltenen strukturierten Arbeitsablauf, den Menschen geschrieben hatten. Daten dienten, wenn überhaupt, der Überwachung und Qualitätssicherung, nicht der Erzeugung von Fähigkeit.

Heute: gelernt aus Daten. Verkörperte KI ersetzt die starre Regel durch ein gelerntes Modell. „Foundation Models“, „Imitation Learning“ und „Reinforcement Learning“ erlauben es einem System, Verhalten aus Beispielen zu verallgemeinern, statt es vollständig auszuprogrammieren. Für humanoide Roboter, die mehr und mehr ihren „Käfig“ verlassen, ist dies auch eine technische Notwendigkeit: Offene, veränderliche Umgebungen wie eine Wohnung, ein Lager, ein geteilter Arbeitsplatz, in dem auch Menschen arbeiten („Mensch-Roboter-Kollaboration“; „MRK“), lassen sich nicht vorab erschöpfend beschreiben. Die Vielfalt an Licht, Objekten, Anordnungen und menschlichem Verhalten ist zu groß für ein festes Skript. Wer mit dieser Varianz umgehen will, muss dem Roboter seine Aufgabe und das bezweckte Arbeitsergebnis erklären, und nicht nur die einzelnen Arbeitsschritte vorgeben.

Warum die benötigten Daten knapp und teuer sind. Entscheidend ist die Art der Daten: Es braucht verkörperte Sensomotorik-Daten – was ein Roboter sieht und „fühlt" und wie er daraufhin handelt. Solche Daten lassen sich nicht aus dem Netz „scrapen" wie Text oder Bilder; sie müssen, anders als dies bei Sprachmodellen / LLMs der Fall ist, in der realen Welt erzeugt werden – in Trainingszentren, über Sensoranzüge oder eben dadurch, dass man Reinigungskräfte filmt. Das verschiebt die gesamte Wertschöpfung: Der dauerhafte, sich verzinsende Vermögenswert ist nicht mehr die Maschine, sondern sind die Daten und die daraus trainierten Modelle. Die Maschine wird zum (zunehmend austauschbaren) Träger einer datengespeisten Fähigkeit. Kurz: Data is the asset.

Der Data Act: Neue Regeln für Daten und Datenzugang

Der Data Act (Verordnung (EU) 2023/2854) schafft ein horizontales Regelwerk für den fairen Zugang zu und die Nutzung von Daten. Anders als die DSGVO erfasst er personenbezogene und nicht-personenbezogene Daten zugleich (Art. 1 Abs. 2). Sein Ziel: den Wert von Industrie- und IoT-Daten heben, Fairness in der Datenwirtschaft herstellen und Anbieterbindung („vendor lock-in") abbauen.

Der Data Act löst damit auch die seit Jahren geführte Diskussion um ein „Dateneigentum“ (im Sinne des § 903 BGB analog) oder eines sonstigen, absolut geschützten Rechts an Daten (im Sinne der §§ 823 Abs. 1, 1004 BGB) ab.

Data Act in der Robotik: Hersteller, Nutzer und Dateninhaber richtig einordnen

• Ein Roboter (Cobot, Autonome Mobile Roboter – AMR, Humanoid, Haushaltsroboter, Drohne/UAS, etc.) ist ein „vernetztes Produkt" im Sinne des Art. 2: ein Gegenstand, der Daten über seine Nutzung und Umgebung erzeugt, erfasst und übermitteln kann.
• Das Flottenmanagement- bzw. Cloud-Backend (die Plattform, über die Roboter überwacht, aktualisiert und gesteuert werden) ist ein „verbundener Dienst": ein Dienst, ohne den das Produkt bestimmte Funktionen nicht erfüllen könnte.
• Der „Dateninhaber" ist regelmäßig der Roboterhersteller oder Plattformbetreiber.
• „Nutzer" ist, wer den Roboter besitzt, mietet oder least – in der Praxis häufig der Betreiber der Flotte.
• Reichweite: Der Data Act gilt extraterritorial – erfasst sind etwa auch Hersteller vernetzter Produkte, die in der EU in den Verkehr gebracht werden, unabhängig vom Ort der Niederlassung des Herstellers (Art. 1).

Data Act: Diese Fristen gelten für Hersteller vernetzter Roboter

Der Data Act trat am 11. Januar 2024 in Kraft und gilt seit dem 12. September 2025. Der für die Produktgestaltung entscheidende Schritt folgt im Spätsommer dieses Jahres: Die Pflicht zum „access by design" (Art. 3 Abs. 1) greift ab dem 12. September 2026 für vernetzte Produkte, die ab diesem Datum in Verkehr gebracht werden (Art. 50). Für Roboterhersteller heißt das konkret: Modelle, die ab dann auf den Markt kommen, müssen den Datenzugang bereits in der Architektur mitbringen – am Robotercontroller, an der „Edge" (dem Netzwerkknoten, der Daten im Werk sammelt und bspw. an die Cloud oder das Backend weitergibt) oder über die Cloud/das Backend selbst (bspw. in Form eines API-Zugriffs).

Data Act: Datenzugang und Datennutzung bei vernetzten Robotern (Kapitel II)

Zugang „by design" und Transparenz (Art. 3). Vernetzte Produkte sind so zu gestalten, dass die erzeugten Daten, einschließlich relevanter Metadaten, standardmäßig einfach, sicher, unentgeltlich, strukturiert und maschinenlesbar und, wo technisch machbar, unmittelbar zugänglich sind. Für die Robotik bedeutet das: Roboter-Telemetrie und Sensordaten müssen über eine definierte Schnittstelle abrufbar sein; schon vor Kauf, Miete oder Leasing ist zu informieren, welche Daten in welchem Umfang und Format anfallen und wie darauf zugegriffen werden kann (Art. 3 Abs. 2–3).

Herausgabe und Nutzung (Art. 4). Sind Daten nicht unmittelbar zugänglich, muss der Dateninhaber die „ohne Weiteres verfügbaren" Daten dem Nutzer unverzüglich, einfach, sicher und unentgeltlich bereitstellen, soweit technisch durchführbar auch fortlaufend und in Echtzeit. Geschäftsgeheimnisse sind zumindest konzeptionell geschützt: Ihre Offenlegung darf an vereinbarte Schutzmaßnahmen geknüpft und in eng umrissenen Ausnahmefällen zurückgehalten oder ausgesetzt werden (Art. 4 Abs. 6–8). Die Hürde ist jedoch hoch: Es genügt nicht, pauschal alles zum Geschäftsgeheimnis zu erklären.

Der vielleicht folgenreichste Hebel und auch Paradigmenwechsel steckt in Art. 4 Abs. 13: Der Dateninhaber darf nicht-personenbezogene, „ohne Weiteres verfügbare" Daten nur auf vertraglicher Grundlage mit dem Nutzer verwenden. Das kehrt die bisherige Voreinstellung um – übertragen auf die Robotik: Ein Hersteller, der Nutzungsdaten aus Roboterflotten an Kundenstandorten für eigene Zwecke nutzt oder bspw. in ein geteiltes Flottenmodell einspeist, braucht je Kunde eine ausdrückliche Vereinbarung – eine „Datenlizenz", selbst wenn die Daten nur der Wartung, der Funktionsverbesserung oder dem Modelltraining dienen. Das Recht, nicht-personenbezogene Daten wirtschaftlich zu verwerten, wird damit in erster Linie dem Nutzer zugeordnet. Ergänzend verbietet es Art. 4 (Abs. 13 f.), aus den Daten Erkenntnisse über die wirtschaftliche Lage des Nutzers zu ziehen, die dessen Marktstellung schaden könnten, und die Daten ohne Vereinbarung an Dritte weiterzugeben.

Weitergabe an Dritte (Art. 5 und 6). Auf Verlangen des Nutzers muss der Dateninhaber die ohne Weiteres verfügbaren Daten sowie die für die Auslegung und Nutzung dieser Daten erforderlichen Metadaten auch einem Dritten bereitstellen. Genau hier liegt ein zentrales Anliegen des Data Act: der unabhängige Aftermarket und die Vermeidung eines „Vendor Lock-In“. Ein Flottenbetreiber könnte bspw. verlangen, dass Roboterdaten an einen unabhängigen Wartungs- oder Instandhaltungsdienst herausgegeben werden. Der empfangende Dritte unterliegt aber eigenen Pflichten (Art. 6): Er darf die Daten nur zu den vereinbarten Zwecken verarbeiten, sie nicht zur Entwicklung eines konkurrierenden Roboters verwenden und nicht ohne Vereinbarung weiterreichen. Ausdrücklich ausgeschlossen als datenempfangende Dritte sind zudem als „Gatekeeper" benannte Unternehmen im Sinne des Digital Markets Act (Art. 5 Abs. 3).

Faire Datenklauseln und Klauselkontrolle (Kapitel III und IV)

Soweit ein Dateninhaber verpflichtet ist, Daten bereitzustellen, müssen die Bedingungen fair, angemessen und nichtdiskriminierend sein; eine etwaige Vergütung muss angemessen sein und ist gegenüber kleinen und mittleren Unternehmen gedeckelt (Art. 8–9). Für Streitfälle stehen zertifizierte Streitbeilegungsstellen bereit (Art. 10) – in Deutschland werden diese durch die Bundesnetzagentur zertifiziert.

Besonders praxisrelevant ist die Klauselkontrolle: Eine Vertragsklausel über Datenzugang, -nutzung oder Haftung ist nicht bindend, wenn sie die Rechte des Nutzers aus Kapitel II zu dessen Nachteil ausschließt oder verändert (Art. 7 Abs. 2) oder wenn sie einseitig auferlegt und missbräuchlich im Sinne des Art. 13 ist. Der Data Act unterscheidet dabei zwischen Klauseln, die per se unwirksam sind, und solchen, deren Missbräuchlichkeit vermutet wird. Das ist der Sache nach eine AGB-Kontrolle für die Datenwirtschaft – und sie trifft Roboter-Liefer-, RaaS- und „Marketplace"-Verträge unmittelbar. Zur Orientierung hat die Kommission unverbindliche Mustervertragsklauseln veröffentlicht; sie sind bewusst nutzerfreundlich und sollten an die eigene Vertrags- und Geschäftslogik angepasst werden.

Cloud-Wechsel, Datenexport und internationale Datennutzung nach dem Data Act

Für RaaS- und Flotten-Backends wichtig: Anbieter von Datenverarbeitungsdiensten (Cloud/Edge) müssen Wechselhürden abbauen, funktionale Gleichwertigkeit ermöglichen und Interoperabilität gewährleisten; die Wechselentgelte entfallen schrittweise (Art. 23–31, insb. Art. 29). Der sog. Vendor Lock-In wird damit reguliert – der Betreiber soll den Datenverarbeitungsdienst wechseln können, ohne seine Daten zu verlieren. Die Frage, wann der Betreiber eines Flotten-Backends als Datenverarbeitungsdienst im Sinne des Data Act gilt, ist gleichwohl nicht einfach zu beantworten und erfordert eine genaue Einordnung unter diesen Begriff (Art. 2 Nr. 8) im Einzelfall.

Hinzu kommt der Schutz nicht-personenbezogener Daten vor unrechtmäßigem Zugriff aus Drittstaaten (Art. 32) – relevant insbesondere für internationale Anbieter. Und: Das sui-generis-Datenbankrecht (Richtlinie 96/9/EG) ist auf Datenbanken mit Produktdaten nicht anwendbar (Art. 43), damit es den Zugang nicht aushebelt.

Data Act und DSGVO: Datenschutz bei Roboterdaten

Der Data Act gilt unbeschadet der DSGVO; bei Konflikten geht der Datenschutz vor (Art. 1 Abs. 5). Wo personenbezogene Daten betroffen sind – beim Haushaltsroboter mit Kamera oder am Arbeitsplatz mit Mensch-Roboter-Kollaboration nahezu durchgängig – und der Nutzer nicht selbst die betroffene Person ist, dürfen Daten nur auf einer gültigen Rechtsgrundlage (Art. 6 DSGVO) herausgegeben werden. In der Robotik sind gemischte Datensätze der Normalfall. Diese Schnittstelle vertiefen wir im nächsten Beitrag der Serie.

Kriterien und Graubereiche beim Data Act

Die eigentliche Beratungsarbeit beginnt dort, wo die Begriffe auf die Wirklichkeit treffen.

• Wer ist „Nutzer“? Eigentümer, Betreiber, RaaS-Anbieter, Leasingnehmer und einzelne Beschäftigte können auseinanderfallen; in der Fabrik ist „Nutzer" die Betriebsstätte, nicht die einzelne Person; an einer Roboterflotte können mehrere Nutzer bestehen. Wer die Rolle nicht sauber zuordnet, verletzt möglicherweise Rechte unter dem Data Act.
• Dateninhaber = Plattformbetreiber. Der schärfste Interessenkonflikt entsteht, wo die Herstellerin zugleich das Netzwerk betreibt, das vom aggregierten Datenfluss profitiert. Genau hier greifen Art. 4 Abs. 13 f. und die Klauselkontrolle des Art. 13 am stärksten.
• Die Trainingsdaten-Frage. Darf eine Herstellerin die Nutzungsdaten von Kundenstandorten in das geteilte Flottenmodell einspeisen, von dem auch Wettbewerber des Kunden profitieren? Nach dem Data Act braucht das eine vertragliche Grundlage (Art. 4 Abs. 13), darf den Kunden nicht schädigen (Abs. 13 f.), und datenempfangende Dritte dürfen damit keinen konkurrierenden Roboter bauen (Art. 6). Die offene Frage: Sind die trainierten Modellgewichte noch „Daten" im Sinne des Akts? Sehr wahrscheinlich nicht – ein Teil der Wertschöpfung entkommt damit dem Zugangsanspruch, sobald aus Rohdaten ein Modell geworden ist. Das ist rechtlich noch nicht ausgestanden, aber für datengetriebene Robotik-Geschäftsmodelle zentral.
• „Ohne Weiteres verfügbare“ Daten gegen abgeleitete Daten. Die Grenze entscheidet, wie viel vom Asset den Nutzer tatsächlich erreicht. Rohe und vorverarbeitete Sensordaten des Roboters – etwa Position, Beschleunigung, Geschwindigkeit, Kraft-/Momenten-, Temperatur- oder Druckwerte – fallen in den Anspruch. Abgeleitete, aufwendig angereicherte Daten und „Inhalte" wie audiovisuelles Material – beispielsweise der fertig aufbereitete 3D-Umgebungs-/SLAM-Datensatz (SLAM: „Simultane Lokalisierung und Kartierung“) – liegen nach dem Verständnis der Kommission eher außerhalb; on-device sofort verworfene Daten ganz außerhalb der Verordnung (keine Pflicht zur Datenspeicherung).
• Geschäftsgeheimnis gegen Zugang. Der Data Act erlaubt das Zurückhalten von Daten nur unter den engen Bedingungen des Art. 4 Abs. 6–8 – die Spannung zwischen Schutzversprechen und gesetzlichem Zugangsanspruch ist vertraglich auszutarieren.
• Keine robotik-spezifische Leitlinie. Für Fahrzeugdaten hat die Kommission eine sektorspezifische Leitlinie veröffentlicht – diese ist aber ausdrücklich nicht auf andere Branchen übertragbar. Für die Robotik fehlt eine entsprechende Handreichung; Einordnungsfragen (was ist „ohne Weiteres verfügbar“, wie tief reicht der Zugang am Controller, etc.) tragen damit mehr Unsicherheit und sollten früh juristisch abgesichert werden.

Handlungsempfehlungen für Robotics & Physical AI

• Datenkatalog je Robotertyp anlegen. Erfassen, was Cobot, AMR oder Humanoid real erzeugt – Telemetrie, Kamera-/LiDAR-/Kraft-Momenten-Sensorik, Trajektorien- und Aufgaben-Logs, Umgebungskarten, Wartungsdaten – und jedes Feld doppelt einstufen: personenbezogen/nicht-personenbezogen und „ohne Weiteres verfügbar"/abgeleitet. Das ist die Grundlage sowohl für Art. 3 und 4 als auch für die Abgrenzung zum Datenschutzrecht.
• Zugang „by design" technisch verorten. Den Datenexport am Robotercontroller bzw. an der „Edge" oder über die Flottenmanagement-API definieren (strukturiert, maschinenlesbar, interoperabel) und das Flotten-/OTA-Backend als „verbundenen Dienst“ mitdenken – für alle Modelle, die ab dem 12. September 2026 in Verkehr gebracht werden.
• Hersteller – Verträge und Plattform absichern. Eigennutzungs- und Trainingsrechte als „Datenlizenz" in Liefer- und RaaS-Verträge aufnehmen (Art. 4 Abs. 13); ein Geschäftsgeheimnis-Schutzkonzept nach Art. 4 Abs. 6–8 aufsetzen; in Partner-/„Marketplace"-Bedingungen die „Konkurrenzprodukt"-Schranke (Art. 6) und die Nichtdiskriminierung gegenüber unabhängigen Servicebetrieben (Art. 8 Abs. 3) verankern; alle Datenklauseln in bestehenden Vertragsmustern am Maßstab der Art. 7 Abs. 2 und 13 prüfen.
• Integrator – Rolle und Lieferkette klären. Eine „wesentliche Veränderung" („substantial modification") kann aus Integratoren Hersteller mit allen Folgepflichten machen (siehe Legal Update #1); Datenklauseln müssen entlang der Lieferkette „back-to-back" durchgereicht werden.
• Betreiber – Datenrechte aktiv nutzen. Zugang und Portabilität der eigenen Roboterdaten gewinnbringend einsetzen. Dieselben Roboterdaten können bspw. zugleich die Beweissicherung der neuen Produkthaftung, die Maschinenverordnung und den CRA bedienen – wer das Datenmanagement früh sauber aufstellt, bedient also mehrere der rechtlichen Säulen auf einmal (siehe Legal Update #1).

Ausblick: Der Data Act verändert datengetriebene Robotik nachhaltig

Der Data Act macht aus der alten Streitfrage „Wem gehören die Daten?" eine konkrete Gestaltungsaufgabe – in der Produktarchitektur ebenso wie im Vertragswerk. Wenn der eigentliche Wert im Datenfluss liegt, entscheidet das Datenrecht über das Geschäftsmodell. CMS begleitet Hersteller, Integratoren und Betreiber interdisziplinär – von der Datenarchitektur über IT-Vertrags- und Datenschutzrecht bis zur internationalen Skalierung.

Im nächsten Teil der Serie wenden wir uns dem Datenschutz zu: dem sehenden und hörenden Roboter und der Frage, wie sich Kamera-, Audio- und Sensordaten DSGVO-konform verarbeiten lassen.

Building the legal stack for Physical AI.

Redaktioneller Hinweis: Die Angaben geben den Stand zum Redaktionsschluss (30. Juni 2026) wieder; einzelne Punkte befinden sich in der Konkretisierung (u. a. Kommissions-Leitlinien und Mustervertragsklauseln). Vor einer konkreten Umsetzung sind die Primärquellen (EUR-Lex) heranzuziehen.

*Gemeint sind Personen jeder Geschlechtsidentität. Um der leichteren Lesbarkeit willen wird im Beitrag die grammatikalisch männliche Form verwendet.