Liability: Who Is Responsible When AI Causes Harm

There is no legal vacuum here. Harm caused with the help of software has been litigated for decades under doctrines that long predate this technology, and the interesting questions are about how those doctrines fit — not about whether anything applies. Nothing on this page is legal advice.

The theories that already exist

Is a model a product?

This is the doctrinal hinge and it is worth understanding why it matters so much. Strict product liability removes the requirement to prove that anyone behaved unreasonably. The claimant shows the product was defective and caused the harm. When the mechanism is opaque and the defendant’s internal process is not visible, removing the fault element is close to determinative.

Product liability regimes were written for manufactured goods. Whether software is a product has been argued for decades, with a common distinction between software embedded in a physical thing — usually treated as part of the product — and software supplied on its own, more readily characterised as a service. A model accessed over an API sits at the far end of that spectrum, which is why several reform efforts have proposed to say explicitly that software and digital services count.

The arguments run both ways and both are serious. For inclusion: claimants cannot realistically prove fault in a system whose behaviour is not deterministic and whose development they cannot observe, and the policy rationale for strict liability — that the party best placed to prevent and to insure against a defect should bear it — applies with full force. Against: strict liability was justified for mass-produced items where a defect is a deviation from a specification, whereas a general-purpose model has no specification to deviate from, its outputs depend on inputs the developer never sees, and the doctrine risks imposing liability for unforeseeable uses.

Three defect theories, applied

Manufacturing defect — the item departs from its own design. There is essentially no analogue: every copy of a weight file is identical. The nearest thing is a serving fault, a wrong quantisation, a corrupted deployment, and that is better analysed as ordinary negligence in operations.

Design defect — the design itself is unreasonably dangerous. In most formulations this is a risk-utility test, frequently requiring the claimant to identify a reasonable alternative design that would have prevented the harm without unduly impairing the product. Applied to a model, this is where evaluations, safety training, guardrails, refusal behaviour and published mitigations all become evidence — of what was feasible, what was known, and what was chosen not to do. The practical implication is uncomfortable and worth stating: the safety literature simultaneously defines the achievable state of the art and thereby defines what a defendant can be criticised for omitting.

Failure to warn — the risk was known and inadequately communicated. This is the theory model cards and documentation speak to. Its limits are well established in other industries: a warning buried in terms nobody reads is weak, warnings do not excuse a design that could have been made safe, and over-warning dilutes. A warning also does less where the user cannot act on it, which is often the position of an end user several layers downstream.

Causation is the real battleground

Doctrine gets the attention; causation and evidence decide the cases. The claimant must show that the output caused the harm, which runs into three practical obstacles.

The output is usually not reproducible: sampling is stochastic, the model version has moved, and the system prompt has changed. Without a log there may be no admissible record of what was actually generated. The relevant information — training data, evaluation results, internal risk assessments — is held by the defendant. And intervening acts break the chain: a human reviewed it, a deployer configured it, a user ignored a warning.

This is why the most consequential provisions in proposed liability regimes are procedural rather than substantive. A disclosure duty requiring a defendant to produce documentation, or a rebuttable presumption of causation once a claimant shows non-compliance with a safety obligation, changes who bears the burden of unresolvable uncertainty. That single mechanism reallocates more risk than any argument about whether software is a product.

Who in the chain actually bears it

Developer, fine-tuner, integrator, deployer, professional user. The default pattern is that whoever had the relationship with the injured party is sued first, then seeks to pass the loss upstream. So the effective allocation is set by the contracts: indemnity scope, liability caps, whether outputs are warranted at all — they generally are not — who owns the obligation to filter, and whose acceptable use policy governs.

Note also that substantial modification usually shifts responsibility. A party that fine-tunes a model, or deploys it for a purpose the developer excluded, tends to assume the position of a producer for that modified thing under several regimes. This is the provision most likely to surprise an organisation that thought it was a customer.

Independent of jurisdiction, four things change exposure: logging that preserves what was actually generated and with what configuration; a human decision point where the harm becomes irreversible; scoping the permitted use and enforcing it rather than merely stating it; and insurance that has been read against the actual deployment. This page describes the shape of the arguments only; liability law differs substantially between jurisdictions and is changing. Take advice.

A final point on why this matters beyond litigation. Liability rules are a pricing mechanism: they decide whose budget absorbs a harm, and therefore who has an economic reason to prevent it. A rule that puts loss on the party least able to reduce it produces insurance rather than safety, and a rule that puts it on the party best placed to change the system produces engineering. That is the substantive question underneath the doctrinal one, and it is the one worth arguing about.