Service Robots and Embodied AI: A Governance Guide for DPOs

Service robots are moving out of controlled industrial spaces and into places built around people.

They may deliver supplies in a hospital, guide customers through a store, monitor shelves, support mobility in a care setting, clean an office after hours or help someone complete everyday tasks at home. Some look recognisably robotic. Others are closer to a mobile sensor platform with a screen, microphone, camera and cloud connection.

For DPOs and compliance teams, the difficulty is not simply that a robot can collect personal data. It is that one deployment can combine continuous sensing, AI-driven interpretation, a connected product, a cloud service and physical action. The legal roles may be split across a manufacturer, software provider, reseller, maintenance company, deploying organisation and third-party model provider. The risks also extend beyond the intended user to workers, visitors and bystanders.

Treating the whole machine as one assessment object produces a vague and unstable answer. A navigation function, conversational assistant, falls-risk alert and staff-performance dashboard may sit in the same casing, but they do different things to different people and engage different rules.

The robot is not the assessment object. Each deployed function, its data flows and its operating model must be assessed separately.

This article sets out a practical governance framework for doing that. It is the anchor for our Robots in the Real World series, which will examine the data, GDPR, legal, vendor and accountability questions in greater depth.

What counts as a service robot or embodied AI?

There is no single governance definition that resolves every legal question. For the purpose of operational assessment, a service robot is a physical system that performs tasks for or around people with some degree of sensing, computation, movement or interaction.

Embodied AI describes the AI-enabled functions operating through that physical system. The software can perceive aspects of the environment, interpret inputs, generate outputs or influence physical behaviour. That may include computer vision, speech recognition, route planning, person detection, behavioural inference or generative conversation.

This is deliberately broader than the familiar humanoid companion. It includes:

• an autonomous mobile robot carrying stock through a warehouse
• a retail assistant that answers questions and directs customers
• a cleaning robot that maps rooms and avoids people
• a care robot that prompts medication or detects possible distress
• a telepresence unit used by clinicians or family members
• a reception robot that recognises appointments or verifies identity
• a domestic-assistance device supplied and monitored by a commercial care provider

Not every device will use an AI system as defined by the EU AI Act, and not every AI function will be high-risk. Those are classification questions to be answered against the actual function and intended purpose. The governance model still needs to identify them.

Why existing review processes can miss the real deployment

Organisations often divide approval work by department. Procurement assesses the supplier. Information security examines the network connection. Privacy receives a processing description. Health and safety looks at physical movement. Operations decides whether the service works.

Each review may be competent and still miss the combined system.

A care robot, for example, may capture audio to recognise a spoken request, send it to a cloud service, infer urgency, alert a worker, log response time and later use interaction data to improve the product. A software update may change the urgency model without changing the hardware. A remote support engineer may be able to activate a diagnostic feed. The service team may then use the same logs to review staff performance.

No single label such as care support, voice assistant or connected product describes all of that. Governance needs to join the views without collapsing their distinct legal tests.

The same problem appears in less sensitive settings. A retail robot described as a customer guide may also analyse footfall, infer age bands, record abusive interactions, monitor staff availability and share device telemetry with its manufacturer. A warehouse robot may begin as a collision-avoidance tool and later acquire productivity analytics tied to named workers.

The practical question is therefore not just what did we buy? It is which functions are active, what does each one do, and who is responsible for the consequences?

Start with a Robot Function Card

We recommend completing a Robot Function Card for every separately deployed function. This creates a common record that privacy, AI governance, security, safety, procurement and service owners can interrogate from their own disciplines.

The record must be specific enough for someone outside the deployment team to reconstruct what the function was intended to do and how it was controlled.

A single robot may need several cards. A navigation card will be different from a facial-verification card. A conversational card will be different from an alerting card. If the device is redeployed from a public reception area to a care unit, the context and affected people may justify new cards even if the vendor says the software is unchanged.

This provides a firmer foundation for the DPIA and AI governance lifecycle than beginning with a broad description of the product.

Keep the legal role vocabularies separate

One of the fastest ways to lose accountability is to use vendor, provider, operator and controller as though they mean the same thing.

They do not.

The same company can hold several roles. A robot manufacturer may be the AI Act provider and product-law manufacturer, act as a GDPR processor for the organisation's service data, and act as a separate controller for product analytics or model improvement. The organisation using the robot may be the GDPR controller and AI Act deployer, but it may acquire provider obligations if it substantially modifies the system or changes its intended purpose within the conditions in Article 25 of the AI Act.

Contracts help allocate tasks, but they do not determine GDPR roles where the reality is different. The EDPB controller and processor guidance remains the appropriate starting point for that analysis. For the AI Act vocabulary, our role-mapping guide explains why the commercial label on the supplier agreement is not enough.

National authority roles also need to be mapped rather than reduced to one universal AI regulator. In Ireland, the AI Office and designated competent authorities operate through a distributed governance model.

One organisation may be the customer, GDPR controller and AI Act deployer at the same time. Those labels answer different questions and carry different duties.

Assess five connected objects, not one machine

The Function Card should expose five connected regulatory objects.

The physical product. This includes movement, contact with people, lifting, access to spaces, physical controls, batteries and safe stopping. Product and machinery rules may determine design, conformity and safety responsibilities.

The AI system or model-enabled function. This includes perception, inference, prediction, recommendation, classification or generation. It may trigger AI Act classification, transparency, oversight and monitoring questions.

The personal-data processing operation. This includes what is collected about each group of people, why it is processed, who determines the purpose, which lawful basis is used, how long data is kept and how rights work in practice.

The connected digital service. This includes cloud processing, remote access, vendor dashboards, software updates, vulnerability management, application programming interfaces and third-party model services.

The operating model. This is how the organisation incorporates the robot into a real service. It covers staffing, escalation, training, consultation, complaints, incident response, fallback arrangements and decisions about when the system may be used.

The objects overlap, but none can substitute for the others. A technically safe product may still support unfair processing. A GDPR-compliant data flow may still be unsafe in physical operation. A vendor may have an AI Act conformity package that does not answer the deployer's questions about worker monitoring or safe service continuity.

The detailed interaction between the laws is mapped in Which Laws Apply to Service Robots?.

Put the service owner at the centre of the lifecycle

The accountable service owner should be identified before the pilot. This is the person or governance body with authority over the operating purpose, resources and decision to continue, change, pause or stop the deployment.

The lifecycle should then contain at least these stages:

1. Define the function. Record the intended purpose, environment, limits and prohibited uses.
2. Map people and flows. Include bystanders, workers and people who cannot realistically avoid the device.
3. Allocate roles. Complete the GDPR, AI Act, product/cyber and service-ownership maps separately.
4. Screen the regimes. Decide whether a DPIA is required, whether an AI function falls within a prohibited, transparency or high-risk category, and which product, consumer, workplace or sector rules are relevant.
5. Obtain evidence. Test supplier claims against technical documentation, instructions, security support, data-flow evidence and operational trials.
6. Design controls. Set access, retention, human oversight, signage, complaints, safe failure and escalation arrangements.
7. Approve the bounded use. The approval should identify what has been authorised and what has not.
8. Monitor operation. Review incidents, false alerts, overrides, complaints, drift, equality effects, update history and actual reliance by staff.
9. Reassess change. New software, models, locations, user groups, analytics or purposes should trigger documented review.
10. Control exit and redeployment. Revoke access, delete data, preserve required evidence and reassess the next use.

This is not a one-time paperwork exercise. The system the organisation assessed at purchase may not be the system operating six months later. Remote updates, configurable features and changes in staff practice can alter the risk without a new item appearing on the asset register.

Make the DPIA operational rather than ornamental

Robotic deployments often combine several indicators of likely high risk: new technology, systematic observation, vulnerable people, special-category data, location tracking, biometric processing or a service context in which people have limited choice.

The Irish DPC's DPIA guidance identifies new technology, systematic monitoring and processing concerning vulnerable data subjects among the factors that can require a DPIA. A DPIA should therefore be screened early and scoped around the functions, not appended after the commercial decision is effectively irreversible.

The DPIA needs to connect to decisions someone can make. That includes removing a feature, restricting an operating zone, preventing secondary use, shortening retention, introducing a non-robot route, changing the human review threshold or refusing deployment where the residual risk cannot be brought within tolerance.

Where the intended use also falls within the AI Act's fundamental-rights impact assessment requirements, the organisation should coordinate the evidence and stakeholder work. It should not assume that one assessment automatically satisfies every legal requirement.

Preserve meaningful human control

Human oversight is often described too casually. A staff member does not provide meaningful control merely because they are somewhere in the process.

The relevant person needs:

• enough information to understand the function and its limits
• time and practical authority to intervene
• access to the relevant output and context
• a safe way to stop, override or move to an alternative process
• protection from targets or workflow pressures that make disagreement unrealistic
• a record of interventions, overrides and unresolved concerns

For physical functions, oversight must connect to safe stopping and service continuity. For recommendation or alert functions, it must connect to the decision that follows. For conversational functions, staff need to know when the robot may be presenting generated content as fact and how to handle a request that should move to a human.

Human oversight also needs testing. A procedure that works in a pilot with extra staff may fail during a busy shift, overnight service or connectivity outage.

Treat pilots as real deployments

The word pilot does not reduce the effect on a person whose voice, image, behaviour or health-related information is processed. Nor does it remove product-safety, employment or equality obligations.

A pilot should have a bounded purpose, limited duration, named owner, approved location, defined data set, success and stop criteria, and a clear decision at the end. It should not quietly become business as usual because the equipment remains on site.

Where people are affected in environments they cannot readily leave, such as care, employment or essential services, consultation and alternative routes deserve particular attention. The DPO should be involved in good time, as required by the GDPR, but should not be asked to own the operational decision.

Know the red flags before procurement closes

Early warning signs include:

• the supplier cannot separate active functions or disable optional analytics
• the data-flow diagram covers the device but not remote support, model providers or telemetry
• anonymous is used without explaining re-identification or model-extraction risk
• the organisation cannot identify who controls product-improvement or training data
• the robot's stated purpose is broad enough to permit surveillance or performance management later
• safety depends on constant connectivity without a tested local fallback
• staff are described as human oversight but have no authority to challenge an output
• software updates can materially change behaviour without notice, testing or rollback
• no one owns complaints that combine privacy, discrimination, physical safety and service quality
• the end of the contract does not address data deletion, device access, logs or redeployment

These are not reasons to reject all robotic systems. They are reasons to slow the decision until the organisation can see the system it would actually be operating.

Our guidance on AI vendor due-diligence evidence packs and AI-assisted complaints and rights requests provides more detailed routes for two of these recurring control gaps.

Questions senior leaders should be able to answer

Before approval, senior leaders should be able to answer five questions in plain language:

1. Which functions are we authorising, for which people and in which settings?
2. Who owns the service outcome, and who can pause or stop the deployment?
3. What evidence supports our legal classifications, safety claims and supplier assurances?
4. How can an affected person avoid, question or complain about the system?
5. What changes would require us to reassess or seek fresh approval?

If those answers depend on the phrase the vendor deals with that, the governance model is incomplete.

The XpertDPO view

Service robots should not be treated as exotic devices sitting outside established governance. They should be treated as complex, changeable operating systems that bring several established duties into one deployment.

The practical response is not one enormous robot policy. It is a disciplined set of function records connected to existing privacy, AI, cyber, safety, procurement, incident and complaints processes. That gives each specialist team something precise to assess and gives senior leaders a clear view of the residual risk they are accepting.

Our AI Governance and DPIA Lifecycle Support helps organisations build that joined evidence around real systems and services. Our DPO Support provides independent advice and monitoring while keeping accountability with the organisation's decision-makers.

The next article in this series, What Data Do Service Robots Collect?, maps the visible, inferred and often overlooked data created by service robots. Later articles address GDPR lawful basis, consent and rights, the EU and UK legal map, vendor due diligence and accountability, complaints and redress.

Sources and further reading

• EU AI Act, Regulation (EU) 2024/1689
• GDPR, Regulation (EU) 2016/679
• EDPB Guidelines 07/2020 on controller and processor concepts
• Irish DPC guidance on data-protection impact assessments
• European Commission AI Act implementation timeline