Blog/robot-policy-updates-insurance

A new policy is a new product: what robot software updates mean for liability and insurance

August 6, 2026vendor-guideinsurancewarehouse-robotics

A robot's behavior is its policy: the trained model that decides what the arm or the vehicle does next. Vendors update these models the way phone apps update. Each push changes how a fleet behaves at customer sites. The law has begun to treat each push as a change to the product itself. Insurers can already see software differences in loss data. This post lays out both, with the primary sources quoted so you can check every word.

First, our limits. We are not lawyers and we are not brokers; nothing here is legal or placement advice. We sell robot evaluation, so we have an interest in the conclusion, and you should read us knowing that. Every claim below carries a numbered source. Where the record is thin we say so in the text. One example: we found no public source showing an insurer re-price a fleet per software version. What the record does show is strong enough.

In the EU, a software update can create a defect you are liable for

The EU rewrote its product liability law in 2024. The new directive counts software as a product outright, and it applies to products placed on the market or put into service after 9 December 2026 [1].

The text is blunt. A maker stays liable for a defect caused by 'software, including software updates or upgrades' [1]. It also stays liable for 'a lack of software updates or upgrades necessary to maintain safety' [1]. The one condition is that the update sits within its control. Not updating is now a defect source, not a defense.

It goes further. Make a substantial change 'through a software update or upgrade, or due to the continuous learning of an AI system', and the clock restarts [1]. The directive treats the changed product as newly made available on the market, or put into service, at that moment. Read that as a robot vendor. A big enough policy update means you shipped a new product, with a new product's exposure.

No court has applied this to a warehouse robot yet; the directive is new and untested. But the direction is written down, in force, and dated.

Cars already live under this regime

Vehicle regulators got here first. UN Regulation No. 156 requires makers of software-updatable vehicles to run a documented update process [2]. Before an update ships, the maker must assess whether it 'will add, alter or enable any functions' that were not present when the vehicle was approved [2]. It must record that the update 'successfully passed verification and validation procedures' [2]. Each relevant software version must carry its own unique ID. A failed update must roll back to the old version, or the vehicle must reach a safe state [2].

The US shows what enforcement looks like. In February 2023, Tesla recalled 362,758 vehicles over Full Self-Driving Beta behavior. The recall report lists the component as 'Vehicle Software', and the remedy was an over-the-air update [3]. Tesla stated it did not concur with the agency's analysis and knew of no related injuries [3]. Ten months later, a second recall covered 2,031,220 vehicles, again remedied by a software push [4].

Note what these recalls are and are not. In both, existing software behavior was the defect and an update was the cure. We did not find a US recall caused by a bad update pushed to a fleet, and we looked. The mechanism still cuts both ways: once a regulator treats software as a component, every version you ship is a component change.

Insurers can already see software in the loss data

Forward collision warning + automatic braking-50% rear-end crashesForward collision warning alone-27% rear-end crashesBlind spot detection-14% lane-change crashesLane departure warningno reduction insurance claim rates
Figure 1. What driver assistance software shows up as in crash and insurance data, per IIHS and HLDI [5]. Read each bar against its own metric, printed beside it: the first two are rear-end crashes, the third is lane-change crashes, and the last is insurance claim rates, where HLDI found no reduction from lane departure warning. IIHS notes the same feature did reduce police-reported single-vehicle, sideswipe and head-on crashes; the null is specific to claim rates [5]. These are different yardsticks from different studies, gathered on one chart only to make a single point: what software a machine runs is visible in loss data.

The chart makes a narrow point. What software a machine runs shows up in crash and claim data, feature by feature. The insurance industry's own research arms measure it [5]. Waymo and Swiss Re went further. They compared a driverless fleet's liability claims to human baselines built from over 500,000 claims. Waymo reports an 88% drop in property damage claims across 25.3 million miles [6]. That figure is the company's own account of a study it co-wrote, so treat it as a vendor number.

Reinsurers have also begun underwriting model performance directly. Munich Re sells cover that lets an AI vendor 'indemnify your clients for their financial losses or legal liabilities directly related to AI errors' [7]. Lloyd's wrote back in 2019 that liability may shift from human drivers to AV makers, and that recalls 'could become larger and more complex' [8]. None of this is a robotics actuarial table. It is the machinery being built around one.

An update that lifts the average can still regress

Here is the part our own work touches. Model updates do not improve uniformly. The research literature calls the failures 'negative flips': cases the old model handled correctly that the new model gets wrong, even when overall accuracy rises [9][11].

Two more results are worth carrying into any update review. Updates that raise a model's accuracy can still hurt the human teams built around it [10]. And retraining can change behavior even when the data has not shifted, from optimization randomness alone [11].

This is why per-episode comparison exists on our platform. An update gate has to see which cases flipped, not just whether the average moved. One disclosure: our public demo data holds two policies tested on different tasks. It cannot show a true same-task update regression. The research above is the evidence base. Our tooling is built for the day your own fleet generates the comparison.

Regulators reward a validated update pipeline

The strictest regimes do not demand a fresh approval for every model change. They demand a tested change process, and they reward it. The FDA now approves a 'predetermined change control plan' for AI devices [12]. The plan describes the changes you intend, how you will validate them, and their impact. Updates that follow the plan ship without a new submission [12]. The EU AI Act mirrors this. Changes the provider pre-declared in the first assessment are not a 'substantial modification'. For high-risk systems, unplanned changes that affect compliance or the intended purpose trigger a new conformity assessment [13].

Even OSHA's manual for industrial robots says the risk assessment documentation should be 'reviewed if any changes are made to the robot application' [14].

1Version every policy you ship

UN Regulation No. 156 requires all initial and updated software versions to be uniquely identifiable; the system identifier is updated when a change leads to a new or extended type approval.

2Assess the update before it goes out

R156 requires a documented process to assess whether an update adds, alters or enables any function not present at approval, and confirmation that it passed verification and validation, per update.

3Keep a rollback path

R156 requires that a failed or interrupted update can be restored to the previous version, or the vehicle placed in a safe state.

4Pre-declare the changes you plan to make

The FDA authorizes a change plan once, then lets validated model updates ship without a new submission. The EU AI Act exempts pre-determined changes from re-assessment the same way.

5Re-check the risk assessment after changes

OSHA's technical manual says the risk assessment documentation should be reviewed if any changes are made to the robot application.

6Record what the update changed in the field

An update that lifts the average can still flip individual cases from pass to fail. Per-episode comparison is the only way to see it.

Figure 2. The update playbook regulators keep converging on, assembled from UN Regulation No. 156 [2], the FDA's change control plan guidance [12], the EU AI Act [13], and OSHA's technical manual [14]. Items 1 to 5 paraphrase those documents; item 6 is our own addition. None of these were written with a warehouse robot vendor in mind. All of them describe the same discipline, and it is the discipline an underwriter can be shown.

None of the six is exotic. Together they are the proof that update risk is managed. The reader who asks for that proof may be a regulator today. Soon it may be an underwriter.

What this means when you talk to your insurer

  • Verified: from December 2026, EU liability attaches to defects from updates, and to safety updates you failed to ship [1].
  • Verified: vehicle regulators already require per-update validation, version identification, and rollback [2].
  • Verified: software differences are visible in insurer claims data [5][6], and model performance itself is now an insurable risk [7].
  • Not verified: we found no public source showing premiums re-priced per software version, and no US recall caused by a pushed update. If someone asserts either, ask for the document.

Our takeaway is the one the regulators converged on. You cannot promise an update will never regress; the research says otherwise [9][10][11]. You can show a pipeline that versions every policy, evaluates before deployment, catches the flips, and rolls back cleanly. That evidence is under your control today, before any of these laws reaches a warehouse.

Sources

All sources read in August 2026. Quotes are verbatim from the primary documents. The two Lloyd's quotes come from a two-column PDF, so we re-checked the sentence stitching against the rendered pages.

  1. Directive (EU) 2024/2853 on liability for defective products, eur-lex.europa.eu. Article 4(1): product 'includes electricity, digital manufacturing files, raw materials and software'. Article 11(2): no exemption where defectiveness is due to 'software, including software updates or upgrades' or 'a lack of software updates or upgrades necessary to maintain safety', within the manufacturer's control. Recital 40 on substantial modification 'through a software update or upgrade, or due to the continuous learning of an AI system'. Recital 63: the directive 'does not apply to products placed on the market or put into service before 9 December 2026'. Recital 58 and Article 17(1)(b): a new expiry period runs for substantially modified products.
  2. UN Regulation No. 156, Software Update Management System, as published in the EU Official Journal, CELEX 42021X0388, eur-lex.europa.eu. Paragraphs 7.1.1.9 (assess whether an update 'will add, alter or enable any functions' not present at type approval), 7.1.2.5(i) ('successfully passed verification and validation procedures'), 7.1.1.2 (unique identification of software versions), 7.2.2.1.1 (restore to previous version or safe state).
  3. NHTSA Part 573 Safety Recall Report 23V-085, Tesla Full Self-Driving Beta, February 2023, static.nhtsa.gov: 'Number of potentially involved: 362,758'; component 'Vehicle Software'; 'Tesla will deploy an over-the-air (OTA) software update at no cost to the customer'; 'while not concurring with the agency's analysis, Tesla decided to administer a voluntary recall out of an abundance of caution'; 'Tesla is not aware of any injuries or deaths that may be related to such conditions.'
  4. NHTSA Part 573 Safety Recall Report 23V-838, Tesla Autosteer, December 2023, static.nhtsa.gov: 'Number of potentially involved: 2,031,220'; 'affected vehicles will receive an over-the-air software remedy'.
  5. IIHS, Advanced driver assistance topic page, iihs.org: 'systems with forward collision warning and automatic braking cut rear-end crashes in half, while forward collision warning alone reduces them by 27% (Cicchino, 2017)'; 'Blind spot detection has been shown to reduce lane-change crashes by 14% (Cicchino, 2018)'; 'Lane departure warning has not brought down insurance claim rates (HLDI, 2023) but has reduced rates of single-vehicle, sideswipe and head-on crashes reported to the police' (further study citations omitted); 'Vehicles equipped with these systems consistently show lower rates of claims for damage to other vehicles and for injuries to people in other vehicles (HLDI, 2023).'
  6. Waymo blog, December 2024, waymo.com, describing a study conducted with Swiss Re: human baselines 'based on Swiss Re's data from over 500,000 claims and over 200 billion miles of exposure'; 'an 88% reduction in property damage claims and 92% reduction in bodily injury claims'; 'across 25.3 million miles, the Waymo Driver was involved in just nine property damage claims and two bodily injury claims.' Waymo also notes both bodily injury claims were still open. Company description of a co-authored study; we did not review the underlying paper.
  7. Munich Re, aiSure product page, munichre.com: 'aiSure-backed performance warranties enable you to indemnify your clients for their financial losses or legal liabilities directly related to AI errors.' The page does not discuss update versioning; we cite it only for model performance being insurable.
  8. Lloyd's, Taking control: artificial intelligence and insurance, Emerging Risk Report 2019, lloyds.com: liability may shift 'from human drivers to automated vehicles (AVs), and therefore to the manufacturers'; 'In general, recalls could become larger and more complex'.
  9. Yan et al., Positive-Congruent Training: Towards Regression-Free Model Updates, arXiv:2011.09161: 'A new model incorrectly predicts the output for a test sample that was correctly classified by the old (reference) model.'
  10. Bansal et al., Updates in Human-AI Teams, AAAI 2019: 'updates that increase AI performance may actually hurt team performance'.
  11. Srivastava et al., An Empirical Analysis of Backward Compatibility in Machine Learning Systems, KDD 2020, microsoft.com/research: 'updates, intended to improve ML models, can introduce new errors'; 'compatibility issues arise even without data shift due to optimization stochasticity'.
  12. FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, issued December 4, 2024, reissued final August 18, 2025, fda.gov: the PCCP describes 'the planned AI-DSF modifications, the associated methodology to develop, validate, and implement those modifications, and an assessment of the impact', reviewed 'without necessitating additional marketing submissions for implementing each modification described in the PCCP'.
  13. Regulation (EU) 2024/1689 (AI Act), eur-lex.europa.eu. Article 3(23) defines 'substantial modification' as a change 'not foreseen or planned in the initial conformity assessment'; Article 43(4): substantial modifications to high-risk systems require a new conformity assessment; for systems that continue to learn, changes 'pre-determined by the provider at the moment of the initial conformity assessment' and covered in the technical documentation do not.
  14. OSHA Technical Manual, Section IV, Chapter 4, Industrial Robot Systems and Industrial Robot System Safety, osha.gov: 'The documentation should also be retained for future reference and reviewed if any changes are made to the robot application.' The page carries no revision date and cites the 2012 edition of ANSI/RIA R15.06.
Share: