Datenschutz und verkörperte KI: Was darf der Roboter sehen und hören?

Roboter nehmen wahr – und das nicht erst, seit sie lernen: Schon die klassische Automatisierung arbeitet mit Kameras, Laserscannern (LiDAR) und Sensorik im Raum. Verkörperte Künstliche Intelligenz (KI) hebt diese Wahrnehmung auf eine neue Stufe: Kameras, Mikrofone, Tiefensensorik und LiDAR sind hier keine Zusatzausstattung, sondern Funktionsbedingung. Für Hersteller, Integratoren und Betreiber* von Robotern und anderen automatisierten Systemen stellen sich damit die zentralen Fragen des Datenschutzrechts: Auf welcher Rechtsgrundlage dürfen Sensordaten verarbeitet werden? Wer ist datenschutzrechtlich verantwortlich? Wann dürfen Betriebsdaten zu Trainingsdaten werden – und wie lässt sich „Privacy by Design" in der Roboterarchitektur umsetzen?

In unserem Serien-Auftakt haben wir gezeigt, dass ein einziger vernetzter Roboter Pflichten aus mehreren Rechtsgebieten zugleich auslöst. Im zweiten Beitrag zum Data Act lautete der Befund: „Data is the asset" – der wirtschaftliche Wert wandert von der Maschine in den Datenstrom. Dieser dritte Beitrag behandelt die Kehrseite: Der Datenstrom, der das Asset ist, enthält zahlreiche personenbezogene Daten.

Lernen mit Sensordaten: Der Datenlebenszyklus von Physical AI und Robotern

Auf dem Pariser „Machina Summit" zeigte das Start-up UMA Anfang Juli seinen Humanoiden „Northstar" – rund 40 Kilogramm leicht, für die Arbeit neben Menschen gebaut und darauf ausgelegt, neue Aufgaben zu übernehmen, die ihm niemand programmiert hat: Er schaut sie sich bei einem Menschen ab (Bloomberg, 07.07.2026). Ansätze wie dieser stützen sich auf die Modellklasse, die die Physical AI derzeit prägt: „Vision-Language-Action"-Modelle (VLA), die Kamerabild und Sprachanweisung unmittelbar in Roboterbewegung übersetzen. Zugespitzt: Das wichtigste Bauteil eines solchen Roboters ist nicht der Greifer, sondern die Kamera.

Personenbezogene Daten braucht ein solches System in jeder Phase seines Lebenszyklus. 

Beim Training entstehen die Fähigkeiten aus menschlichen Demonstrationen („Imitation Learning“) und Teleoperations-Sitzungen: Gefilmt wird, wer vormacht – oft Beschäftigte – und was im Hintergrund liegt – oft eine Wohnung oder eine Werkhalle. 

Im Betrieb nimmt der Roboter laufend seine Umgebung wahr, um zu navigieren, zu agieren und niemanden zu gefährden – das gilt für den lernenden Humanoiden ebenso wie für klassische Robotik und Industrieautomation mit fest installierten Kameras und Laserscannern. 

Und im Verbesserungszyklus schließt sich der Kreis: Betriebsdaten fließen als neues Trainingsmaterial in die Flotte zurück, Mitschnitte dienen der Fehleranalyse, und bei der Fernwartung blickt der Support möglicherweise auch live durch die Roboterkamera.

DSGVO und Robotik: Warum Roboter ihre Umgebung wahrnehmen müssen

Ein Roboter, der sich zwischen Menschen bewegt, muss wahrnehmen, um niemanden zu verletzen: Der kollaborierende Roboter („Mensch-Roboter-Kollaboration“, MRK – oder „Cobot“) bremst, wenn eine Hand in den Arbeitsraum greift; der autonome mobile Roboter im Lager weicht aus, bevor er jemanden touchiert; der Haushaltsroboter dosiert seine Kraft, weil ein Kind im Weg stehen könnte. Genau diese Risikobeherrschung verlangt das Produktsicherheitsrecht. Wahrnehmung ist damit keine Komfortfunktion, sondern die Voraussetzung dafür, dass der Roboter überhaupt ohne Schutzzaun unter Menschen arbeiten darf – und die Datenerhebung ist daher kein abschaltbares „Feature“.

Neu ist all dies nicht: Die klassische Industrieautomation überwacht seit Jahrzehnten mit „Machine Vision“-Kameras die Fertigung und sichert Anlagen und fahrerlose Transportsysteme mit Lichtschranken und Sicherheits-Laserscannern ab. Neu ist zweierlei. Erstens verlässt der Roboter seinen Käfig: Er agiert längst nicht mehr nur in abgeschirmten Roboterzellen, zu denen ausschließlich eingewiesenes Personal Zutritt hatte, sondern teilt sich Werkhalle, Gehweg und Wohnung mit Menschen, die dafür weder eingewiesen sind, noch eingewilligt haben. Zweitens ändert sich damit das Datenprodukt: Der klassische Sicherheits-Laserscanner meldet im Kern ein einziges Bit – „Schutzfeld verletzt“ –, kein Bild und keine Identität; Datenminimierung war konstruktiv eingebaut. Die moderne Perzeption, die den Zaun ersetzt, dreht das Verhältnis um: Sie erzeugt hochauflösende Roh- und Tiefenbilder von allem und jedem im Umfeld, aus denen die Sicherheitsentscheidung erst berechnet wird. Je näher der Roboter am Menschen arbeitet, desto mehr muss er über ihn wissen. 

Für die DSGVO heißt das: Der Grundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) kann nicht bedeuten: „keine Kamera“. Er verschiebt die Frage vom Ob zum Wie – welche Daten, in welcher Auflösung, wie lange, an welcher Stufe der Verarbeitungskette (Sensor-Chip, Hauptrechner, „Edge“, Cloud) und in welcher Form (Rohbild, anonymisiertes Abbild, abstraktes Merkmal) verarbeitet werden. Datenschutz wird zur Architekturentscheidung.

Personenbezogene Sensordaten: Welche Daten unter die DSGVO fallen

Der Personenbezug (Art. 4 Nr. 1 DSGVO) reicht weiter, als Entwicklern oft bewusst ist: Maßgeblich ist, ob eine Person mit verhältnismäßigen Mitteln identifiziert werden kann. Kamerabilder und Audioaufnahmen mit Stimmen sind der klare Fall. Weniger offensichtlich sind drei Fallgruppen:

• Der Punktwolken-Mythos. Das Argument „Wir nutzen nur LiDAR und Tiefensensorik, keine Farbkamera“ macht Daten nicht anonym. 3D-Punktwolken enthalten Körpersilhouetten und Gangmuster; in Kombination mit Ort und Zeit sind Personen häufig re-identifizierbar. Anonymität ist ein hoher Maßstab – nicht schon die Abwesenheit eines Farbbildes.
• Karten und Grundrisse. „SLAM“-Karten (Simultane Lokalisierung und Kartierung) einer Wohnung bilden private Lebensverhältnisse ab und sind dem Bewohner zuordenbar.
• Innenwahrnehmung mit Außenwirkung. Auch vermeintlich „roboterinterne“ Daten tragen Personenbezug, sobald Menschen mit der Maschine interagieren: Kraft- und Berührungssensorik protokolliert den Kontakt mit einem Menschen, Gelenk-Encoder zeichnen beim händischen Führen („Teachen“) die Bewegung des Beschäftigten auf, und Trajektorien- wie Taktzeitdaten spiegeln in der MRK das Arbeitsverhalten der Beteiligten.

Hinzu kommt Art. 9 DSGVO: Setzt der Roboter Gesichtserkennung zur eindeutigen Identifizierung ein (bspw. zur Nutzerauthentifizierung), verarbeitet er biometrische Daten der besonderen Kategorie – mit engem Erlaubnisrahmen. Die bloße Personen-Detektion („dort ist ein Mensch, ich bremse“) ohne Identifizierung fällt regelmäßig nicht darunter; die Grenze ist im Einzelfall zu ziehen.

Schließlich der Haushalts-Irrtum: Die Haushaltsausnahme (Art. 2 Abs. 2 lit. c DSGVO) privilegiert allein die ausschließlich persönliche Tätigkeit des privaten Nutzers – nicht die Erfassung des öffentlichen Raums und niemals den Hersteller, der die Daten in seiner Cloud verarbeitet. Der Roboter im Wohnzimmer entlastet also den Käufer, nicht den Anbieter.

Datenschutzrechtliche Verantwortung von Herstellern, Betreibern und Cloud-Diensten

Für den Einsatz vor Ort ist regelmäßig der Betreiber Verantwortlicher (Art. 4 Nr. 7 DSGVO); der Hersteller, der das Flotten- oder Cloud-Backend als „verbundenen Dienst“ bereitstellt (siehe Beitrag zum Data Act), agiert insoweit als Auftragsverarbeiter (Art. 28 DSGVO).

Die Rolle kippt jedoch, sobald der Hersteller die Daten für eigene Zwecke nutzt – Produktverbesserung, Fehleranalyse, vor allem Modelltraining über die Flotte hinweg: Dann wird er insoweit selbst Verantwortlicher; bei arbeitsteiliger Zweckbestimmung kann in bestimmten Fällen auch eine gemeinsame Verantwortlichkeit (Art. 26 DSGVO) entstehen. Vertragsseitig gehören Auftragsverarbeitungsvertrag und die „Datenlizenz“ nach Art. 4 Abs. 13 Data Act daher in ein konsistentes Rollenmodell – zwei Dokumente, ein Datenfluss.

Liegt das Flotten-Backend bei einem Anbieter außerhalb der EU oder greift der Fernwartungs-Support aus einem Drittland auf Roboterkameras zu, kommen die Übermittlungsregeln des Kapitels V DSGVO hinzu (Angemessenheitsbeschluss, Standardvertragsklauseln oder andere geeignete Garantien).

Beim Consumer-Roboter ist dagegen der Hersteller für die Cloud-Verarbeitung meist direkt Verantwortlicher, wenn der Nutzer aufgrund der Haushaltsausnahme nicht in den Pflichtenkreis der DSGVO fällt. Eine Auftragsverarbeitung nach Art. 28 DSGVO setzt insofern einen Verantwortlichen voraus, in dessen Auftrag verarbeitet wird; der privilegierte Privatnutzer ist hier aber gerade keiner.

DSGVO-Rechtsgrundlagen für Robotik und Physical AI

In der Robotik betrifft ein und derselbe Sensorstrom typischerweise drei Personenkreise mit je eigener Rechtsgrundlagen-Logik.

1. Nutzer und Vertragspartner. Soweit die Verarbeitung für Betrieb und Funktion erforderlich ist und der Vertragspartner selbst der Betroffene ist, trägt Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung); darüber hinausgehende Zwecke brauchen ein berechtigtes Interesse oder eine Einwilligung.

2. Unbeteiligte – der Regelfall im öffentlichen Raum. Wer einem Serviceroboter im Baumarkt oder einem Lieferroboter auf dem Gehweg begegnet, hat keine Vertragsbeziehung und kann realistischerweise nicht einwilligen. Tragfähig ist hier allein das berechtigte Interesse (Art. 6 Abs. 1 lit. f DSGVO – mit einer Abwägung, deren Ausgang von der Technik abhängt: Verarbeitung möglichst auf dem Gerät, sofortige Unkenntlichmachung in der Verarbeitungskette (bevor gespeichert wird), kurze Speicherfristen und klare Zweckbindung senken die Eingriffstiefe und tragen die Abwägung. Als Maßstab dienen auch die bestehenden Leitlinien zur Videoüberwachung; die Dashcam-Rechtsprechung liefert die Blaupause: Eine permanente, anlasslose Aufzeichnung ist datenschutzrechtlich unzulässig, eine kurze, anlassbezogene Speicherung (Ringspeicher) kann dagegen verhältnismäßig sein (BGH, Urt. v. 15.05.2018 – VI ZR 233/17). Übertragen auf die Robotik: Der Roboter darf sehen, um zu navigieren – er darf nicht alles behalten, was er sieht.

Dazu die Informationspflichten (Art. 13 und Art. 14 DSGVO): Ein Roboter kann selbst zum Informationsmedium werden durch gut sichtbare Kennzeichnung und Piktogramme am Gerät, Statusleuchten für aktive Aufzeichnung, QR-Code zu den vollständigen Datenschutzhinweisen, Aushänge am Einsatzort (mehrstufige Information). Dasselbe Informationskonzept kann eine zweite Pflicht gleich miterledigen: Nach Art. 50 Abs. 1 KI-VO (anwendbar seit dem 2. August 2026) müssen Personen erkennen können, dass sie mit einem KI-System interagieren, sofern dies nicht ohnehin offensichtlich ist – in klarer Weise, spätestens bei der ersten Interaktion (Art. 50 Abs. 5 KI-VO). Kennzeichnung, Statusanzeigen und die Ansprache des Roboters sind der natürliche Ort, DSGVO-Information und KI-VO-Transparenz in einem Zug umzusetzen. Transparenz wird somit Teil des Produktdesigns.

3. Beschäftigte. In der MRK werden Kollegen zu Dauer-Datenquellen; Rechtsgrundlage ist § 26 BDSG (Erforderlichkeit für das Beschäftigungsverhältnis) bzw. eine Kollektivvereinbarung (Art. 88 DSGVO). Für die sicherheitsgerichtete Sensorik am MRK-Arbeitsplatz ist die Erforderlichkeit gut begründbar – der Arbeitgeber ist zum Schutz seiner Beschäftigten verpflichtet (§§ 3 ff. ArbSchG); heikel wird es erst, wo dieselben Daten zusätzlich zur Auswertung oder für das Training genutzt werden sollen.

Ein Punkt wird dabei häufig unterschätzt. Flottendaten eines autonomen mobilen Roboters kartieren zwangsläufig auch Wege und Taktzeiten der Mitarbeiter. Der wahrnehmende Roboter ist daher regelmäßig eine technische Einrichtung, die zur Überwachung von Verhalten und Leistung objektiv geeignet ist – nach ständiger Rechtsprechung genügt das für das Mitbestimmungsrecht des Betriebsrats (§ 87 Abs. 1 Nr. 6 BetrVG). Ein Rollout ohne Betriebsrat ist ein vermeidbares Risiko; die Betriebsvereinbarung kann zugleich als Rechtsgrundlage dienen.

Sicherheit als Rechtsgrundlage? Lit. c und lit. d richtig einordnen. Naheliegend ist der Gedanke, die sicherheitsgerichtete Wahrnehmung gleich auf eine rechtliche Verpflichtung (Art. 6 Abs. 1 lit. c DSGVO) oder den Schutz lebenswichtiger Interessen (Art. 6 Abs. 1 lit. d DSGVO) zu stützen – schließlich verlangen Maschinenverordnung und Arbeitsschutzrecht die Beherrschung der Risiken. Ganz so einfach ist es nicht: Lit. c setzt voraus, dass die Rechtspflicht die Verarbeitung selbst hinreichend bestimmt vorgibt (Art. 6 Abs. 3 DSGVO). Sicherheitsnormen verpflichten aber nur zur Risikobeherrschung und lassen die Wahl der Mittel offen – ob trennender Schutzzaun oder sensorische Überwachung, entscheidet der Hersteller bzw. Betreiber. Die laufende Umgebungswahrnehmung trägt lit. c deshalb regelmäßig nicht; die Sicherheitspflicht liefert nicht die Rechtsgrundlage, wohl aber erhebliches Gewicht in der Interessenabwägung (Art. 6 Abs. 1 lit. f DSGVO) und in der Erforderlichkeitsprüfung des § 26 BDSG. Anwendungsfälle dieser Rechtsgrundlage kann es gleichwohl geben – dort, wo das Gesetz die Verarbeitung selbst anordnet: etwa aufgrund produktsicherheitsrechtlicher Melde- und Dokumentationspflichten und künftig im Rahmen der Protokollierungspflichten der KI-VO für Hochrisiko-Systeme.

Art. 6 Abs. 1 lit. d DSGVO schließlich ist die Grundlage für den akuten Ausnahmefall, nicht für den Dauerbetrieb (Erwägungsgrund 46: nachrangig gegenüber anderen Grundlagen): Erkennt ein Assistenzroboter eine gestürzte, nicht ansprechbare Person und setzt mit Bild und Standort einen Notruf ab, kann genau diese anlassbezogene Verarbeitung auf lit. d gestützt werden – die permanente Kameraüberwachung, die dem vorausgeht, nicht.

KI-Training mit Betriebsdaten: Datenschutz bei der Zweckänderung

Wer Daten zum Betrieb erhoben hat und sie selbst zum Training verwenden will, nimmt eine Zweckänderung vor, die am Kompatibilitätstest des Art. 6 Abs. 4 DSGVO zu messen ist oder eine eigene Rechtsgrundlage braucht. Der Europäische Datenschutzausschuss hat die Leitplanken gesetzt (EDSA, Stellungnahme 28/2024): Das Training von KI-Modellen kann auf ein berechtigtes Interesse gestützt werden – nach dreistufiger Prüfung und mit belastbaren Schutzmaßnahmen. Und ein trainiertes Modell ist nicht per se anonym: Lassen sich personenbezogene Daten aus den Modellgewichten extrahieren oder werden sie ausgegeben, bleibt die DSGVO auf das Modell selbst anwendbar – samt Betroffenenrechten, deren Umsetzung technisch anspruchsvoll ist. Soweit das Training nicht vom Betreiber ausgeht, sondern vom Hersteller, verlässt dieser seine Rolle als Auftragsverarbeiter und benötigt ebenfalls eine eigene Rechtsgrundlage für das Training.

Besonders praxisrelevant ist ein Detail aus dem Entwicklungsalltag: Dort werden oft vollständige Sensor-Mitschnitte protokolliert (im ROS-Ökosystem als „rosbags" bekannt) – für „Debugging“ und Fehleranalyse unverzichtbar, datenschutzrechtlich aber ein lückenloses Protokoll des Einsatzorts. Hier kollidiert die Speicherbegrenzung (Art. 5 Abs. 1 lit. e DSGVO) mit berechtigten – und künftig teils verpflichtenden – Dokumentations- und Beweisinteressen (Protokollierung nach der KI-VO, Produktbeobachtung und Beweissicherung der neuen Produkthaftung). Soweit die Protokollierung gesetzlich angeordnet ist, trägt Art. 6 Abs. 1 lit. c DSGVO die Verarbeitung (siehe oben); für das Überschießende bleibt es bei Abwägung und Gestaltung. Der Zielkonflikt lässt sich nur konstruktiv auflösen: selektives Logging, Anonymisierung vor der Speicherung, gestufte Aufbewahrung.

Data Act und DSGVO: Rechtssichere Datennutzung in der Robotik

Der Data Act gilt unbeschadet der DSGVO; im Konflikt geht der Datenschutz vor (Art. 1 Abs. 5 Data Act). Praktisch bedeutet das: Der Datenzugangsanspruch des Nutzers ist keine Rechtsgrundlage für die Daten Dritter. Verlangt ein Flottenbetreiber Kameradaten beim Hersteller heraus, auf denen Beschäftigte oder Kunden zu erkennen sind, braucht die Herausgabe eine eigene Grundlage nach Art. 6 DSGVO (ggf. Art. 9 DSGVO).

Privacy by Design für Robotik: Datenschutz als Teil der Systemarchitektur

Art. 25 DSGVO verlangt Datenschutz durch Technikgestaltung – bei Physical AI ist das wörtlich zu nehmen. Bewährte Muster sind etwa: Inferenz auf dem Gerät oder an der „Edge" statt Rohdaten-Streaming in die Cloud; Verarbeitung im flüchtigen Speicher mit sofortigem Verwerfen (was zugleich außerhalb des Data-Act-Zugangs liegt); Unkenntlichmachung in der Verarbeitungskette vor jeder Speicherung; Verwendung von Ringspeichern statt permanenter Speicherung; reduzierte Auflösung, wo Detektion genügt; lokale Schlüsselwort-Erkennung („Wake Word“) statt dauerhaftem Audio-Streaming in die Cloud; getrennte Datenpfade für Sicherheitsfunktion und Komfort- bzw. Analysezwecke; Rollen- und Zugriffskonzept im Flotten-Backend. Unkenntlichmachung entfaltet dabei nur dann anonymisierende Wirkung, wenn das Rohmaterial nicht parallel fortbesteht – andernfalls liegt lediglich Pseudonymisierung vor, und die DSGVO bleibt vollständig anwendbar.

Die Hardware kommt dem entgegen, denn Sensordaten durchlaufen ohnehin eine spezialisierte Vorverarbeitung: Bildsignalprozessoren („ISP") bereiten das Rohsignal der Kamera auf, und in vielen Sensor-„Systems-on-Chip“ sitzt inzwischen eine „Neural Processing Unit“ (NPU), die einfache Wahrnehmungsaufgaben – etwa das Klassifizieren von Objekten oder das Schätzen von Körperhaltungen („Posen“) – bereits am Sensorknoten erledigt, bevor der Hauptrechner die Daten überhaupt sieht. Wer diese Kette bewusst gestaltet, kann sie so bauen, dass nur das abstrakte Ergebnis den Sensorknoten verlässt („Person in zwei Metern, Ausweichkurs eingeleitet“) – nicht das Rohbild. Dass dabei weniger übertragen und weniger Energie verbraucht wird, macht die Vorverarbeitung auch ökonomisch attraktiv: Datenschutz und Ressourceneffizienz ziehen am selben Strang. Rechtlich hat das eine Rückkopplung: Art. 25 DSGVO knüpft ausdrücklich an den „Stand der Technik“ an – was am Sensor bereits möglich ist, prägt mit, was rechtlich erwartet werden kann, auch in der Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO.

Flankierend die Datenschutz-Folgenabschätzung (DSFA – Art. 35 DSGVO): Bei systematischer, umfangreicher Überwachung öffentlich zugänglicher Bereiche ist sie Pflicht, beim Einsatz neuartiger Technologien regelmäßig angezeigt – für mobile Roboter in geteilten Räumen also der Normalfall. Richtig eingesetzt, ist die DSFA kein nachlaufendes Compliance-Papier, sondern ein Konstruktionsdokument, das neben die Risikobeurteilung der Maschinenverordnung tritt: ein integriertes Risiko-Engineering für Sicherheit und Datenschutz.

Praxisempfehlungen für DSGVO-konforme Robotik und Physical AI

• Dokumentieren, welche Daten der Roboter tatsächlich erzeugt. Je Robotertyp und Einsatzort festhalten: Welche Sensoren erfassen was? Sind darauf Personen erkennbar oder bestimmbar? Wo werden die Daten verarbeitet und gespeichert, wie lange, und wer hat Zugriff? Ergänzt um Zweck und Rechtsgrundlage je Datenart, entsteht daraus das Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO) – und zugleich die Grundlage für die Transparenz- und Zugangspflichten des Data Act.
• Die Architektur datenschutzkonform gestalten – und die Entscheidungen dokumentieren. Verarbeitung so nah am Sensor wie möglich: zuerst auf dem Gerät, dann an der „Edge“ im eigenen Netz; in die Hersteller-Cloud nur, was übergreifend gebraucht wird. Das Rollenmodell samt Auftragsverarbeitung und Datenlizenz konsistent aufsetzen; die DSFA als Konstruktionsdokument neben der Risikobeurteilung der Maschinenverordnung führen.
• Den Einsatzort vorbereiten – und im Arbeitsumfeld die Mitbestimmung. Das Kennzeichnungs- und Informationspaket erstellen und vor Ort umsetzen (Piktogramme, Hinweise, QR-Ziel zu den vollständigen Datenschutzinformationen – zugleich die Transparenz nach Art. 50 KI-VO); im Arbeitsumfeld den Betriebsrat früh einbinden (§ 87 Abs. 1 Nr. 6 BetrVG) und die Betriebsvereinbarung als Rechtsgrundlagen-Anker mit klarem Regelungskatalog nutzen (Zwecke, Auswertungsgrenzen, Zugriff, Löschung).
• Den Daten-Lebenszyklus steuern. Vor der Nutzung von Felddaten für das Training eine Zweckänderungsprüfung (Art. 6 Abs. 4 DSGVO) als internes Freigabe-Gate schalten; das Lösch-Konzept als Aufbewahrungsmatrix führen – Ringspeicher- und Speicherfristen je Datenklasse, abgeglichen mit Dokumentations- und Beweissicherungspflichten; einen Antwortpfad für Betroffenenanfragen definieren.

Datenschutz als Erfolgsfaktor für Physical AI und moderne Robotik

Wer Roboter baut oder betreibt – klassisch automatisiert oder verkörpert intelligent –, entscheidet mit jeder Stufe der Sensor-Pipeline zugleich über Datenschutzrecht. Dieselben Architekturentscheidungen, die die DSGVO-Abwägung tragen, berühren zugleich den Data Act. CMS begleitet Hersteller, Integratoren und Betreiber interdisziplinär – von der Sensor-Pipeline über Betriebsvereinbarung und Vertragsarchitektur bis zur Trainingsdaten-Governance.

Building the legal stack for Physical AI.

Redaktioneller Hinweis: Die Angaben geben den Stand zum Redaktionsschluss (13. Juli 2026) wieder. Vor einer konkreten Umsetzung sind die Primärquellen (EUR-Lex, EDSA, Rechtsprechungsdatenbanken) heranzuziehen.

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