Beyond Boilerplate: How to Draft AI Usage Disclaimers in B2B Tech Contracts

The average Indian B2B tech contract today has exactly one sentence addressing artificial intelligence: “outputs generated by AI tools are provided for informational purposes only and should not be relied upon without independent verification.” Lawyers paste it in. Founders sign it. Both parties move on. That single sentence does not protect anyone under Indian law. It does not satisfy the Digital Personal Data Protection Act, 2023 (DPDPA). It does not address IP ownership of AI-generated deliverables. It says nothing about what happens to customer data fed into a model, who bears liability when an AI output causes a downstream business loss, or how agentic AI workflows that touch multiple data sources are disclosed. As AI integrations shift from background utilities to core product features in Indian B2B SaaS, the gap between what contracts say and what the law actually requires has become commercially material.

What does “AI usage disclaimer” actually mean in a B2B contract?

The phrase covers at least three distinct legal instruments that most founders collapse into one, and each has a different purpose and a different legal test.

The first is an output accuracy disclaimer: a clause stating that AI-generated outputs may be inaccurate, incomplete, or unsuitable for specific decisions, and that the vendor is not warranting the correctness of any AI-generated result. This is the closest cousin of the one-sentence language most contracts currently use. Its primary function is to shift reliance risk from vendor to customer.

The second is a data processing disclosure: a clause that identifies which customer data is being processed by an AI model, under what legal basis, for what stated purpose, and by which sub-processors (including the underlying model provider). Under the DPDPA 2023, this is not optional language. It is a statutory obligation that sits on the data fiduciary regardless of what the contract says.

The third is an AI feature notification: a clause that tells the customer what aspects of the product or service are AI-powered, what that means for human oversight, and what the customer’s responsibilities are in reviewing outputs before acting on them. As agentic AI moves into core business workflows, this clause is increasingly the one that determines who bears liability when an AI recommendation causes a business decision to go wrong.

Running all three together as a single boilerplate paragraph is where most Indian B2B contracts fail. Each instrument has a different drafting logic, a different legal basis, and a different audience within the customer’s organisation (their legal team, their privacy team, and their operational team respectively).

The three instruments in a B2B AI contract:

Instrument	Primary function	Who on the customer side cares	Regulatory anchor
Output accuracy disclaimer	Shift reliance and consequential loss risk	Legal / procurement	Indian Contract Act, 1872 (Sections 73-74)
Data processing disclosure	Satisfy DPDPA fiduciary obligation	Privacy / DPO	DPDPA 2023, Sections 8-9
AI feature notification	Establish human-in-the-loop responsibility	Operations / product	Consumer Protection Act, 2019; IT Act, 2000

Why the boilerplate approach fails

The boilerplate AI disclaimer was borrowed from US software licensing practice, where it was designed to sit alongside broad warranty exclusions under the Uniform Commercial Code. That context does not translate to India in three important ways.

First, India does not have a codified equivalent of implied warranty exclusion for services. Under the Indian Contract Act, 1872, when a party fails to perform a contract in a way that causes loss, Section 73 allows recovery of compensation for losses that are within the reasonable contemplation of the parties at the time of contracting. A broad “no warranty on AI outputs” clause may not extinguish this exposure if the customer can demonstrate that the AI output was central to the service being delivered, and that the vendor knew the customer would rely on it for consequential decisions.

Second, the DPDPA 2023 creates a statutory liability floor. Section 25 of the Act prescribes penalties of up to ₹250 crore for failure to maintain reasonable security safeguards to prevent a personal data breach, and up to ₹200 crore for failure to notify the Data Protection Board within the required timeline. These penalties apply to data fiduciaries regardless of what their contracts say. A clause purporting to cap liability at one month’s fees does not bind the Data Protection Board of India (DPBI) and does not reduce the statutory fine.

Third, when customer data is flowing into an AI model, the customer is not merely relying on your output. You are processing their data. That transforms the contractual relationship: you are now a data fiduciary (or in some structures, a data processor acting on behalf of a fiduciary), and the law imposes specific obligations on you that cannot be contracted away downstream.

The practical consequence of this for a B2B SaaS company signing an enterprise MSA is that a boilerplate disclaimer creates a false sense of protection while leaving the real exposure intact. Enterprise legal teams have started to notice. At least three of the enterprise agreements Treelife reviewed in the last quarter were returned by procurement teams with “AI clause insufficient” comments, requiring renegotiation of the entire data processing and liability architecture.

What is the regulatory floor that an AI disclaimer cannot waive?

No contractual disclaimer can waive obligations that Indian statute places directly on your company. Understanding this floor is the prerequisite to drafting a disclaimer that actually works.

DPDPA 2023 obligations that survive any disclaimer:

The Digital Personal Data Protection Act, 2023 applies wherever personal data of individuals in India is being processed, including by AI systems operating outside India that serve Indian users (Section 3, extraterritorial application). “Processing” is defined broadly to include collection, storage, use, sharing, transmission, and erasure. Any AI model that ingests customer-provided data containing names, identifiers, behavioural patterns, or professional information is almost certainly processing personal data under this definition.

As a data fiduciary, your obligations under Sections 8 and 9 of the DPDPA include: collecting data only for a specified, lawful purpose; not processing data beyond that purpose; maintaining security safeguards appropriate to the risk; deleting data when the purpose is fulfilled; and ensuring that any data processor (including your AI model provider) you engage is contractually bound to the same standards. These are statutory duties. An “as-is, no warranty” clause between you and your enterprise customer does not alter your regulatory position with the DPBI.

The DPDPA Rules 2025, notified in November 2025 with a phased enforcement timeline through May 2027, add specificity to breach notification obligations. A data breach involving AI-processed personal data must be reported to the Board without delay and with prescribed content within 72 hours. Your contract should account for this timeline in the breach notification clause, not override it.

IT Act 2000 exposure that disclaimers cannot neutralise:

Section 43A of the Information Technology Act, 2000 imposes a compensation obligation on body corporates that handle sensitive personal data negligently and cause wrongful loss. The Supreme Court’s reading of this provision, reinforced by the IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, means that if your AI system handles medical information, financial data, passwords, biometric data, or sexual orientation information, and a breach occurs due to inadequate controls, compensation liability arises regardless of contractual limitation.

Section 79 of the IT Act grants intermediary safe harbour from third-party content liability, but that harbour is conditional on the intermediary not initiating the transmission, not selecting the receiver, and not modifying the content. An AI model that generates outputs based on customer data is not obviously performing a passive intermediary function. Whether the safe harbour applies to an AI vendor’s output liability is a live and unresolved question in Indian law, and drafting that assumes safe harbour protection may not hold.

February 2026 IT Rules: synthetic content obligations:

The Ministry of Electronics and Information Technology (MeitY) amended the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 in February 2026 to include due-diligence obligations for synthetically generated information, effective 20 February 2026. The amendments define “synthetically generated information” as audio, images, or video created or materially altered by AI so realistically that they could be mistaken for real. Intermediaries (which includes many B2B SaaS platforms) must now implement mechanisms to label synthetic content and maintain audit trails. If your B2B product generates synthetic media or heavily altered outputs, your contract should address the labelling and disclosure obligations the amended Rules impose, and where responsibility for compliance sits between vendor and customer.

The regulatory floor in summary:

Regulatory instrument	Penalty or consequence	Can a contract disclaim it?
DPDPA 2023, Section 25(a): security failure	Up to ₹250 crore per instance	No, applies to the entity, not the contract
DPDPA 2023, Section 25(b): notification failure	Up to ₹200 crore	No
IT Act 2000, Section 43A: negligent data handling	Compensation (no cap in Act)	Partially, if security standards are demonstrably met
IT Rules Feb 2026: synthetic content labelling	Non-compliance triggers intermediary liability exposure	No, labelling obligation applies to the platform
Indian Contract Act 1872, Section 73: loss in contract breach	Reasonable contemplation damages	Partially, with well-drafted limitation clause

What should an AI usage disclaimer in an Indian B2B contract actually include?

A functional AI contract clause set covers six areas. These can sit in the main MSA, in a separate AI addendum, or distributed across a Data Processing Agreement (DPA) and the main agreement depending on deal structure. What matters is that all six are present, specific, and internally consistent.

1. Start with definitions: what “AI” means in your contract

This is the step most Indian B2B contracts skip entirely, and it is the reason subsequent clauses fail. If your contract uses “artificial intelligence” without defining it, any clause that follows accuracy disclaimers, audit rights, data processing obligations — has an undefined scope. A customer can argue that a particular automated function does or does not fall within the term, and the ambiguity is read against the party relying on the limitation (that is, you).

A working definitions block for an AI-enabled B2B SaaS agreement needs at least four defined terms, each calibrated to what your product actually does.

“Artificial Intelligence” or “AI System” should capture the specific type your product uses. The Organisation for Economic Co-operation and Development (OECD) definition, which defines AI broadly as a machine-based system that makes predictions, recommendations, or decisions influencing real or virtual environments, is a workable starting point for general products. If your product uses generative AI specifically, define “Generative AI” as a subset: a class of AI that produces content (text, images, code, audio) in response to prompts rather than following deterministic rules.

“AI Inputs” should define what data the AI system receives to function. This is the anchor for your data processing obligations: you cannot argue your DPDPA obligations are limited if your Input definition is vague about what constitutes personal data in scope.

“AI Outputs” should define what the system produces, including any intermediate outputs in a multi-step agentic pipeline. If your system produces draft text that a human then edits, both the draft and the edit trail may be in scope. Define them separately if the liability logic differs.

“AI Features” should list, by name or category, the specific product capabilities that are AI-powered. This matters for two reasons: the customer knows what they are disclaiming reliance on, and future model upgrades that add new AI-powered features can be flagged as requiring contract amendment rather than slipping in silently under a generic definition.

The discipline of getting these four definitions right forces a productive conversation internally about what your product actually does with data, and surfaces edge cases like agentic sub-pipelines or third-party AI-powered integrations — that your team may not have consciously classified as AI for contractual purposes.

The clause must identify which product features or service components use AI, what type of AI (rule-based automation, machine learning, generative AI, agentic AI), and what the AI does with customer data as part of that function. Generic language like “the platform may use artificial intelligence” is insufficient for DPDPA compliance and provides no useful boundary for a liability dispute.

A working scope clause looks like this: “The platform uses large language model (LLM)-based generative AI to process customer-submitted documents and generate draft outputs. Customer data submitted for AI processing is transmitted to [Model Provider Name], operating as a sub-processor under the Data Processing Agreement. No customer data is used to train or fine-tune the underlying model unless Customer explicitly opts in under Section [X].”

That clause does four things: it identifies the AI type, it identifies the sub-processor, it clarifies training data use (the question most templates leave silent), and it reserves the opt-in mechanism that DPDPA requires for secondary processing purposes.

2. Output accuracy: what “no warranty” can and cannot say

The disclaimer of warranties on AI outputs is legitimate and necessary. What fails is drafting that purports to exclude all liability, including for consequential losses, without addressing the reliance structure of the product.

Under Indian Contract Act 1872, Section 74, if a contract fixes an amount as compensation for breach, that amount is enforceable as liquidated damages (not a penalty) if it represents a genuine pre-estimate of loss. The converse of this is that a clause purporting to exclude all liability, including for losses within reasonable contemplation, may be read by an Indian court as against public policy where the service was presented as one customers would reasonably rely on. This is particularly acute in AI products marketed for financial, healthcare, legal, or compliance decisions.

The accuracy disclaimer should include three specific elements: a clear statement that AI outputs are probabilistic and may contain errors; a specification of which types of decision the customer should not take based solely on AI outputs, calibrated to what the product actually does; and a statement of which outputs require mandatory human review before action. This last element converts the clause from a bare disclaimer into an operational responsibility allocation, which is far more defensible.

3. IP ownership of AI-generated outputs

Under the Indian Copyright Act, 1957, copyright subsists in “original literary, artistic, musical, or dramatic works” (Section 13) and is owned by the “author” (Section 17). The Act was drafted before generative AI existed, and the question of whether an AI-generated output has a human author sufficient to attract copyright protection remains judicially unsettled in India.

What is settled is this: if a human (the customer’s employee) provides the prompt and the context, and the AI produces the output, that human may have a claim to authorship of the resulting work. Your contract needs to specify who owns the AI output, who owns any modifications the customer makes to it, and whether the vendor retains any licence to use the output for model improvement or benchmarking. If you are silent on this, you create a dispute waiting to happen.

A clean IP clause should: assign output ownership to the customer on delivery; retain a royalty-free licence for the vendor to use anonymised and aggregated output patterns for product improvement only, with explicit exclusion of personal data; and state that training data use of customer-specific outputs requires separate written consent.

4. Data processing obligations and DPA requirement

If your AI product processes personal data, you are required under the DPDPA 2023 to enter into a written contract with each customer that binds you as a data processor to the customer’s data fiduciary obligations. The DPDPA Rules 2025 specify minimum content for such contracts.

A standalone DPA (or a DPA schedule to the MSA) should cover: the categories of personal data being processed; the legal basis for processing; processing purposes (including AI functions); security measures and the standard to which they are maintained; sub-processor engagement and notification; breach notification timelines aligned to the 72-hour DPDPA obligation; data retention and deletion on termination; audit rights for the customer; and return or deletion of data on request. These are not negotiating positions. They are statutory requirements.

Enterprise customers who have competent DPOs are increasingly requiring DPDPA-aligned DPAs before signing any AI-enabled SaaS agreement. Treelife’s commercial team has seen a material uptick in MSAs stalled at legal review specifically because the vendor’s DPA was either absent or used EU GDPR language adapted for India, which is not the same standard.

5. Sub-processor disclosure and AI model provider clause

One of the most consistently missing clauses in Indian B2B AI contracts is sub-processor disclosure. If your SaaS product is built on OpenAI, Anthropic, Google, or any other third-party model, that model provider is processing your customer’s data as a sub-processor under your data processing chain. The DPDPA makes the data fiduciary (your customer) ultimately responsible for sub-processor compliance, which means they have a legitimate interest in knowing who your sub-processors are and what commitments those sub-processors have made.

The sub-processor clause should: list all AI model providers as named sub-processors; confirm that each sub-processor is contractually bound by data processing terms at least as restrictive as the vendor’s own obligations; specify the mechanism by which the customer is notified of sub-processor changes (30-day notice is market standard in India at present); and confirm that cross-border transfers (if the model provider is outside India) are conducted under a transfer mechanism permitted under DPDPA.

This last point requires precision: the DPDPA operates a negative-list (blacklist) model for cross-border transfers under Section 16(1), not a whitelist. Personal data may be transferred to any country outside India, except those specifically restricted by the Central Government by notification in the Official Gazette. As of July 2026, no countries have been placed on the restricted list. The default position is therefore permissive: transfers to all jurisdictions, including the US, EU, and other major model-provider locations, are currently permitted. However, sectoral regulations overlay this: RBI’s 2018 Payment Data Localisation Circular requires all payment system data to be stored within India, and SEBI’s 2023 data localisation advisory requires trading and investor data to remain in Indian jurisdictions. For BFSI-sector customers of your AI product, these sectoral restrictions apply regardless of the DPDPA’s permissive default. Your sub-processor clause should confirm which data categories are subject to sectoral localisation rules and that those categories are handled accordingly.

6. Model audit rights: what the customer can demand about the AI itself

Data processing audit rights (the right to inspect your security controls and data handling practices) are now a standard DPA term. What enterprise customers are increasingly adding and most B2B AI vendors have not caught up to is a separate category: model audit rights. These are the rights to inspect and receive documentation about the AI model itself, not just the data it processes.

Model audit rights typically cover three things. The first is model documentation, often called a model card: a summary of the model’s intended use, training data sources, known limitations, performance benchmarks, and bias evaluation results. Customers in regulated sectors (financial services, healthcare, HR technology) are starting to require model cards as a precondition for deployment, because their own regulators are beginning to ask for them. SEBI’s guidance on algorithmic systems and the RBI’s AI-in-lending expectations both create downstream documentation obligations for the regulated entity, which they can only discharge if their AI vendor provides the underlying model information.

The second is accuracy and bias testing reports. These are the outputs of the evaluation runs the vendor conducts (or should conduct) before deployment. Customers want to know: how was the model tested, what error rates were observed, and whether the model performed consistently across different demographic or linguistic segments. The third is the right to commission independent testing, i.e., a penetration test or bias audit conducted by a third party of the customer’s choosing, not just the vendor’s own evaluation.

Vendors resist open-ended model audit rights because model documentation may contain competitively sensitive information. The negotiated middle ground is usually: model cards provided on request and updated with each major model version; bias testing reports provided annually or on request; and third-party audit rights available with 30-day notice, subject to the auditor signing a confidentiality agreement.

If you are the vendor, resist audit language that gives the customer unlimited inspection rights without a confidentiality and use restriction. If you are the buy-side, resist language that makes model documentation “available on reasonable request” without specifying a timeline and the minimum content of what is produced.

Standard limitation of liability clauses in Indian SaaS contracts cap total liability at the fees paid in the preceding 12 months and exclude indirect, consequential, special, and punitive damages. These caps are enforceable between commercial parties under Indian Contract Act 1872 in respect of contractual claims. They do not, however, apply to:

• Statutory penalties under the DPDPA (which fall on the entity, not on contract)
• Compensation claims under Section 43A of the IT Act
• Claims arising from fraud or wilful misconduct (an Indian court will not enforce a cap that shields bad faith conduct)
• Claims involving death or personal injury resulting from negligence

For AI-specific risk, the limitation clause should additionally address two things that standard language misses. The first is model drift and performance benchmarks, which merit their own drafting treatment below. The second is the agentic AI scenario, where an AI component takes actions in the world (sends emails, executes queries, initiates workflows) rather than merely generating text. Agentic AI operates on a different liability logic because the output is not a recommendation but an action, and the consequential loss profile is fundamentally different.

How to draft an AI performance SLA and remediation trigger

The reason model drift matters contractually is that a disclaimer of accuracy at the point of signing does not address what happens when accuracy degrades after deployment. A model that produces outputs with a 5% error rate at go-live and a 22% error rate six months later has changed materially. Without a performance benchmark in the contract, there is no agreed point at which the degradation becomes a breach rather than an accepted limitation.

An AI performance SLA needs four components to be enforceable and useful.

The first is a named performance metric. For text-generation products, this is typically a precision or recall rate on a defined evaluation dataset. For classification products, it is accuracy on a representative sample. For document processing, it may be an extraction accuracy percentage on a defined document type. The key is that the metric must be objectively measurable by both parties, not just self-reported by the vendor. State the metric in the schedule by name, with a description of how it is measured and who can conduct the measurement.

The second is a threshold value. This is the minimum acceptable performance level, below which a remediation obligation triggers. Set the threshold at a level that represents genuinely degraded performance, not a hair’s breadth above random chance. A 70% accuracy threshold on a contract review tool is meaningless if the industry standard is 92%. Thresholds should be agreed based on the vendor’s tested performance at signing and a documented degradation allowance.

The third is a monitoring and notification obligation. The vendor should be required to run periodic performance evaluations (quarterly at minimum for high-criticality applications) and notify the customer within a specified period if the model’s performance falls below the agreed threshold. This converts the model drift risk from a latent unknown into a contractually managed disclosure obligation.

The fourth is a remediation timeline and termination right. If performance falls below threshold, the vendor has a defined period (30 days is common in practice) to restore performance above the threshold. If remediation fails, the customer has the right to terminate the AI-specific scope of the agreement without penalty, with a prorated fee refund. Without a termination right tied to performance failure, the customer is locked into paying for a product that is no longer performing to the agreed standard.

For most Indian B2B contracts in 2026, this level of AI performance SLA drafting is not yet standard. It is, however, what enterprise procurement teams at BFSI, healthcare, and large-enterprise technology buyers are beginning to request. Getting ahead of it in your standard form saves a renegotiation cycle when the first large customer asks for it.

Liability clause comparison for AI-enabled B2B SaaS:

Risk type	Standard boilerplate covers it?	What is actually needed
AI output inaccuracy causing business decision loss	Partially, if reliance disclaimer is present	Named output categories + mandatory review specification
DPDPA breach penalty (up to ₹250 crore)	No, statutory, cannot be limited by contract	Indemnity carve-out for regulatory fines, DPA compliance obligations
IP infringement claim on AI output	No	Output IP warranty + third-party IP indemnity from vendor
Sub-processor breach (model provider hacked)	No	Sub-processor liability flow-through clause, security audit rights
Agentic AI action causing direct loss	No	Human override requirement, action scope limitation, real-time log access
Model drift causing systematic errors over time	No	Performance benchmark, monitoring obligation, notification requirement

Does the buy-side contract differ from the sell-side contract?

Yes, materially. The sell-side AI contract (your MSA with enterprise customers, where you are the vendor) is primarily about limiting your AI output liability while satisfying DPDPA data processing obligations and disclosing sub-processor chains. The buy-side AI contract (your agreement with your own AI model providers, where you are the customer) is about importing sufficient protection to cover the commitments you are making downstream.

This creates a contractual alignment problem that many Indian B2B tech companies have not yet mapped. You are promising your enterprise customer a 72-hour breach notification window in line with DPDPA. Your model provider’s standard terms give you a 30-day notification window and cap their liability at your last 12 months of subscription fees. If a breach originates at the model provider, your customer has a DPDPA claim against you, and you have a contractually capped recovery from the provider. The gap is your exposure.

Before signing your upstream AI vendor agreement, review: their breach notification timeline against your downstream commitment; their liability cap against your downstream exposure; whether their security certifications (SOC 2, ISO 27001) meet the “reasonable security safeguards” standard under the DPDPA; and whether they permit you to conduct or commission security audits. If the upstream terms do not match your downstream commitments, you either renegotiate, change your downstream commitment, or carry the gap as a business risk.

The RBI Draft Guidance on Model Risk Management (24 June 2026, consultation open until 24 July 2026) sharpens the sell-side obligation specifically for vendors supplying AI to banks, NBFCs, and other RBI-regulated entities. The guidance states explicitly that a regulated entity is accountable for the outcomes of all models it uses, regardless of vendor origin. In practice, this means your bank or NBFC customer cannot outsource model accountability to you, but they will contractually require you to enable the validation, documentation, and monitoring obligations that sit on them as the regulated entity. Expect requests for model cards, validation access, explainability documentation, and kill-switch enablement as standard terms in any enterprise agreement with a financial services customer from late 2026 onward.

What do bias and ethical AI obligations look like in Indian B2B contracts?

India does not have a standalone AI Act equivalent to the European Union’s AI Act. This is by design: MeitY has signalled that the government prefers governing AI through existing legal frameworks rather than creating a dedicated regulatory layer. That position does not, however, mean that AI systems deployed in India have no bias or fairness obligations. It means those obligations arise from existing law, often in ways that contracting parties have not yet mapped.

The most direct source of bias-related liability for AI in B2B contexts is the Consumer Protection Act, 2019. Section 2(7) defines a “consumer” broadly enough to include businesses purchasing services for use rather than resale. Section 84 establishes product liability for service defects, including services that fail to meet the standard that a reasonable person would be entitled to expect. An AI system that makes consequential decisions (credit eligibility, procurement scoring, HR screening, pricing) and does so in a way that systematically disadvantages a particular group can be characterised as a defective service if the defect was foreseeable and not disclosed.

Constitutional principles add a second layer for AI systems used by or on behalf of government entities, or in contexts touching fundamental rights. The right to equality under Article 14 of the Constitution, as interpreted by the Supreme Court in the K.S. Puttaswamy (Privacy) judgment (2017), creates an implicit non-arbitrariness standard for algorithmic decision-making that affects individuals’ legal or economic interests. This is not a direct contract obligation, but it shapes the environment in which an AI-caused harm claim is adjudicated.

For B2B contracts, the practical implication is a bias and fairness clause that covers three things:

The first is a representation by the vendor that the AI system has been evaluated for bias on the categories relevant to the deployment context. For an HR screening tool, that means evaluation across gender, age, educational background, and regional language. For a credit scoring model, that means evaluation across income brackets, geographic regions, and gender. The representation does not require a perfect model. It requires an honest one: a model that has been tested, whose limitations are documented, and whose outputs are monitored.

The second is a disclosure obligation: if the vendor discovers or is notified of a systematic bias in the model’s outputs affecting a defined group, the customer must be notified within a specified timeline (seven to fourteen days is workable), along with a remediation plan. This mirrors the logic of breach notification: the customer needs to know when the tool they are relying on has a structural problem.

The third is a model version change commitment: when the vendor upgrades or replaces the underlying AI model, the new model must be tested for bias before deployment in the customer environment, and the results provided to the customer. This directly addresses the model version gap: many current B2B contracts allow the vendor to swap underlying models without customer consent, which means the bias testing the customer conducted before signing is no longer relevant.

If you are selling into BFSI, healthcare, HR technology, or any context where the AI makes decisions that affect individuals’ access to financial products, employment, or services, bias provisions are not a negotiating concession. They are the clause that protects you when a downstream complaint surfaces about a systematic pattern in your outputs.

1. Treating the AI disclaimer as a single clause rather than a clause architecture

Every AI-enabled MSA needs an output accuracy disclaimer, a data processing schedule (DPA), a sub-processor list, an IP ownership clause, and a synthetic content disclosure where relevant. Compressing all of this into one paragraph produces language so vague it covers nothing with certainty. Indian courts interpret ambiguous limitation clauses against the party seeking to rely on them (contra proferentem). Vague AI disclaimers are read against the vendor.

2. Using GDPR-adapted DPA templates without India-specific adjustment

India’s DPDPA is not GDPR. The rights framework, the lawful basis structure, the breach notification timelines, and the regulatory authority are all different. A DPA that correctly implements GDPR obligations may miss the specific obligations on data processors under DPDPA Section 9, may reference an incorrect standard for data transfer mechanisms, and may not create the audit rights that Indian enterprise customers now require. The cost of adapting a GDPR DPA for India is one review cycle. The cost of an incorrect DPA being rejected by an enterprise procurement team mid-deal is the deal.

3. Leaving training data use silent

Almost every AI vendor contract that Treelife reviews is silent on whether customer data is used to train or fine-tune the underlying model. This silence creates maximum exposure: the customer can plausibly argue that no consent was given, that the use exceeds the stated purpose under DPDPA Section 6, and that any output the model subsequently generates has been influenced by their data without authorisation. If you do not use customer data for training, say so in terms. If you reserve the right to use anonymised or aggregated data for model improvement, say so explicitly and get contractual acknowledgment.

4. Specifying a generic liability cap without carving out DPDPA exposure

A clause capping liability at “fees paid in the preceding three months” reads cleanly in a standard SaaS context. In an AI contract, it creates a specific problem: if a DPDPA breach triggers regulatory action against your customer (who is the data fiduciary), their indemnity claim against you may exceed that cap significantly. Enterprise customers are negotiating separate, higher liability caps for data protection breaches, and in some cases are requiring uncapped liability for DPDPA penalties. You need to decide your position on this before you are in a room with a large enterprise’s legal team negotiating a ₹2 crore ARR deal.

5. Missing the February 2026 synthetic content obligations

For B2B AI products that generate images, video, audio, or heavily AI-modified document content, the February 2026 IT Rules create an affirmative labelling and audit trail obligation. If your product qualifies as an intermediary under the IT Act, this obligation is yours. If your customer uses your product to generate synthetic content that they then distribute without labelling, your contract should clarify who bears compliance responsibility for the output-side obligation. Most current Indian B2B contracts do not address this at all.

Case study

Situation: Bengaluru-based Series A B2B SaaS company, 18 months post-launch, ₹1.8 crore ARR, building an AI-powered contract review tool for Indian mid-market companies. Closing a ₹60 lakh annual deal with a Hyderabad-headquartered manufacturing group.

Challenge: The customer’s legal team flagged three gaps: no DPA identifying the LLM provider as a sub-processor; the liability cap (three months’ fees) was below the minimum they required for data processing agreements; and the AI output accuracy clause said nothing about document categories the tool could not reliably process.

What Treelife did: Drafted a DPDPA-aligned DPA naming the LLM provider as a sub-processor with a 72-hour breach notification obligation and audit rights. Restructured the liability clause with a standard cap for service failures and an enhanced cap (24 months’ fees) for data protection breaches. Added an output accuracy schedule specifying three document categories where human review was mandatory before reliance.

Outcome: Deal closed within three weeks of revised document delivery. No renegotiation on commercial terms. The customer’s legal team accepted the revised AI schedule without further comment. ARR secured without any concession on pricing.

FAQ’s on Beyond Boilerplate

Q: Do I need a separate AI addendum or can I add AI clauses to the existing MSA?
A: Either structure works legally. A separate AI addendum is preferable when you have multiple customers with different AI feature sets, because you can vary the addendum without reopening the master terms. A scheduled clause in the MSA is simpler for standardised products. The DPA is always best as a separate schedule regardless of structure, because it is subject to its own amendment cycle as DPDPA Rules evolve.

Q: Does the DPDPA apply to B2B contracts, or only to consumer-facing products?
A: The DPDPA applies to any processing of personal data of individuals in India, including in B2B contexts. Employee data, end-user data flowing through a B2B SaaS product, and any identifiable individual data processed by your AI system is in scope. The Act does not exclude business-to-business processing. Even in a purely enterprise deployment, if the system ingests personal data (employee names, customer records, professional communications), DPDPA obligations apply.

Q: What is the minimum content of a Data Processing Agreement under the DPDPA?
A: The DPDPA Rules 2025 require that a data processor agreement (between a data fiduciary and a data processor) include: a specification of the personal data being processed; the processing purposes; security obligations on the processor; breach notification obligations; sub-processor engagement conditions; and data return or deletion provisions on termination. This is a floor, not a ceiling. Enterprise procurement teams often require additional terms including audit rights, penetration test report access, and performance warranties.

Q: Can I use a single AI disclaimer for all customers, or does it need to be customised?
A: A single standard form works if your AI feature set and data processing activities are uniform across customers. Where customers use different data categories, have different regulatory obligations (for example, a financial services customer subject to RBI guidelines, or a healthcare customer subject to additional data obligations), or have different sensitivity requirements, the AI schedule should be varied accordingly. The scope clause in particular should accurately describe what the AI does with that specific customer’s data.

Q: What happens if my AI output causes a customer to lose money on a business decision?
A: This is a consequential loss scenario. Under Indian Contract Act 1872, Section 73, the customer can claim losses that arise naturally from the breach or that were within the reasonable contemplation of both parties at the time of contracting. A well-drafted output accuracy disclaimer shifts the reliance risk by specifying that the customer must apply independent judgment before acting on AI outputs. If the customer can show they disclosed their intended reliance to you before contracting, that contemplation argument is stronger. The disclaimer must be specific enough to put the customer on notice of the limitation, not just a generic “use at your own risk” statement.

Q: Who owns the copyright in an AI-generated document or analysis?
A: Under the Indian Copyright Act, 1957, copyright vests in the human author. Where a customer’s employee provides the prompts and context that produce an AI output, there is an argument for customer authorship. Your contract should clarify this by expressly assigning output copyright to the customer on generation, retaining only the limited vendor licence needed for product improvement on anonymised data. Leaving IP ownership silent creates a dispute where one does not need to exist.

Q: What should I do about AI model providers who change their terms unilaterally?
A: Your upstream agreement with the model provider should include a change notification obligation and a right to terminate for cause if the provider materially changes terms in a way that impairs your ability to meet downstream commitments. Additionally, your downstream MSA should include a “no less favourable” standard: the sub-processor terms you pass through to customers must be at least as protective as the terms you receive from the provider. If the provider weakens their terms, you have a window to renegotiate or substitute before your customer’s protections are impaired.

Q: What happens contractually when I upgrade or replace the underlying AI model in my product?
A: A model version change is a material event that most current contracts handle inadequately, often through a vague “we may update the service” provision. The right approach is a specific model version change clause that requires: advance notice to the customer (30 days is workable for non-critical applications, 60 days for deployments where the customer has done their own AI risk assessment); re-execution of any bias testing the parties agreed to at onboarding; and a customer right to delay adoption of the new model version for a defined period if they need time to validate. Where the product is used in a regulated context (a SEBI-regulated entity’s workflow, or an RBI-supervised lender’s credit process), the customer may need to inform their regulator of the model change. Your contract should acknowledge this obligation and give the customer adequate notice to comply.

Q: Is an “as-is” clause sufficient to disclaim AI output liability in India?
A: No. An “as-is” clause disclaims implied warranties of quality and fitness for purpose, which have limited codified standing in Indian contract law compared to common law jurisdictions. Indian courts assess liability under contract through Section 73 (compensation for loss naturally arising from breach or within reasonable contemplation) rather than implied warranty doctrine. A product liability claim under the Consumer Protection Act, 2019 is also possible if the AI product is used by a business that is itself a “consumer” under that Act, which requires a separate analysis by turnover and usage.

Q: What disclosure do I need to make about using AI-generated synthetic content in my product?
A: Under the February 2026 IT Rules amendments, if your platform generates or substantially modifies audio, images, or video using AI, and the result could be mistaken for real content, you have labelling and audit trail obligations. In a B2B context, your contract should specify whether the vendor or the customer is responsible for applying required labels to AI-generated synthetic content before distribution, and which party maintains the audit log.

Q: How should I handle SEBI or RBI customers who have sector-specific AI restrictions?
A: This question has become significantly more specific with the RBI’s Draft Guidance on Regulatory Principles for Model Risk Management, released on 24 June 2026 for public consultation (Press Release No. 2026-2027/528, comments open until 24 July 2026). The draft applies to all RBI-regulated entities including commercial banks, NBFCs, small finance banks, payment banks, co-operative banks, credit information companies, and all-India financial institutions. It requires a Board-approved Model Risk Management Framework covering all models used by the entity, including those sourced from third-party vendors. Critically, the guidance states that a regulated entity is accountable for the outcomes of all models it uses regardless of vendor origin. If you are selling an AI product into any of these entities, you should expect them to require: model documentation (model cards with intended use, training data description, known limitations, and performance benchmarks); independent model validation rights; explainability thresholds for any AI-driven decision that affects customers; kill-switch and human override mechanisms; and disclosure to customers when they are interacting with an AI system. Your contract should enable, not obstruct, the regulated entity’s compliance with these obligations. A representation by the customer that their use case complies with their sectoral regulator’s framework, plus a commitment by you to provide the documentation the regulator requires, is the minimum. For SEBI-regulated entities, SEBI has issued separate guidelines on algorithmic systems for market intermediaries that carry analogous documentation and audit obligations. The liability for regulatory non-compliance in the customer’s sector rests with the customer, but your contract should make this allocation explicit and give you adequate notice before a regulatory inspection that touches your system.

Q: What is a reasonable liability cap for data protection breaches in an AI SaaS agreement?
A: Market practice in India in 2026 is converging toward a two-tier structure. General liability (covering service failures, SLA breaches, and non-data claims) is capped at fees paid in the preceding 12 months. Data protection liability (covering DPDPA-related claims, breach response costs, and regulatory exposure) is capped at a higher amount, often 24 months’ fees or a fixed sum. Regulatory fines under DPDPA are not capped by contract: they are imposed on the entity. The contractual cap governs indemnity claims between the parties, not the fine itself.

Q: What should the AI clause look like for an agentic AI product (one that takes actions, not just generates text)? A: Agentic AI contracts require two additional elements beyond standard AI disclaimers. The first is an action scope limitation: a specific definition of what actions the AI is permitted to take autonomously, and a mandatory human approval requirement before actions above a specified threshold. The second is an action log obligation: the vendor must maintain and make available a real-time or near-real-time log of all actions taken by the AI agent. Without these, consequential loss liability for an erroneous autonomous action is almost impossible to disclaim effectively, because the AI was acting on behalf of the customer within a scope the vendor defined and enabled.

Q: When do I need to update my existing contracts to reflect DPDPA obligations?
A: The DPDPA Rules 2025 (notified 13 November 2025) implement in three phases. Phase 1 established the Data Protection Board of India, which is now operational. Phase 2, effective 13 November 2026, activates the Consent Manager framework. Phase 3, effective 13 May 2027, is the full enforcement date when all substantive compliance obligations, notice requirements, breach notification timelines, data principal rights, and penalty provisions come into force. The DPBI is operating in a guidance and awareness mode through 2026, with hard enforcement from 13 May 2027. That said, enterprise customers subject to the Act are already amending procurement requirements ahead of enforcement, and DPA terms are among the first things their legal teams are requesting. If your contract was signed before November 2025 and does not contain a DPA schedule, an amendment or supplemental agreement is advisable in the second half of 2026. Waiting until May 2027 to start the review means you will be renegotiating under customer pressure rather than on your own terms.

Regulatory references

• Indian Contract Act, 1872 (Sections 23, 73, 74)
• Digital Personal Data Protection Act, 2023 (Sections 3, 6, 8, 9, 12-17, 16, 25)
• Digital Personal Data Protection Rules, 2025 (notified 13 November 2025; Phase 2 effective 13 November 2026; Phase 3 full enforcement 13 May 2027)
• Information Technology Act, 2000 (Sections 43A, 72A, 79)
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011
• Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021, as amended by Amendment Rules, 2026 (G.S.R. 120(E), 10 February 2026; synthetic content obligations effective 20 February 2026)
• India AI Governance Guidelines, 2025 (MeitY, notified 5 November 2025 under IndiaAI Mission; non-binding but establishes India’s AI governance approach)
• RBI Draft Guidance on Regulatory Principles for Model Risk Management, 2026 (Press Release No. 2026-2027/528, 24 June 2026; consultation open until 24 July 2026)
• RBI Payment Data Localisation Circular (DPSS.CO.PD No. 2785/02.14.003/2017-18)
• SEBI data localisation advisory, 2023
• Copyright Act, 1957 (Sections 13, 14, 17)
• Consumer Protection Act, 2019 (Sections 2(7), 84)
• Constitution of India, Article 14 (equality, non-arbitrariness — relevant to AI decision-making claims)
• K.S. Puttaswamy v. Union of India (2017) 10 SCC 1 (Supreme Court, nine-judge bench) — right to privacy, algorithmic decision-making implications
• Companies Act, 2013 (for corporate governance obligations in AI procurement)

External sources

• Ministry of Electronics and Information Technology (MeitY)
• Data Protection Board of India (DPBI) — notified under DPDPA
• Ministry of Corporate Affairs
• Securities and Exchange Board of India
• Reserve Bank of India