The AI Liability Chain: Who Is Responsible When an AI Output Causes Loss?

An AI system may generate the answer, but the law still looks for a human or organisation that designed, deployed, adopted or acted upon it.

A customer relies on incorrect information supplied by a company’s AI chatbot and loses money. A lender rejects an applicant because an automated system produces an inaccurate credit score. A lawyer files fictitious judgments generated by an AI tool. A business uses an AI agent that places an incorrect order or discloses confidential information.

In each case, the immediate explanation may be that “the AI made a mistake.” Legally, however, that is usually only the beginning of the inquiry.

Present liability systems generally do not treat an AI system as an independent legal person capable of bearing responsibility. Instead, the law asks:

• Who selected and deployed the system?
• Who controlled the data, instructions and safeguards?
• Who communicated or adopted the output?
• Who could reasonably have prevented the loss?
• Was the loss caused by a defective system, negligent deployment, unreasonable reliance or misuse?
• What did the contracts between the different parties provide?

The result is not a single point of liability but an AI liability chain.

The central distinction: outward liability and inward allocation

Every AI-loss dispute contains two separate questions.

The first is the external liability question: who can the injured person sue?

The second is the internal allocation question: can the organisation that compensates the injured person recover that amount from its AI vendor, integrator, data provider or another participant in the supply chain?

A customer ordinarily has no contractual relationship with the developer of the foundation model operating behind a company’s chatbot. The customer will therefore usually proceed first against the company whose website, employee, product or decision caused the loss. That company may subsequently seek indemnification from the technology provider.

This produces a practical rule:

The party closest to the affected person may face the claim first, while the party with the greatest technical control may ultimately bear some or all of the loss.

Who sits in the AI liability chain?

1. The data provider

An AI system is influenced by the information used to train, fine-tune or supplement it. Liability may begin at the data layer where:

• personal data was collected or used unlawfully;
• inaccurate or outdated data was supplied;
• protected material was included without the necessary rights;
• the data provider breached a warranty concerning provenance or accuracy;
• biased or incomplete data produced a foreseeable discriminatory result.

A data provider will not automatically be liable whenever an AI output is wrong. The claimant must still connect the defective or unlawful data to the eventual output and loss. That can be difficult where multiple datasets, models and processing stages contributed to the result.

2. The foundation-model or AI-system provider

The model provider develops the underlying system. Its potential exposure may arise from:

• unsafe system design;
• inadequate testing;
• undisclosed limitations;
• misleading accuracy claims;
• defective updates;
• inadequate cybersecurity;
• failure to warn against foreseeable high-risk uses;
• failure to provide sufficient technical information to downstream deployers.

The revised European Product Liability Directive expressly brings software, including AI systems, within the modernised product-liability framework. It also responds to the evidentiary difficulty faced by claimants where the internal operation of a complex product is controlled by the manufacturer. The Directive must operate through Member State implementation and does not replace every contractual, privacy or national tort remedy.

Whether similar product-liability reasoning applies in India will depend partly on whether the AI offering is characterised as a product, a service or a combination of both.

3. The application developer or system integrator

Most organisations do not expose customers directly to a raw foundation model. An intermediary developer may connect the model to company databases, create prompts, establish retrieval systems, define decision rules and build the user interface.

The integrator can therefore create new risks even where the underlying model functions as intended. Examples include:

• connecting the model to an unreliable database;
• failing to limit the system’s permissions;
• designing prompts that encourage unsupported conclusions;
• omitting escalation to a human reviewer;
• failing to test foreseeable user questions;
• allowing an AI agent to execute transactions without approval;
• failing to preserve logs needed to investigate an incident.

The model provider may argue that the loss arose from improper integration. The integrator may argue that the model’s limitations were not adequately disclosed. The answer will depend heavily on technical evidence, contractual responsibilities and system logs.

4. The deploying business

The deployer is the organisation that decides to use the system in its operations. It may be a bank using automated credit assessment, a hospital using diagnostic support, an employer screening candidates or a retailer operating a customer-service chatbot.

For the affected person, the deployer will frequently be the most visible defendant because it:

• selected the use case;
• placed the system into operation;
• presented the output as part of its service;
• decided how much human review was required;
• controlled whether the output would be acted upon;
• benefited commercially from the automation.

The EU AI Act reflects this division by imposing separate obligations on providers and deployers of high-risk AI systems. The legislation regulates matters such as risk management, documentation, human oversight, monitoring and the allocation of responsibilities across the AI lifecycle. It is primarily a regulatory framework rather than a complete civil-compensation code.

5. The human professional or decision-maker

A professional cannot normally avoid an existing duty of care merely by saying that an AI tool supplied the incorrect answer.

This is especially relevant to lawyers, doctors, accountants, financial advisers, architects and other professionals whose work requires independent judgment. AI may assist the professional, but it does not ordinarily replace the professional’s obligation to verify material information before relying upon or communicating it.

In Mata v. Avianca, Inc., lawyers submitted fictitious judicial decisions and quotations generated through ChatGPT. The United States District Court imposed sanctions, emphasising that technological assistance did not remove counsel’s responsibility for verifying the material placed before the court.

The case does not establish that every inaccurate AI-assisted document creates liability. It establishes the more important proposition that the person who signs, files or adopts the output remains responsible for performing the verification required by that person’s professional role.

6. The end-user

An end-user may also cause or contribute to the loss by:

• using the system for a prohibited purpose;
• deliberately bypassing safeguards;
• concealing the intended use from the vendor;
• ignoring conspicuous warnings;
• manipulating the system to produce harmful output;
• relying on an output that was clearly presented as uncertain or incomplete.

Such conduct may reduce the damages recoverable, interrupt causation or shift responsibility away from upstream participants. A generic disclaimer, however, will not necessarily protect a provider or deployer where the system was marketed for the very purpose that caused the loss.

What the decided cases tell us

A chatbot is part of the business, not a separate legal entity

In Moffatt v. Air Canada, a customer relied on incorrect information supplied by an Air Canada chatbot concerning bereavement fares. The British Columbia Civil Resolution Tribunal rejected the suggestion that the chatbot was independently responsible. It treated the chatbot as part of Air Canada’s website and held the airline liable for negligent misrepresentation.

The decision is from a tribunal and does not create binding global precedent. Nevertheless, its reasoning is commercially significant: a business that places an AI interface before customers cannot ordinarily separate itself from the representations made through that interface merely because the words were generated automatically.

Human oversight must be meaningful, not ceremonial

In State v. Loomis, the Wisconsin Supreme Court considered the use of the proprietary COMPAS risk-assessment system in criminal sentencing. The Court permitted its limited use but required warnings and stressed that the score could not determine the sentence by itself. The judgment illustrates a recurring principle: where an automated output affects important rights, it should support rather than replace the legally responsible decision-maker.

A person who merely clicks “approve” without examining the material may not provide meaningful human oversight. The legal inquiry will examine whether the reviewer had sufficient authority, information, competence and time to disagree with the system.

An intermediate score can itself become an automated decision

In SCHUFA Holding (Scoring), C-634/21, the Court of Justice of the European Union considered a credit-reference agency that generated a probability score used by lenders. The Court held that generating the score could itself amount to automated individual decision-making under Article 22 of the GDPR where the recipient gave the score a determining role in its decision.

This is important for AI supply chains. A technology provider cannot always avoid responsibility by saying that it only supplied a recommendation. Where the recommendation practically determines the final result, the intermediate stage may attract direct legal scrutiny.

Explanation must help the person understand and challenge the decision

In Dun & Bradstreet Austria, C-203/22, the CJEU held that “meaningful information” about automated decision-making must explain the procedure and principles actually applied in a manner that enables the individual to understand and challenge the result. Merely supplying a complex formula or hiding the process behind a broad trade-secret claim is not necessarily sufficient. Legitimate confidentiality interests must instead be balanced through the competent authority or court.

For businesses, explainability is therefore not merely an engineering aspiration. In certain contexts, it can become part of the organisation’s ability to defend the legality and reasonableness of a decision.

The GDPR perspective: liability follows control over processing

The GDPR does not regulate “AI” as a single legal category. It regulates the processing of personal data. An AI system therefore engages the GDPR when personal data is used in its training, prompts, retrieval process, profiling, outputs or decision-making.

The controller cannot simply blame the processor

The organisation that determines why and how personal data will be processed will generally be the controller. A cloud, model or analytics provider may act as its processor, although some providers may become independent or joint controllers depending on their actual decisions concerning the data.

A processing agreement allocates obligations between the parties, but it does not automatically remove the controller’s outward accountability. The CJEU has held that a controller cannot escape liability under Article 82 merely by pointing to the negligence or failure of a processor or another person.

The controller must therefore conduct due diligence before deployment, issue appropriate instructions, examine whether the provider uses data for its own purposes, monitor the processing and maintain evidence of compliance.

Article 22 protects against certain solely automated decisions

Article 22 applies to decisions based solely on automated processing that produce legal effects or similarly significant effects. Subject to its exceptions, the provision requires safeguards including an opportunity for human intervention, the ability to express one’s position and the ability to contest the decision.

Not every AI-assisted decision is covered. A product recommendation or grammar correction will ordinarily be different from the refusal of credit, termination of employment, denial of insurance or another decision substantially affecting a person.

The label “human in the loop” is also not conclusive. Where the supposed human reviewer habitually accepts the AI recommendation, lacks authority to change it or does not understand how it was generated, a court or regulator may examine whether the decision was functionally automated.

A DPIA can become evidence of reasonable governance

Article 35 of the GDPR requires a Data Protection Impact Assessment where processing is likely to create a high risk to individuals. Professor Margot Kaminski’s research explains how the DPIA connects individual rights with systemic governance and can improve both accountability and explainability in algorithmic systems.

A meaningful AI impact assessment should identify:

• the affected individuals and possible forms of harm;
• the data and models being used;
• the likelihood of inaccurate or discriminatory results;
• the role of human reviewers;
• appeal and correction mechanisms;
• security and confidentiality risks;
• the evidence required to investigate future disputes.

A generic compliance document prepared after deployment will provide considerably less protection than an assessment that actually influenced system design.

A GDPR violation does not automatically produce damages

Article 82 permits compensation for material and non-material damage caused by an infringement. In Österreichische Post, C-300/21, the CJEU held that an infringement alone is insufficient: the claimant must establish an infringement, damage and a causal connection between them. At the same time, non-material damage does not have to cross an independently imposed minimum threshold of seriousness.

For an AI claimant, proving causation may remain difficult. The person must ordinarily show that the unlawful processing or automated decision caused the financial, reputational, psychological or other recognised harm claimed.

The wider EU liability framework

The EU AI Act allocates regulatory duties across providers, deployers, importers, distributors and other actors. The revised Product Liability Directive separately addresses defective products and expressly accommodates software and AI. The proposed standalone AI Liability Directive, which had sought to assist claimants through disclosure and causation presumptions, was withdrawn by the European Commission in 2025.

Consequently, AI-related loss in Europe is not governed by one comprehensive damages statute. Liability may emerge through a combination of:

• the GDPR;
• the revised Product Liability Directive;
• national contract and tort law;
• consumer-protection law;
• discrimination law;
• sector-specific financial, medical, employment or public-law duties;
• the AI Act’s regulatory obligations.

A violation of an AI Act obligation may become relevant evidence when a court considers defect, fault, foreseeability or the standard of care, even where compensation is claimed under another body of law.

The position in India

India does not presently have a standalone civil-liability statute dealing comprehensively with loss caused by AI systems. The current approach is therefore technology-neutral: the claimant must fit the harm within existing contract, consumer, data-protection, sectoral or public-law principles.

Contractual liability

Section 73 of the Indian Contract Act, 1872 permits compensation for loss that naturally arose from the breach or that the parties knew, when contracting, was likely to result from it. Remote and indirect losses are excluded.

In a business-to-business AI dispute, the central questions may include:

• what accuracy or performance was promised;
• whether the output was advisory or intended for operational reliance;
• whether the use fell within the agreed purpose;
• whether limitations were adequately disclosed;
• whether the customer followed required review procedures;
• whether the claimed loss was foreseeable;
• whether an exclusion, indemnity or liability cap applies.

Terms stating that outputs “may be inaccurate” are relevant, but they do not necessarily override a specific warranty, a misleading sales representation or an obligation to exercise reasonable skill.

Consumer and product liability

Chapter VI of the Consumer Protection Act, 2019 permits product-liability actions against a product manufacturer, product service provider or product seller for harm caused by a defective product. The Act identifies matters including manufacturing defects, design defects, deviation from specifications, failure to conform to an express warranty and inadequate instructions or warnings.

An AI-related consumer claim may alternatively be framed as deficiency in service or an unfair trade practice, depending on how the system was supplied and represented.

A recurring classification question will be whether a particular AI system is a product, a service or a composite offering. Downloadable or embedded software may present a stronger product character than access to a continuously changing cloud-based model. Until Indian courts address these distinctions directly in the AI context, claimants are likely to plead overlapping grounds.

The Digital Personal Data Protection Act

The Digital Personal Data Protection Act, 2023 creates an important accountability structure for AI processing involving digital personal data. However, its implementation is phased. Under the November 2025 commencement notification, many of the substantive obligations governing Data Fiduciaries are scheduled to commence eighteen months after Gazette publication and were therefore not yet fully operational in July 2026. The DPDP Rules, 2025 follow a similar staggered commencement structure.

Once the relevant provisions are operative, Section 8 will make a Data Fiduciary responsible for processing conducted by it or on its behalf by a Data Processor, irrespective of an agreement to the contrary. It also requires the fiduciary to take reasonable security safeguards. Where personal data is used to make a decision affecting a Data Principal, or disclosed to another fiduciary, the Act requires reasonable efforts concerning completeness, accuracy and consistency.

This is especially significant for AI-assisted lending, insurance, employment, health and platform decisions. A company may outsource the technical processing, but it will not be able to outsource its statutory position as Data Fiduciary merely through a vendor agreement.

The DPDP Act’s enforcement model centres primarily on Board-imposed monetary penalties. Those penalties are credited to the Consolidated Fund of India, rather than operating as a direct equivalent of the individual compensation claim available under Article 82 of the GDPR. A person seeking compensation may therefore still need to rely on other civil, consumer, contractual or sectoral remedies.

India’s AI Governance Guidelines, released in November 2025, additionally emphasise responsible development, data management, transparency and risk governance. They are important governance guidance, but they do not themselves replace the need to establish a recognised cause of action for compensation.

How should a court allocate responsibility?

A workable liability analysis should examine five factors.

1. Control

Who could change the model, data, prompts, permissions, interface or human-review process?

The greater the control over the source of risk, the stronger the argument for responsibility.

2. Commercial benefit

Who introduced the system to reduce costs, accelerate decisions or improve revenue?

The organisation obtaining the commercial benefit will often be expected to manage the corresponding operational risk.

3. Representation and reliance

Who placed the output before the affected person? Was it presented as authoritative, verified, advisory or experimental?

The stronger the representation and the more foreseeable the reliance, the harder it becomes to rely on a general disclaimer.

4. Ability to prevent harm

Which actor could most efficiently have prevented the loss through testing, warnings, access controls, human review or correction procedures?

This resembles the risk-management approach proposed in Andrea Bertolini’s European Parliament study, which considers placing responsibility on the actor best positioned to control and manage the technological risk.

5. Causation

Which failure actually produced the loss?

An inaccurate model output does not establish that the model provider caused the damage. The result may have arisen because the deployer supplied incorrect data, the integrator removed a safeguard, the employee ignored a warning or the claimant relied unreasonably on a provisional response.

The system’s logs, model version, retrieved documents, prompts, confidence indicators, human-review records and subsequent actions will therefore be central evidence.

What the research says

The academic debate has consistently identified information asymmetry and causation as the main barriers for people harmed by AI. The provider may possess the model documentation and logs, while the claimant sees only the final decision.

Andrea Bertolini’s European Parliament study recommends a risk-management approach under which responsibility is placed on the operator best able to control the relevant technological risk.

Andrew Selbst and Julia Powles argue that GDPR explanations should be functional: the information supplied must enable the person to understand the decision sufficiently to exercise legal rights and challenge the outcome.

Reuben Binns’ work on multi-stage profiling demonstrates why responsibility cannot always be understood by examining only the last step. A profile, score or recommendation generated earlier in the chain may effectively determine the later decision.

Philipp Hacker’s analysis of the proposed European AI liability directives focuses on evidentiary imbalance, presumptions of causation and the gaps that remain where claimants cannot access information needed to prove fault or defect. Although the standalone AI Liability Directive was later withdrawn, the evidentiary problem identified in the paper remains.

Research by Claudio Novelli, Federico Casolari, Philipp Hacker, Giorgio Spedicato and Luciano Floridi similarly examines how generative AI cuts across liability, privacy, intellectual-property and cybersecurity law, rather than fitting neatly within one regulatory category.

Contracts must map the entire chain

A conventional software agreement is often inadequate for an operational AI system. The contract should identify:

1. The permitted use case: What decisions may the system support, and which uses are prohibited?
2. Role allocation: Who is the provider, integrator, deployer, controller, processor or independent controller?
3. Performance standards: What testing, accuracy, reliability or service levels have actually been promised?
4. Known limitations: Which foreseeable errors, unsuitable contexts and dependency risks must be disclosed?
5. Human oversight: Which outputs require approval, and who has the authority and competence to reject them?
6. Logging and evidence: Which prompts, outputs, source documents, model versions and approval records must be retained?
7. Change management: Can the provider alter the model, training process or safety features without notice?
8. Incident response: How quickly must hallucinations, data leaks, discriminatory patterns and security incidents be reported?
9. Audit and testing: Does the customer have rights to conduct evaluations, red-team testing or independent audits?
10. Indemnities and liability caps: Which party bears claims arising from unlawful data, defective integration, IP infringement, cybersecurity failure or prohibited use?
11. Insurance: Do the parties maintain technology-errors, cyber, professional-indemnity or product-liability coverage appropriate to the use case?
12. Correction and appeal: Can affected persons obtain human review, correct underlying data and challenge the outcome?

These clauses allocate risk between the contracting parties. They do not automatically extinguish statutory rights available to consumers, data subjects or other injured third parties.

The practical rule

When an AI output causes loss, liability is unlikely to stop at the sentence: “the system generated it.”

The customer-facing organisation will often be the first target because it deployed the system, benefited from it and invited reliance on its output. The organisation may then proceed against the integrator or model provider if a defect, undisclosed limitation or contractual breach caused the problem. A professional who adopted the output without verification may bear independent responsibility. An end-user who misused the system may also contribute to the loss.

The most defensible rule is therefore:

Responsibility should follow control, reliance and the ability to prevent harm—not merely the location at which the incorrect output first appeared.

AI may make the chain longer and the evidence more technical. It does not make accountability disappear.

This article is intended for general informational purposes and does not constitute legal advice