How to Decide Whether an AI Agent's Promise Binds the Company That Deployed It
A customer is told by a chat interface that a fee will be waived, or that delivery will happen by a particular date, and nobody at the company decided either thing. Whether an AI agent can commit the business that deployed it is answered in Indian law by attribution first and by contract formation second, and in that order.
Step 1: Start With Attribution, Not With the Output
Section 11 of the Information Technology Act, 2000 attributes an electronic record to the originator in three situations: where it was sent by the originator himself; where it was sent by a person who had the authority to act on behalf of the originator in respect of that electronic record; and where it was sent by an information system programmed by or on behalf of the originator to operate automatically.
The third limb is the one that matters here, and it is unusually direct. An automated system that the company programmed, or had programmed on its behalf, produces records that are the company's own. There is no intermediate question of whether the system meant to say it, because the provision attributes the record by reference to who programmed the system rather than to what the system intended.
Step 2: Dispose of the Electronic Form Argument
Section 10A of the same Act provides that where a proposal, its acceptance, or the revocation of either is expressed in electronic form or by means of an electronic record, the contract is not unenforceable merely because electronic means were used. It was inserted by the Information Technology (Amendment) Act, 2008 with effect from October 27, 2009.
So the fact that the exchange happened in a chat window is not a defence, and an argument built on the medium rather than on the content of the exchange will not survive this provision. What remains is the ordinary law of formation.
Step 3: Ask Whether the Output Was a Proposal or an Acceptance at All
Attribution settles whose statement it is. It does not settle what the statement was. An output that describes a policy, estimates a timeline or answers a question is not an offer, and a system that says a refund is usually processed within a week has not promised a refund.
The analysis is the familiar one: was there a definite proposal, communicated, capable of acceptance, and was it accepted. That question should be answered before anything is conceded, which is a reason to work from the exact words the system produced rather than from the customer's account of them.
Step 4: Where the Output Went Beyond the Remit, Look at Induced Belief
Suppose the output was a definite promise that the company never authorised. Section 237 of the Indian Contract Act, 1872 addresses the closest analogous problem: where an agent does acts or incurs obligations to third persons without authority, the principal is bound by those acts and obligations if he has by words or conduct induced those third persons to believe that the acts and obligations were within the agent's authority.
The illustrations are instructive. Goods are sent to an agent for sale with a private instruction not to sell below a fixed price; a buyer who does not know of the instruction contracts below it; the principal is bound. Negotiable instruments endorsed in blank are entrusted to an agent and sold contrary to a private instruction; the sale is valid. In both the private limit is invisible to the third party, and that is why it does not travel.
Step 5: Name the Limit of the Agency Analogy
An automated system is not a person and cannot be an agent in the sense the Contract Act uses, so that provision is reasoned from rather than applied. The attribution provision is what does the work directly, and the agency material is useful because it supplies the test for an induced belief rather than because the system is an agent.
The practical consequence runs against the deploying company. A private configuration limit that the customer could not see is the same thing as the private instruction in the illustrations, and the company placed the interface in front of the customer, told the customer to use it and gave it the company's name.
Step 6: Control the Representations at Source
Since attribution follows from programming, the leverage is in the programming and in what is displayed. Three measures do most of the work: constraining the system so that it cannot express a commitment on price, timing, liability or waiver; routing anything that would be a commitment through a human confirmation step that the customer can see; and stating, where the customer will actually read it, what the interface can and cannot settle.
A limit that is visible to the customer is doing legal work. A limit that exists only in the configuration file is not, which is the whole lesson of the illustrations.
Step 7: Keep the Record of What the System Was Programmed to Do
Retain the conversation log, the version of the system and its configuration in force at the time, the instructions and constraints it was operating under, and the record of any human confirmation step.
Attribution under the third limb turns on what the system was programmed to do, so the configuration record is not background material. It is the evidence on which the attribution question is decided, and it is usually overwritten long before a dispute arrives.
Common Pitfalls to Avoid
Arguing that nobody at the company said it: The third limb of the attribution provision attributes the record of an automatically operating system to the person who programmed it or had it programmed.
Arguing that a chat exchange is not a contract: Electronic form is expressly not a ground of unenforceability.
Conceding formation too early: Attribution establishes whose statement it was, not that the statement was a proposal or an acceptance.
Relying on an invisible configuration limit: A private instruction unknown to the third party is the fact pattern of both illustrations to the induced belief provision.
Treating the system as an agent: It is not a person, so the agency provision is reasoned from by analogy while attribution does the work directly.
Letting the logs roll over: The configuration in force at the time is the evidence the attribution question turns on.
Key Statutory Provisions
Section 11 of the Information Technology Act, 2000: Attribution of electronic records. An electronic record is attributed to the originator where it was sent by the originator himself, by a person who had the authority to act on behalf of the originator in respect of that electronic record, or by an information system programmed by or on behalf of the originator to operate automatically.
Section 10A of the same Act: Validity of contracts formed through electronic means. Where a proposal, its acceptance, or the revocation of either is expressed in electronic form or by means of an electronic record, the contract is not unenforceable merely because electronic means were used for that purpose. Inserted by the Information Technology (Amendment) Act, 2008 with effect from October 27, 2009.
Section 237 of the Indian Contract Act, 1872: Liability of principal inducing belief that agent's unauthorized acts were authorized. Where an agent has without authority done acts or incurred obligations to third persons on behalf of his principal, the principal is bound by them if he has by his words or conduct induced those third persons to believe that they were within the scope of the agent's authority. Two illustrations deal with a private instruction on price and with negotiable instruments endorsed in blank, in each case unknown to the third party.
Sources and References
Sections 10A and 11 in the consolidated copy of the Act, with the amendment footnote
Section 237 of the Indian Contract Act, 1872, with its illustrations
Information Technology Act, 2000, sections 10A and 11, and the Indian Contract Act, 1872, section 237
Disclaimer: This article is for informational purposes only and does not constitute legal advice. Readers should consult a qualified legal professional for advice specific to their circumstances.
Comments