Nickeled & Dimed

Penny for your thoughts?

We are accepting articles on our new email: cnes.ju@gmail.com

Validity without Reliability: AI-Generated Contracts and the Emerging Doctrinal Gap in Indian Contract Law

By — Divyaansh Kharbanda

Abstract

India, the most active market for large-language models (LLM) like ChatGPT, Gemini and Perplexity, has seen these tools enter  the domain of contract drafting. While the recent Supreme Court’s Draft regulations on AI in Courts permit the usage of such tools under human supervision, this article argues that supervision cannot remedy the structural unpredictability of LLMs. As studies have shown, LLMs are non-deterministic, prompt-sensitive and prone to hallucination, which produces “contractual deepfakes” that may be enforceable but commercially unsound. Although the Indian Contract Act, the Information Technology Act and the Bharatiya Sakshya Adhiniyam (BSA) resolve the question of formation and admissibility of such contracts, they offer no answer for assessing whether an AI-generated contract reflects the party’s actual bargain. This article argues that this gap is not incidental but structural, arising from the very characteristics that make LLM-generated drafting unpredictable and difficult to verify. Accordingly, this article calls for a doctrinal response that examines the substantive viability of AI-generated contracts and not merely their formal validity.

Introduction

The usage of AI has arisen in top law firms in India. The usage of platforms such as SpotDraft, Harvey AI, and Luminance are already embedded in the contract review and drafting workflows of the legal industry. Various small-scale businesses also use models like ChatGPT and Gemini for legal advice and legal drafting. With this growth, commentary on the legal status of such contracts has mostly focused on the question of formation and admissibility. On this account, it is observed that AI-generated contracts are valid as long as they satisfy  Section 10 of the Indian Contract Act, which specifies the basic elements of a contract, and further, no objection is grounded in the absence of human drafting under Section 10A of the Information Technology Act.

The Supreme Court’s draft Regulations for the Usage of Artificial Intelligence have followed this framing. AI tools may be used subject to mandatory human review and disclosure of AI-generated content. Further, the DPITT’s working paper on generative AI and Copyright has similarly treated hallucination and bias as risks to be addressed through better disclosure obligations rather than technology itself. Therefore, the regulatory climate suggests that human supervision and disclosure are adequate safeguards against the unreliability of large language models, with the hidden assumption that these models do in fact meet the requirements of a valid contract. This assumption is precisely what the framework leaves untested. Whether a generated document satisfies Section 10 of the Contract Act is treated as a question of form, that is, whether the text contains an offer, acceptance and lawful consideration rather than a question of whether the text produced a process capable of reliably reflecting what parties intended, which forms the very basis of contract law. This concern is acute, particularly for small businesses that lack the legal expertise to identify when a generated contract diverges from their actual bargain. Indian contract law does not have an overarching duty of good faith, despite courts increasingly invoking fairness as a safeguard precisely in situations where one party cannot meaningfully assess the terms they are accepting. Where LLM generates the contractual document, this concern shifts from the negotiation table to the process of drafting itself. Hence, the question shifts from whether the parties understood what they signed to whether the document they signed reflects what either party actually agreed.

The Myth of the Reliable Draft: LLM Unpredictability and the case of “Contractual Deepfakes”

 Consider a prevalent practice example. Imagine a startup asks ChatGPT to draft a service agreement. The definitions clause excludes “Confidential Information” that the receiving party can show was independently developed through standard sensible drafting. The indemnity clause imposes liability on the same party for “any disclosure of Confidential Information” with no reference to the earlier carve-out. Now read on its own, both clauses stand their ground, yet read together, the document no longer means what either clause, by itself, suggests. A reviewer skimming for obvious drafting errors has little reason to catch it, because nothing about either provision looks defective.

This is essentially a predictable consequence of how large language models generate text. However, scholarship suggests this assumption is misplaced, not because supervision is unimportant but because it addresses the wrong layer of the problem. LLMs do not draft contracts in any meaningful sense, but rather they generate statistically probable sequences of words drawn from the contractual documents in their training data, without any understanding of the transaction or the applicable law.

Three features of this process are relevant, each undermining a different assumption a reviewing lawyer might bring. First, LLMs are non-deterministic, that is, identical prompts can yield materially different outputs, so “fixing” one draft says little about the next. Second, they are prompt-sensitive, which means minor inconsequential changes in phrasing alter the substance of the generated clause, which may turn the reviewer’s own instruction into an uncontrolled variable. Third, because LLMs generate text autoregressively, word by word, without any overarching model of the document, they are prone to the kind of internal inconsistency illustrated above, that is, a clause unobjectionable in isolation may conflict with a definition or recital elsewhere in the same document.  If contractual deepfakes are a product of how LLMs generate text, the question then becomes whether existing contract law can respond to it.

The Doctrinal Gap

The difficulty is not that Indian contract law lacks rules that govern agreement, but that those rules presuppose the reliability of the document through which agreement is expressed. Section 10 of the Contract Act validates an agreement once it satisfies offer, acceptance, consideration and consent. It asks whether an agreement exists and not whether the document reflects what was agreed. This way, a contract generated by an LLM may satisfy Section 10 while still failing to capture the parties’ intended allocation of rights and obligations. Section 10 validates the resulting document without addressing the possibility that the text itself is a product of probabilistic error. This structural limitation reflects a deeper tension, as the foundational concepts of offer, acceptance and consent ‘remain pertinent’ in digital contexts, yet their implementation in contemporary scenarios frequently results in ambiguity and inconsistency. LLM contracts end up compounding this limitation.

This was played out in a study on LLM-based risk detection in Indian commercial contracts, where it was observed that a vendor agreement whose indemnity clause, read with its limitation of liability clause, had left the vendor liable for data breach without a time limit or definition. The defect surfaced eighteen months later, by which time litigation costs had consumed the contract’s entire annual value.

Further on, existing doctrines offer limited assistance. For example, a mistake under Sections 20-22 requires a shared erroneous belief, yet a contractual deepfake may involve no mistaken belief at all. Rectification under Section 26 of the Specific Relief Act, 1963 presupposes a provable prior common intention distinct from the document, an assumption which may fail where the LLM-generated text was the only draft. The result, therefore, is that a contract becomes formally valid, electronically enforceable under Section 10A of the IT Act, and admissible, yet is detached from the bargain the parties believed they had reached. In Karti Chidambaram v. Union of India, it was held that morphed and manipulated content falls within defamation and cybercrime law where it misrepresents a person. Yet there exists no judicial tool to address a contract that misrepresents the parties’ own bargain, despite the harm in both cases being the same, that is, a document that does not reflect reality.

Conclusion

Contractual deepfakes is not a drafting problem but rather a consequence of how LLMs generate text and the law having no answer for it. The concept of good faith that parties cannot meaningfully assess whether a generated document reflects their bargain is precisely what Section 10 does not solve or was designed to catch.

 As adoption of LLMs increases, the gap will not close on its own, as the growing reliance on these tools makes intervention more urgent, not less. As this article has shown, the problem posed by LLM-generated contracts is structural rather than supervisory. The failure lies not in the absence of human review but in the absence of any doctrinal standard capable of asking whether the generated text faithfully captures what the parties intended.

What this calls for, then, is a doctrinal response that goes further. One that draws on the emerging judicial recognition of fairness and good faith in Indian contract law to develop a reliability standard and in doing so, asks whether Indian contract law possess the doctrinal tools to assess not merely whether an AI-generated contract is valid, but whether it is the contract the parties actually made.

About the Author– 

Divyaansh Kharbanda is a 5th Year Law student currently pursuing B.A L.L.B from Jindal Global Law School, Sonipat. His interest lies in exploring corporate law and its intersection with artificial intelligence.

Image source- https://www.paxton.ai/topics/contract-drafting-ai-streamline-your-contract-creation-with-paxton-ai.

Leave a Reply


Discover more from NICKELED AND DIMED

Subscribe now to keep reading and get access to the full archive.

Continue reading