Why the distinction matters
An AI model and an AI system are different technical units, and an investigation should identify both before assigning product liability roles. A model may supply predictive or generative capability. A system combines that capability with software, interfaces, instructions, data sources and operational controls. Directive (EU) 2024/2853 includes software and intangible components within its framework, but the words model and system do not themselves decide whether a particular supplier is liable. The broader AI product liability analysis connects classification with safety, damage and evidence.
Consider a model used in two applications. One application displays suggestions for review; the other automatically controls a device. Identical model outputs can have different safety implications because integration, safeguards and foreseeable use differ. An assessment that stops at the model name may overlook the actual source of the risk. Conversely, looking only at the interface may hide a defect originating in an upstream component.
Map the technical layers
Begin with the model identifier and distinguish it from a product name. Record the weights or hosted model version where available, inference implementation, application release, retrieval sources, system instructions and relevant configuration. A model alias that silently resolves to a newer release is weaker identification than a fixed version. Where a supplier will not expose internal details, preserve the identifiers and contractual descriptions that are available.
Next identify the decision pathway. An input might pass through preprocessing, a model, an output filter and a rules engine before reaching a user or actuator. Each transformation may affect safety. A dangerous command could arise from the base model, application instructions, a conversion error or a missing safety check. A technical diagram is useful only if it records the deployed arrangement rather than the intended architecture in an outdated design document.
Product and component are functional legal questions
Article 4 defines a product to include software. A component can be tangible or intangible, including a related service, when integrated into or interconnected with a product. Whether a model supplied in a particular arrangement is the relevant software product or component requires examination of its function and supply. The AI Act's separate treatment of general-purpose AI models assists regulatory classification but does not replace the Directive's definitions.
Article 8 addresses a defective component that was integrated into or interconnected with a product within the manufacturer's control and caused that product to be defective. The finished-product manufacturer's responsibility is not erased merely because an upstream component contributed. Equally, identifying a model supplier does not prove that its component was defective or caused the finished system's safety failure. Preserve the evidence connecting the alleged failure to the relevant layer.
Do not copy roles from the AI Act
Regulation (EU) 2024/1689 defines AI systems and provider and deployer roles for its own purposes. Its regulatory architecture distinguishes general-purpose AI models from the systems using them. Those distinctions help explain why a model can be supplied upstream of an application, but an AI Act provider label cannot automatically establish a Product Liability Directive manufacturer role.
An application company may develop the surrounding software and place a branded system on the market. A different company may supply the model or a hosted capability. An integrator may change the purpose, configuration or operating environment. Assess what each entity actually made, supplied, branded or modified under the relevant instrument. The comparison of providers and application developers examines this actor mapping without assuming that one regulatory title determines every legal outcome.
Version boundaries affect causation
A safety test of model version A does not necessarily describe an incident involving version B, even if the public product name remained unchanged. Changes to retrieval data, prompts or application code can also alter behaviour without changing the model weights. Keep a chronology separating model changes from application releases, configuration changes and operating conditions. This makes a claim about a particular defect testable.
Reproducing an output later may help, but failure to reproduce it does not establish that the original record is wrong. Sampling settings, external tools and data sources can vary. Nor does successful reproduction establish liability without the relevant safety and harm analysis. Preserve the original event evidence and describe which aspects of a later experiment match, differ or cannot be reconstructed. Distinguishing observation from reconstruction is especially important with remotely supplied models.
Dates, harm and proof remain separate
The corrected Directive's scope concerns products placed on the market or put into service after 8 December 2026, with national transposition due by 9 December 2026. Record dates for the relevant supplied product rather than assuming every model update restarts every legal period. If a substantial modification is alleged, document what changed and who controlled it before drawing a legal conclusion.
Finally identify covered damage and the causal chain. A model's limitations may be technically important while the claimed loss falls outside Article 6. Article 10's complexity-related presumption requires its specified conditions and remains rebuttable. A precise model-to-system map supports those legal questions; it does not replace them. The strongest map connects each technical layer to an identifiable supplier, release, safety function and piece of evidence.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Incident-time model, application and configuration identifiers
- Relevant inputs, outputs and decision records
- Supplier roles and change-control history
Independent educational information at EU Directive level. National implementing law and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.