GDPR Compliance for Service Robots

Does a Service Robot Process Personal Data?

Usually yes. A service robot in a staffed building almost always processes personal data, because its navigation and safety sensors capture identifiable people. Video frames, depth point clouds that preserve body shape, badge and access-card reads, and WiFi or Bluetooth device identifiers taken during localisation all count as personal data when a person can be singled out. The robot does not need to recognise a face for GDPR to apply.

The usual counter-argument is that the robot is "just navigating". That argument fails on the evidence. A depth sensor mounted at 30 centimetres returns a dense 3D reconstruction of a corridor, and a person walking through it is not an anonymous grey blob in the stored data: their height, gait, clothing and position in time are all recorded, and in a small team those attributes are re-identifying on their own.

The Four Sensor Payloads That Make GDPR Apply

Four payload types appear on almost every commercial service robot, and each has a different GDPR profile. Knowing which ones your unit carries decides the depth of the assessment.

Payload	Personal data it captures	Typical retention temptation
RGB camera (vSLAM or obstacle)	Faces, clothing, badge lanyards, screens, documents in frame	Full shift video kept 30-90 days "for incident review"
3D depth / LiDAR	Body shape, height, gait, occupancy of a room	Point clouds kept indefinitely to re-map floors
RF sniffing (WiFi/BLE during localisation)	Device MAC addresses, which link to a named employee's phone	Raw scan logs kept for signal diagnostics
Interaction logs (screen taps, voice, delivery recipient)	Who requested what, at what time, to which room	Full ordering history in the fleet portal

The fourth row is the one operators underestimate. A delivery robot that records "recipient at room 412, 14:07, one parcel" is building a movement profile of named staff even with no camera at all. If the same fleet software can rank employees by deliveries received, that is a monitoring system with a robot attached, and it falls squarely inside the assessment.

The DPIA Trigger Test

Article 35 requires a DPIA where processing is likely to result in a high risk to rights and freedoms. Supervisory authorities publish lists of the criteria that push processing into that band, and a service robot usually hits several at once. Work through the test before committing to a deployment date, because a DPIA done after go-live is a harder conversation.

Trigger condition	Does a robot trip it?	Evidence to collect
Systematic monitoring of a publicly accessible area	Yes, if the robot covers corridors, lobbies or shop floors on a repeating route	Route map with camera field-of-view coverage polygons
Monitoring of employees in the workplace	Yes, in nearly every cleaning and delivery case	Statement of what telemetry is visible to managers
Processing of vulnerable data subjects	Yes in hospitals, care homes and schools	Site classification and any patient or child capture in frame
Innovative use of technology	Yes, mobile autonomy plus bio-adjacent sensing qualifies	Sensor specification and AI component description
Data processed on a large scale	Depends on floor area and footfall	Daily person-capture estimate: routes times footfall
Matching or combining datasets	Yes when robot logs join badge or rostering data	Integration diagram naming every receiving system
Automated decisions with legal effect	Rarely, but see the Article 22 section below	Any rule that changes a person's pay or standing

Two or more yes answers is the practical threshold most authorities use to expect a DPIA. A cleaning fleet in an occupied office hits at least four. The honest conclusion for most deployments is that the assessment is not optional, and the useful work is doing it once, well, rather than arguing about whether it applies.

Filling In a DPIA Section by Section

Article 35(7) sets out the minimum content. The table below translates each statutory field into what a robot deployment actually has to say. A DPIA that answers these nine rows in plain language will survive a supervisory-authority request without a rewrite.

Article 35(7) field	Robot-specific answer
Systematic description of processing	Route, shift pattern, sensor list, capture rate in frames per minute, every system the data reaches
Purpose of processing	The operational purpose only. Floor coverage and obstacle avoidance are purposes; "improving our AI" is not unless specified and lawful
Necessity assessment	Why a robot rather than a fixed sensor, and why this sensor resolution rather than a coarser one
Proportionality assessment	Whether capture can be reduced: masked faces, downsampled depth, disabled RF scanning where not needed
Risks to rights and freedoms	Loss of anonymity in staff areas, performance monitoring by inference, re-identification of visitors
Measures to address risks	Retention limits, access control, on-device processing, vendor contractual terms
Data subject consultation	Staff notice, works council involvement where one exists, visitor signage at entry points
DPO opinion	Written sign-off, or a documented reason none is appointed
Sign-off and review date	Named controller approver and a review trigger on any sensor or software change

The row that gets skipped is necessity. A DPIA that says "the robot needs a camera to navigate" without testing a lower-resolution or masked alternative reads like a justification written after the purchase order. Document the alternatives you rejected, and why, before the deployment decision is fixed.

Controller, Processor and Joint Controller

A robot deployment has three parties and the GDPR roles are frequently mislabelled in the contract, which matters because the roles decide who answers a subject access request and who carries the fine. The building operator usually determines the purpose, so the operator is the controller. The robot vendor supplies the hardware and often the fleet software, and typically acts as a processor. The complication is the fleet-software vendor, which may see data across many customers and can drift into joint controllership if it uses that data for its own product development.

Party	Usual role	What it must sign
Building operator or FM contractor	Controller	DPIA sign-off, staff notice, records of processing
Robot vendor (hardware and firmware)	Processor, or controller for its own telemetry	Article 28 processor agreement, sub-processor list, deletion-on-exit
Fleet-software vendor	Processor, or joint controller if it reuses data	Article 28 agreement plus an explicit no-secondary-use clause
Integrator or reseller	Usually none, but check	Confirmation it does not retain a copy

The processor agreement is where deployment projects lose control. An Article 28 agreement should state the retention period, name every sub-processor, require notification before adding one, and commit to deletion or return on termination. If the fleet software keeps a copy of the video after the contract ends, the deployment has no exit, and the exit clause in the contract renewal and exit planning guide will not save it.

The data-ownership question runs alongside this. Who can export the fleet data, and who can delete it, is a commercial question with a legal shadow; the data ownership and API interoperability guide sets out the access levels to negotiate, and it is worth reading before rather than after the processor agreement is signed.

Article 22 and Performance Monitoring

Article 22 restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect a person. A robot rarely makes that decision by itself. The exposure appears one step later, when robot telemetry becomes the evidence for a management decision about a named employee.

The realistic scenario is a cleaning fleet. The robot reports coverage percentage, cycle time and the rooms it visited. A site manager compares coverage per shift against a staff roster and concludes that one operative is underperforming. No algorithm decided anything, but a person's standing at work was altered by an automated measurement system they cannot inspect or contest. That is the pattern supervisory authorities care about, and it is why the DPIA has to state whether telemetry is attributable to named individuals.

• Keep telemetry at task level, not person level. Report rooms cleaned per shift, not per named operative, unless there is a documented operational need.
• Publish the metric before you measure it. A metric introduced silently after deployment is the one that generates complaints.
• Give the human a route to contest. If a coverage figure feeds a performance conversation, the employee must be able to see the figure and the raw log behind it.
• Separate the safety log from the performance log. Incident video used for a safety investigation should not become routine management reporting by default.

These four points belong in the DPIA and in the works council discussion, if the site has one. The consultation mechanics for a unionised site are covered in the works council and trade union consultation guide, because the monitoring question is the one that most often stalls a deployment after the hardware has arrived.

Retention and the Cost of Keeping Video

Retention is where GDPR obligations and storage bills meet, and the arithmetic usually surprises the operator. A single 1024-pixel camera recording continuously at 15 frames per second produces roughly 1.5 to 3 gigabytes of compressed video per hour depending on scene complexity. A cleaning robot running two 4-hour shifts covers 8 hours, so 12 to 24 gigabytes per unit per day.

Across a modest fleet of six units that is 72 to 144 gigabytes per day, or 26 to 52 terabytes per year. At typical object-storage pricing plus egress, the annual bill lands in the low thousands of currency units, and that is precisely the cost the storage vendor's invoice documents. The GDPR obligation does not care about the bill, but it makes a clear demand: keep the minimum necessary, for the minimum period.

Retention policy	What it means operationally
7 days rolling	Covers incident investigation for the current week; almost always defensible as necessary
30 days rolling	Defensible if incident reporting lags; requires justification in the DPIA
Indefinite	Not defensible for routine video; retention without purpose fails the storage limitation principle
On-device only, no upload	Strongest position; requires that the robot can complete its task without cloud video

The strongest deployment design is one where video never leaves the robot unless an incident is flagged. That single architectural choice removes most of the retention argument, reduces the storage bill to near zero, and makes the DPIA considerably shorter. Ask the vendor whether it is possible, and treat "no" as a specification answer rather than a technical inevitability. The same on-device reasoning applies to the data flows described in the occupancy sensor and BMS integration guide, where aggregate occupancy is usually all the building system actually needs.

The Procurement Clauses That Close the Gap

Most GDPR problems in a robot deployment are decided in the purchase contract, long before an assessment is written. Six clauses carry the weight.

• Purpose limitation clause: the vendor may not use customer data for model training, benchmarking or product improvement without separate written consent.
• Retention clause: a stated maximum, with automatic deletion, not a customer-configurable default that nobody changes.
• Sub-processor clause: a named list, notification before change, and a right to object.
• Deletion-on-exit clause: deletion within a stated number of days of termination, with written confirmation.
• Assistance clause: the vendor assists with subject access requests within a stated turnaround, at no extra charge.
• Audit clause: the right to inspect, or to receive an independent audit report, covering the data flows named in the DPIA.

These are ordinary Article 28 requirements, and yet they are the clauses most often missing from a robot purchase order written against a datasheet. The gap is structural: the people who write the order are buying a machine, and the people who know Article 28 are not in the room. Bringing the DPIA into the procurement process, rather than running it as a post-award compliance step, is what closes it.

What to Ask Before You Sign

A short list of questions separates a vendor that has thought about this from one that has not. Ask them in writing, and keep the answers with the DPIA.

1. Which sensors capture personal data, and can each be disabled independently?
2. Does video leave the robot, and if so, where is it stored and for how long?
3. Can the fleet software rank or score named employees, and is that switchable off?
4. Who are the sub-processors, and has any of them changed in the last twelve months?
5. What happens to customer data thirty days after contract termination?
6. Are you a processor, a joint controller, or a controller for any part of this data?
7. Can you supply the technical and organisational measures in writing for our DPIA annex?

A vendor that answers all seven with specifics is a vendor you can deploy with. A vendor that answers the first three and goes quiet is telling you something more useful than any brochure. For the wider compliance picture around safety certification and insurance, the safety standards and compliance guide and the insurance evidence pack guide cover the parallel document sets, and the site survey readiness assessment is the right place to surface sensor coverage before the DPIA is written rather than after.

None of this is a reason to avoid deployment. Buildings that run robots in 2026 do so with a DPIA on file, a processor agreement that names the data flows, and a retention policy the operator can defend. The difference between a deployment that stalls at the compliance gate and one that does not is almost never the robot. It is whether the paperwork was started in week one or week twelve.