Robotics Incidents: A Practical Typology

The operational reality of robotics in Europe is shifting from controlled laboratory environments and predictable industrial lines to dynamic, unstructured settings in hospitals, city centres, and offices. As this shift accelerates, the way we classify, investigate, and attribute responsibility for incidents must evolve in parallel. A purely technical failure log is insufficient; the context of the incident—where it occurred, who was present, what the machine was instructed to do, and how it was supervised—determines which legal frameworks apply and where liability ultimately rests. This article provides a practical typology of robotics incidents and explains how context shapes responsibility across EU-level regulations and national implementations.

Incident Typology: A Context-Driven Framework

Incidents involving robots are rarely monocausal. They typically emerge from a combination of technical performance, environmental conditions, human actions, and organisational decisions. A useful typology distinguishes incident domains (workplace, healthcare, public spaces) and cross-cutting causal categories. This structure helps professionals map an event to the correct regulatory lens and identify the actors with duties of care.

Workplace Robotics

Industrial and collaborative robots (cobots) in factories and warehouses remain the most mature use case, yet incidents still occur. The dominant pattern is misalignment between risk assessment and actual use. A cobot may be certified for limited force and speed under a specific risk assessment, but then be repurposed without re-evaluation, or its safety parameters may be silently overridden during maintenance. In such cases, responsibility typically sits with the employer (as the operator) and the system integrator, under the EU framework for machinery and occupational safety.

Common Subtypes

• Boundary drift: The robot’s operational envelope expands due to software updates, sensor recalibration, or physical repositioning, bringing it into contact with workers.
• Mode confusion: Operators misinterpret the robot’s state (e.g., “paused” vs “reduced speed mode”), leading to unsafe interaction.
• Human-robot handover failures: During collaborative tasks, the timing of handovers between human and machine is misjudged, causing collisions or ergonomic injuries.
• Maintenance errors: Lockout/tagout procedures are bypassed, or safety-rated signals are tampered with, often under production pressure.

Healthcare Robotics

Robotic systems in healthcare—surgical assistants, rehabilitation robots, logistics robots in hospitals—operate in high-stakes environments with vulnerable subjects. Incidents here often involve contextual fragility: the system performs within specification, but the clinical context changes unexpectedly (patient anatomy, infection control protocols, staff availability). The regulatory mix is dense: medical device regulations, product liability, and national healthcare governance all intersect.

Common Subtypes

• Clinical workflow mismatch: The robot’s intended workflow conflicts with hospital protocols, leading to workarounds that increase risk.
• Training gaps: Surgeons or nurses are trained on the device in ideal conditions, but not on rare failure modes or emergency fallbacks.
• Data-driven misjudgment: Systems relying on intraoperative sensing or imaging can produce erroneous outputs if sensor calibration drifts or the patient’s condition deviates from training data.
• Environmental interference: Electromagnetic interference or Wi-Fi congestion disrupts telemetry, causing delayed responses or loss of control.

Public Spaces

Service robots, delivery bots, and autonomous mobile platforms in public spaces introduce uncontrolled actors and heterogeneous environments. Incidents here are often context-determined: a robot may behave correctly in a mapped campus but fail in a construction detour or crowded pedestrian zone. The regulatory context spans product safety, data protection, local public space ordinances, and potentially the AI Act for higher-risk applications.

Common Subtypes

• Map-environment mismatch: The robot’s internal map does not reflect temporary changes (e.g., event barriers, parked vehicles), leading to navigation errors.
• Interaction misread: The robot misinterprets human gestures or crowd dynamics, resulting in abrupt stops or collisions.
• Connectivity dependency: Loss of network coverage or cloud services degrades autonomy, sometimes without a safe fallback.
• Misuse or interference: Members of the public intentionally obstruct or tamper with the robot, raising questions about foreseeable misuse and design safeguards.

Why Context Determines Responsibility

Responsibility is not a property of the robot; it is a distribution of duties across actors in a specific context. European law allocates duties based on roles in the supply chain and the nature of the risk. The same physical event can lead to different legal outcomes depending on where and how it occurred.

Key Principle: Responsibility follows control and foresight. The actor who controls the operational parameters and can reasonably foresee the risks must bear the duty to mitigate them.

Regulatory Lenses by Context

In the workplace, the employer has a duty to ensure safety under national transpositions of EU directives (e.g., the Machinery Regulation and the Framework Directive on occupational health and safety). The system integrator or manufacturer is responsible for ensuring the machine meets essential health and safety requirements and provides adequate instructions. If an incident arises from a production-line change not reflected in the risk assessment, the employer’s duty is triggered. If it arises from a faulty safety component, the manufacturer’s duty is engaged.

In healthcare, the device may be a regulated medical device under the Medical Devices Regulation (MDR). The hospital is both an employer and a user of a medical device. If the incident relates to a design flaw in the device or its software, the manufacturer bears responsibility. If it relates to clinical governance, training, or maintenance, the hospital may be liable. National healthcare laws may impose additional duties of care on clinicians and administrators.

In public spaces, the operator of the robot (which could be a private company or a municipal authority) typically bears primary responsibility for safe operation. The manufacturer remains responsible for product safety. If the robot processes personal data, data protection rules apply, and the operator must demonstrate compliance. Local public space regulations may impose restrictions on where and when robots can operate, and non-compliance can shift responsibility toward the operator or the municipality, depending on permitting and oversight.

Human Oversight and the AI Act

For higher-risk AI systems embedded in robots, the AI Act introduces explicit obligations around human oversight, robustness, and transparency. The nature of oversight matters: if a human is expected to intervene in real time, the system design must make that feasible and the operator must ensure the human is trained and not overloaded. If an incident occurs because oversight was impractical (e.g., too many alerts, insufficient time to react), responsibility may lie with the operator for inadequate staffing or with the manufacturer for poor human-machine interface design.

From Event to Allocation: A Practical Method

When an incident occurs, professionals need a method to map facts to duties. The following steps reflect regulatory expectations and practical experience.

Step 1: Establish the Operational Context

Document the environment, task, actors, and state of the system at the time of the incident. This includes the robot’s mode, sensor status, connectivity, and any recent changes to software or physical layout. In healthcare, record the clinical protocol being followed; in public spaces, record the route, time of day, and environmental conditions.

Step 2: Identify the Actors and Their Roles

Map the supply chain and operational chain: manufacturer, importer, distributor, system integrator, operator, employer, and supervising professional. For AI-enabled systems, identify the deployer and the person responsible for human oversight.

Step 3: Determine Applicable Regulations

Overlay the context with the regulatory framework:

• Machinery safety: Essential health and safety requirements, conformity assessment, and instructions for use.
• Product liability: Defective product claims under national implementations of the EU Product Liability Directive (new revised directive expected to be transposed by late 2026).
• Data protection: GDPR obligations for data processing, including lawfulness, transparency, and security.
• AI Act: Risk classification, conformity assessment, and post-market monitoring for higher-risk AI systems.
• Occupational safety: Employer duties under national law.
• Medical device regulation: If the robot is a medical device, MDR obligations for clinical evaluation, vigilance, and post-market surveillance.
• National public space rules: Permits, insurance, and local ordinances.

Step 4: Analyze Causation and Foreseeability

Ask what was reasonably foreseeable. If a robot failed in a scenario that was documented in risk assessments but not mitigated, responsibility may fall on the operator. If the scenario was not foreseeable due to a design limitation, the manufacturer may be responsible. If the scenario was foreseeable but the system was not designed to handle it, the integrator or manufacturer may be responsible.

Step 5: Map Duties to Failures

For each failure, identify which actor had the duty to prevent it:

• Design failure: Manufacturer or software developer.
• Inadequate instructions or training: Manufacturer and/or operator/employer.
• Improper integration or modification: System integrator or operator.
• Inadequate supervision or staffing: Operator/employer.
• Failure to maintain or update: Operator/employer.
• Data misuse or breach: Data controller (often the operator).

Comparative Views Across Europe

While EU-level regulations provide harmonized baselines, national implementations and enforcement cultures differ. This affects incident investigations and liability outcomes.

Germany

Germany has a strong tradition of technical standards (e.g., through DIN and the German Institute for Standardization). The German approach to workplace safety is rigorous, with employers expected to implement comprehensive risk assessments and documented procedures. In healthcare, university hospitals often have mature governance structures for medical devices, but the complexity of clinical workflows can still create gaps. German courts have been active in product liability cases, and the concept of Herstellerhaftung (manufacturer liability) is well established.

France

France emphasizes worker participation and the role of the CHSCT (or its successors) in safety decisions. In public spaces, municipalities may impose strict conditions on experimental deployments. The French data protection authority (CNIL) is active on privacy-by-design, which can affect robot deployments that capture video or audio in public areas. Healthcare institutions often rely on national guidelines for device governance, and liability can be shared between the institution and the manufacturer depending on the nature of the incident.

United Kingdom (post-Brexit)

The UK retains EU-derived product safety and machinery regulations but diverges in some areas. The Health and Safety Executive (HSE) is influential in workplace incidents, with a pragmatic focus on whether risks were “reasonably foreseeable” and whether control measures were “reasonably practicable.” The UK’s approach to AI governance is evolving, with a focus on context-based oversight rather than a rigid list of prohibited uses. Incident investigations often emphasise the role of the duty holder and the adequacy of risk management processes.

Nordic Countries

Sweden, Finland, and Denmark have high robot density and strong collaboration between industry and regulators. They often lead in safety culture and worker training. In healthcare, Nordic institutions are advanced in digitalisation, which can both mitigate and introduce risks (e.g., dependency on integrated electronic health records). Public space deployments are typically cautious, with pilots closely monitored and insurance requirements clearly defined.

Spain and Italy

Both countries have active manufacturing and healthcare sectors. Enforcement can vary regionally, and national regulators may rely on sector-specific guidance. In public spaces, local municipalities play a significant role, and incident outcomes can depend on the clarity of local permits and insurance mandates.

Legal Definitions that Matter in Practice

Several definitions shape how incidents are interpreted and how responsibility is allocated.

Product defect: Under the revised Product Liability Directive (PLD), a product is defective when it does not provide the safety a person is entitled to expect, considering all circumstances, including the product’s presentation, instructions, and reasonably foreseeable misuse. For AI-enabled robots, this includes the behavior of the system in real-world conditions, not just its intended use.

Reasonably foreseeable misuse: Manufacturers must anticipate how users might misuse the product and design safeguards or provide warnings. In public spaces, this includes foreseeable interference by third parties.

Human oversight: The AI Act requires that higher-risk systems be designed to allow human oversight that is effective, timely, and proportionate. If oversight is technically possible but operationally infeasible (e.g., due to speed or complexity), the system may not meet this requirement.

Controller vs processor: Under GDPR, the controller determines the purpose and means of data processing. For robots capturing video or telemetry, the operator is usually the controller. If a vendor provides a cloud platform, they may be a processor. Incident responsibility for data breaches follows this distinction.

Incident Investigation: Practical Considerations

A robust investigation must combine technical and legal perspectives. It should be designed to satisfy regulatory expectations while preserving legal privilege where appropriate.

Data Preservation

Robotics systems generate logs, sensor data, and sometimes video. Preserve this data immediately, including system version numbers, software update history, and configuration files. For AI systems, capture model versions, training data provenance (to the extent available), and inference logs. Under GDPR, if personal data is involved, document the lawful basis for processing and ensure any data retention complies with legal holds.

Chain of Custody

Document who handled the system and data after the incident. This is critical for product liability and potential litigation. For medical devices, follow the manufacturer’s and hospital’s incident reporting procedures to maintain regulatory compliance.

Stakeholder Mapping

Identify all actors with potential duties: manufacturer, importer, system integrator, operator, employer, supervising professional, data controller, and, where relevant, the provider of a general-purpose AI model. Early clarity prevents misattribution and ensures that regulatory notifications are sent to the correct authority.

Regulatory Notifications

Timelines matter. For medical devices, serious incidents must be reported to the national competent authority within defined periods (often 2 or 10 days, depending on severity). For AI systems classified as high-risk under the AI Act, post-market monitoring and reporting obligations will apply once the regime is fully applicable. Workplace incidents may require notification to labor inspectorates or safety authorities under national law. Missing a notification deadline can itself be a regulatory breach.

Design and Operational Mitigations

Reducing incident risk requires attention to both design and operations. The following practices align with regulatory expectations and practical safety.

Design Practices

• Contextual risk assessment: Go beyond the lab. Test in realistic environments and with representative users. Document assumptions and validate them.
• Fail-safe states: Define and implement clear safe states for different failure modes. Ensure that transitions to safe states are predictable and timely.
• Transparent interfaces: Provide operators and supervisors with unambiguous status information and actionable alerts. Avoid overloading users with low-value notifications.
• Version control and rollback: Maintain strict control over software updates. Provide mechanisms to roll back to a known-safe configuration.
• Privacy by design: Minimise data collection, anonymise where possible, and implement strong access controls.

Operational Practices

• Dynamic risk assessment: Reassess risk when the environment, task, or team changes. Do not rely on static risk assessments.
• Competency-based training: Train operators not only on normal use but on failure modes and emergency procedures. Validate competency periodically.
• Human oversight adequacy: Ensure that the person overseeing the system has the capacity and authority to intervene. Avoid assigning oversight to already overloaded staff.
• Incident learning loops: Use near-misses and minor incidents to update risk assessments and design requirements.
• Insurance and contractual clarity: Ensure that contracts clearly allocate responsibilities for integration, maintenance, and incident response. Verify that insurance covers the intended operational context.

Illustrative Scenarios: Context Matters

Consider a collaborative robot in a factory that collides with a worker. If the collision occurred because the robot’s safety parameters were changed by the integrator without updating the risk assessment, the integrator may share responsibility with the employer for failing to verify the configuration. If the collision occurred because the robot’s sensor was dirty and the employer had no cleaning procedure, the employer’s duty is primary. If the sensor was faulty despite proper maintenance, the manufacturer may be liable.

Consider a surgical robot that causes unexpected bleeding. If the event occurred because the surgeon deviated from the intended procedure, the hospital’s clinical governance may be implicated. If the event occurred because the robot’s force sensor miscalibrated due to a software update, the manufacturer’s duty is engaged. If the hospital failed to follow the manufacturer’s calibration protocol, the hospital may be liable. The same physical outcome can lead to different allocations based on context.

Consider a delivery