Every answer and its explanation appears here once you have finished the path. Each one then links to the matching glossary entry, where the concept is set out in full with its worked example.
1. The revised product liability directive explicitly brings software and artificial intelligence systems within the notion of a product. What does that change for the victim of damage caused by an algorithm?
They no longer need to prove fault, the regime being one of strict liability
The European product liability regime has rested since the 1980s on a simple idea: whoever puts a defective product into circulation answers for the damage it causes, without any need to establish fault on their part. The victim must prove the damage, the defect and the link between them, which is already demanding, but need not show negligence. That regime was written for physical objects, and whether it covered software stayed open for decades, with the practical consequence that a victim of algorithmic damage was often pushed back to fault-based liability, meaning to proof they had no way of producing. The revision settles it by bringing software and artificial intelligence systems within the notion of a product, and it extends the notion of defect to security failures, updates and continuous learning, which aims squarely at systems that change after they are sold. For an insurer the consequence is that the claim changes cover and often changes insured: what was argued as a service failure is now handled as a product defect.
Glossary entry →2. Directive 2024/2853 creates a rebuttable presumption of defectiveness where proving the defect is excessively difficult because of the product's technical complexity. Applied to an opaque model, what effect does that produce?
Inexplicability turns back on the manufacturer, who must prove the absence of a defect
A model's opacity long served as a defense: what went wrong inside cannot be shown, so the victim fails to prove the defect, so the claim falls. The presumption reverses exactly that mechanism. Where technical complexity makes proof excessively difficult, the defect is presumed, and it falls to the manufacturer to show its product was not defective, which means opening its training documentation, its datasets and its logs. Inexplicability, yesterday's technical argument, becomes a legal burden, and that is the point to retain because it changes what documentation is worth inside a company: what was an internal good practice becomes the exhibit without which one loses. Note that the presumption is rebuttable, which is no detail: the manufacturer keeps a defense, but must build it from evidence only it holds. For underwriting, this shifts examination of the risk toward a model's actual traceability rather than its advertised performance.
Glossary entry →3. The development-risk defense exonerates a producer where the state of knowledge, when the product was put into circulation, could not have revealed the defect. Why does it hold poorly against embedded AI updated remotely?
The reference moment disappears, the manufacturer keeping control of the product after sale
This defense rests on a precise image, that of an object frozen at the factory gate: one judges what could be known at that instant, and what was discovered later cannot be held against the producer. The image holds for a mechanical component and stops holding for a system its manufacturer keeps modifying, since it retains control of the product through updates and remote access. The reference moment on which the whole exoneration rested then dissolves: at what date is the state of knowledge assessed, when January's software is no longer September's and the model has gone on learning in between? A product that is never finished is a product whose liability never closes, and that is a deep change for insurance, which usually reasons by occurrence or claims-made year over stable objects. The defence stays in the text; what matters is that it becomes very hard to invoke for the very party that kept its hand on the product after selling it.
Glossary entry →4. A health insurer uses a model to price its individual policies. Under Regulation (EU) 2024/1689 it deploys a high-risk system under Annex III. What does that classification trigger?
Data governance, documentation, logging, human oversight and conformity assessment
The regulation's architecture is a pyramid of risk, from prohibited uses at the top to minimal risk at the base, and it is on the intermediate high-risk category that the bulk of the constraint falls. There are two routes in, worth telling apart: Annex I, where the system is embedded as a safety component in an already regulated product, and Annex III, which covers eight sensitive standalone use domains, among them biometric identification, employment, critical infrastructure and access to essential services. Pricing health and life insurance contracts comes under the second route, which the sector should know: insurance is named among this text's addressees. The classification then triggers a set of process rather than outcome obligations, risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity, validated by a conformity assessment. These are obligations about how the system is built and run, and they are proved with documents.
Glossary entry →5. A company screens job applications with a third party's model, without putting in place the required human oversight. A rejected candidate challenges the decision. How does the regulation split the roles?
The provider owes compliant design, the deployer appropriate use and oversight
The regulation distinguishes two roles and assigns them different obligations, which is the entry point of any loss analysis in this field. The provider, who designs and places the system on the market, owes compliant design, documentation and post-market monitoring. The deployer, the professional putting the system to work in a concrete setting, owes appropriate use, adherence to the instructions, human oversight and, for some, a fundamental rights impact assessment. The distinction structures how the burden splits when damage occurs: a failure may stem from a design defect, and one goes back to the provider, or from inappropriate use, and one stops at the deployer. The case here plainly belongs to the second, since the breach concerns an obligation specific to the deployer. What makes the exercise hard in practice is the length of the value chains, one system often embedding others, so that classifying each party is argued before liability even arises. The contract between them organizes their recourse; it does not redistribute the obligations the regulation attaches to each role.
Glossary entry →6. A public body brings a social decision-support system into service and must carry out a fundamental rights impact assessment. How does it differ from the conformity assessment borne by the provider?
It addresses the system's effects in its context of use, not its design
The two exercises look alike in form and differ in object, and confusing them leads to believing an obligation met when it is not. The conformity assessment looks at the system itself: its design, documentation and robustness, and it falls on whoever places it on the market. The fundamental rights impact assessment looks at what the system will produce where it is to be used, on the people subjected to it, and it falls on the deployer: discrimination, intrusion on privacy and dignity, access to services. The same model, perfectly compliant, can therefore be harmless in one setting and troubling in another, which is precisely why the second assessment exists. It is due before deployment, making it a piece of use design rather than an after-the-fact check, and it draws on the data protection impact assessment the general regulation already knew. It targets in particular public bodies and certain private operators supplying essential services, which makes it directly relevant to part of the financial sector.
Glossary entry →7. An insurer automatically declines a policy on the sole basis of an algorithmic score. Article 22 of the GDPR, which predates the AI regulation, already applies. What does it require?
The right to obtain human intervention, to state one's view and to contest
The AI regulation is often discussed as if it inaugurated the framing of algorithmic decisions in Europe, and that is inaccurate: Article 22 of the General Data Protection Regulation has done so since 2018. It covers decisions producing legal effects or significantly affecting a person where they are based solely on automated processing, with no real human involvement. The principle is that the person has the right not to be subject to such a decision, with framed exceptions, and in all cases enjoys safeguards: to be informed, to obtain human intervention, to state their view and to contest. Two points carry the text's whole reach. The word solely is the pivot: a formal human sign-off that approves without being able to decide otherwise does not take the case out of scope, and that is where real compliance is settled for most arrangements. And recital 71 cites the automatic refusal of an online credit application and e-recruiting, insurance following the same logic, meaning an insurer automating underwriting or cancellation falls under both regimes at once, this one and the AI regulation.
Glossary entry →8. An operator trains a robot already in service on a new task, creating a hazard that did not exist before. The European machinery regulation draws a consequence. Which?
They become the manufacturer of the modified machine, with the duties that follow
Whoever modifies a machine in a way that creates a new hazard becomes the manufacturer of the modified machine, and inherits the whole set of duties that follow: conformity assessment, technical file, declaration and marking. The rule existed in substance under the earlier regime, it is now defined, and above all it expressly covers digital modifications as much as physical ones. The difficulty lies in applying it to a learning system, and it is not theoretical: does training a robot on a new task, loading a control policy supplied by a third party, or allowing continuous learning in operation amount to a substantial modification? The criterion given, the appearance of a new hazard, presupposes knowing what the machine will do afterwards, which is precisely undetermined. The insurance consequence deserves seeing whole, because it surprises operators: a loss that would have fallen under general liability shifts to product liability, a regime many machine users do not know since they do not think of themselves as manufacturers. Classifying the operator, before classifying the damage, is therefore the file's first question.
Glossary entry →9. In 2025 the European Commission withdrew its proposed directive on AI liability, which was to introduce causation presumptions and access to evidence. What is left to victims?
National law and the revised product liability regime
The withdrawn proposal targeted a point the other texts do not address: not what must be done to comply, but how a victim establishes the link between a system and their damage when they cannot look inside it. To that end it provided causation presumptions and mechanisms for access to evidence. Its withdrawal, announced in 2025 for want of consensus and amid regulatory simplification, leaves AI civil liability to national law and to the revised product liability regime. What that means, and does not mean, is worth measuring. It is not a vacuum: the revised regime now covers software, it is strict, and its presumption of defectiveness answers part of the evidential difficulty. But it covers damage caused by a defective product, and leaves outside its scope situations the withdrawn directive addressed, notably purely non-material damage or damage flowing from use rather than defect. The AI regulation itself organizes no compensation: it is a market-placing text, whose breach is sanctioned by fines rather than by making good a loss. The practical consequence is that the applicable regime will depend on the country as much as on the facts.
Glossary entry →