Before You Deploy Humanoid Robots on the Factory Floor: The Safety Architecture Decisions That Will Define Your Liability Exposure

Humanoid robots are moving from demonstration environments into commercial pilot agreements faster than most operations teams have had time to develop coherent procurement frameworks. Platforms like Agility Robotics' Digit 5 arrive with built-in human-detection capabilities and manufacturer-specified safe motion policies, which can create a misleading impression that the hard safety work has already been done. It has not. The decisions that will define your liability exposure in a shared human-robot workspace are not about the robot hardware. They are about the infrastructure assumptions, accountability structures, and incident response protocols that your organisation builds around it.

Companion piece to our broader work on humanoid robot deployment in enterprise settings. See From General-Purpose to Production-Ready: What CTOs Must Solve Before Deploying Physical AI on the Factory Floor for a technical and strategic guide covering integration architecture, failure modes, and the operational gap between adapts to tasks and owns outcomes in live environments.

Proximity Detection Is a System, Not a Feature

Humanoid robot vendors will specify proximity detection ranges and human-classification accuracy rates in their datasheets. What those sheets rarely make explicit is the environmental envelope those figures assume. Detection performance that holds in a clean, well-lit demonstration space will degrade in a facility with reflective floor surfaces, dense racking, airborne particulates, or variable lighting across shifts.

Before you accept a vendor's proximity specification as a deployment baseline, your engineering team needs to characterise the sensing conditions across every zone the robot will operate in. This means mapping ambient light levels, identifying occlusion patterns created by existing equipment, and assessing whether your facility's thermal profile will interfere with infrared-based detection layers. A figure quoted at the component level is not a system-level guarantee.

The commercial implication is direct. If a proximity mitigation behaviour fails and a worker is injured, the question your insurer and legal counsel will ask is whether your team validated that the detection system was operating within its specified conditions at the time of the incident. Vendor datasheets will not answer that question for you.

Safe Motion Policies Involve Trade-offs Your Procurement Team Will Not Surface

Safe motion policies govern how a humanoid robot modifies its trajectory, speed, or task execution when a human enters a defined proximity zone. Most commercial platforms offer configurable thresholds, which sounds like flexibility but is more accurately described as a set of trade-offs your operations team needs to own explicitly.

Threshold Calibration

Tighter proximity thresholds reduce collision risk but increase the frequency of motion interruptions. In a high-throughput environment, frequent interruptions accumulate into meaningful throughput loss. If your business case was built on a cycle time assumption, and your safety team subsequently tightens thresholds during commissioning, the financial model changes. Both decisions need to be in the room at the same time.

Failure Mode Accountability

Safe motion policies also define what the robot does when its detection input is degraded or absent. Whether the system defaults to a full stop, a reduced-speed continuation, or a supervisor alert depends on how the policy was configured and what your facility's operational context requires. That configuration decision belongs to your organisation, not the vendor. Documenting it before deployment is not a bureaucratic exercise. It is the foundation of your incident defence if a failure mode is ever invoked.

Workspace Segregation Assumptions Need to Be Tested, Not Inherited

Many facilities approaching humanoid robot pilots have existing segregation infrastructure from earlier automation deployments: fixed barriers, light curtains, or painted floor zones. The temptation is to treat that infrastructure as compatible with a humanoid deployment because humanoids are designed to operate in mixed environments. That reasoning inverts the logic.

A humanoid robot's ability to navigate shared space does not make legacy segregation infrastructure adequate. It means the segregation assumptions need to be re-evaluated from scratch against the specific motion envelope, task profile, and human traffic patterns of the new deployment. A light curtain positioned for a stationary industrial arm operates on fundamentally different assumptions than one positioned for a bipedal robot moving between workstations.

Facility retrofit costs are consistently underestimated in early pilot budgets. The assessment should include sensor infrastructure upgrades, network connectivity requirements for real-time safety monitoring, and any structural modifications needed to support safe charging or docking zones. These are not optional line items to revisit post-pilot.

Accountability Structures Need to Be Written Before Anything Is Switched On

The standard vendor contract for a humanoid robot pilot will assign accountability for safe deployment to the operator. That is not unreasonable, but it means your organisation needs to have defined internally who holds accountability for each layer of the safety architecture before the contract is signed.

This includes specifying who owns the proximity threshold configuration, who is authorised to modify it during operation, and what change management process governs those modifications. It also includes defining what constitutes a reportable incident versus a routine mitigation event, and how incident data flows from the robot's onboard logging to your safety management system.

Regulators and insurers increasingly expect evidence of a documented safety management process, not just a record that a CE-marked or UL-certified product was purchased. The certification covers the product. It does not cover the deployment.

What to Require From Vendors Before Signing

Procurement conversations for humanoid robot pilots tend to focus on hardware specifications, integration APIs, and service level commitments. The questions that matter more for liability management are less commonly asked.

You should require vendors to provide the environmental operating envelope for all safety-relevant sensor systems, not just headline accuracy figures. You should ask for documented failure mode behaviour for each safe motion policy, including what happens when sensor input falls below a reliability threshold. You should also establish contractually what data the vendor retains from onboard logging, who owns that data, and under what conditions the vendor can access it.

Finally, ask explicitly whether the platform has been deployed in a facility with comparable human traffic density and task complexity to yours. Reference deployments in controlled pilot environments are not equivalent to production evidence. Understanding that distinction before you commit to a pilot structure will shape how you phase the rollout and what validation gates you set before expanding scope.