The AI Indemnity Trap: Negotiating Liability When Third-Party Algorithms Hallucinate

Every founder who has embedded a third-party AI model into their product has read an indemnity clause that sounds reassuring. The vendor promises to indemnify against claims that its technology infringes a third party’s intellectual property. What that clause does not say, and what most founders do not notice until a claim lands, is that intellectual property infringement is a narrow slice of what can go wrong with a generative AI system. When the model hallucinates a wrong medical dosage, a false credit decision, a fabricated legal citation, or defamatory content about a customer, the same indemnity clause that felt protective on signing day usually does not apply. This is the AI indemnity trap, and it sits at the centre of nearly every AI vendor contract an Indian startup signs today.

What is the AI indemnity trap in vendor contracts?

The AI indemnity trap is the mismatch between what a founder believes an AI vendor’s indemnity clause covers and what it actually covers on a plain reading. Most AI vendor agreements, including those from the large model providers, promise to defend the customer against third-party claims that the vendor’s underlying model infringes copyright, patent, or trademark rights. That promise says nothing about the accuracy, reliability, or safety of the model’s output. A hallucinated fact, a fabricated case citation, an invented product specification, or a discriminatory recommendation is not an intellectual property claim. It is an output quality failure, and output quality failures fall outside the indemnity almost every time.

Founders fall into the trap because the word indemnity does a lot of psychological work. Once a contract contains an indemnity clause, founders tend to stop reading closely, assuming the vendor has accepted downstream risk. In reality, the scope of that indemnity is defined narrowly, the liability cap that governs everything else in the contract (typically twelve months of fees paid) still applies to any claim outside the indemnity, and consequential losses are usually excluded altogether. The founder discovers the gap only when a customer sues them, not the vendor, because the founder’s product is what the end customer actually interacted with.

Why does a standard AI indemnity clause not cover hallucinations?

A standard AI indemnity clause does not cover hallucinations because it is drafted around a different risk: the possibility that the model was trained on protected content without a licence. Vendors extended IP indemnities to reassure enterprise buyers after early copyright litigation against model developers made headlines. That commercial pressure did not extend to output accuracy, because accuracy is a much harder promise to make. A model provider cannot predict every hallucination in advance, and underwriting that risk at scale would require pricing the indemnity like an insurance product rather than a contract term.

Three structural reasons keep hallucination outside the indemnity fence:

• Defined trigger events. The indemnity typically triggers only on “a third party claim that the output infringes intellectual property rights.” A defamation claim, a negligence claim, or a regulatory penalty does not meet that trigger.
• Carve-outs for modified or fine-tuned output. If the customer fine-tuned the model, added a system prompt, or combined the output with its own data (which nearly every startup does), the vendor’s indemnity obligation is usually voided entirely under a standard exclusion clause.
• The overriding liability cap. Even where a claim survives the trigger test, most AI vendor contracts cap aggregate liability at fees paid in the preceding twelve months. For a startup paying a large model provider a few lakhs a month in API fees, that cap is nowhere near the size of a real-world harm claim.

The three-link liability chain when you embed a third-party model

Every startup that builds a product on top of a third-party AI model sits inside a three-link chain: the end customer who suffers the harm, the startup’s product that surfaced the AI output, and the model provider whose system generated it. Each link in that chain tends to assume the layer below is carrying the risk, and none of them is, unless the contract says so explicitly.

Link in the chain	Who they are	Default assumption	Actual exposure
End customer	The person who acted on the AI output (a patient, a borrower, a buyer)	Believes the platform is responsible for what it told them	Can sue the startup directly under contract, tort, or the Consumer Protection Act, 2019
Startup (the customer of the AI vendor)	The company that embedded the model into its product	Believes the vendor’s indemnity covers AI-related claims	Bears the claim first, since the end customer contracted with the startup, not the model provider
Model provider	The AI vendor whose model generated the output	Believes its terms of service and liability cap fully insulate it	Exposure limited to the narrow IP indemnity and the fee-based cap, rarely more

The end customer has no direct contractual relationship with the model provider. They contracted with the startup. That single fact means the startup is almost always the first, and often the only, defendant with deep enough pockets and a direct enough relationship to be worth suing. The model provider’s contract terms are irrelevant to the end customer’s claim against the startup; they only matter for whether the startup can recover anything back from the vendor afterward, and as the table above shows, that recovery path is narrow.

What Indian law governs liability for AI-generated errors?

No standalone Indian statute governs AI liability as of mid-2026, which means liability for an AI-generated error currently gets pieced together from four existing legal frameworks, each covering a different part of the harm.

Indian Contract Act, 1872. Sections 124 and 125 govern the indemnity clause itself. Under Section 124, a contract of indemnity is a promise to save the promisee from loss caused by the promisor’s conduct or the conduct of a third person, which in principle is broad enough to cover an AI vendor’s output. In practice, Indian courts enforce indemnity strictly according to its drafted scope (Gajanan Moreshwar v. Moreshwar Madan, AIR 1942 Bom 302, remains the leading authority on when an indemnity obligation crystallises). If the clause is drafted to cover only IP infringement, an Indian court will not read hallucination liability into it by implication.

Consumer Protection Act, 2019. Chapter VI, Sections 82 to 87, introduced product liability into Indian law for the first time, covering a product manufacturer, product service provider, or product seller for harm caused by a defective product or deficient service (Section 83, Consumer Protection Act, 2019). If a startup’s AI-powered service gives a customer materially wrong information that causes personal injury, property damage, or mental agony, that customer has a statutory route to claim compensation from the startup as the service provider, independent of what the startup’s contract with its AI vendor says. Section 84(2) is notable because it removes the requirement to prove negligence for manufacturer liability, a form of strict liability that Indian courts are still working out how to apply to software and AI services specifically.

Information Technology Act, 2000. Section 79 gives intermediaries a safe harbour from liability for third-party content, but that safe harbour is conditional on due diligence and applies to platforms hosting user content, not to a startup that actively deploys an AI model to generate its own product’s output. A startup using AI to generate underwriting decisions, medical triage suggestions, or legal drafts is not hosting third-party content; it is publishing its own product’s output, which places it outside Section 79’s protection.

Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025. Where an AI system processes personal data and hallucinates or mishandles that data (for example, fabricating a customer’s transaction history or exposing one customer’s data in another’s output), the DPDP Act’s obligations on data fiduciaries apply independently of the underlying contract, and liability for a data principal’s grievance sits with the fiduciary, not automatically with any data processor engaged under a service agreement. The Digital Personal Data Protection Rules, 2025 were notified by the Ministry of Electronics and Information Technology on 13/11/2025 and are now in force on a phased timeline, with most substantive obligations taking effect by May 2027. The Rules carry a provision of direct relevance to AI vendor contracts: a Significant Data Fiduciary must exercise due diligence to verify that the algorithmic software it uses for processing does not pose a risk to a data principal’s rights, an obligation that sits alongside, and does not replace, the bias and discrimination indemnity gap discussed below. A startup engaging an AI vendor that processes customer personal data should have this due diligence obligation, and its allocation between customer and vendor, reflected in the data processing agreement, not left to the AI vendor’s standard terms.

Two developments from 2026 are worth tracking closely. The Supreme Court’s draft Regulations for the Use of Artificial Intelligence in Courts, 2026, released for consultation in June 2026, take the position that an AI system’s hallucination is not a valid excuse for the human officer who relied on it, a “no fault liability on the user” approach that signals how Indian regulators are likely to treat AI liability more broadly: responsibility sits with whoever deployed the tool, not the tool itself. Separately, the amended IT Rules framework tightened due diligence standards for platforms enabling AI-generated content, moving the due diligence bar from periodic policy compliance to continuous, demonstrable monitoring. Neither development creates a new AI liability statute, but both confirm the direction: Indian regulators are placing the burden of AI-generated harm on the deploying business, not the model developer, which makes the contract between the startup and its AI vendor the only real risk-transfer mechanism available today.

Does algorithmic bias in AI output need its own indemnity carve-out?

Yes, and most founders miss this because bias claims do not look like the AI risk they were warned about. Hallucination is about factual accuracy. Bias is about whether the model’s output systematically disadvantages a protected group, and it shows up most often in AI-assisted hiring screens, credit and loan underwriting, insurance pricing, and tenant screening tools. A model that was never explicitly instructed to discriminate can still produce a discriminatory pattern of outcomes, because it inherited that pattern from its training data, and the customer deploying the model, not the model provider, is the one facing the applicant, borrower, or tenant who was screened out.

This risk needs separate treatment from a hallucination clause for two reasons. First, the harm is often invisible until someone runs a disparate impact analysis across many decisions, which means it surfaces long after the contract was signed and often after hundreds of decisions have already been made. Second, regulatory exposure for biased AI-assisted decisions in lending and employment is developing faster than exposure for one-off inaccurate outputs, and a regulator’s finding of a discriminatory pattern carries penalty and reputational consequences well beyond what a single customer’s claim would generate. A negotiated AI vendor contract should include a specific representation that the vendor has tested the model for disparate impact across the categories relevant to the use case, and an indemnity trigger that explicitly covers regulatory action or third-party claims arising from biased or discriminatory output, not just inaccurate or defamatory output. A one-time representation at signing is not enough on its own, because a model’s behaviour can drift as it is updated or as the underlying population it scores changes; the contract should also require the vendor, or the startup itself if it controls the deployment, to run periodic impact monitoring across the outcomes most likely to trigger a discrimination claim, with a defined cadence rather than an open-ended commitment to “monitor as appropriate.”

Does agentic AI that takes autonomous actions change the liability analysis?

Yes, materially. Everything discussed so far assumes a human reads the AI’s output before it causes harm, whether that is a chatbot’s answer or an underwriting recommendation. Agentic AI systems that can execute a transaction, send a communication, or modify a record without a human approving each step remove that checkpoint entirely. A single erroneous autonomous action, an agent that mispriced an order, sent an unauthorised communication, or approved a transaction it should have flagged, causes direct financial harm the moment it happens, with no human decision point in between to interrupt it.

This shifts the applicable legal theory. A hallucinated chatbot answer that a human then acted on typically gets analysed as a service deficiency, since a person made the final decision. An agentic AI’s autonomous action looks more like a product defect claim, because the system itself made and executed the decision, which is the theory some commentators expect courts to extend toward strict liability under frameworks similar to India’s Consumer Protection Act, Chapter VI, where a manufacturer or service provider can be liable without proof of negligence. Contracts for agentic AI tools should therefore include a mandatory action-approval workflow for any transaction above a defined value or risk threshold, a dedicated and higher liability cap than a standard chatbot integration, and an explicit allocation of responsibility for actions the agent takes within versus outside its authorised scope.

How should founders negotiate AI indemnity clauses with vendors?

Negotiating an AI vendor contract needs to be treated as a risk allocation exercise, not a standard procurement review. The following clauses close the specific gaps described above, in the order a founder should prioritise them.

Clause to negotiate	What it should say	Why it matters
Expanded indemnity trigger	Extend beyond “IP infringement claims” to “any third-party claim arising from inaccurate, defamatory, or harmful AI-generated output, where the output was generated using the vendor’s model in accordance with the agreement”	Closes the core hallucination gap that the standard IP-only indemnity leaves open
Carve-out survival for permitted customisation	State that reasonable prompt engineering, system instructions, or fine-tuning on the customer’s own data does not void the indemnity, unless the customisation was the proximate cause of the harm	Prevents the vendor from voiding the entire indemnity because you did the normal, expected work of building a product on their API
Consequential loss carve-out narrowing	Expressly state that loss arising from a repeated or systemic AI output error, even across many transactions or customers, is treated as direct loss for the purposes of the indemnity, not indirect or consequential loss	Without this, an expanded indemnity trigger can still be defeated by the standard exclusion for indirect and consequential losses once the harm scales across many customers
Reliance disclaimer counter-clause	Cap or remove any clause in the vendor’s terms stating the customer must independently verify all AI output before relying on it, or limit it to high-risk decision categories you define	A broad reliance disclaimer in the vendor’s own terms can undercut your expanded indemnity by shifting the duty to verify back onto you for every output, not just the ones you agreed to review
Dedicated liability sub-cap for AI-generated harm	Negotiate a separate, higher cap for claims arising from AI output, ideally linked to the vendor’s professional indemnity insurance limits rather than fees paid	The standard twelve-month fee cap is disconnected from real-world harm size and needs its own ceiling
Human-in-the-loop allocation clause	Define explicitly which decisions require human review before customer-facing use, and record that allocation in the contract, not just internal policy	Creates a documented basis to argue the loss was a shared or vendor-side failure if a claim arises from a decision that should have carried human oversight
Audit and transparency rights	Require the right to request incident logs, model version history, and safety filter configuration on request, particularly after any reported error	Gives you the evidence needed to establish causation in a downstream dispute, since AI failures are otherwise difficult to trace back to a specific model behaviour
Insurance stacking requirement	Require the vendor to disclose whether it carries technology errors and omissions or AI liability insurance, and at what limits	Tells you whether the vendor’s indemnity promise is backed by real capital or just contractual language with nothing behind it

Two negotiation dynamics are worth knowing before this conversation starts. First, large model providers (the API layer) will rarely move on their standard terms for a single startup customer, however large the ask. Their leverage comes from scale, and an early-stage company’s negotiating position with them is weak. Second, the mid-layer vendor, meaning the company that builds a specific product on top of a large model and sells it to you as a packaged tool (a customer support bot, an underwriting engine, a document review tool), has far more room to negotiate, because they are the ones actually competing for your account. Most of the negotiation leverage in this chain sits at that mid-layer, not at the foundation model layer, so founders should focus negotiation effort where it has the highest probability of moving the needle.

Common mistakes that cost founders time and money

Assuming “AI indemnity” on the marketing page means comprehensive coverage. Vendors advertise “AI indemnification included” as a selling point, but the actual clause in the master service agreement is almost always narrower than the marketing language suggests. Read the defined term for “claim” in the contract itself, not the sales deck.

Signing the vendor’s standard terms of service without a master agreement. Many startups adopt AI tools through a click-through terms of service rather than a negotiated contract, particularly for lower-cost tools. Click-through terms almost never include a negotiated indemnity at all, leaving the startup with zero contractual recourse if a claim arises.

Treating the AI vendor relationship as a one-time procurement decision. Model versions change, safety filters get updated, and vendor terms are amended unilaterally with notice periods as short as thirty days. A contract reviewed once at signing and never revisited misses these changes, several of which can silently narrow the indemnity further over the life of the relationship.

Not documenting the human review layer. When a claim does arise, the first question an Indian court or a regulator asks is whether a human reviewed the AI output before it reached the customer. Startups that cannot produce a record of their human-in-the-loop process (who reviewed what, and when) lose the argument that the harm was a shared failure rather than a defect in their own product design under Section 84 of the Consumer Protection Act, 2019.

Underestimating the Consumer Protection Act’s product liability exposure. Founders often assume that because their contract with the AI vendor limits the vendor’s liability, their own exposure to the end customer is similarly limited. It is not. The Consumer Protection Act’s Chapter VI liability runs directly from the startup to the end consumer and cannot be contracted away by a clause in a separate, unrelated agreement with the AI vendor.

In the commercial contract engagements we have run at Treelife

In the commercial contract engagements we have run at Treelife, the AI indemnity gap shows up most often at the term sheet stage of a fundraise, when an investor’s legal counsel asks a founder to walk through exactly what happens if the company’s AI-powered feature gives a customer wrong information. Most founders have not modelled this until that question is asked. The pattern we see repeatedly is a founder who negotiated hard on pricing and SLA terms with their AI vendor but accepted the indemnity clause as boilerplate, not realising that Section 84(2) of the Consumer Protection Act, 2019 removes the negligence defence entirely for a defective service, which means the fact that the AI vendor was at fault, not the startup, is not a complete answer to a consumer’s claim. We have also seen due diligence findings where the absence of a documented human review process for AI-assisted decisions (loan underwriting, medical triage, legal drafting) became a closing condition, because investors increasingly treat this as a governance maturity signal, not a legal afterthought. The fix is rarely a wholesale rewrite of the vendor contract. It is usually three to five specific clause amendments, negotiated early, that close the highest-probability gaps rather than attempting to eliminate all AI risk contractually, which is not realistically achievable given where the market currently stands.

Case Study

Situation: A Series A fintech founder based in Bengaluru had embedded a third-party LLM into a customer-facing loan eligibility chatbot, using the vendor’s standard API terms without a negotiated master agreement.

Challenge: The chatbot had, on three occasions, given customers inaccurate eligibility figures that did not match the actual underwriting outcome, generating customer complaints and a threatened regulatory query. The vendor’s indemnity clause covered IP infringement only, and the founder had no documented human review step before the chatbot’s output reached customers.

What Treelife did: We renegotiated the vendor agreement to include an expanded indemnity trigger covering inaccurate output, added a dedicated liability sub-cap tied to the vendor’s insurance limits, and helped the company implement and document a human review checkpoint for any eligibility figure above a defined loan amount threshold.

Outcome: The renegotiated contract closed the primary gap before the next fundraising round’s legal due diligence, and the documented human review process was cited by the investor’s counsel as a positive governance signal rather than a flagged risk, avoiding a closing condition that would otherwise have delayed the round by an estimated three to four weeks.

FAQ’s on the AI Indemnity Trap

Q: Does a standard AI vendor indemnity clause cover hallucinations?
A: No, in almost all cases. Standard AI indemnity clauses are scoped to third-party intellectual property infringement claims. A hallucinated fact, fabricated citation, or inaccurate recommendation is an output quality issue, not an IP claim, and falls outside the clause unless it has been specifically negotiated to include it.

Q: What does it typically cost to renegotiate an AI vendor’s indemnity terms?
A: For a mid-layer AI product vendor (not a foundation model provider), legal costs for a targeted clause renegotiation typically run lower than a full contract rewrite, since the work focuses on three to five specific amendments rather than the entire agreement. Foundation model providers rarely negotiate bespoke terms below enterprise-tier spend commitments.

Q: How long does an AI vendor contract renegotiation usually take?
A: A focused renegotiation covering indemnity scope, liability caps, and human-in-the-loop allocation typically takes two to four weeks with a responsive vendor, longer if the vendor’s legal team requires internal escalation for any deviation from standard terms.

Q: What documentation should a startup maintain to support an AI liability defence?
A: Model version and configuration logs, records of any human review checkpoints and who performed them, the specific system prompts or fine-tuning applied, and a copy of the vendor’s terms in effect at the time the disputed output was generated, since vendor terms change frequently.

Q: Does using a third-party AI model hosted outside India create additional FEMA or data localisation exposure?
A: Payment for the API service itself is typically a standard import of services and does not trigger FEMA-specific structuring beyond normal outward remittance compliance. The more material exposure is under the DPDP Act, 2023 and the now-notified DPDP Rules, 2025, where personal data processed by an offshore model provider needs a data processing agreement that allocates breach, misuse, and algorithmic due diligence liability clearly between the startup and the vendor.

Q: Is there a DPIIT-recognised startup exemption relevant to AI liability?
A: No. DPIIT recognition provides tax and compliance benefits under the Startup India framework but has no bearing on product liability exposure under the Consumer Protection Act, 2019, or on indemnity obligations under a commercial contract.

Q: What happens if the AI vendor becomes insolvent after a claim arises?
A: The startup’s indemnity right against the vendor becomes an unsecured claim in the vendor’s insolvency, which is often worth little in practice. This is the strongest argument for negotiating a liability sub-cap linked to the vendor’s actual insurance coverage rather than relying on the indemnity promise alone, since insurance proceeds are not affected by the vendor’s insolvency in the same way a contractual promise is.

Q: Can an investor’s due diligence process flag AI liability gaps before a funding round closes?
A: Yes, and increasingly does. Legal due diligence for Series A and later rounds now regularly includes a review of AI vendor contracts and human oversight processes, particularly for startups in fintech, healthtech, and legal or compliance-adjacent products, where an AI error has a direct path to consumer harm.

Q: Are co-founders personally liable if an AI-powered product feature causes customer harm?
A: Personal liability for founders in this context typically arises only where there is evidence of fraud, gross negligence, or wilful misconduct in how the AI feature was deployed, rather than from the underlying AI error itself. Documented human review processes and a properly negotiated vendor contract are the primary defences against escalation toward personal exposure.

Q: Does the Consumer Protection Act’s product liability chapter apply to purely digital, non-physical AI products?
A: The Act’s definition of product liability extends to a product service provider for a faulty, imperfect, or deficient service, which Indian consumer forums have applied to digital and software-based services. An AI-powered feature that forms part of a paid or free consumer-facing service falls within this scope where it causes qualifying harm.

Q: What is the single highest-priority clause to negotiate if a startup only has room to push on one term?
A: The liability sub-cap for AI-generated harm, linked to the vendor’s insurance limits rather than fees paid. Even an expanded indemnity trigger is of limited value if the overriding liability cap still limits recovery to a few months of API fees.

Q: If a vendor’s model is later found to produce biased hiring or lending recommendations, does that fall under the standard IP indemnity?
A: No. Bias and discrimination claims are a distinct risk category from both IP infringement and hallucination, and standard indemnity clauses rarely mention them at all. This needs a specifically negotiated representation and indemnity trigger, covered in the algorithmic bias section above.

Regulatory references

• Indian Contract Act, 1872, Sections 124 and 125 (contracts of indemnity)
• Consumer Protection Act, 2019, Chapter VI, Sections 82 to 87 (product liability)
• Information Technology Act, 2000, Section 79 (intermediary safe harbour)
• Digital Personal Data Protection Act, 2023
• Digital Personal Data Protection Rules, 2025 (notified 13/11/2025, Ministry of Electronics and Information Technology)
• Regulations for the Use of Artificial Intelligence in Courts, 2026 (draft, released for public consultation, June 2026)
• IT Rules amendment, 2026 (synthetically generated information due diligence framework)
• Gajanan Moreshwar v. Moreshwar Madan, AIR 1942 Bom 302

External sources

• Ministry of Corporate Affairs
• Income Tax India
• Reserve Bank of India
• Startup India