When a delivery robot blocks a crossing, a service robot collides with a customer, or an autonomous vehicle makes a confusing move near pedestrians, the first question is usually straightforward: who is responsible?

The robot may have made the visible error, but it is generally not the meaningful bearer of legal or practical responsibility. A machine cannot compensate an injured person, revise a safety policy, arrange repairs, or decide whether a fleet should return to service. Responsibility may instead involve the organisations and people around it: the manufacturer, software provider, fleet operator, maintenance contractor, venue, remote supervisor, user, or, in limited circumstances, an authority responsible for permissions or infrastructure.

That distinction matters because a public robot failure is more than a technical event. It is a social event. Witnesses want to know whether anyone was monitoring the machine, whether it was suitable for that location, and what will prevent a repeat. A credible response requires safe recovery procedures, preserved evidence, clear communication, appropriate insurance, and a reachable organisation that can act.

What counts as a robot mistake?

Not every awkward robot behaviour has the same consequences. A delivery robot pausing at a curb because it cannot identify a temporary obstacle differs greatly from a machine striking a pedestrian, damaging property, or blocking an accessible route. The seriousness of the outcome affects the urgency of the response, but minor incidents can still expose weaknesses that become important when systems operate at scale.

A robot malfunction or unsafe outcome can arise from several sources:

• a hardware problem, such as a fault in a brake, wheel, battery, camera, or emergency-stop system;
• a software error affecting route planning, perception, or movement control;
• sensor confusion caused by glare, rain, shadows, reflective surfaces, roadworks, or crowded surroundings;
• inaccurate maps or incorrect geofencing, the virtual boundary limiting where a machine may travel;
• a communication failure between the robot and a remote assistance team;
• poor maintenance, incomplete inspection, or an uninstalled update;
• deployment in an environment beyond the robot’s intended operating limits; or
• interference or misuse by a customer, employee, passer-by, or another road user.

Autonomous systems act within programmed limits using sensors, models, rules, and operational policies. That is not the same as human understanding or intent. A robot does not choose to be careless in the same sense as a distracted driver. However, an organisation may still face questions about whether it tested the system adequately, addressed known risks, maintained it properly, or deployed it in unsuitable conditions.

The setting changes the stakes. A warehouse robot may operate in a controlled environment with trained staff and marked routes. A hospital service robot must coexist with patients, visitors, and emergency workers. A sidewalk delivery machine may encounter children, dogs, cyclists, uneven pavement, construction work, and people using wheelchairs or mobility aids. Autonomous vehicles operating at road speeds can create more severe consequences when something goes wrong.

The responsibility chain behind an autonomous machine

Robot liability and responsibility may be shared rather than assigned neatly to one party. The legal outcome depends on the facts and the law where an incident occurs, but investigations commonly examine the full system around the machine.

Key questions may include: Was the robot defectively designed or manufactured? Was its software reasonably safe for its intended task? Did the operator maintain it and follow operating instructions? Was remote supervision adequate? Did a venue or fleet manager approve a route with predictable hazards? Did another person interfere with the robot?

In broad terms, product liability concerns whether a defective product caused harm. Negligence generally concerns whether a person or organisation failed to take reasonable care. A business deploying robots may owe duties to customers, employees, and members of the public, particularly where machines move through shared spaces. The precise terminology and legal tests vary by jurisdiction.

Potentially relevant parties may include:

• the robot manufacturer and component suppliers;
• the developer of navigation, perception, fleet-management, or cloud software;
• the company that owns or operates the fleet;
• a remote supervisor or operations centre;
• a maintenance provider;
• the retailer, hospital, hotel, warehouse, or venue using the machine;
• a customer or employee who misused it; and
• in some situations, a public authority responsible for permits, operating conditions, or infrastructure.

This does not mean that every party is liable whenever a robot fails. It means that a serious incident may require examining more than the robot’s final movement. A collision could involve a faulty sensor, a missed inspection, a poor route, weak remote-assistance procedures, or several contributing factors.

Autonomy does not transfer blame to the machine

It can be tempting to say an autonomous robot is responsible because no person gave it an immediate command. The machine may have selected an action without real-time instruction, but technical autonomy and legal accountability are different concepts.

Autonomy is a capability: the ability to perform a task with limited direct human control. Legal responsibility involves duties, enforcement, assets, insurance, and the ability to provide compensation or make changes. Robots are generally not treated as independent legal persons in ordinary commercial deployment. The people and businesses behind them remain the parties able to prevent harm, investigate failures, pay claims, and decide whether a system should continue operating.

Greater autonomy can make causation harder to establish. A modern robot may combine hardware from one supplier, mapping from another, machine-learning models, cloud services, remote assistance, and local route settings chosen by an operator. Software updates and environmental changes can also affect behaviour. Complexity may create disputes, but it does not remove the need for accountability.

Laws differ significantly among countries, states, cities, and industries. Rules for autonomous vehicles are often more developed than rules for smaller delivery robots, while workplace robots may also be subject to occupational safety requirements. Anyone dealing with an actual injury, property-damage claim, or enforcement action should seek advice in the relevant jurisdiction.

The first minutes after a public failure

After an autonomous robot accident or potentially dangerous malfunction, the first priority should be protecting people rather than continuing a service or managing public relations.

A sensible immediate response may include:

1. Stop, isolate, or place the machine in a safe state.
2. Check whether anyone needs medical help and contact emergency services where appropriate.
3. Prevent further harm, such as securing a spill, redirecting traffic, or creating an accessible route around the machine.
4. Notify the responsible operator or emergency contact.
5. Preserve relevant evidence before logs, video, and system data are overwritten.
6. Identify affected people and document basic facts without pressuring anyone to make a statement.
7. Consider removing similar machines from service if the problem could recur.

Fail-safe behaviour is particularly important near children, older adults, cyclists, and disabled people, who may face greater risk when a machine stops or behaves unpredictably. A robot that cannot safely interpret its surroundings should not continue attempting to improvise. Depending on its design and setting, it may need to slow down, stop safely, request assistance, and clearly indicate its status.

Remote assistance can help, but it is not a complete answer. Operators may face delays, incomplete camera views, poor connectivity, or responsibility for multiple machines. Companies should define what remote staff can do, expected response times, and when local emergency procedures take priority over normal operations.

How companies should communicate after a visible failure

Public trust in robots is shaped by the response as well as the original error. If people watched a robot block a pavement or collide with something, a statement saying only that an “unexpected issue” occurred may appear evasive. It can leave affected people uncertain about whether the company understands the incident or has taken meaningful action.

A useful public response separates four elements:

• Confirmed facts: what happened, where and when it occurred, and whether injury or property damage has been reported.
• What remains unknown: whether the cause is under review and what evidence is being examined.
• Immediate actions: whether the robot, route, software feature, or service has been paused or restricted.
• Next steps: how affected people can contact the company and when further information may be available.

Companies should avoid prematurely blaming a bystander, customer, remote operator, or the robot itself. Early witness accounts may be incomplete, and sensor data may not establish why a system behaved as it did. A log can show what the robot detected or classified, but not necessarily whether its response was appropriate.

Privacy also requires care. Footage and sensor data may be important evidence, yet they can capture faces, licence plates, homes, hospital areas, or sensitive commercial locations. Organisations need procedures for secure retention, limited access, and lawful disclosure. Transparency does not require publishing every recording.

Who pays? Insurance and compensation

When a robot causes injury, property damage, or business disruption, insurance may be as important as engineering. The relevant coverage depends on the machine, contract, location, and cause of the incident.

Potentially relevant cover may include commercial general liability, product liability, property insurance, vehicle insurance for road-going systems, cyber coverage, professional indemnity insurance, and workers’ compensation where employees are involved. Contracts between vendors, operators, and venues may also specify who insures equipment, who handles claims, and how responsibility is allocated when software, maintenance, or operations are implicated.

Insurers and investigators may ask practical questions: What software version was installed? When was the robot last inspected? Was it operating within its approved area? Did a remote operator intervene? Had similar warnings appeared before? Were staff trained to respond? Was a known issue addressed?

Disputes may focus on whether the event involved a defective product, unsafe deployment, inadequate maintenance, misuse, poor infrastructure, or an external event that could not reasonably have been prevented. Coverage may respond to a claim while insurers later pursue recovery from another party, depending on the policy terms and applicable law.

There is no single universal model for robot insurance. Requirements and available products vary widely. Businesses deploying robots in public or shared spaces should establish coverage, reporting procedures, and contractual responsibilities before an incident occurs.

Evidence matters more than the robot’s explanation

People often expect a robot company to explain why a machine acted as it did. In practice, the most useful answer may come from evidence gathered after the event.

Relevant records can include sensor readings, camera footage, route maps, geofencing data, software and model versions, remote-operator messages, maintenance history, battery and motor diagnostics, network status, weather conditions, and information about nearby roadworks or obstructions. In a serious autonomous vehicle incident, physical evidence and independent reconstruction may also be important.

Data logs are valuable, but they are not automatically neutral or conclusive. Sensors have blind spots, timestamps may not align across systems, and logs may show a classification without proving it was reasonable. Records may also be controlled by several vendors, which can complicate preservation.

Companies should have an incident-preservation process before deployment. This may include preventing automatic overwriting of relevant records, documenting chain of custody, and retaining the software configuration involved. Independent review can be particularly important after serious incidents, because the deploying company should not be the only interpreter of evidence about its own system.

Why people judge robots differently

People know that human couriers, drivers, and service workers can make mistakes. They may be more willing to forgive a person who apologises, explains what happened, and tries to help. A robot cannot offer that human form of repair.

At the same time, people may expect machines to be more consistent than humans because they are engineered, tested, and presented as reliable systems. A delivery robot repeatedly obstructing a pavement can feel less like an isolated error and more like evidence that an organisation has imposed an unfinished system on the public.

Opacity can intensify this reaction. A person can often explain their decision in ordinary language. An autonomous system may produce a technical explanation that is difficult for an affected person to understand or challenge. AI accountability is therefore not only about algorithms. It is also about whether people can reach a responsible organisation, report harm, receive understandable information, and be treated fairly.

Small failures matter because they shape everyday acceptance. A robot that blocks a narrow pavement may create a disproportionate burden for a wheelchair user, a visually impaired pedestrian, a parent with a stroller, or someone carrying heavy items. Delivery robot safety includes accessibility and public-space design, not only collision avoidance.

Designing robots to fail safely and recover

Good robotics liability practice begins before a claim. It starts with systems designed to fail safely, visibly, and recoverably.

Safeguards may include low operating speeds, emergency-stop controls, redundant sensors, conservative braking, geofencing, obstacle detection, secure communications, remote assistance, and safe fallback modes. A fallback may mean stopping in the safest available position, activating a visible status signal, preserving an incident record, and requesting help rather than continuing through uncertainty.

Robots should communicate their state in ways people can understand. A machine that is confused should not appear ready to proceed normally. Lights, sounds, displays, and clear contact methods can help nearby people understand whether it is stopped, yielding, awaiting assistance, or out of service.

Technical controls need operational discipline. Staff require training, maintenance schedules must be realistic, and deployment areas should match a robot’s demonstrated capabilities rather than best-case demonstration conditions.

What cities and regulators may require

Governments and regulators may seek to support useful services while ensuring that pavements, roads, hospitals, and workplaces do not become poorly supervised testing environments.

Depending on the jurisdiction and robot type, rules may address registration, operating zones, speed limits, public-space access, accessibility, remote supervision, cybersecurity, insurance, incident reporting, and safety documentation. Autonomous vehicles may also be subject to traffic laws, testing permits, crash-reporting requirements, or rules relating to human fallback drivers.

Effective oversight considers both the device and its environment. A robot may be technically capable yet unsuitable for a narrow pavement, crowded station, complex crossing, or construction-heavy area. Operating permits and location restrictions can account for local infrastructure and vulnerable road users.

The central principle is simple: responsibility should be clear before widespread deployment. People should not have to discover after an incident that no one knows who can stop the fleet, respond locally, handle a claim, or provide information.

What should happen after the incident

A credible post-incident process does not end when the robot is collected. It should include containment, investigation, communication with affected people, corrective action, and follow-up after any redeployment.

A software update may help, but software is not always the root cause. A failure may also reflect inaccurate maps, poor route selection, weak escalation procedures, inadequate training, a maintenance gap, or an environment that was never suitable for the machine. In some circumstances, restricting or suspending operations may be more appropriate than immediately resuming service after a patch.

Companies should track near misses and repeated low-level failures, not only collisions and insurance claims. A pattern of route blockages, sensor confusion, or frequent remote-assistance requests may identify a systemic issue before someone is injured.

The most trustworthy autonomous system is not the one that claims never to fail. It is the one with clear limits, safe fallbacks, reachable humans, and a serious process for learning when it does.

Trust requires an accountable system

The lasting question after a robot makes a mistake in public is not whether the machine should be blamed like a person. It is whether the people and organisations behind it built an accountable system.

That system includes safe design, realistic operating limits, human oversight, accessible recovery procedures, preserved evidence, appropriate insurance, fair handling of claims, and honest communication. It also requires regulators and cities to set expectations before autonomous machines become ordinary users of shared public spaces.

Robots will encounter uncertainty: pavements change, people behave unpredictably, sensors fail, software contains errors, and real life is more complicated than a test route. Public trust in robots will depend less on promises of perfection than on how seriously organisations handle the moments when perfection fails.

Image by pasja1000 on Pixabay.