Two descriptions can refer to different legal roles
An AI provider and an application developer may supply different parts of the same product, but neither description alone decides product liability. A model supplier can provide an upstream capability while an application developer builds the interface, instructions, safeguards and decision pathway used by customers. Directive (EU) 2024/2853 requires analysis of the actual product and economic operator. The AI product liability framework explains the separate requirements of defectiveness, damage and causation.
Provider is also a defined role under Regulation (EU) 2024/1689, the AI Act. Its meaning belongs to that Regulation's compliance framework. A business can be an AI Act provider and a manufacturer under the Product Liability Directive, but that conclusion must be reached under each instrument's definitions. Do not assume that identifying a regulated provider answers who manufactured the allegedly defective application or component.
Establish what each business supplied
Map the upstream model, inference software, hosted endpoint, application code and finished interface. Then identify who developed, supplied and branded each item. An application may use a model through an API without receiving the weights. Another developer may fine-tune an openly supplied model and distribute the resulting software. These arrangements create different evidence questions even when the screen shown to users looks similar.
Release records and contracts can reveal which business approved changes, specified permitted uses and controlled the system's safety measures. Preserve documentation that applied at the time of the incident. Current website descriptions can differ from earlier promises and limitations. A contract's allocation of support or indemnities can help explain the relationship, but it does not automatically decide the statutory rights of a person injured by the finished product.
Locate the alleged safety failure
The investigation should distinguish a defect allegedly present in an upstream capability from one introduced by application design. A model might produce uncertain predictions that an application labels as authoritative instructions. A developer might remove a warning, disable a filter or connect a general-purpose output directly to machinery. Alternatively, a supplier might provide a component whose behaviour is unsafe within its specified use.
Article 7 examines all relevant safety circumstances, including presentation, reasonably foreseeable use, interoperability and learning behaviour. Its test is not satisfied merely by showing that an application used a third-party model. Nor can an application developer establish safety simply by saying the model was externally supplied. Compare the actual incident pathway with the intended design and the safety measures that were reasonably relevant to that pathway.
Understand the component rule and its limits
Article 8 addresses the manufacturer of a defective component where integration or interconnection within the manufacturer's control caused the finished product to be defective. It also preserves the finished-product manufacturer's responsibility. Establishing an upstream relationship is therefore only the beginning. Evidence must connect the component's defectiveness to the finished product's lack of expected safety and the resulting harm.
Article 11 provides a component-related exemption where the product's defectiveness is attributable to its design or the instructions given by its manufacturer to the component manufacturer. Interface requirements, prohibited uses and integration decisions can matter here. An instruction is evidence to assess in context, rather than an automatic defence against every foreseeable application. The AI integrator analysis considers the organisation that assembles these parts into an operational system.
Updates can move the factual boundary
A model supplier may change a hosted model while the application developer retains the same public version number. An application developer may change prompts or retrieval data while the model remains fixed. Record both histories. Without them, investigators may attribute a dangerous result to the wrong release or confuse a later correction with the original system's behaviour.
Manufacturer control under Article 4 and Article 11's rules on later software-related defects can affect a defence based on when defectiveness arose. They do not create automatic liability for every update. Identify who supplied, authorised or could supply the relevant change, whether it affected safety and whether it contributed to the alleged harm. A helpful chronology records the responsible decision-maker and supporting evidence for each step.
Keep harm, proof and timing distinct
Pure commercial disappointment is not automatically Article 6 damage. The Directive addresses specified injury, property and data damage categories with exclusions. For example, a lost sales opportunity following a poor AI recommendation differs from injury caused by an unsafe control instruction. Both may be serious, but the available legal routes and necessary proof are not interchangeable.
Under Article 10, the claimant ordinarily proves defectiveness, damage and causation. Disclosure and conditional rebuttable presumptions can assist in defined circumstances; upstream opacity alone does not determine liability. The corrected product scope begins after 8 December 2026, separately from the 9 December 2026 transposition deadline. Preserve the supplied versions, relevant dates, role evidence and competing causal explanations so that the applicable national framework can be examined without relying on job titles.
Where suppliers disagree about the source of a failure, retain each account and the documents it relies on. A support response blaming an upstream model and a model supplier blaming integration are competing explanations. Compare them against the actual deployment and event sequence. Attribution becomes stronger when an explanation identifies a reproducible mechanism and weaker when it rests only on the other company's position in the supply chain.
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.