AI Integrator Product Liability | ProductLiability.help

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Integration can affect both safety and legal role

An AI integrator brings models, software, data and operational controls together. Its potential product liability depends on what it actually develops, supplies, brands or modifies, and how an alleged defect causes covered harm. Integration is not a universal statutory role carrying automatic liability. The AI product liability framework explains why the relevant product, expected safety, economic operator and causal chain must be established separately.

An integrator could build a finished software product, incorporate an AI component into a physical device, or provide technical installation services for someone else's product. Those activities should not be treated as equivalent. Identify the deliverable, the entity under whose name it was supplied and the control retained over its operation. A project invoice saying integration services is relevant evidence, but it does not conclusively determine the legal classification.

Describe the assembled product

Start with the operational architecture. Record the model, application, connectors, sensor inputs, retrieval sources, output processing and human controls. Identify which parts existed before the integrator's work and which it added. A visual interface may conceal important decisions such as converting a model's confidence score into an automatic command or routing an answer to a safety-critical workflow.

Then preserve specifications and acceptance records. What use was the finished arrangement intended to support? Which limits were communicated? Who decided the fallback behaviour when the model failed, the network disconnected or an output was uncertain? The alleged defect may concern the assembly of otherwise functional parts. Treating each component as individually operational does not answer whether their combined behaviour provided the expected safety.

Test the manufacturer definition

Article 4 of Directive (EU) 2024/2853 defines manufacturer by activities including development, manufacture, having a product designed or manufactured and presenting oneself as manufacturer through branding or another distinguishing feature. An integrator supplying its own branded AI application may therefore require analysis as a manufacturer. The conclusion depends on the actual product and activities, rather than on whether the business calls itself a consultant.

Article 8 also addresses component manufacturers and final-product manufacturers. Where a defective component integrated or interconnected within the manufacturer's control causes the product to be defective, the component rule can become relevant without removing the final manufacturer's responsibility. The provider and application developer comparison helps distinguish an upstream model issue from safety decisions introduced in the integrator's application layer.

Later changes have a separate test

An integrator can also work on a product already supplied by another manufacturer. Article 8 treats a person who substantially modifies a product outside the manufacturer's control and subsequently makes it available on the market or puts it into service as its manufacturer. The Directive defines substantial modification by reference to relevant product safety rules or, in their absence, specified changes in performance, purpose or type and risk.

Do not equate every new prompt, connector or model version with substantial modification. Record the before-and-after function and risk, whether the original design assessment foresaw the change and who authorised it. A change within the original manufacturer's control raises different questions from a change outside that control. Preserve both the technical modification record and the facts of subsequent supply or use.

Integration evidence should follow the failure pathway

Suppose an AI component generates a recommendation that an integrator's rules engine turns into a device command. The investigation needs the original recommendation, the conversion rule, the command issued and the device's response. A screenshot of the final output may omit the step that introduced the safety risk. Conversely, an apparently risky output may have been blocked before it could cause harm.

Preserve realistic test scenarios, error handling, fallback rules and evidence of human oversight. Include failed tests and unresolved limitations alongside successful demonstrations. Compare the incident environment with the conditions used during acceptance testing. A system tested only with clean inputs may behave differently with missing sensors or stale data. Those differences are factual leads, not independent findings of legal defectiveness.

Responsibility still requires scope and causation

The corrected Directive covers products placed on the market or put into service after 8 December 2026, while national transposition is due by 9 December 2026. Check the applicable national legislation rather than assuming that a project completed in a particular year automatically falls within the new framework. Record supply, modification and incident dates separately.

Article 6 defines the covered harm categories and exclusions. Article 10 requires proof of defectiveness, damage and causal connection, subject to defined rebuttable presumptions. An integrator's involvement does not eliminate those elements or make every failed deployment a product liability case. A useful assessment links the integrator's concrete decisions to the relevant product, safety expectation and mechanism of harm, while preserving evidence that may support another explanation.

Handover documentation also matters. Record which controls were delivered enabled, which settings the customer could change and what training accompanied the system. If a safety function depended on a customer action, establish whether that dependency was clearly communicated and feasible in the operating environment. These details help distinguish the integrated product as supplied from its later use. They do not establish that either the customer or integrator must necessarily bear the resulting loss.

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.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.