Data protection and Physical AI: What are robots allowed to see and hear?

Robots perceive their surroundings – and not just since they began to learn: Even conventional automation makes use of cameras, laser scanners (LiDAR) and sensor technology. Physical artificial intelligence (AI) takes this perception to a new level: Cameras, microphones, depth sensors and LiDAR are not merely optional extras here, but essential for the system to function. For manufacturers, integrators and operators of robots and other automated systems, this raises key questions under data protection law: On what legal basis may sensor data be processed? Who is responsible for data protection? When may operational data be used as training data – and how can "privacy by design" be implemented in robot architecture?

In the first article in our series, we demonstrated that a single connected robot triggers obligations from multiple areas of law simultaneously. In the second article on the Data Act, the conclusion was: "Data are the asset" – economic value is shifting from the machine to the data stream. This third article addresses the flip side: The data stream, which is the asset, contains a wealth of personal data.

Learning from sensor data: the data lifecycle of Physical AI and robots

At the "Machina Summit" in Paris in early July, the start-up UMA unveiled its humanoid "Northstar" – weighing around 40 kilograms, built to work alongside humans and designed to take on new tasks that nobody has programmed it to perform: It learns them by observing a human (Bloomberg, 7 July 2026). Approaches such as this are based on the model class that is currently shaping Physical AI: "Vision-Language-Action" (VLA) models, which directly translate camera images and voice commands into robotic movements. To put it plainly: The most important component of such a robot is not the gripper, but the camera.

A system of this kind requires personal data at every stage of its lifecycle. 

During training, the robot acquires abilities from human demonstrations ("imitation learning") and teleoperation sessions: The camera focuses on the person demonstrating the task (often a member of staff) and whatever is in the background (often a person's home or a factory workshop). 

During operation, the robot continuously perceives its surroundings in order to navigate, carry out tasks and ensure that no one is put at risk – this applies to the learning humanoid just as much as it does to conventional robotics and industrial automation systems with permanently installed cameras and laser scanners. 

And in the improvement cycle, the process comes full circle: Operational data flow back into the fleet as new training material, recordings are used for fault analysis, and during remote maintenance, support staff may even view the situation live through the robot's camera.

The GDPR and robotics: why robots need to perceive their surroundings

A robot moving amongst people must be able to perceive its surroundings so as not to hurt anyone: A collaborative robot ("human-robot collaboration", HRC – or "cobot") brakes if a hand moves into its workspace; the autonomous mobile robot in the warehouse swerves out of the way before it comes into contact with anyone; the domestic robot carefully controls its speed because a child might be in the way. It is precisely this risk management that is required by product safety legislation. Perception is therefore not a convenience feature, but a prerequisite for the robot to be allowed to work amongst people without a safety barrier – and data collection is therefore not a "feature" that can be switched off.

None of this is new: For decades, conventional industrial automation has been using "machine vision" cameras to monitor production and photoelectric sensors and safety laser scanners to safeguard facilities and driverless transport systems. There are two new developments. Firstly, the robot has left its confines: It no longer operates solely within shielded robot cells to which only trained staff had access, but now shares factory workshops, pavements and homes with people who are neither trained nor have given their consent. Secondly, this changes the nature of the data product: At its core, the conventional safety laser scanner transmits a single bit – "protective field violated" – rather than an image or an identity; data minimisation was built into its design. Modern perception technology, which replaces the barrier, turns this around: It generates high-resolution raw and depth images of everything and everyone in the vicinity, which are then used to calculate the decision on safety. The closer a robot works to humans, the more it needs to know about them. 

As far as the GDPR is concerned, this means that the principle of data minimisation (Article 5 (1) (c) GDPR) cannot simply mean "no camera". It shifts the focus from "whether" to "how" – specifically, which data are processed, at what resolution, for how long, at which stage of the processing chain (sensor chip, main computer, "edge", cloud) and in what form (raw image, anonymised image, abstract feature). Data protection thus becomes an architectural decision.

Personal sensor data: what data are covered by the GDPR

The concept of "personal data" (Article 4 no. 1 GDPR) extends further than developers often realise: The decisive factor is whether an individual can be identified using proportionate means. Camera images and audio recordings containing voices are clear-cut cases. Three groups of cases are less obvious:

• The point cloud myth. The argument that "We only use LiDAR and depth sensors, not a colour camera" does not make the data anonymous. 3D point clouds contain body silhouettes and gait patterns; when combined with location and time, individuals can often be re-identified. Anonymity sets a high bar – it is not simply achieved by the absence of a colour image.
• Maps and floor plans. "SLAM" (Simultaneous Localisation and Mapping) maps of a person's home depict private living conditions and can be linked to the occupant.
• Internal perception with external impact. Even data that are supposedly "internal to the robot" are personal data as soon as humans interact with the machine: Force and touch sensors record contact with a person; joint encoders record the employee's movements during manual guidance ("teaching"); and trajectory and cycle time data reflect the working behaviour of all those involved in human-robot collaboration.

Then there is Article 9 GDPR: If the robot uses facial recognition for unambiguous identification (e.g. for user authentication), it processes special-category biometric data – subject to a strict set of permissions. The mere detection of a person ("there's a person there, I'll brake") without identification is generally not covered; the line must be drawn on a case-by-case basis.

Finally, there is the "household" misconception: The household exemption (Article 2 (2) (c) GDPR) applies solely to the purely personal activity of private users – not to the monitoring of public spaces, and certainly not to the manufacturer who processes the data in its cloud. Robots in the living room therefore relieve the buyer of the GDPR's obligations, not the provider.

Data protection responsibilities of manufacturers, operators and cloud service providers

For on-site use, the operator is typically the controller (Article 4 (7) GDPR); the manufacturer, which provides the fleet or cloud backend as a "related service" (see article on the Data Act), acts as the processor in that respect (Article 28 GDPR).

However, the roles are reversed as soon as the manufacturer uses the data for its own purposes – product improvement, fault analysis and, above all, model training across the fleet: In such cases, the manufacturer itself becomes the controller; where the purpose is based on the division of labour, joint controllership (Article 26 GDPR) may also apply in certain cases. From a contractual perspective, the data processing agreement and the "data licence" under Article 4 (13) Data Act (see article on the Data Act) therefore form part of a consistent role model – two documents, one data flow.

If the fleet backend is hosted by a provider outside the EU or if remote maintenance support from a third country accesses robot cameras, the data transfer rules set out in Chapter V GDPR also apply (adequacy decision, standard contractual clauses or other appropriate safeguards).

In the case of consumer robots, however, the manufacturer is usually the direct controller for cloud processing if the user does not fall within the scope of the GDPR due to the household exemption. Data processing pursuant to Article 28 GDPR therefore requires a controller on whose behalf the data are processed; however, the privileged private user is not such a controller in this context.

GDPR legal bases for robotics and Physical AI

In robotics, a single sensor stream typically affects three different groups of individuals, each with its own legal basis.

1. Users and contractual partners. Insofar as the processing is necessary for operation and functionality, and the contractual partner is the data subject itself, Article 6 (1) (b) GDPR (performance of a contract) applies; any purposes beyond this require a legitimate interest or consent.

2. Uninvolved third parties – the norm in public spaces. Anyone who encounters a service robot in a DIY store or a delivery robot on the pavement has no contractual relationship and cannot realistically give consent. The only viable legal basis here is the legitimate interest (Article 6 (1) (f) GDPR) – subject to a balance of interests, the outcome of which depends on the technology: Processing the data on the device wherever possible, immediate de-identification within the processing chain (before storage), short storage periods and clear purpose limitation reduce the level of interference and support the balance of interests. The existing guidelines on video surveillance also serve as a benchmark; case law on dashcams provides the blueprint: Permanent, incident-free recording is inadmissible under data protection law; by contrast, short-term, incident-based storage (ring buffer) may be justified (German Federal Court of Justice, judgment of 15 May 2018 – VI ZR 233/17). Applied to robotics: The robot is permitted to see in order to navigate – it is not permitted to retain everything it sees.

The information obligations (Article 13 and Article 14 GDPR apply here): A robot can itself become a medium for providing information through clearly visible labelling and pictograms on the device, status lights indicating active recording, a QR code linking to the full data protection notice, and notices put up on display at the site of operation (multi-tiered information). The same information concept can fulfil a second obligation at the same time: Under Article 50 (1) AI Act (applicable as of 2 August 2026), individuals must be able to recognise that they are interacting with an AI system, unless this is already obvious – in a clear manner at the latest at the time of the first interaction (Article 50 (5) AI Act). Labelling, status indicators and the way the robot is addressed are the natural points at which GDPR information and AI Act transparency can be implemented in one go. Transparency thus becomes an integral part of the product design.

3. Employees. In HRC, colleagues become permanent data sources; the legal basis for this is section 26 German Federal Data Protection Act (BDSG) (necessity for the employment relationship) or a collective agreement (Article 88 GDPR). The need for safety-oriented sensor technology at an HRC workplace is easy to justify – employers are required to protect their employees (sections 3 ff. German Occupational Safety and Health Act (ArbSchG)); matters only become complicated when the same data are to be used additionally for analysis or training purposes.

One aspect is often underestimated in this regard. Fleet data from an autonomous mobile robot inevitably also map employees' routes and cycle times. The perceiving robot is therefore typically a technical device that is objectively suitable for monitoring behaviour and performance – according to established case law, this is sufficient to trigger the works council's co-determination right (section 87 (1) no. 6 German Works Constitution Act (BetrVG)). A roll-out without the works council's involvement is an avoidable risk; the works agreement can also serve as the legal basis.

Safety as a legal basis? Correctly interpreting Article 6 (1) (c) and (d) GDPR. It is tempting to think that safety-oriented processing could be based directly on a legal obligation (Article 6 (1) (c) GDPR) or the protection of vital interests (Article 6 (1) (d) GDPR) – after all, the Machinery Regulation and health and safety legislation require risks to be managed. It is not quite as simple as that: Point (c) requires that the legal obligation sufficiently specifies the processing itself (Article 6 (3) GDPR). However, safety standards only impose an obligation to manage risks and leave the choice of means open – whether to use a protective barrier or sensor-based monitoring is decided by the manufacturer or operator. Continuous environmental monitoring therefore does not generally satisfy point (c); the safety obligation does not provide the legal basis, but it does carry considerable weight in the balance of interests (Article 6 (1) (f) GDPR) and in the assessment of necessity under section 26 German Federal Data Protection Act (BDSG). There may nevertheless be cases where this legal basis applies – namely where the law itself requires processing: for example, due to reporting and documentation obligations under product safety law and, in future, within the framework of the logging obligations under the AI Act for high-risk systems.

Article 6 (1) (d) GDPR provides the basis for specific exceptional cases, not for continuous operation (Recital 46: subordinate to other legal bases): If an assistive robot detects a person who has fallen and is unresponsive, and makes an emergency call by transmitting an image and location, it is precisely this incident-based processing that can be justified under point (d) – but not the continuous camera surveillance that precedes it.

AI training using operational data: data protection in the event of a change of purpose

Anyone who has collected operational data and wishes to use them for training purposes is changing the purpose of the data; this must be assessed against the compatibility test set out in Article 6 (4) GDPR or requires a separate legal basis. The European Data Protection Board has set out the guidelines (EDPB, Opinion 28/2024): The training of AI models may be based on a legitimate interest – following a three-stage assessment and subject to robust safeguards. And a trained model is not anonymous per se: If personal data can be extracted from the model weights or are output, the GDPR remains applicable to the model itself – including data subjects' rights, the implementation of which is technically challenging. Where the training is carried out not by the operator but by the manufacturer, the latter ceases to act as a data processor and also requires its own legal basis for the training.

One detail from day-to-day developments is particularly relevant in practice: Complete sensor recordings are often logged (known as "rosbags" in the ROS ecosystem) – indispensable for debugging and fault analysis, but, from a data protection perspective, they constitute a comprehensive record of the site of operation. Here, the storage limitation (Article 5 (1) (e) GDPR) conflicts with legitimate – and, in future, partly mandatory – interests in documentation and evidence (logging in accordance with the AI Act, product monitoring and the preservation of evidence under the new product liability legislation). Where logging is required by law, Article 6 (1) (c) GDPR provides the legal basis for the processing (see above); for anything beyond this, the matter remains subject to the balance of interests and design. This conflict of objectives can only be resolved constructively: selective logging, anonymisation prior to storage, and tiered retention.

Data Act and GDPR: legally compliant data use in robotics

The Data Act applies without prejudice to the GDPR; in the event of a conflict, data protection will prevail (Article 1 (5) Data Act). In practice, this means that the user's right of access to data does not constitute a legal basis for third-party data. If a fleet operator requests camera data from the manufacturer in which employees or customers can be identified, the disclosure of such data requires its own legal basis under Article 6 GDPR (or, where applicable, Article 9 GDPR).

Privacy by design for robotics: data protection as part of the system architecture

Article 25 GDPR requires data protection through technical design – in the case of Physical AI, this must be taken literally. Proven patterns include, for example: inference on the device or at the "edge" rather than streaming raw data to the cloud; processing in volatile memory with immediate discarding (which also falls outside the scope of the Data Act access right); de-identification within the processing chain prior to any storage; use of ring buffers instead of permanent storage; reduced resolution where detection is sufficient; local keyword recognition ("wake word") instead of continuous audio streaming to the cloud; separate data paths for security functions and for convenience or analysis purposes; and a role-based and access-based concept in the fleet backend. In this context, de-identification only has an anonymising effect if the raw data do not continue to exist in parallel – otherwise, it is merely pseudonymisation and the GDPR remains fully applicable.

The hardware accommodates this, as sensor data undergo specialised pre-processing in any case: Image signal processors (ISPs) process the camera's raw signal, and many sensor "systems-on-chip" now incorporate a "neural processing unit" (NPU) that performs simple perception tasks – such as classifying objects or estimating body postures ("poses") – at the sensor node before the main computer even sees the data. Anyone who designs this chain deliberately can set it up so that only the abstract result leaves the sensor node ("Person two metres away, evasive manoeuvre initiated") – not the raw image. The fact that this results in less data being transmitted and less energy being consumed also makes pre-processing economically attractive: Data protection and resource efficiency go hand in hand. Legally, this has a reciprocal effect: Article 25 GDPR explicitly refers to the "state of the art" – what is already technically possible with the sensor helps to determine what can be legally expected, including in the balance of interests under Article 6 (1) (f) GDPR.

This is complemented by the Data Protection Impact Assessment (DPIA – Article 35 GDPR): It is mandatory in the case of systematic, extensive surveillance of publicly accessible areas, and is generally advisable when using novel technologies – which is therefore the norm for mobile robots operating in shared spaces. When used correctly, the DPIA is not merely a retrospective compliance document, but a design document that complements the risk assessment required by the Machinery Directive: an integrated risk engineering approach to safety and data protection.

Practical recommendations for GDPR-compliant robotics and Physical AI

• Document which data the robot actually generates. Record the following for each type of robot and site of operation: Which sensors detect what? Can humans be recognised or identified from these data? Where are the data processed and stored, for how long, and who has access? Supplemented by the purpose and legal basis for each type of data, this forms the record of processing activities (Article 30 GDPR) – and, at the same time, the basis for the transparency and access obligations under the Data Act.
• Design the architecture to comply with data protection regulations – and document the decisions. Process data as close to the sensor as possible: first on the device, then at the "edge" within your own network; only send data to the manufacturer's cloud that are required across the board. Consistently implement the role model, including data processing and data licensing; maintain the DPIA as a design document alongside the risk assessment required by the Machinery Directive.
• Prepare the site of operation – and co-determination in the working environment. Create the labelling and information package and implement it on site (pictograms, notices, a QR code linking to the full data protection information – thereby ensuring transparency in accordance with Article 50 AI Act); involve the works council at an early stage within the working environment (section 87 (1) no. 6 German Works Constitution Act (BetrVG)) and use the works agreement as a legal foundation with a clear set of rules (purposes, limits on analysis, access, erasure).
• Manage the data lifecycle. Before using field data for training, conduct a change-of-purpose assessment (Article 6 (4) GDPR) as an internal approval gate; manage the data erasure policy as a retention matrix – ring buffer and retention periods for each data class, aligned with documentation and evidence preservation obligations; define a response procedure for data subject requests.

Data protection as a key to success for Physical AI and modern robotics

Anyone who builds or operates robots – whether traditionally automated or embodied intelligent systems – is simultaneously making decisions regarding data protection law at every stage of the sensor pipeline. The very same architectural decisions that underpin GDPR compliance also have implications for the Data Act. CMS provides interdisciplinary support to manufacturers, integrators and operators – from the sensor pipeline and works agreement to contract architecture and training data governance.

Building the legal stack for Physical AI.

Editor's note: The information reflects the situation prevailing at the time of going to press (13 July 2026). Consult the primary sources (EUR-Lex, EDPB, database for judgments) before actually implementing the contents.