Imagine an accident in a warehouse: a robot damages an expensive instrument while moving goods. The hardware supplier says the mechanics worked properly. The model company says the environment fell outside its testing conditions. The integrator says the customer changed the settings. The customer just wants production running again, but first receives three explanations pointing to someone else.
This is a hypothetical scenario, not a reported incident. It is worth rehearsing before a purchase. The more independently a machine can act, the less its delivery chain can rely on “we’ll work it out if something goes wrong.”
Physical AI’s commercial maturity depends on more than how much work it completes when things go well. It also depends on whether failures can be contained quickly, investigated and met with the responsibility that was promised.
Safety, investigation and compensation are three different questions
Safety design aims to reduce the likelihood of accidents. Investigation tries to establish why an accident happened. Compensation determines how losses are addressed. These processes are related, but none can substitute for the others.
Passing a test does not mean a system cannot fail in a new environment. Paying a claim does not mean the system has been repaired. And a supplier’s technical explanation does not mean affected people have received an adequate remedy.
Google DeepMind’s robotics safety explanation combines safeguards at the semantic, physical and operational levels. This layered approach helps us understand risk: interpreting instructions, constraining movements and managing the site may each need their own defenses. It is a technical framework, not a substitute for product certification or a determination of legal liability in an accident.Official safety explanation
Buyers should therefore ask three separate questions: which risks have been tested, who takes over when something goes wrong, and who responds first when a loss occurs. Reducing all three to a single “success rate” hides the distinctions that matter most.
Greater autonomy calls for a clearer chain of responsibility
A robot service may involve hardware, a foundation model, a task application, site integration, operations, maintenance and customer use. Each party has different control, information and opportunities to intervene.
I would map the chain of control before assigning responsibilities. Who authorized the task? Who changed the speed or range of movement? Who knew the site conditions had changed? Who could stop the system? These questions help identify what evidence to retain and make contracts more specific.
This does not mean whoever controls a button necessarily bears all liability. Legal responsibility still depends on the jurisdiction, facts and applicable rules. Nor can a contract simply eliminate third-party rights. The point here is the organizational design that should be completed before deployment.
Customers can agree on a clear incident-response contact: the service provider first coordinates recovery, preserves evidence and contacts the relevant parties, then allocates costs internally after an investigation. That contact need not bear every final loss. It should, however, spare the customer from explaining the same incident repeatedly to several companies.
An autonomous system ready for commercial delivery needs an operator who can be found, who responds and who has the power to act.
That operator also needs real resources: authority to pause tasks, arrange replacement services and notify affected people. A customer-service email address without the power to resolve problems is not a complete response capability.
Logs should help establish the facts, with limits on what they collect
If all that remains after an accident is a model-generated explanation, we may not know what actually happened. More useful evidence could include task versions, authorization records, key sensor states, human interventions, software updates and emergency stops.
But “record everything for safety” is not enough justification either. In homes and care settings, keeping video and audio indefinitely can turn an investigation system into everyday surveillance.
I suggest designing retention around specific purposes: keep essential event summaries during normal operation; preserve relevant footage after an anomaly within permissions explained in advance; and log access, exports and deletions, with time limits and exceptions for legally required retention or preservation during an investigation. The approach must be checked against the jurisdiction, site risks and privacy requirements. One template cannot cover both a warehouse and a bedroom.
Evidence must also be allowed to remain uncertain. A sensor’s failure to record something does not prove it never happened. A model’s account of the cause is not an independent finding. Traceability should help people judge the facts, not let a system automatically absolve itself.
Insurance can transfer some losses. It cannot fix a bad system.
Insurance belongs in the business design because an individual customer may be unable to bear a rare but severe loss. But whether coverage is available, which situations it covers and what it excludes all require specific assessment. Product descriptions should not assume that “insurance will cover it.”
A fuller cost assessment should include deductibles, downtime, replacement services, investigation and maintenance, along with losses that may not be covered. Otherwise, the equipment looks inexpensive only because the risk has been left with the customer.
Likewise, work-acceptance records can help define contractual performance, but they do not assign liability automatically. If Proken records an accepted movement of goods, it may show that specified work was accepted under particular conditions. It cannot prove that no hidden damage occurred during the operation, or turn a unit of work into a legal conclusion.
That is why a measurement system must accommodate failure, rework and disputes. A ledger recording only successful actions can show progress, but cannot support a lasting service on its own.
Small businesses need rules they can afford to follow
The strongest objection is that layers of audits, logs and insurance may make deployment so costly that only large companies can use robots. That concern is valid, especially when compliance procedures are disconnected from actual risk.
The response should be proportionality. Low-risk, reversible tasks can use concise standard terms and event records. Tasks involving bodily harm, critical infrastructure or sensitive spaces need stricter validation and response arrangements. Risk categories should also change as operating experience accumulates.
Businesses can do something practical now: include a failure drill in the procurement demonstration. Introduce a safe anomaly and ask the supplier to show how the system stops, who is notified, what is recorded and how service resumes. Then put those commitments into the service agreement.
This may reveal more about delivery capability than another seamless demonstration. Failure cannot be eliminated entirely. Gaps in responsibility can be reduced in advance.
Earlier, when discussing care, we asked whether machines could improve people’s lives. At the institutional level, that becomes another version of the same question: when a machine fails to do what was promised, are people still treated promptly and fairly?
When buying a robot, would you first ask how much work it can complete—or request a full demonstration of what happens after a failure?