# Who Is Accountable for Service Robots? Governance, Complaints and Redress Canonical URL: https://xpertdpo.com/service-robot-accountability-complaints-redress/ Content type: Article Published: 2026-08-14T10:53:08+01:00 Updated: 2026-08-14T10:53:09+01:00 Author: Philipa Jane Farley, Head of Legal and Operations Summary: Service robots need clear owners for decisions, incidents and complaints. We explain governance, DPO independence, evidence, redress and when a deployment should stop. ## Article When a service robot causes harm, makes a poor recommendation or creates a privacy concern, `the robot did it` is not an accountability answer. Neither is `the vendor's system made the decision`. The organisation selected the function, placed it into a real service, determined how staff would rely on it and decided what would happen when it produced an alert, response or action. The supplier and other parties may carry their own legal responsibilities, but the deploying organisation still needs named people who can explain and control its use. That is particularly important because a single event may cross several boundaries. A care robot may collide with a resident after a sensor fault, record video of the event, fail to send an alert and then lose the diagnostic log during a software update. The matter can involve safety, service quality, personal data, cybersecurity, vendor performance and AI governance at once. This final article in our *Robots in the Real World* series explains how to build accountability and redress around the live service. It assumes the organisation has already completed the [function-led governance framework](https://xpertdpo.com/service-robots-embodied-ai-governance/) and [vendor due diligence](https://xpertdpo.com/robot-vendor-due-diligence-security/). ### Name the accountable service owner Each deployed function needs an accountable service owner with authority over its purpose, resources and continued use. That owner should be able to: - confirm what the function is authorised to do - ensure staffing, training and fallback arrangements remain effective - receive monitoring, incident and complaint information - require corrective action from internal teams and suppliers - approve bounded changes through the governance process - pause or stop the function where risk is not controlled - account to the appropriate senior governance body The owner may be a senior operational leader rather than a technical specialist. What matters is decision authority and a direct connection to the service in which the robot operates. A product owner or innovation lead can support the deployment without being the accountable service owner. Similarly, a vendor relationship manager cannot own safety and rights outcomes merely because they manage the contract. ### Allocate responsibilities without creating one artificial owner Accountability is not the same as making one person responsible for every specialist task. | Responsibility | Appropriate lead | Required connection | | --- | --- | --- | | Service purpose and continued use | Accountable service owner | Senior approval, resources and stop authority | | Physical safety and safe operation | Safety or operational owner | Incident process, maintenance and fallback | | Personal-data compliance | Controller management, advised and monitored by the DPO | DPIA, rights, breach and complaint routes | | AI classification and controls | AI governance owner with provider/deployer input | Function record, human oversight, monitoring and change control | | Cybersecurity | Security owner | Asset, vulnerability, access and incident management | | Supplier performance | Commercial or vendor owner | Evidence, service levels, escalation and remedies | | Frontline handling | Service manager | Staff instructions, person-facing explanation and escalation | The table should become a working responsibility map with named people and deputies. It should show who is informed and consulted as well as who acts. The legal roles remain separate. A supplier may be responsible as an AI provider or product manufacturer. The deploying organisation may be responsible as GDPR controller, AI deployer, employer and regulated service provider. Joint investigation does not erase those distinctions. > Accountability means someone has authority to decide and evidence to explain. It does not mean one team absorbs every legal duty in the chain. ### Keep the DPO independent and properly involved The DPO advises on data-protection obligations, monitors compliance, advises on DPIAs, cooperates with the supervisory authority and acts as its contact point. The DPO should be involved early, receive the information needed to perform those tasks and report directly to the organisation's highest management level, in line with Articles 38 and 39 GDPR. The DPO should not be made the accountable owner of the robot, the DPIA risk or the operational decision to deploy. That would confuse independent advice with management responsibility and can create a conflict of interests. A sound approval record therefore distinguishes: - the DPO's advice and any concerns - management's response to that advice - the decision-maker who accepts the residual risk - conditions attached to approval - the monitoring the DPO will perform - the escalation route if the approved controls are not maintained Where management departs from the DPO's advice, the reasons should be documented. The same principle applies when the DPO recommends pausing a function after a complaint or material change. Our [DPO Support](https://xpertdpo.com/dpo-support/) model is designed to preserve that line while helping senior teams work through difficult operational choices. ### Define pause and stop authority before it is needed An emergency stop button controls immediate physical movement. Governance also needs authority to pause a data, AI or service function. Predefined triggers might include: - repeated physical safety events or unexplained movement - a material cybersecurity vulnerability without adequate mitigation - loss of required logs or human-oversight capability - performance falling below an approved threshold for an affected group - use outside the approved purpose, location or population - a vendor update that changes function or data use without assessment - a serious complaint indicating risk to rights or essential service access - inability to provide the promised alternative or fallback service - a legal classification or conformity assumption proving incorrect The response can be proportionate. The organisation may disable one feature while retaining basic navigation, restrict the device to one area, move to manual operation or withdraw the robot entirely. Staff should know who can make the decision outside normal governance meetings. The service should not continue by default because the contract owner, DPO and safety lead are waiting for one another. ### Monitor the live function, not the original business case Monitoring should establish whether the system is behaving as assessed and whether people are relying on it as intended. Useful indicators include: - false positive, false negative and non-response rates - physical contacts, emergency stops and near misses - human overrides and occasions where staff ignored or could not challenge an output - performance differences across relevant groups or environments - complaints, service refusals and requests for an alternative - unauthorised uses or workarounds - software, model, configuration and subprocessor changes - remote-support access and security events - system downtime and fallback use - rights requests and response difficulties Counts need context. A falling complaint rate may mean the system improved, or that people no longer know how to complain. A high override rate may show healthy human control, or that the function is not reliable enough to use. Governance reports should include narrative analysis and actions, not only a dashboard. Monitoring frequency should reflect consequence and change. A high-impact care function needs closer review than a bounded after-hours floor-cleaning route. ### Build one front door for mixed complaints People should not have to identify the correct legal regime before an organisation will listen. A complaint may be expressed as: - `It followed me around the shop.` - `It told everyone why I needed help.` - `It never understands my accent.` - `My manager is using its logs to measure my breaks.` - `It refused to let me through.` - `I do not want it in my room.` - `Nobody came when it raised the wrong alert.` Each statement can raise privacy, equality, safety, employment or service-quality questions. The intake route should accept the complaint in ordinary language, acknowledge it, identify immediate safeguarding or preservation needs and route it internally without sending the person from team to team. Frontline staff need short escalation criteria and a way to record the function, location, time, device and people involved. They should not investigate technical detail themselves or promise a conclusion before the evidence is secured. ### Preserve the truth of what happened Service-robot complaints can be difficult to reconstruct because the device moves, data may be overwritten and software can change remotely. On intake, the organisation may need to preserve: - device identity, location and configuration - software and model version - sensor events, alerts and confidence information - generated response or action - human review, override and escalation records - remote-access and support sessions - relevant video, audio, transcripts or diagnostic bundles - staff notes, witness accounts and service records - notices and instructions in force at the time - previous similar events Preservation should be proportionate and access-controlled. It should not become an excuse to retain all robot data indefinitely. A defined legal or complaint hold can protect the relevant material while ordinary deletion continues elsewhere. The evidence must also surface uncertainty. If the system does not log why a model produced an output, the organisation should say so and use the available inputs, version, test evidence and human actions rather than inventing a precise explanation. ### Join incident triage without merging legal tests One event can trigger several processes: - a personal-data breach assessment under GDPR or UK GDPR - a cybersecurity incident response - a product-safety or machinery event - an AI Act serious-incident or market-surveillance route where the relevant provisions apply - a workplace accident or safeguarding route - a service-quality complaint - a contractual notification and preservation request to the supplier The incident lead should convene the relevant owners quickly, establish facts once and maintain a shared chronology. Each specialist then applies the correct threshold, deadline and reporting route. This prevents contradictory accounts and duplicated interviews while preserving the separate legal decisions. A safety event is not automatically a personal-data breach. A poor generated response may be a complaint without meeting an AI serious-incident definition. The same facts can still support more than one conclusion. The [service-robot legal map](https://xpertdpo.com/service-robots-eu-laws-compliance/) identifies the principal EU, Irish and UK regimes. Incident procedures should link to that map and the deployed Function Card rather than trying to reproduce every threshold in one checklist. ### Understand the regulatory complaint and explanation routes Under GDPR, individuals can complain to a supervisory authority and seek a judicial remedy in the circumstances set out in the Regulation. Controllers must also facilitate individual rights and provide transparent information. Article 85 of the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) provides a route for a natural or legal person with grounds to consider that the Act has been infringed to submit a complaint to the relevant market-surveillance authority. Article 86 provides a right to a clear and meaningful explanation of the role of certain high-risk AI systems in individual decisions that produce legal effects or similarly significantly affect a person, subject to its conditions. Those provisions are not a universal explanation or compensation scheme for every robot output. Article 85's complaint route follows the Act's general application from 2 August 2026. Article 86 concerns decisions taken on the basis of output from Annex III-listed high-risk systems that produce legal or similarly significant effects. Given the amended 2 December 2027 timetable for the detailed Annex III high-risk obligations, organisations should verify how commencement applies to the specific function and decision before stating that an Article 86 right is available. In Ireland, the [AI Office of Ireland](https://xpertdpo.com/ai-office-of-ireland-powers-regulators-reporting/) sits within a distributed authority model. The relevant route depends on the AI Act provision, sector and issue. The [Data Protection Commission receives data-protection complaints and concerns](https://www.dataprotection.ie/en/individuals/exercising-your-rights/raising-concern-commission), even where the same facts also raise AI Act questions for another authority. In the UK, the [ICO's organisational complaints guidance](https://ico.org.uk/for-organisations/how-to-deal-with-data-protection-complaints/) reflects the duty in force from 19 June 2026. Organisations need a clear route, must acknowledge a data-protection complaint within 30 days and must investigate and respond without undue delay. Our article on the [ICO complaints process and DSAR disputes](https://xpertdpo.com/ico-data-protection-complaints-dsar-disputes/) explains the operational evidence the ICO is likely to need. ### Make redress practical in the service A good complaint response does more than quote the privacy notice or supplier explanation. Depending on the issue, practical redress may include: - providing a clear explanation and the relevant records - correcting a record or adding the person's challenge - restoring access to a service or offering a human alternative - deleting or restricting data where the legal conditions are met - removing an unfair performance record from an employment process - changing a route, threshold, interface or operating zone - retraining staff or changing human-review arrangements - disabling a function or reversing an update - notifying other affected people - compensating or referring the matter through the appropriate legal route The response should address the person's actual concern. If a resident says a robot entered a private space, a technical assurance that the video was processed locally does not resolve the intrusion. If a worker challenges a productivity inference, explaining the camera specification does not answer how the inference affected management action. Accessible routes are essential. People may need support from a representative, family member, advocate or trade union. They should not be required to interact with the robot to complain about it. ### Require vendor cooperation without outsourcing the response The supplier may hold logs, model information and technical expertise needed for the investigation. Contracts should support timely preservation, explanation, remediation and regulatory cooperation. The deploying organisation should still own its response to the affected person where it is the controller or service provider. Forwarding the supplier's statement without scrutiny can reproduce gaps or commercial framing. The organisation must connect the technical account to its own decision, staff action and service consequence. Where the vendor is a separate controller, AI provider, manufacturer or other duty holder, it may need to respond through its own legal route. A coordinated account is useful, but it should identify which party reached which conclusion. ### Close the loop after a complaint or incident Resolution is incomplete until the organisation asks what should change. The review should consider: - whether the Function Card, DPIA or classification was wrong or incomplete - whether staff followed the process and had realistic authority - whether the same issue could affect other people, sites or devices - whether the vendor needs to correct the product or documentation - whether notices, training, fallback or complaints routes need revision - whether the function should be paused pending evidence - whether previous decisions or records should be revisited Actions need named owners, due dates and evidence of completion. Material learning should feed into procurement, update approval and future deployment standards. Our article on [AI-assisted complaints and rights requests](https://xpertdpo.com/ai-assisted-complaints-rights-requests/) describes how a joined case record can support that closure without losing the original evidence. ### The XpertDPO view Accountability for service robots should be visible before anything goes wrong. People need one route into the organisation. Staff need clear escalation and pause authority. Senior leaders need a named service owner. The DPO needs independence and access to evidence. Suppliers need enforceable cooperation duties. Regulators need an accurate chronology rather than six teams offering separate fragments. That structure is not only for major incidents. It allows ordinary complaints, near misses and override patterns to improve the deployment before harm becomes systemic. Our [AI Governance and DPIA Lifecycle Support](https://xpertdpo.com/ai-governance-dpia-lifecycle-support/) helps organisations connect function records, assessments, monitoring and change control. Our [DPO Support](https://xpertdpo.com/dpo-support/) provides independent advice, challenge and regulatory support while the organisation retains responsibility for its decisions. This concludes the series. The starting point remains the [Service Robots and Embodied AI governance guide](https://xpertdpo.com/service-robots-embodied-ai-governance/), supported by the articles on [robot data and privacy risks](https://xpertdpo.com/service-robot-data-privacy-risks/), [GDPR lawful basis and rights](https://xpertdpo.com/service-robots-gdpr-lawful-basis-consent/), the [EU and UK legal map](https://xpertdpo.com/service-robots-eu-laws-compliance/) and [vendor due diligence](https://xpertdpo.com/robot-vendor-due-diligence-security/). ### Sources and further reading - [EU AI Act, Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) - [GDPR, Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016R0679) - [Regulation of Artificial Intelligence Act 2026](https://data.oireachtas.ie/ie/oireachtas/act/2026/31/eng/enacted/a3126.pdf) - [Irish DPC guidance on raising a concern with the Commission](https://www.dataprotection.ie/en/individuals/exercising-your-rights/raising-concern-commission) - [ICO guidance on handling data-protection complaints](https://ico.org.uk/for-organisations/how-to-deal-with-data-protection-complaints/) - [EDPB guidance on automated decision-making and profiling](https://www.edpb.europa.eu/documents/guideline/automated-decision-making-and-profiling_en) ## General Information Only This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation. If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/