There is no single GDPR lawful basis for using a service robot.
A robot may navigate without identifying anyone, process a spoken request to provide assistance, detect a possible fall, authenticate a staff member, record an incident and send technical telemetry to its manufacturer. Those are different processing operations with different purposes, affected people and consequences.
Trying to assign one lawful basis to the whole machine usually produces one of two errors: consent is stretched across processing that is not genuinely optional, or legitimate interests is used as a catch-all without examining necessity and impact.
The better approach starts with the Robot Function Card and governance framework and the service-robot data inventory. Once the organisation can describe the function and its data flow, it can apply the GDPR tests to the processing that actually takes place.
Define the purpose before choosing the lawful basis
The purpose should state what the organisation is trying to achieve, for whom and in which context. Operating the robot is not a purpose. Neither is innovation, safety or service improvement without further detail.
Useful purpose statements are narrower:
- routing an autonomous cart around people to deliver supplies on a hospital floor
- responding to a customer's request for directions inside a shop
- notifying a care worker when defined sensor conditions indicate a possible fall
- authenticating an authorised employee before opening a secure stock area
- retaining an incident log to investigate physical contact involving the device
The purpose controls the necessity analysis. It also determines what people should be told, what data is excessive, how long it should be kept and whether a later use is compatible.
A supplier's broad list of possible uses does not become the deploying organisation's purpose. The controller must decide which functions it has enabled and why. Optional analytics, model improvement and staff-performance reporting should not inherit the basis selected for the frontline service.
Match each processing operation to the correct Article 6 basis
The GDPR provides six lawful bases in Article 6. Their availability depends on the facts and, for public task and legal obligation, the relevant EU or Member State law.
| Possible basis | Where it may arise | Points to test |
|---|---|---|
| Contract | Processing objectively necessary to provide a service requested under a contract with the individual | Convenience or inclusion in terms is not enough; the processing must be necessary for that contract |
| Legal obligation | A specific legal duty requires the controller to process the data | Identify the duty and necessity; a general safety responsibility does not automatically justify every monitoring feature |
| Vital interests | Processing is necessary to protect someone's life or another vital interest | Narrow and fact-specific; not a routine basis for planned care or general risk reduction |
| Public task | Processing is necessary for a task in the public interest or official authority | Identify the legal foundation and show why the particular processing is necessary |
| Legitimate interests | The controller or a third party pursues a legitimate interest and the necessity and balancing tests are met | Record the interest, alternatives, affected people, reasonable expectations and safeguards |
| Consent | The person freely gives specific, informed and unambiguous agreement and can withdraw without detriment | Power imbalance, unavoidable bystanders and essential services can make consent invalid or impractical |
The table is a screening aid, not a conclusion. A retail robot may use legitimate interests for limited obstacle avoidance, while a separately activated personalised service might rely on contract or consent. A public hospital may have a public-task route for a defined care function, while the manufacturer's product-improvement processing requires a separate analysis and possibly a different controller determination.
Choose the lawful basis for the processing operation, not for the hardware that happens to perform it.
Consent is not a universal answer
Robots invite consent language because they interact directly with people. That does not mean consent is the correct basis.
Valid consent must be freely given, specific, informed and unambiguous. It must be as easy to withdraw as to give. The person must have a genuine choice, and the organisation must be able to stop the consent-based processing without unfair detriment.
That becomes difficult where:
- a worker is asked to agree to monitoring by an employer
- a care recipient depends on the organisation for essential support
- the robot observes visitors and bystanders who never interact with it
- refusing would mean losing practical access to a shop, building or service
- several functions are bundled behind one
acceptcontrol - withdrawal cannot be propagated to the vendor, logs or model-training systems
Consent may still be appropriate for a genuinely optional function. A user might choose to enrol a voice profile, activate personalised conversation or permit a non-essential research use. The organisation then needs a realistic non-consent route and a system capable of honouring withdrawal.
It should not seek consent for processing it intends to continue regardless of the answer. Nor should it switch quietly to legitimate interests after a person withdraws from the same operation. If another basis genuinely applies, that should be established from the outset and explained accurately.
Special-category data requires a second condition
Article 9 adds protection for special categories of personal data, including data concerning health and biometric data used for uniquely identifying a person.
Where Article 9 applies, the controller needs both an Article 6 lawful basis and an Article 9 condition. Depending on the function and national law, relevant conditions may include:
- explicit consent
- employment, social-security or social-protection obligations and rights authorised by law
- protection of vital interests where the person is physically or legally incapable of consenting
- substantial public interest on the basis of law with appropriate safeguards
- provision or management of health or social care under the required professional or legal safeguards
The availability of a condition is not automatic because the robot is used in care. A general-purpose assistant does not transform every interaction into health-care processing, and the health or social-care condition has its own purpose and confidentiality requirements.
Biometric language also needs care. A camera image of a face can be personal data. It falls within the special-category biometric rule when specific technical processing is carried out for the purpose of uniquely identifying the person. Person detection, age estimation and facial authentication are not interchangeable.
Inferences matter too. Movement, speech, repeated requests or room context may be used to infer health or disability. The organisation should assess the nature and intended use of the output rather than assuming that non-medical sensors produce only ordinary data.
Fairness reaches beyond technical accuracy
A service robot can be accurate on average and still operate unfairly.
It may recognise some accents, skin tones, heights, mobility patterns or communication styles less reliably. It may approach people who do not want interaction, repeatedly fail to understand a person with a speech impairment or generate an inappropriate conversational response in a sensitive setting. Staff may trust an alert more readily for one group than another.
Fairness assessment should examine:
- whether the function is appropriate in the setting at all
- who benefits and who carries the inconvenience or risk
- who can avoid or use an alternative route
- performance across relevant groups and real environmental conditions
- the consequences of false positives, false negatives and non-response
- whether people are nudged to disclose more because the robot appears social or authoritative
- whether data from one service purpose is later used to evaluate workers or classify customers
The controller should test supplier performance claims against its own context. A model evaluated in a quiet laboratory may behave differently in a busy shop, a multilingual care service or a warehouse with protective clothing and machinery noise.
Our guidance on bias, fairness and explainability evidence sets out the records governance teams should expect beyond a headline accuracy figure.
Build privacy by design into the physical experience
Privacy by design is not confined to settings menus and policies.
For a robot, it can include:
- limiting operating zones and sensor direction
- processing navigation data locally and transiently
- disabling microphones, identity features or analytics that are not required
- using physical indicators when cameras, microphones or remote access are active
- preventing operation in particularly private spaces
- separating safety event logs from staff-performance systems
- setting conservative default retention
- requiring a deliberate action before personalised or conversational processing begins
- providing a human or non-robot service route
These controls reduce reliance on notices and individual objections after collection has begun. They also make the approved purpose more resistant to function creep.
Use layered transparency where the processing happens
Articles 12 to 14 require information to be concise, transparent, intelligible and accessible. A robot that moves through shared spaces needs more than one notice channel.
The first layer should help a person understand the active function: whether the device is recording, responding, identifying, monitoring or connected to a remote human. A second layer can explain purposes, data categories, recipients, retention and rights. Detailed information can sit online, but it must be reachable without requiring a person to scan a code as the only route.
Different groups may need different information. Workers should understand how robot logs are used in management. Residents and families may need an accessible service explanation. Visitors need notice before entering a monitored area. Children require age-appropriate information where the service is directed to them.
Transparency must also cover the organisation's actual role allocation. Your data is processed securely by our technology partner does not explain that a manufacturer uses interaction clips for its own model improvement or that a remote support team can view live video.
Apply Article 22 function by function
Article 22 is often mentioned whenever an AI system makes an automated output. Its scope is narrower.
Under the EU GDPR, the core test asks whether there is:
- a decision about an individual
- based solely on automated processing, including profiling
- that produces legal effects or similarly significantly affects that person
Obstacle avoidance, room mapping or automatic battery charging will not normally meet that test. A robot-generated alert reviewed meaningfully by a trained worker may also fall outside Article 22, although the surrounding processing remains subject to the rest of the GDPR.
The position may be different where a system automatically refuses access, withdraws a service, changes a person's care pathway, allocates work with significant consequences or makes another consequential decision without meaningful human involvement.
The word human in a workflow diagram does not settle the question. Review must be real. The reviewer needs authority, competence, relevant information and enough time to change the outcome. Routine approval, impossible workloads or blind reliance may leave the decision effectively automated.
Where Article 22 applies, the controller needs an applicable exception and the required safeguards. The person may have rights including human intervention, an opportunity to express their point of view and to contest the decision. Special-category data creates additional restrictions.
The EDPB guidance on automated decision-making and profiling should be used for the detailed analysis. UK organisations should separately check the amended UK GDPR automated-decision provisions in the Data (Use and Access) Act 2025 and their commencement position rather than assuming the EU and UK tests remain identical.
Make rights operational across the device and vendor chain
Individual rights cannot be delivered by the privacy team alone if the relevant data is spread across a robot, fleet console, incident platform, support desk and model provider.
The organisation should know how it will handle:
Access. Search raw records, transcripts, inferences, alerts, logs and relevant recipient information. A device serial number, room, shift or event time may be needed to locate data where the person's name was never used.
Rectification. Correct inaccurate identity data and give effect to a challenge to an inference or event record. Keeping a disputed label with a note may be necessary where deletion would damage an audit trail.
Erasure and restriction. Propagate the request across active systems, exports, support cases and processor environments, subject to the applicable limits and retention needs.
Objection. Identify processing based on legitimate interests or public task and provide a route that can change what happens operationally, not merely record dissatisfaction.
Portability. Assess whether the conditions apply and whether the organisation can provide relevant data in a structured, commonly used, machine-readable format.
Automated-decision safeguards. Route requests for human intervention, explanation and contesting to someone able to review the decision and its context.
Processor contracts and vendor operating procedures should support these tasks within the controller's deadline. A supplier statement that the data is not searchable by name is not the end of the analysis if the organisation can identify the person through other available information.
Complaints are a governance signal
People may complain about the robot without using privacy language. They may say it follows them, does not understand them, reveals private information, treats a family member differently or makes staff feel constantly watched.
Frontline complaints routes should therefore recognise privacy and AI issues and connect them to the DPO, service owner, security and safety teams where appropriate. The organisation should preserve the relevant configuration, logs, notices and human actions so the complaint can be investigated against what happened at the time.
Our article on AI-assisted complaints and rights requests explains how privacy teams can maintain a coherent evidence trail. The final article in this series addresses service-robot accountability, complaints and redress in detail.
Complete the DPIA before the operating model hardens
Service-robot functions can combine new technology, systematic observation, vulnerable people, special-category data and consequential outputs. These are strong indicators for early DPIA screening.
The assessment should examine necessity and proportionality for each function, risks to all affected groups, the effectiveness of proposed controls and the residual risk. It should record alternatives considered, including less intrusive settings or a non-robot process. Where the DPIA continues to indicate high risk that the proposed mitigations do not remove, the controller must consult the supervisory authority under Article 36 before processing begins.
The DPO must be involved properly and in good time. The DPO advises and monitors; the service owner and controller remain responsible for the decision, resources and risk treatment.
The XpertDPO view
GDPR compliance for service robots begins with refusing the fiction that the machine performs one processing activity.
Separate the functions. State the purposes. Identify the people affected. Then choose and document the lawful basis, Article 9 condition, fairness controls, transparency, rights operations and Article 22 position for each relevant operation.
That work can feel slower than applying one label to the product. It is much faster than trying to reconstruct the processing after a complaint, incident or software update reveals that the original assessment never described the live system.
Our AI Governance and DPIA Lifecycle Support connects GDPR analysis with the AI, vendor and operational evidence around each function. Our DPO Support gives organisations independent advice and monitoring without transferring ownership away from accountable management.
The next article, Which Laws Apply to Service Robots? An EU Compliance Map, places the GDPR alongside the EU AI Act, product, cyber, consumer, workplace and sector-specific regimes, with a separate UK position.