Ein Roboter, vier Interessenten, eine falsch gestellte Frage

Ein Logistikunternehmen betreibt einen Roboter, der täglich Behälter zwischen Regal und Verladerampe bewegt. Die Maschine protokolliert Gelenkzustände, Fahrwege, Fehlermeldungen und Kamerabeobachtungen. Der Hersteller möchte aus diesen Beobachtungen bessere Greifstrategien entwickeln, weil ihm genau solche Fehlerfälle in der Entwicklung fehlen. Der Betreiber will vor allem verstehen, warum die Anlage zuletzt häufiger stillstand, und offen halten, ob er den Wartungsdienst wechselt. Ein Beschäftigter, der neben dem Roboter arbeitet, möchte wissen, ob er auf den Aufnahmen erkennbar ist. Ein Cloudanbieter verwaltet zusätzlich einen Teil der technischen Infrastruktur, über die diese Daten laufen.

Wem gehören diese Daten? Die Frage klingt nach einem klaren Ja oder Nein, führt aber in die falsche Richtung, sobald sie eine einzige Antwort für sämtliche Beteiligten und sämtliche Datenarten verlangt. Entscheidend ist nicht, wer den Roboter bezahlt oder wer den Server betreibt. Entscheidend ist, wer auf welche Information zugreifen darf, wofür er sie verwenden darf und unter welchen Bedingungen er sie weitergeben darf.

Stehen Sie vor der Unterschrift unter eine Beschaffung oder eine Robotics-as-a-Service-Vereinbarung – im Einkauf, in der Rechtsabteilung oder in der technischen Leitung –, sollten Sie diese Fragen vor Vertragsabschluss klären, nicht danach. Ein Vertrag, der die Eigentumsfrage global regelt, aber die Zugriffsrechte offenlässt, löst genau das falsche Problem. Dieser Beitrag klärt, was der EU Data Act dazu tatsächlich vorgibt, wo er offene Fragen dem Vertrag überlässt und wie sich das in eine prüfbare Vertragsklausel übersetzen lässt.

Wie Trainingsdaten für Physical AI heute in großem Maßstab industriell produziert werden, ist eine benachbarte, aber andere Frage – dazu mehr in unserem Beitrag zu chinesischen Datenfabriken für Physical-AI-Trainingsdaten.

Wie sich parallel ein eigener Handelsmarkt für Robotikdaten entwickelt, ordnet ein eigener Beitrag zum entstehenden Markt für Roboterdaten ein. Die Rechtsfrage davor ist eine andere: Was ein Vertrag regeln muss, bevor überhaupt Daten fließen, produziert oder gehandelt werden können.

Was der Data Act regelt: Zugang, nicht Eigentum

Der EU Data Act ist seit dem 12. September 2025 grundsätzlich anwendbar, veröffentlicht wurde die Verordnung bereits am 22. Dezember 2023. Zwischen Veröffentlichung und Anwendungsbeginn lag damit eine knapp zweijährige Übergangszeit, die Herstellern und Betreibern Zeit geben sollte, ihre Verträge und Systeme anzupassen. Wer heute noch mit „das gilt doch erst“ argumentiert, argumentiert gegen ein Datum, das seit über einem Jahr Vergangenheit ist.

Zum erfassten Nutzerkreis können neben Eigentümern auch Mieter und Leasingnehmer eines vernetzten Produkts gehören. Für Ihre Beschaffungsentscheidung ist das mehr als eine Randnotiz, denn gerade bei Robotics-as-a-Service fällt rechtliches Eigentum an der Maschine häufig nicht mit der Partei zusammen, die sie im Alltag betreibt.

Der zentrale Punkt bleibt trotzdem die Reichweite der Regelung selbst: Das Regelwerk verteilt Zugangs- und Nutzungsrechte; daraus folgt kein pauschales Alleineigentum an sämtlichen Informationen eines Systems. Die Einordnung ist produkt- und vertragsabhängig – ob und in welchem Umfang eigentumsähnliche Rechte im Einzelfall bestehen, hängt vom konkreten Produkt und vom jeweiligen Vertrag ab. Eine allgemeingültige Eigentumsregel für „die Daten des Roboters“ gibt es deshalb nicht, weil der Data Act sie so nicht vorsieht, und wer sie trotzdem in einen Vertrag schreibt, schreibt etwas, das im Streitfall wenig trägt.

Ist ein Roboter ein vernetztes Produkt? Der funktionale Test vor der Kategorie

Bevor sich die Frage nach Zugangsrechten überhaupt stellt, muss geklärt sein, ob ein Gerät in den Anwendungsbereich des Data Act fällt. Maßgeblich ist dafür kein Etikett, sondern eine Funktion: Ob ein Roboter ein vernetztes Produkt im Sinne des Data Act ist, hängt davon ab, ob er nutzungsbezogene Daten erzeugt und über einen Dienst kommunizieren kann. Die Kommission nennt Roboter als Beispiel für mögliche vernetzte Produkte, geprüft wird das am Einzelprodukt.

Das ist eine wichtige Unterscheidung, weil sie die Reihenfolge der Prüfung umdreht. Nicht die Kategorie entscheidet über die Funktion, sondern die Funktion entscheidet, ob die Kategorie hier überhaupt greift. Ein autarker Greifarm ohne jede Konnektivität und ohne erzeugte Nutzungsdaten fiele demnach anders aus als ein vernetzter Serviceroboter, der Sensordaten laufend an eine Cloud-Plattform meldet – obwohl beide umgangssprachlich „Roboter“ heißen.

Für Ihre Beschaffung folgt daraus eine sehr konkrete erste Frage an jeden Anbieter: Erzeugt das angebotene Gerät überhaupt Daten, die unter den Data Act fallen, und über welchen Kommunikationsweg? Ein Anbieter, der diese Frage nicht klar beantworten kann, hat entweder sein eigenes Produkt nicht rechtlich eingeordnet oder möchte die Antwort offenlassen. Beides gehört vor Ihrer Unterschrift geklärt, nicht danach.

Access-by-Design: die Pflicht ab dem 12. September 2026

Neben der Frage, wer Zugriff erhält, regelt der Data Act auch, wie dieser Zugriff technisch möglich sein muss. Für nach dem 12. September 2026 in Verkehr gebrachte vernetzte Produkte sieht der Data Act eine access-by-design-Pflicht für direkten Datenzugang vor. Maßgeblich ist dabei das einzelne Produkt, nicht der Zeitpunkt, zu dem eine Modellreihe erstmals vorgestellt wurde.

Diese Unterscheidung hat für Beschaffungsentscheidungen praktische Folgen. Ein Roboter, dessen Baureihe bereits seit Jahren im Markt ist, kann trotzdem unter die Pflicht fallen, wenn das konkrete Exemplar erst nach dem Stichtag in Verkehr gebracht wird. Umgekehrt bedeutet eine neue Softwareversion für eine ältere Hardware nicht automatisch, dass die Pflicht greift, weil es um das Produkt geht, nicht um jede Aktualisierung.

Für Ihren Einkauf im Herbst 2026 lohnt deshalb eine einfache Frage an den Anbieter: Wann genau wird das bestellte Gerät in Verkehr gebracht, und ist der direkte Datenzugang bereits in der Konstruktion vorgesehen oder muss er nachgerüstet werden? Ein Anbieter, der diese Pflicht erst nach der Lieferung nachrüstet, verschiebt ein technisches Problem auf einen Zeitpunkt, an dem der Vertrag bereits unterschrieben ist.

Das Dateninventar statt der globalen Eigentumsklausel

Für Ihr Robotikprojekt ist ein Dateninventar sinnvoller als eine globale Eigentumsklausel, weil eine einzelne Klausel niemals abbilden kann, wie unterschiedlich die tatsächlich entstehenden Datenarten sind. In einem solchen Inventar lassen sich Antriebswerte, Fehlerereignisse, Auftragsinformationen, Umgebungsaufnahmen und berechnete Zustandsindikatoren getrennt beschreiben. Hinzu kommen Metadaten: Zeitstempel, Einheit, Sensorposition, Softwareversion oder die Bedeutung eines Fehlercodes.

Eine Temperaturzahl ohne Einheit und Einbauort ist für die Instandhaltung kaum brauchbar. Ein Fehlerprotokoll ohne Versionsinformation kann eine falsche Analyse auslösen, weil derselbe Zahlencode in einer älteren Softwareversion etwas anderes bedeutet haben kann als in der aktuellen. Die Nutzbarkeit einer Information entsteht deshalb nicht allein durch den Zugang zu einem Datenpunkt, sondern durch ihren Zusammenhang mit Zeit, Ort und Bedeutung.

Ein Inventar sollte außerdem zwischen Erzeugen und Speichern unterscheiden. Eine Steuerung kann einen Wert kurzfristig benötigen, ohne ihn dauerhaft abzulegen. Eine Kamera kann lokal ausgewertet werden, ohne dass ein einziges Bild die Anlage verlässt. Diese Architekturen dürfen im Vertrag nicht so beschrieben werden, als seien sie identisch, sonst entsteht eine Zugriffsklausel für Daten, die es in der beschriebenen Form gar nicht gibt.

Servicezweck und Trainingszweck: zwei getrennte Verwendungen

Die Nutzung nicht personenbezogener Produktdaten durch den Dateninhaber setzt eine Vereinbarung mit dem Nutzer voraus. Datenzugang ist zudem nicht mit beliebiger Weiterverwendung gleichzusetzen – welche Nutzung ein bestimmtes Modelltraining darstellt, lässt sich nicht allein durch den Verweis auf „Verbesserung des Produkts“ entscheiden.

Ein Beispiel macht die Trennung greifbar, ausdrücklich als Gedankenexperiment formuliert: Ein Hersteller erhält Motortemperaturen, um einen konkreten Defekt an einer bestimmten Maschine zu diagnostizieren. Derselbe Datensatz könnte später für ein allgemeines Verfahren zur Zustandsprognose über viele Maschinen hinweg interessant werden. Beide Verwendungen können technisch sinnvoll sein, sie beantworten aber verschiedene Fragen und sollten deshalb vertraglich als unterschiedliche Zwecke geführt werden.

Noch größer wird der Abstand, wenn zusätzlich Kamerasequenzen aus dem Betrieb in ein allgemeines Robotikmodell einfließen sollen, das der Hersteller auch anderen Kunden anbietet. Dann geht es nicht mehr um die Wiederherstellung der vorhandenen Maschine, sondern um die Entwicklung weiterer Produkte oder Fähigkeiten. Eine Vereinbarung, die diesen Unterschied sichtbar macht, gibt beiden Seiten die Grundlage, über eine Gegenleistung für die zusätzliche Nutzung überhaupt zu verhandeln – ohne sie bleibt „Verbesserung des Service“ ein Sammelbegriff, unter dem sich fast jede Verwendung rechtfertigen lässt.

An dieser Stelle berührt der Data Act eine zweite Verordnung, ohne mit ihr identisch zu sein: Wird derselbe Datensatz zum Training eines Hochrisiko-KI-Systems im Sinne der EU-KI-Verordnung verwendet, verlangt deren Artikel 10 vom Anbieter dieses KI-Systems – in der Regel dem Hersteller, der das Modell trainiert, nicht dem Betreiber oder Beschaffer des Roboters – eine Data Governance für die Trainings-, Validierungs- und Testdaten – einschließlich der Herkunft der Daten –, unabhängig davon, ob die Daten zugekauft oder im eigenen Betrieb erzeugt wurden. Der Data Act regelt, wer auf die Rohdaten zugreifen darf; Artikel 10 der KI-Verordnung regelt, was mit Daten geschehen muss, die tatsächlich in ein Hochrisiko-Training einfließen. Beide Fragen sind getrennt zu klären und ersetzen sich nicht gegenseitig.

Robot-as-a-Service verschiebt Rollen, nicht die Verantwortung

Robot-as-a-Service wird meist aus der Perspektive von Anschaffung und laufender Vergütung betrachtet. Für Datenfragen kommt eine weitere Ebene hinzu: Eigentum an der Maschine, betriebliche Nutzung und Kontrolle über eine Cloudplattform können bei unterschiedlichen Parteien liegen, und keine dieser Parteien verschwindet dadurch aus der Verantwortung.

Ein ausdrücklich fiktives Beispiel zeigt die Komplexität: Ein Hersteller behält den Roboter in seinem Eigentum, ein Logistiker bestellt eine monatliche Transportleistung, ein Integrator verbindet die Maschine mit dem Lagerverwaltungssystem, und ein externer Dienstleister betreibt das Flottenportal. Eine einzige Formulierung wie „die Daten stehen dem Eigentümer zu“ würde die betrieblichen Bedürfnisse dieser Konstellation nicht abbilden, weil der Logistiker Ereignisse für seine Prozessanalyse braucht, der Integrator Schnittstelleninformationen zur Fehlerbehebung und der Hersteller Zustandsdaten für die vereinbarte Wartung.

Wenn Sie über eine solche Konstellation verhandeln, sollten Sie vor der juristischen Feinformulierung den Datenweg einmal nüchtern aufzeichnen: Wo entsteht eine Information, wer empfängt sie, wer entscheidet über die weitere Verwendung, und welche Kopien werden angelegt? Ein solches Bild reduziert die Gefahr, dass vertragliche Begriffe und technische Wirklichkeit auseinanderlaufen – ein Risiko, das bei mehreren beteiligten Unternehmen deutlich größer ist als bei einem einzelnen Anbieter-Kunden-Verhältnis.

Kamerabilder: Betriebsdaten und personenbezogene Daten zugleich

Besonders sorgfältig muss mit Kameradaten umgegangen werden, weil eine einzelne Aufnahme zugleich einen Greiffehler, einen vertraulichen Produktionsaufbau und eine erkennbare Person zeigen kann. Ihre Einordnung hängt nicht davon ab, dass die Kamera an einem Roboter befestigt ist, sondern vom tatsächlichen Inhalt des Bildes.

In einem fiktiven Fehlerfall greift ein Roboter an einem Behälter vorbei. Für die technische Analyse ist womöglich nur der Bereich um Greifer und Behälter relevant, während der vollständige Videostream zusätzlich Gesichter, Namensschilder und eine Fertigungsstation im Hintergrund enthalten könnte. Eine begrenzte Aufnahmezone, lokale Auswertung oder ein gezielter Bildausschnitt können die Diagnoseinformation erhalten, ohne den vollständigen Kontext zu übertragen.

Die DSGVO bleibt bei personenbezogenen Daten eigenständig zu beachten, ein industrieller Vertrag ersetzt diese Prüfung nicht. Die Leitlinien des Europäischen Datenschutzausschusses zu Datenschutz durch Technikgestaltung vom 20. Oktober 2020 betonen dazu insbesondere Zweckbindung, Datenminimierung und angemessene Voreinstellungen. Auch das Entfernen eines Namens macht eine durch Kontext weiterhin identifizierbare Person nicht automatisch anonym – wer als einzige Person zur fraglichen Zeit an der fraglichen Station stand, bleibt erkennbar, auch ohne dass ihr Name im Datensatz steht.

Geschäftsgeheimnisse: geschützt, aber nicht pauschal ausgeschlossen

Der Data Act schützt Geschäftsgeheimnisse, jedoch nicht als pauschalen Vorrang vor Datenzugangsrechten. Aus „vertraulich“ folgt weder automatisch „nie zugänglich“ noch „muss vollständig offengelegt werden“ – die Ausnahme gilt nur, wenn ein Anbieter nachweisen kann, dass die Offenlegung mit hoher Wahrscheinlichkeit einen erheblichen wirtschaftlichen Schaden verursacht.

Für Physical AI sind solche Konflikte naheliegend. Ein Fehlerbild kann Rückschlüsse auf eine besondere Greifergeometrie zulassen, eine Folge von Arbeitsaufträgen kann das Produktionsvolumen erkennen lassen, und Sensorwerte können indirekt Informationen über eine Materialrezeptur enthalten. Ein Anbieter, der pauschal „Geschäftsgeheimnis“ ruft, sobald ein Datenzugang unbequem wird, verkennt, dass die Ausnahme eine konkrete Voraussetzung und keinen automatischen Ausschluss darstellt.

Ein denkbarer technischer Ansatz wäre, einen ausgewählten Fehlerausschnitt mit den erforderlichen Zustandswerten bereitzustellen, statt den gesamten Produktionsverlauf zu übertragen. Beide Seiten profitieren davon, Schutz und Nutzbarkeit früh zu strukturieren, denn eine unstrukturierte Datensammlung zwingt später oft zur unbefriedigenden Wahl zwischen zu viel Freigabe und vollständiger Blockade.

Was eine Herstellerdokumentation in der Praxis zeigt

Boston Dynamics beschreibt selbst diese Unterscheidung in der Datenschutzdokumentation zum Serviceroboter Stretch: Service Logs seien für Kunden nicht direkt einsehbar, während Leistungsinformationen über Berichte beziehungsweise Oberflächen verfügbar seien. Das ist eine Herstellerdarstellung mit Stand Januar 2026, keine Vertrags- oder Rechtskonformitätsprüfung durch Dritte.

Der Nutzen dieses Beispiels liegt in seiner Konkretheit, weil es zeigt, warum „wir erhalten unsere Daten“ keine ausreichende Produktspezifikation ist. Ein Kunde kann bestimmte Kennzahlen sehen und dennoch keinen unmittelbaren Einblick in die Daten besitzen, aus denen eine technische Diagnose entsteht. Ob das im konkreten Vertragsverhältnis erforderlich, zulässig oder veränderbar ist, muss gesondert geprüft werden – die Veröffentlichung einer Datenbeschreibung ist kein Nachweis, dass sämtliche beschriebenen Prozesse in jeder Installation identisch funktionieren.

Für Ihre Beschaffung folgt daraus eine nützliche Reihe von Fragen: Welche Ereignisse kann Ihre eigene Instandhaltung unabhängig nachvollziehen, welche zusätzlichen Informationen benötigt der Hersteller tatsächlich und wofür, und wer dokumentiert, auf welcher Grundlage Daten für Diagnose und spätere Modellverbesserung verwendet werden? Die belastbare Antwort steht nicht in der Herstellerdokumentation selbst, sondern im Vertrag: Nur eine Klausel, die genau diese drei Punkte benennt, macht die Zusicherung im Datenschutzhinweis für Ihr Haus verbindlich – ohne sie bleibt sie eine einseitige Selbstauskunft. Das gilt selbst dann, wenn ein Anbieter – wie im Fall von Boston Dynamics – umfangreiche und öffentlich einsehbare Hinweise veröffentlicht.

Der Exportfähigkeitstest und das Prüfschema für den Vertragstext

Wie eng technische und organisatorische Nutzbarkeit zusammenhängen, zeigt ein weiteres, ausdrücklich fiktives Beispiel. Ein Betrieb erhält nach Vertragsende eine große CSV-Datei mit Zeitstempeln und numerischen Fehlercodes. Der Export ist im Sinne der gelieferten Felder vollständig. Trotzdem kann die neue Instandhaltung wenig damit anfangen, wenn die Zuordnung der Codes, die Systemversionen und die Einheiten fehlen – ein Status kann in einer frühen Softwareversion „Auftrag angehalten“ bedeutet haben und später „Auftrag verworfen“, ohne dass diese Bedeutungsänderung im Export erkennbar ist.

Ein Datenraum-Ansatz wie der Demonstrator RoX, vorgestellt zur automatica im Juni 2025, zeigt in die richtige Richtung: Er beschreibt den Austausch von Anwendungsdaten zur erneuten Modellschulung einschließlich Nachvollziehbarkeit und Datenkontrolle. RoX ist ein Entwicklungsansatz für einen Demonstrator, kein Nachweis eines allgemeinen Rechtsanspruchs oder einer flächendeckenden Praxis. Sein konzeptioneller Wert liegt darin, Rechte und Datenbewegung gemeinsam zu denken, statt einen Export als reine Dateiübergabe zu behandeln.

Für die Vorbereitung Ihres Vertrags lässt sich daraus ein kompaktes Prüfschema ableiten. Es ersetzt keine juristische Prüfung im Einzelfall, gibt aber Ihrer Verhandlung eine Struktur, die über eine pauschale Eigentumsklausel deutlich hinausgeht.

Ein kleiner praktischer Test lässt sich daran anschließen, ohne dass er einen gesetzlichen Mindestumfang behauptet: Eine fachlich geeignete zweite Person versucht, aus einem begrenzten Beispiel-Export einen bekannten Vorfall zu rekonstruieren – welche Maschine betroffen war, welche Aufgabe vorlag, wie das Ereignis endete. Scheitert dieser Test, lässt sich konkret benennen, welche Metadaten oder Erklärungen im Vertragstext noch fehlen, statt erst nach Vertragsende festzustellen, dass der Export zwar vollständig, aber unbrauchbar ist.

Was dieser Beitrag nicht regelt

Zwei Themen bleiben hier bewusst ausgeklammert, nicht übersehen: Der Wechsel von Cloud-Diensten nach Kapitel VI des Data Act und die Mitbestimmung bei Überwachungstechnik sind eigene, umfangreiche Themen, die dieser Beitrag nicht behandelt. Haben Sie neben dem Hersteller auch einen Cloudanbieter im Vertragsgeflecht, sollten Sie diese Fragen gesondert klären, weil sie eigene Fristen, eigene Verfahren und – bei der Mitbestimmung – eigene betriebliche Beteiligungsrechte mit sich bringen, die mit den hier beschriebenen Datenzugangsfragen zusammenhängen, aber nicht identisch sind. Wer beide Vertragsstränge getrennt hält, vermeidet, dass eine Datenschutz- oder Datenzugangsklausel nebenbei Fragen mitregelt, für die sie nie gedacht war.

Rechtssicherheit entsteht am Vertragstext, nicht an der Eigentumsfrage

Die eingangs gestellte Eigentumsfrage lässt sich am Ende präziser stellen: Wer benötigt welche Information, wozu darf sie verwendet werden, und welche Bedingungen gelten, wenn sich Kamera, Cloudservice oder Modell ändern? Für Ihren konkreten Beschaffungs-, Beschäftigten- oder Trainingsfall ersetzt diese Einordnung keine juristische Prüfung im Einzelfall. Sie liefert aber die Struktur, mit der sich eine solche Prüfung überhaupt sinnvoll vorbereiten lässt.

Ein Vertrag, der ein Dateninventar, eine Zwecktrennung und einen Exportfähigkeitstest enthält, verhandelt etwas Konkretes. Ein Vertrag, der nur festhält, wem „die Daten“ gehören, verhandelt einen Begriff, den der Data Act für Roboterdaten so nicht kennt. Die Durchsetzung liegt nach Artikel 37 Absatz 1 des Data Act bei den von den Mitgliedstaaten benannten zuständigen Behörden; welche Sanktionen im Einzelfall drohen, richtet sich nach Artikel 40 Absatz 1 des Data Act nach dem jeweiligen nationalen Umsetzungsrecht und ist damit selbst wieder eine Frage für die eigene Rechtsabteilung, nicht für diesen Beitrag.

Für translationale Physical AI – Systeme, die aus realen Einsätzen lernen sollen – ist das mehr als eine juristische Fußnote. Ein Datensatz, dessen Herkunft, Zweck und Berechtigung ungeklärt bleiben, hilft der nächsten Produktgeneration wenig, ganz gleich wie groß er ist. Erst wenn Zugriffsrechte, Zwecke und Exportfähigkeit den Übergang von einer Maschine zur nächsten überstehen, wird aus einem datenproduzierenden Roboter ein Betrieb, der seine eigene Erfahrung tatsächlich nutzen kann.