What is AI liability?

How it works

<strong>Liability starts with harm, not with the model name</strong>

AI liability is not triggered merely because a tool uses machine learning or generative AI. It arises when a person, business or public body can point to a legally recognised harm and connect that harm to a defect, a failure of reasonable care, an unfair or misleading practice, a discriminatory act, or a breach of a sector rule. The label "AI" matters because it affects proof and governance, but it does not create a universal cause of action on its own.

This is why one incident can produce several legal questions at once. A claimant may want compensation. A regulator may want the practice stopped or changed. A supplier and deployer may argue over indemnities and responsibility inside their contract. An insurer may then ask whether the event falls inside policy cover.

<strong>Claims usually travel through existing legal routes</strong>

Product liability is one route. Here the focus is the product or software itself. In the EU's revised product liability regime, software and AI systems count as products, and liability can continue where defects appear after an update or through continuous learning that remains under the manufacturer's control. That route is mainly about defect and causal connection, rather than proving fault.

Fault-based claims, including negligence-style claims, ask a different question: did someone fail to act with reasonable care in design, testing, deployment, monitoring, warning, human oversight or response? This route becomes important where the dispute is about how a system was built, configured or used rather than whether it was a defective product.

Consumer and contract law add another route. If an AI-enabled service gives inaccurate information, is marketed beyond what it can reliably do, or is used in a way that is unfair to consumers, liability may arise through ordinary consumer protection and contractual duties. Rights-based and public law routes can also matter, especially in employment, biometrics, privacy and other regulated settings.

<strong>Responsibility can attach to more than one actor</strong>

The original model developer is not always the only actor that matters. A product manufacturer may package the system under its own name. A deployer may decide the use case, the thresholds, the review process and whether staff must rely on or challenge the system. A service provider may fine-tune, host or continuously update the model. In some regimes, importers, authorised representatives, fulfilment providers and certain platforms can also be drawn into the liability chain.

The practical lesson is simple: responsibility follows role, control and legal duty. If a manufacturer keeps control over updates, patches or post-release learning, upstream liability can remain important. If an employer, retailer, hospital or public authority chooses the setting, the human workflow and the action taken on the system's result, downstream liability can be just as important.

Internal contracts still matter, but mainly for cost allocation between businesses. They do not automatically wipe away responsibilities owed to workers, consumers, patients or regulators.

<strong>Causation and proof are often the hardest part</strong>

AI complicates proof because behaviour may depend on data quality, deployment context, model changes, third-party components and human handovers. A harmful result may come from several small failures rather than one obvious bug. That makes it harder to show what specifically caused the harm, or to show that a business acted reasonably.

This is one reason AI governance records matter so much. Evidence such as intended use statements, version history, data provenance where available, test methods, known limits, user notices, complaint handling, monitoring records and incident reports can make or break a case. The revised EU product liability rules now include access-to-evidence mechanisms in national court proceedings, which reflects how central proof problems have become in digital and AI disputes.

In practice, liability is often shaped by what an organisation can document after the event. If you cannot explain what was deployed and how it was controlled, both defence and redress become harder.

<strong>AI-specific governance does not replace ordinary liability law</strong>

Standards and governance frameworks do not create automatic immunity. NIST's AI RMF is voluntary and risk-based, and its value lies in structuring governance around harms, accountability, transparency and ongoing management. NIST's generative AI profile adds practical emphasis on legal and regulatory requirements, pre-deployment testing, content provenance and incident disclosure. Those activities do not answer liability by themselves, but they shape the evidence available when liability is disputed.

The same is true for AI-specific regulation. New AI rules may create documentation, transparency and monitoring duties, yet compensation and fault questions often still run through ordinary product, consumer, labour, privacy and negligence law. In Europe, that point is especially important because the 2022 AI Liability proposal did not become law. In the Commission's 2025 work programme, it was listed as having no foreseeable agreement, with the Commission saying it would assess another approach. So the central legal picture remains one of adaptation, not full replacement.

<strong>Sector rules can change both the standard of care and the remedy</strong>

Once AI is used in a supervised field, general liability analysis is only part of the story. Employment is a clear example. If hiring software screens people out in a discriminatory way, the fact that software did the first pass does not remove the employer's responsibility. In US enforcement, the EEOC has treated automated discrimination as ordinary discrimination carried out through new tools.

Health care is another strong example. For AI-enabled medical devices, the FDA expects lifecycle documentation, evidence supporting safety and effectiveness, and post-market performance monitoring. That means liability arguments in health settings are often shaped by what the device sponsor documented before release, how it manages changes, and whether users were given information appropriate to the context of use.

The wider lesson is that supervised domains usually have a thicker evidence base. Sector regulators often make the expected standard of care more concrete, which can sharpen both prevention and later disputes.

<strong>Good governance creates legal evidence</strong>

The most durable way to think about AI liability is to treat governance artefacts as future evidence. Useful records include AI inventories, intended use statements, role allocation, supplier due diligence, documented tests, model and system change controls, logs, user notices, operator training, complaint channels and incident escalation paths. Good recordkeeping turns a vague story into a defensible chronology.

This is also where assurance and audit matter. They do not replace legal analysis, but they test whether the documentation is complete, current and usable under pressure. If harm occurs, those records shape arguments about reasonable care, causation, apportionment and remedy. If the records are poor, liability risk becomes evidential as well as legal.