Logistics plant engineering is currently undergoing the most radical transformation in its history. Whereas mechanics, steel construction and simple programmable logic controllers (PLCs) once dominated the landscape, today neural networks, computer vision and autonomous decision-making algorithms determine the efficiency of modern distribution centres. However, as technical complexity grows, so does legal exposure. With the new EU Product Liability Directive (Directive (EU) 2024/2853), which must be transposed into German law by 9 December 2026, the European legislator is responding to the challenges of digitalisation. For plant manufacturers, system integrators and importers of AI hardware, the boundaries of liability are shifting towards increased risk responsibility.
Software as an actual product: the end of liability privileges
One of the central tenets of previous product liability law was the fundamental restriction to physical objects, meaning that the extension of the Product Liability Act to software was contentious. Software was often regarded as a service or merely an accessory, and victims were denied recourse under product liability law.
The new Directive breaks with this tradition. Software is now explicitly a product. This applies regardless of whether it:
- is embedded in the hardware of a picking robot,
- controls an entire conveyor system as an operating system,
- or operates as a cloud-based warehouse management system (WMS) via an API interface.
The product status of software applies regardless of whether it is stored on a device or accessed via cloud or software-as-a-service technologies. (Open-source software developed or provided outside the scope of a business activity is expressly excluded from the legal definition of a product.)
For plant engineering, this means a software error leading to damage1 (e.g. a collapsed shelving system due to faulty loading logic) can now, in principle, trigger strict liability. The claimant no longer needs to prove fault on the part of the manufacturer; it is sufficient to prove that the product was defective and that this defect caused the damage.
This means: If damage occurs because the AI makes a wrong decision (e.g. an autonomous vehicle crashes into a shelf because object recognition fails), the manufacturer is liable even if they programmed it ‘to the best of their knowledge.’ Liability is based solely on the defectiveness of the product, not on any personal misconduct on the part of the developers.
The dynamic concept of defect and the ‘learning risk’
In traditional mechanical engineering, a product was considered safe if it corresponded to the state of the art at the time it left the factory floor. With AI systems that continuously adapt their behaviour during operation through machine learning, this static approach falls short.
- Liability for learning-induced errors: If a system develops dangerous behaviour through training with customer data, this may be attributed to the manufacturer. AI systems that alter their behaviour after deployment and thereby cause damage, remain the responsibility of the manufacturer ‘as long as they are under the control’ of the manufacturer or updates are directly or indirectly the manufacturer’s responsibility.
- Machine learning: If an AI-controlled order-picking system chooses unsafe routes through autonomous learning and thereby causes accidents, the manufacturer may be liable. They can exonerate themselves if they demonstrate that they could have restrained the algorithm through clear ‘guardrails’ (safety limits) and the operator ignored these.
- Defectiveness due to failure to provide updates: A product may now also become defective if necessary software updates or security patches are not provided. In logistics plant engineering, where systems are often in operation for 15 to 20 years, this establishes a long-term obligation to monitor and update the product. A lack of cybersecurity is explicitly classified as a product defect if it jeopardises the safety of physical operations.
Relaxation of the burden of proof: The end of the ‘black box’ defence
Until now, plaintiffs had to prove precisely which technical defect caused the damage. In the world of AI, this is often impossible. The directive introduces a reversal of the burden of proof here:
- If the system is “excessively complex” – which is likely to be the case for most modern AI applications – and the claimant demonstrates damage as well as a probable malfunction, the burden of proof is reversed. The manufacturer must now prove that their system functioned without fault. This amounts to a burden of proof for the manufacturer if they cannot provide detailed “reasoning logs.”
- Disclosure obligations: The courts may compel manufacturers to disclose parts of their source code, training logs or risk analyses in court; this requires consistent, legally sound documentation and governance. Companies must therefore significantly strengthen their documentation strategy (“reasoning logs”) in order to be able to prove the correctness of the algorithm in the event of a dispute.
Exculpation and exemption from liability in plant engineering
Despite these stricter requirements, the manufacturer is not without protection. The Directive provides for specific defences (exculpation) that are of crucial importance in the logistics sector.
- The defence of development risk: A manufacturer is not liable if the fault was not recognisable according to the state of the art at the time of placing the product on the market. But beware: For AI products, the required safety level is high and must be continuously developed. Anyone using AI must demonstrate that they have applied the latest methods for validating and verifying AI systems (e.g. formal methods or simulation tests).
- The Operational Design Domain (ODD): A key ground for exemption is improper use by the operator. System manufacturers must precisely define the operating conditions of their AI systems in the contract and in the technical documentation. If a picking robot is certified for an environment with a temperature of 20°C and a level industrial floor, but the operator uses it in a cold store or on uneven ground, the manufacturer is not liable for any resulting navigation errors.
Conclusion: A new quality attribute – ‘legal resilience’
The new EU Product Liability Directive is not an obstacle to innovation, but a guide to safer and more transparent automation. For operators of logistics facilities, it offers the opportunity to safeguard the technical complexity of their systems through clear contractual guidelines.
Liability security is becoming a quality feature: operators who prioritise transparency and a precise division of roles with their plant manufacturers not only minimise their legal risks but also create the basis of trust necessary for the success of Logistics 4.0. By 2026, legal resilience will be just as important as the mechanical resilience of the plant itself.
Implementation into German law remains to be seen by 9 December 2026 at the latest, but a broad interpretation and a significant tightening of liability are to be expected. Companies in the logistics plant engineering sector should take early action on compliance initiatives.
1 Under section 1(1), second sentence, of the Product Liability Act (ProdHaftG), only damage to property used for private purposes is eligible for compensation under the Product Liability Act. Personal injury is therefore particularly relevant in this context.
