When an automated system produces a harmful outcome, the question of who answers for it has no settled answer. The difficulty is structural: the chain from model to harm passes through several parties, each of whom controlled only part of it.
The chain has at least three links
A model is built by one organisation, incorporated into a product by another, and operated by a third within a particular workflow.
The builder chose the training data and the safety behaviour. The integrator chose the prompts, the permissions and where outputs are shown.
The operator chose to rely on the result, and often to rely on it without checking.
Each decision contributed. Isolating one as the cause requires an argument, and every party has a plausible version pointing elsewhere.
Product liability assumes a defect
Traditional product law asks whether an item was defective, meaning it failed to perform as a reasonable consumer would expect.
A brake that fails is defective. A model that produces a confident wrong answer is doing what such models do, and the documentation says so.
If the stated behaviour includes fallibility, the argument that the product was defective becomes weak, and liability drifts toward whoever relied on it.
That outcome places the burden on the party with the least information about why the system behaved as it did.
Contracts push risk down the chain
Commercial terms for model access typically disclaim responsibility for outputs and require the customer to indemnify the provider.
The integrator, facing the same exposure, passes comparable terms to its own customers.
By the time the chain reaches an individual, the accumulated disclaimers may leave nobody contractually responsible for the outcome at all.
Consumer protection law limits how far this can go, and the limits vary by jurisdiction, which means the same failure has different answers in different countries.
Negotiating power decides most of it. A large enterprise can strike the indemnity clause; a small business signs the standard form.
Professional duties do not transfer
Where a regulated professional is involved, the answer is clearer and less comfortable for them.
A doctor, lawyer or engineer carries a duty of care that belongs to the person, not to the tools they use.
Using a system that produced a wrong recommendation does not discharge that duty, and courts have generally treated tools as instruments rather than as co-decision-makers.
This makes professionals cautious in a way that the tools' marketing does not anticipate, and it explains why adoption in regulated fields lags demonstrations.
Autonomy weakens the operator defence
The analysis changes when a system acts rather than advises.
An agent that sends messages, moves money or changes records has produced an outcome without a human decision in between, and the operator cannot be said to have relied on anything.
Responsibility then rests more heavily on whoever configured the permissions and limits, because those choices were the last meaningful control.
This is why the practical governance question is rarely about the model and usually about what the deployment was allowed to touch.
Causation is difficult to establish
Litigation requires showing that the system caused the harm, and reconstruction is hard after the fact.
Model behaviour varies between identical requests, the version in use may have been replaced, and the surrounding prompt may not have been recorded.
Without logs of the exact inputs, outputs and configuration at the time, the claimant may be unable to demonstrate what actually happened.
Retention of that record is therefore becoming a legal requirement in some sectors, which changes what deployments have to build before they launch.
Regulation is moving toward the deployer
Emerging rules in several jurisdictions place obligations on whoever puts a system into use in a high-consequence setting.
The reasoning is that the deployer knows the context, chose the application and is positioned to monitor for harm, while the model builder knows none of the specifics.
Builders carry separate obligations around documentation, testing and disclosure of limitations, which are the things they alone can provide.
The division is imperfect but coherent: the builder is accountable for what the system is, the deployer for what it is used to do.
Insurance will settle it before the courts do
Most disputes will not reach judgment. They will be resolved by whether an insurer paid.
Underwriters are already asking deployment questions — what the system decides, what human review exists, what is logged — and pricing accordingly.
That pressure produces standards faster than legislation, because a company that cannot obtain cover cannot proceed regardless of what the law permits.
The practical answer to who is liable is therefore being written in policy schedules and exclusions, and it is being written now, well ahead of the case law that will eventually confirm or overturn it.