Product Liability Coverage for Cobot Deployments

A textile worker's head is crushed between a swinging robotic arm and a stationary bracket. An auto-plant worker is struck by a robot that powers on without warning. These are the incidents AGCS points to as the classic shape of robot injury, and in both cases the chain of cause runs short and visible: a manufacturer built the machine, a worker operated near it, and fault travels a straight line between the two. Cobot deployments do not share that geometry. Standard product liability law was built for a world where one discrete manufacturer makes a product and one discrete user operates it, but a cobot cell typically involves four separate parties, each touching the system at a different stage: the manufacturer who builds the hardware, the integrator who installs and configures the work cell, the programmer who writes the task logic, and the operator who runs the machine day to day. Any one of them can introduce the defect that eventually injures someone. The same design feature that makes cobots commercially attractive, their ability to work alongside people without a safety cage, is what makes the fault chain so hard to untangle, because removing the cage removes the clean separation between "the machine's space" and "the worker's space" that made older robot liability cases comparatively simple to adjudicate. A cobot insurance program built on the assumptions of conventional product liability will miss the parties who actually introduce risk and the moments at which that risk gets introduced.

The four parties who share responsibility when a cobot causes harm

When a cobot injures a worker or damages equipment, responsibility can land on the original equipment manufacturer, the systems integrator, the programmer, and the operator, sometimes on one of them alone and sometimes on several at once. The manufacturer carries exposure for defects in the hardware itself: force-limiting failures, safety-rated sensor malfunctions, and the kind of flaws AGCS identifies as drivers of increased product liability risk in this category. The integrator's exposure looks different because the integrator rarely builds anything from raw materials; the risk comes from how the work cell was designed and configured, and an unforeseen hazard introduced at installation is a professional error. The programmer or software developer introduces a third distinct layer of risk, because task logic written after the hardware ships, the collision zones, speed thresholds, and payload parameters that govern how the cobot actually moves, is not the manufacturer's code. If a programming error causes a cobot to exceed its force limits during a specific motion sequence, the liability sits with whoever wrote that logic, not with whoever built the arm. The operator holds the fourth and in some ways the most continuous exposure, because the operator is the party who changes production parameters, retrains the cobot for a new task, or skips the risk assessment that is supposed to follow any modification to the work envelope, and compliance obligations place ongoing duties of risk assessment and employee training squarely on that operator's shoulders. AI-augmented cobots complicate this four-party structure further by adding an implicit fifth actor: the model or inference system making decisions in real time, where no single human authorized the specific action that caused harm, which makes root cause analysis slower and claim resolution harder for every party still in the chain.

Commercial general liability policy gaps in the fault chain

A standard commercial general liability policy is written around a named insured and a per-occurrence limit. It can extend to multiple named and additional insureds, but it was never built to allocate fault across a four-party chain, and it follows only a loss that originates in human error, not a software decision made after deployment or a loss that originates in autonomous action. That mismatch has gotten sharper, not softer, in the past year. ISO endorsement CG 35 08 took effect in January 2026, and it removes from the Products/Completed Operations Liability Coverage Part of the CGL any bodily injury or property damage arising out of generative artificial intelligence, so the foundational policy most site owners require before letting a cobot onto the floor may now explicitly exclude the class of event most likely to occur in that cell. ISO endorsement CG 40 47, effective the same month, separately excludes bodily injury, property damage, and personal and advertising injury arising out of generative artificial intelligence, and a cobot whose task logic is AI-generated or modified at runtime falls under that exclusion even when the hardware itself is entirely conventional. WTW's Andrew Hill has pointed out that many policy wordings predate the emergence of AI and autonomous robotics altogether, and that coverage should never be assumed; the question an operator needs answered is whether the policy requires a human actor to be responsible for the triggering event, a condition that AI-directed motion simply does not satisfy. Carriers have not waited for a wave of claims to test this. Major insurers sought regulatory approval to add AI exclusions to their general liability forms, and in the large majority of cases they received it. Even if a standard policy does respond to a cobot incident, it typically covers the physical injury or property damage and stops there, so you lose the production losses and line-shutdown costs that follow when a cell is taken offline pending investigation, costs that can dwarf the direct damage figure the policy was written to cover.

Coverage needs at each node

A cobot insurance program that actually matches the fault chain requires separate, or at minimum explicitly coordinated, coverage instruments at each node, because no single standard policy follows liability wherever it happens to land. At the manufacturer's node, the need is a product liability policy that covers autonomous and sensor-driven hardware without carving out AI-directed decisions, and that addresses recall costs if a programming flaw turns out to affect an entire model line; AGCS treats product recall arising from malfunction or programming flaw as a direct product liability exposure for cobot makers specifically. At the integrator's node, the exposure is professional rather than physical in origin, a cell design or configuration choice that creates a hazard nobody anticipated, and that is the province of professional liability or technology errors and omissions coverage, which addresses wrongful acts and performance failures tied to technology decisions in a way general liability does not reach. The programmer's node calls for the same tech E&O coverage, because software errors in task logic, motion parameters, or collision-zone definitions sit outside a CGL policy's intent entirely, and a program that doesn't separately address software-originated physical loss leaves this node uninsured no matter how strong the hardware coverage looks. The operator's node needs CGL, properly endorsed and checked against the new ISO exclusions, paired with employers' liability and workers' compensation to cover third-party bodily injury and property damage on one side and employee injury on the other; an off-the-shelf CGL policy may now exclude the cobot incident from coverage entirely, so the endorsement language has to be reviewed line by line to confirm it actually holds. Networked cobot cells add a cyber dimension that cuts across all four nodes, since AGCS flags cyberattack as a distinct risk category of its own, security weaknesses in default configurations, authentication, and open-source components can let an attacker manipulate a robot controller directly, and a compromised cobot that injures someone creates a liability that no standard property or liability policy is positioned to reach. Cobots also move between facilities and are frequently leased or financed rather than owned outright, so your inland marine and equipment coverage needs to track the machine's actual location and current value as it moves, not a static figure set once at purchase.

How safety standards become underwriting requirements

Underwriters increasingly treat documented compliance with safety standards as a condition of binding coverage, not a line item on the application to be filled in and forgotten. A deployment that cannot produce a completed risk assessment against the applicable standard hands the carrier grounds to deny a claim later on the theory that the insured misrepresented the risk at the point of binding. A national standard addresses the full lifecycle of industrial robot safety, with its Part 3 approved on October 7, 2025, and the full standard published October 29, 2025, serving as the national adoption of the broader international framework. A submission that cites only one part of that standard without the others signals to an underwriter that the applicant's safety program may be incomplete, and that signal shapes both price and willingness to bind. For AI-autonomous systems, underwriters now expect system observability as a non-negotiable condition at renewal: immutable logs of every autonomous action the cobot has taken. When an incident occurs, forensic review of those logs shows a carrier whether the failure originated in a software flaw, a sensor error, or an environmental anomaly, letting the carrier assign fault correctly and pursue subrogation against the party actually responsible. Compliance obligations place the burden of producing risk assessment reports, compliance certificates, and incident logs on the operator as an ongoing duty, not a one-time filing, and a company that cannot produce those documents at the moment a claim is filed has effectively written the carrier's denial rationale for it. Insurers have limited historical claims data for cobot-specific incidents, and that actuarial reality is why they lean more heavily than usual on documented safety practice as a proxy for risk quality. A well-documented submission lowers the underwriter's uncertainty directly, and that reduction in uncertainty is what produces materially better terms.

Coverage requirements buried in enterprise and government deployment contracts

Enterprise contracts that impose insurance requirements on cobot vendors are frequently written to a standard that assumes one responsible party exists, and that assumption creates a direct mismatch with a fault chain that actually has four. A certificate of insurance can look entirely compliant on paper, but the underlying policy can still fail to respond to an AI-originated incident. Contracts should require, at minimum, commercial general liability, technology errors and omissions, cyber liability, and professional liability where applicable, and they should name the deploying organization as an additional insured on the vendor's policies. But additional insured status creates a false sense of security once the underlying CGL itself excludes autonomous systems under ISO endorsement CG 35 08, because naming a party as additional insured on a policy that doesn't cover the incident protects nobody. The liability cap structures common in AI vendor agreements compound this exposure further: most cap total indemnification at twelve months of fees. The contractual ceiling on damages can sit orders of magnitude below the actual loss from a serious incident, and that gap is one the vendor's own insurance has to bridge if the cap is ever challenged in court. Government and defense work carries its own additional layer. A defense-sector law bans the use or acquisition of certain covered AI systems by a national defense agency and required their removal from agency systems and contractor environments by January 17, 2026, and counsel working on these contracts should be prepared to negotiate warranty and indemnification provisions tailored specifically to AI errors, bias, and unintended behavior, exposures that standard indemnification language was never written to reach.

Submission quality and whether a cobot company gets covered

Everything mapped above, the multiple responsible parties, the AI-directed decisions, the evolving safety standards, the carrier retreat already visible in the 2026 ISO endorsements, adds up to a risk profile that a generic broker working from a standard application form is poorly equipped to place correctly. That broker will either misprice the risk or slot the company into a policy that excludes its actual operations, and the applicant frequently will not realize it until a claim is denied. Underwriters working in this space have limited actuarial history to draw on. Submission quality itself functions as one of the strongest signals of risk maturity they have available. An application that names the relevant safety standards by number, documents the risk assessment process in detail, describes the fault-chain structure of the specific deployment, and identifies which coverage line addresses which node will produce materially better terms than a generic form that simply describes a "manufacturing robot." The same data scarcity that makes this business harder to price also makes carriers who want cobot risk on their books compete on terms for a well-presented submission, while declining or heavily restricting one that leaves them guessing about the autonomy architecture underneath it. A broker who reads the actual policy language before it binds, before an incident forces the question, and who routes the submission to a carrier whose form explicitly covers autonomous systems catches the ISO exclusion before it becomes a denied claim, instead of leaving the submission in a standard ISO-form CGL policy that was never built to hold it. A generic placement will miss the exclusion entirely, and the company will not learn that until the claim it filed comes back denied.