[Robotics](https://rankshieldrobotics.com/) / [Blog](https://rankshieldrobotics.com/blog/) Blog / Compliance # A Robot Causes Harm. Can You Prove What It Was Told to Do? From 9 December 2026 the revised EU Product Liability Directive treats software and AI systems as products, and it lets a court presume your product defective if you fail to disclose relevant evidence when asked [1](#ref-1). For a robot that means the dispute after an incident is not only about what the machine did. It is about whether you can show what it was told to do, by whom, and whether that was permitted. Most fleets currently cannot. By RankShield Robotics, Robot Security Research | Published August 30, 2026 ## Key takeaways - Directive (EU) 2024/2853 applies to products placed on the market or put into service after 9 December 2026 , and member states must transpose it by that date [1](#ref-1) [2](#ref-2) . - Article 4(1) defines a product to include software , and the recitals extend that to operating systems, firmware, applications and AI systems [1](#ref-1) . - Article 10(2)(a): a court may presume defectiveness where the defendant fails to disclose evidence under Article 9 [1](#ref-1) . Absence of a record is not neutral, it is adverse. - Article 10(4) allows a presumption where a claimant faces "excessive difficulties, in particular due to technical or scientific complexity" [1](#ref-1) . A robot incident is close to the definition of that. - Liability can run 10 years generally and 25 for latent defects [3](#ref-3) , so the question is not whether you log, it is whether you can still answer in two decades. ## What actually changes on 9 December 2026? The old product liability regime, in place since 1985, is replaced. Directive (EU) 2024/2853 applies to products "placed on the market or put into service after 9 December 2026," and member states must implement it by that date [1](#ref-1)[2](#ref-2). Products already on the market before then stay under the old rules, with an important exception covered further down. Three changes matter for robotics. Software becomes a product in its own right. The claimant's evidential burden is eased through a disclosure duty and a set of rebuttable presumptions. And liability attaches not only to manufacturers but to importers, distributors, and anyone who substantially modifies a product after it is placed on the market, to the extent the defect results from that modification [2](#ref-2). It also arrives in company. The Cyber Resilience Act's reporting obligations start 11 September 2026, the Data Act applies from 12 September 2026, and the Machinery Regulation applies from 20 January 2027 [4](#ref-4). One law firm's summary of the convergence is worth quoting because it is also the practical answer: "by preserving evidence and preparing documentation (logging, SBOM, technical documentation) at an early stage, companies can simultaneously fulfil product liability, CRA and the Machinery Regulation requirements" [4](#ref-4). One further point that changes the shape of the risk: the separately planned AI Liability Directive was withdrawn in 2025, "meaning that the (strict) product liability legislation now takes precedence" [4](#ref-4). There is no softer AI-specific regime waiting behind this one. Four EU instruments land between September 2026 and January 2027, and the same evidence artifact serves all of them. ## Is a robot's software really a "product" now? Yes, explicitly. Article 4(1) defines a product as "all movables, even if integrated into, or inter-connected with, another movable or an immovable," and states that it "includes electricity, digital manufacturing files, raw materials and software" [1](#ref-1). Recital 13 makes the breadth clear: software covers operating systems, firmware, applications and AI systems, whether stored on a device, accessed over a network, or supplied as a service [1](#ref-1). For a robot this collapses a distinction people have relied on. The chassis, the controller firmware, the navigation stack, the policy that decides what the machine may do, and any model weights that shape its behavior are all within the same liability frame. Analysis of the software provisions notes that any software placed on the market or put into service, standalone or in combination with another product, falls in scope, with a narrow carve-out for open-source software supplied outside a commercial activity [3](#ref-3). The consequence is that "the hardware was fine, it was a software issue" stops being a defence and starts being a description of which product was defective. ## What happens if you cannot disclose the evidence? The court may presume the product was defective. Article 9(1) obliges a defendant to disclose relevant evidence at the request of a person claiming compensation, once that claimant has presented facts sufficient to support the plausibility of the claim [1](#ref-1). Article 10(2)(a) then provides that defectiveness is presumed where the defendant fails to make that disclosure [1](#ref-1). Read that sequence slowly, because it inverts an instinct. In an ordinary engineering dispute, the party with no records is merely unhelpful. Here, the party with no records supplies the other side with a presumption. Silence is not a neutral position, and "our logging was not configured for that" is a statement with a legal consequence attached rather than an operational excuse. Provision | What triggers it | Effect | Article 9(1) | Claimant presents a plausible case | Defendant must disclose relevant evidence [1](#ref-1) | Article 10(2)(a) | Defendant fails to disclose | Defectiveness presumed [1](#ref-1) | Article 10(2)(b) | Product breached mandatory safety requirements | Defectiveness presumed [1](#ref-1) | Article 10(2)(c) | Obvious malfunction in reasonably foreseeable use | Defectiveness presumed [1](#ref-1) | Article 10(4) | Excessive difficulty from technical or scientific complexity, and defect is likely | Defectiveness or causation presumed [1](#ref-1) | Two honest qualifications. Disclosure is "limited to what is necessary and proportionate," and the directive requires courts to weigh confidentiality and trade secrets [1](#ref-1), so this is not an open invitation into your source tree. And every presumption listed is rebuttable by the defendant [1](#ref-1)[2](#ref-2). The question this article is about is what you would rebut it with. ## Why are robots the paradigm case for the complexity presumption? Because Article 10(4) is written for exactly the situation a robot incident produces. It allows a court to presume defectiveness or the causal link where a claimant faces "excessive difficulties, in particular due to technical or scientific complexity," provided they still demonstrate that the defect is likely [1](#ref-1). That last condition matters and is often dropped in summaries: the presumption is not automatic, the claimant must still get over a threshold. Now consider what an injured person faces after a robot incident. The behavior emerged from a control policy interacting with sensor input, possibly a learned model, a fleet management instruction, and a physical environment. Reconstructing which of those produced the movement is genuinely hard, and it is hard in precisely the way the provision names. Legal commentary on embodied AI frames the underlying difficulty as an open question: "What constitutes a 'defect', when does it arise, and how far does the obligation to monitor the product extend if the product continues to evolve on its own after being placed on the market?" [4](#ref-4) The strategic implication is uncomfortable and worth stating plainly. Complexity has historically favored the defendant, because the claimant could not untangle the system. Under this directive complexity can favor the claimant instead. The party best able to make the system legible is the party that benefits, and for a robot fleet that party should be you. ## Does this reach robots that are already in the field? Not directly, and then frequently yes, through updates. The directive applies to products placed on the market or put into service after 9 December 2026 [1](#ref-1), so a robot deployed before that date starts under the old regime. But practitioner analysis notes that "any substantial modification or update to such a product after this date may bring it within the scope of the new Directive" [2](#ref-2). For most product categories that caveat is a footnote. For robots it is the main event, because robots are updated constantly: firmware revisions, navigation policy changes, new manipulation skills, refreshed models. A fleet placed in service in early 2026 and actively maintained through 2027 is not obviously outside the new regime, and the question of whether a given update was a substantial modification is one you would rather answer with a change record than with recollection. The practical move is to stop treating December as a line between two fleets and start treating it as the date by which your evidence capability should cover everything you operate. Our page on [security for robot fleet operators](https://rankshieldrobotics.com/industries/robot-fleet-operator-security/) covers the operational side. ## Is failing to ship a security update now a liability exposure? It is treated as one. Analysis of the software provisions is direct: manufacturers remain liable even where software was not defective at release, because they carry an obligation to provide "software updates or software upgrades" that eliminate emerging defects and maintain cybersecurity across the lifecycle, for as long as they retain the technical capability to do so [3](#ref-3). Practitioner commentary describes liability for "defective software, unsafe digital functionalities or the failure to provide necessary security updates" [2](#ref-2). Set that against what actually happens in this market. We recently looked at [two published unauthenticated root chains in a humanoid robot with no confirmed fixed firmware release](https://rankshieldrobotics.com/blog/robot-vulnerability-no-patch-compensating-controls/). Under the old regime that gap was an operator's security problem. Under this one it is also a manufacturer's liability question, and the operator's problem becomes evidencing that they did what was available to them while no fix existed. There is a fair protection for manufacturers who do patch, and it deserves stating because the opposite is often assumed: "a software update does not mean that the older version of the software was defective" [3](#ref-3). Shipping a fix is not an admission. That removes one of the perverse incentives that used to discourage prompt patching. ## How long do you need to be able to answer? Longer than most log retention policies contemplate. Claims must be brought within three years from the claimant's cumulative knowledge of the damage, the defect, and the identity of the liable operator, sitting inside a general period of ten years and an extended period of twenty-five years for latent defects [3](#ref-3). Twenty-five years is the number that should reorder a retention discussion. A robot shipped in 2027 could generate a question in 2052 about what it was running and what it was authorized to do. Very few robotics organizations have logging they expect to be able to read that far out, and fewer still have thought about whether the format, the keys, and the verification path survive that long. This is where the difference between a log and a record becomes practical rather than semantic. A log is something you kept. A record is something whose integrity you can still demonstrate, to someone adversarial, long after the people who built the system have moved on. [Tamper-evident action provenance](https://rankshieldrobotics.com/solutions/robot-action-provenance/) is designed for the second case, because the first case invites the obvious question of who could have edited it. ## What evidence would actually rebut a presumption? Evidence that answers, for one named unit at one named moment, what was running, what it was told to do, whether that was permitted, and what it then did. Those four questions are the spine of any post-incident argument, and each maps to something a fleet either has or does not. What was running is firmware, policy and model version, established by attestation rather than by an asset spreadsheet, since the spreadsheet records what should have been deployed rather than what was. What it was told to do is the command and the principal that issued it. Whether it was permitted is the authorization decision, which only exists as evidence if the decision was made by something that recorded it. What it did is the actuation outcome, which is the one most systems capture and the least useful on its own. The integrity layer is what converts these from assertions into evidence. A record you could have altered is worth considerably less against a rebuttable presumption than one you demonstrably could not, which is the entire argument for writing provenance somewhere the operator cannot quietly revise. See [firmware attestation](https://rankshieldrobotics.com/solutions/firmware-attestation-rats/) and the [pre-actuation authorization gate](https://rankshieldrobotics.com/solutions/pre-actuation-authorization-gate/) for how the first three are produced as a byproduct of normal operation rather than assembled after an incident. Honest scope, since this is a legal context: none of this determines liability, and none of it substitutes for counsel. It determines whether you arrive at the argument with a record or without one. That is a narrower claim than "compliance" and a more useful one. ## What should a robot maker or operator do before December? Run the disclosure question against yourself while it is hypothetical. Pick one robot, pick one moment last week, and try to establish what firmware and policy it was running, what it was commanded to do, by whom, whether that command was authorized, and what it actually did. Note where you had to guess. Then check how long those answers remain available, and whether anyone could have edited them in the meantime. The worksheet below structures that exercise and produces a downloadable summary you can take to counsel or an insurer. It is a readiness prompt rather than legal advice, and everything runs in your browser. Interactive tool ### Disclosure Readiness Worksheet Could you answer an Article 9 disclosure request today, for one unit, at one moment? Nothing you enter leaves your browser. An incident happens tomorrow and you receive a disclosure request. Tick what you could evidence today, for one named unit, at one named moment. Which exact firmware, policy and model versions were running on that specific unit at that moment What command the robot received, and which principal issued it Whether that command was authorized, and against which policy What the robot actually did, as distinct from what it was asked to do That the record itself has not been altered since the event Which security updates were available, which were applied, and when How long can you still answer these for a unit shipped today? Under 2 years, or we have not decidedAbout 10 years25 years or more DISCLOSURE READINESS 0of 6 questions answerable Download your disclosure readiness summary ## Frequently asked questions about robot liability and evidence under the revised Product Liability Directive **When does the new EU Product Liability Directive apply to robots?** Directive (EU) 2024/2853 applies to products placed on the market or put into service after 9 December 2026, and member states must transpose it into national law by that date [1](#ref-1)[2](#ref-2). Robots deployed before then remain under the previous regime, although practitioner analysis notes that a substantial modification or update after that date may bring an older product within scope [2](#ref-2). Given how frequently robot firmware, policies and models are updated, that caveat reaches a large part of an actively maintained fleet. **Is robot software covered by the directive?** Yes. Article 4(1) defines a product to include software, and the recitals extend that to operating systems, firmware, applications and AI systems, whether stored on a device, accessed over a network or supplied as a service [1](#ref-1). Analysis of the software provisions confirms that software placed on the market or put into service, standalone or combined with another product, is in scope, with a narrow exception for open-source software supplied outside a commercial activity [3](#ref-3). For a robot, the firmware, the control policy and any model weights sit inside the same liability frame as the chassis. **What is the disclosure obligation under Article 9?** Once a claimant presents facts sufficient to support the plausibility of a claim, the defendant is obliged to disclose relevant evidence [1](#ref-1). Disclosure is limited to what is necessary and proportionate, and courts must weigh confidentiality interests and trade secrets [1](#ref-1). The consequence of failing to disclose is set out in Article 10(2)(a): the court may presume the product defective [1](#ref-1). That is why an inability to produce records is not a neutral position in a dispute under this directive. **Are the presumptions of defectiveness automatic?** No, and two qualifications matter. Every presumption in Article 10 is rebuttable by the defendant [1](#ref-1)[2](#ref-2). And the complexity presumption in Article 10(4) is not triggered by complexity alone: the claimant must face excessive difficulties due to technical or scientific complexity and must still demonstrate that the defect is likely [1](#ref-1). The practical question for a robot operator is therefore not whether a presumption can arise, but what evidence you would rebut it with if one did. **Does shipping a security patch admit the earlier version was defective?** No. Analysis of the software provisions states directly that a software update does not mean the older version of the software was defective [3](#ref-3). This matters because the opposite assumption discourages prompt patching. The related obligation runs the other way: manufacturers are expected to provide updates that address emerging defects and maintain cybersecurity across the lifecycle while they retain the technical capability, and failure to provide necessary security updates is described as a liability exposure [2](#ref-2)[3](#ref-3). **How long do we need to retain robot evidence?** Longer than typical logging policies assume. Claims must be brought within three years of the claimant's cumulative knowledge of the damage, the defect and the liable operator, within a general period of ten years and an extended period of twenty-five years for latent defects [3](#ref-3). A robot shipped in 2027 could therefore attract a question in 2052. The practical test is not only whether records are retained but whether they remain readable and verifiable after the original systems and staff are gone. **What does RankShield Robotics provide here, and what does it not?** We provide the evidence layer: attestation establishing which firmware, policy and model version a specific unit was running, authorization decided off-robot so that the permit or refusal exists as a record rather than an inference, and tamper-evident provenance written where the operator cannot quietly revise it. What we do not do is determine liability, certify compliance, or replace legal advice. The narrow and useful claim is that these controls decide whether you enter a dispute able to answer the disclosure question or unable to. ## References - European Union. Directive (EU) 2024/2853 on liability for defective products (Articles 4, 9 and 10) . 2024, applies from 9 December 2026. [eur-lex.europa.eu/eli/dir/2024/2853/oj/eng](https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng) - Gibson Dunn. EU Product Liability Directive: Responding to Software, AI and Complex Supply Chains . 2026. [www.gibsondunn.com/eu-product-liability-directive-responding](https://www.gibsondunn.com/eu-product-liability-directive-responding-to-software-ai-and-complex-supply-chains/) - International Bar Association. Liability for software under the new European Product Liability Directive . 2026. [www.ibanet.org/European-Product-Liability-Directive-liabilit](https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software) - CMS. Physical AI: embodied AI gives rise to new legal requirements . 2026. [cms.law/en/deu/legal-updates/physical-ai-embodied-ai-gives-r](https://cms.law/en/deu/legal-updates/physical-ai-embodied-ai-gives-rise-to-new-legal-requirements) ## Keep exploring [SOLUTIONTamper-evident action provenance](https://rankshieldrobotics.com/solutions/robot-action-provenance/)[INDUSTRYInsurance and risk attestation](https://rankshieldrobotics.com/industries/robot-insurance-risk-attestation/)[BLOGWhen a robot CVE has no patch](https://rankshieldrobotics.com/blog/robot-vulnerability-no-patch-compensating-controls/) ## Arrive at the argument with a record. Attested versions, authorization decided off-robot, and provenance the operator cannot quietly revise. [Request early access](https://rankshieldrobotics.com/request-access/) This article is for general information and does not constitute legal advice. It summarizes provisions of Directive (EU) 2024/2853 and published analysis of it; national transposition varies, and the application of any provision to a specific product, incident or organization is a question for qualified counsel. Article and recital references are to the directive as published. Presumptions described here are rebuttable, and the complexity presumption additionally requires a claimant to demonstrate that the defect is likely. Confirm current national implementation before relying on any date or provision stated here.