Product Liability and Functional Safety at Deployment Scale

Robot product liability is the legal exposure a manufacturer or integrator carries when an autonomous system causes harm, and the strength of the defense rests almost entirely on the engineering record. Who identified the hazards. Who evaluated the risks. What evidence shows the safety functions worked as designed. If those records exist and connect, the company has a defensible position. If they don't, the company has a problem that no amount of after-the-fact explanation fixes.

For years, this exposure stayed theoretical for most robotics companies. Systems shipped in pilot quantities to sophisticated industrial buyers who ran their own safety programs and absorbed much of the deployment risk. The volumes were small, the customers were experts, and the liability questions rarely left the contract negotiation.

That era is closing. Autonomous systems are moving into warehouses, hospitals, and job sites at volumes the industry hasn't handled before, purchased by organizations that have never run a hazard analysis and don't know they should. When the buyer has no safety team, the safety gap doesn't disappear. It travels upstream to whoever built and integrated the system.

Why does deployment scale change the liability picture?

Three things compound at volume.

Exposure multiplies faster than engineering changes. A design decision made once ships ten thousand times. A hazard that was acceptable in a supervised pilot, with trained operators and a fenced environment, meets untrained users and unplanned environments across the whole fleet. The engineering didn't get worse. The population of situations got bigger.

The buyer's sophistication drops. Early customers evaluated safety architecture because they had people who could. Mass-market buyers evaluate price and throughput. They will not catch the gap in your risk assessment during procurement. They'll find it in an incident report.

Records age badly. Static documents and spreadsheets can't keep up with rapidly evolving systems. The risk assessment written for version 1.0 says nothing about the firmware shipping in version 3.2 unless someone maintained the connection, and in a fragmented toolchain of spreadsheets and documents, almost nobody does. The result is a fleet in the field and a safety record describing a product that no longer exists.

The uncomfortable summary: "safety is the customer's problem" was never a principle. It was a description of a market condition, and the condition is ending.

What does a defensible safety record look like?

When something goes wrong, the questions are simple and predictable. Who assessed the risk? Where is the analysis? Does the evidence match the product that shipped? A defensible record answers them without archaeology:

• A hazard analysis that reflects the current product, not the version certified two years ago. Systematic, documented, and updated as the design changed.

• Traceability from every hazard to a control and from every control to evidence. The chain from identified risk to validated safety function has to be explicit enough that an outside reviewer can walk it.

• Rationale recorded at the time of decision. Why this performance level, why this safeguard, why this residual risk was judged acceptable. An undocumented decision and a wrong decision are indistinguishable years later.

• Validation and test records connected to requirements, so the evidence proves the specific claims the safety case makes.

• A record of what changed and when, because fleets get updated, and the safety argument has to move with the product.

None of this is exotic. It's the same discipline functional safety standards like IEC 61508 and ISO 13849 already require. The difference at deployment scale is that the record stops being paperwork for an assessor and becomes the company's institutional memory of why the product is safe. Companies that can produce it answer hard questions in an afternoon. Companies that can't spend months reconstructing decisions from old emails, and reconstruction convinces nobody.

Can safety records be an advantage instead of overhead?

Yes, and the companies winning in robotics right now treat them that way. A complete, current, traceable safety record earns its keep long before any incident:

• It shortens enterprise procurement, because the buyer's risk and compliance reviewers get answers instead of promises.

• It accelerates certification, because assessors move quickly through documentation with clean traceability.

• It reassures boards and investors that growth won't convert into uncontrolled exposure.

This is the core argument for treating safety as infrastructure rather than a compliance checkbox. The engineering investment is the same either way. The return depends on whether the record is built continuously, as a byproduct of structured safety engineering, or assembled retroactively every time someone important asks.

The proof that continuous works exists at the largest deployment scale in the industry. ASAP was developed over 5 years inside Amazon Robotics and protects a fleet of more than 1 million robots in 24/7 operation. That fleet generates exactly the situation this post describes, enormous exposure across an enormous population of deployments, and the answer was a platform where hazard analysis, requirements, reliability evidence, and validation stay connected as the systems evolve. The measured results: 26 weeks faster product launches and more than $30M saved globally, because the same record that defends the product also accelerates it. Independent T2 Tool Qualification from TUV Rheinland and HORIBA MIRA adds a layer most manufacturers can't claim, third-party confirmation that the toolchain producing the evidence reveals defects without introducing errors.

Fast and defensible turn out to be the same property. Both come from knowing, at any moment, why the product is safe and being able to show it.

If your deployment volume is growing faster than your safety record, that gap is worth closing before someone else finds it. Talk to Fennec about building a record that keeps up.