AI and Product Liability: Who Answers When It Is Wrong

Product liability increasingly reaches software and AI systems, which changes who answers when something causes harm. The revised EU regime is explicit about it. This guide covers what that means in practice, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

How does defect apply to an AI system?

Through the safety a person is entitled to expect, which depends heavily on what you said it does.

Factor	How it affects the assessment
Product presentation	Claims set the expectation
Reasonably foreseeable use	Includes misuse you should have anticipated
Stated limitations	Shift expectations if genuinely communicated
Testing performed	Evidence of reasonable care
Post-market monitoring	Expected, and evidenced
Updates and learning	Can introduce defect after release

Why do product claims matter so much?

Because they set the safety expectation against which defect is judged.

A system marketed as detecting a condition is judged against that claim. The same system described as surfacing information for a professional to evaluate is judged against a different one. That makes marketing language a liability decision, and it is worth reviewing claims with that framing rather than only a regulatory one.

How do updates affect liability?

The revised regime contemplates defects arising after a product is placed on the market, including from updates and from machine learning within the manufacturer's control.

That makes version records and post-market monitoring directly relevant rather than merely good practice. A manufacturer that cannot say what changed, when, and what testing preceded it is in a weak position when something goes wrong after an update.

What reduces exposure?

Documented testing against realistic and adverse conditions, limitations stated where users will see them, human oversight where consequences are serious, and post-market monitoring that catches problems before users report them.

The last one is underrated. An organisation that detected a degradation and acted is in a materially different position from one that learned about it from a claim.

What evidence do you need?

Testing evidence covering realistic and adverse conditions, records of what limitations were communicated and where, version and change records, post-market monitoring results, and incident records showing what was done in response.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes adverse-condition testing and monitoring into the delivery plan. Testing that covers only expected inputs is evidence of limited value; testing that covers the conditions a reasonable engineer would anticipate is evidence of care.

It also argues for conservative behaviour at the edges: a system that abstains when uncertain is safer and easier to defend than one that produces a confident answer for every input. See what is abstention in ai.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Marketing capability beyond what testing supports. Burying limitations where nobody reads them. Shipping updates without testing records. And monitoring availability while ignoring output quality.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

Who in the chain carries the risk?

It depends on role and jurisdiction, and it can reach manufacturers, importers, and in some cases those who substantially modify a product.

For AI specifically, an organisation that fine-tunes or substantially modifies a third-party model may find itself in a manufacturer position for the resulting system. That is worth establishing before a programme is well advanced. See EU AI Act GPAI obligations.

What should you do first?

Read your own product claims as though you were assessing them against what your testing actually demonstrates. Gaps there are the cheapest exposure to close.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: testing extended to adverse and edge conditions rather than expected inputs, limitations communicated where users see them, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and insurance coverage.