When the AI fails, whose problem is it?

AI contracts are not ordinary software contracts

Buying an AI tool feels like buying software, but the risk profile is different and the contracts are written to reflect that and can be in the vendor's favor. An AI system can produce a discriminatory output, hallucinate a false statement, leak data it was fed, or behave in ways no one fully predicted, and the central question every AI vendor contract is silently answering is: when that happens, whose problem is it? Almost always, the contract is drafted so the answer is “yours, the customer.” Reviewing one properly means reading past the performance promises to the liability architecture underneath, because that is what determines your actual exposure when the system does something you did not expect.

What the vendor is actually promising

Marketing language and contractual commitment are very different things. The demo shows the system working; the contract often promises remarkably little about it. The review questions are concrete: Does the vendor warrant the system's accuracy or performance at all, or is it provided “as is”? Does it commit to anything about bias, compliance with laws like HB 3773 or BIPA, or the provenance of its training data? What are its security and data-handling obligations? What happens to your data — is it used to train the vendor's models, and can you stop that? The gap between what a salesperson says and what the contract guarantees is where customers get hurt, and closing that gap is the point of the review.

Where liability lives — and what the carve-outs eliminate

The heart of an AI contract is the liability and indemnification structure, and it is usually built to protect the vendor. Limitation-of-liability clauses commonly cap the vendor's total exposure at something small — often the fees paid — while disclaiming consequential and indirect damages entirely, which can leave a customer facing a large regulatory or class-action liability with only a token contractual remedy against the vendor that supplied the tool. Indemnification provisions are where the real sleight of hand happens: a vendor may offer indemnification that sounds protective but is hollowed out by carve-outs — excluding exactly the AI-specific risks (bias claims, IP-infringement in outputs, data-related claims) that you most need covered. Reading what the carve-outs actually eliminate, rather than that an indemnity exists, is the difference between protection and the illusion of it.

Reviewed by someone who knows what these systems do

An AI vendor contract is easier to evaluate when you understand the technology it governs — what these systems are actually capable of, how they fail, and where the realistic risks sit. Adam reviews AI vendor and procurement contracts from exactly that vantage: as the architect of a production multi-agent AI system who governs AI daily and holds the AIGP credential, he reads the contract against how the technology behaves, not just as a document. That means spotting where a promise is meaningless because the system cannot actually deliver it, and where a carve-out eliminates coverage for the failure mode most likely to occur. Vendor review also frequently connects to BIPA (if the tool touches biometrics) and to governance and employment compliance, so the contract is read in the context of the laws it implicates.

A defined, deliverable scope

AI vendor-contract review is well suited to a flat-fee or hourly scope: a focused review of a proposed agreement, a redline of the liability and indemnification terms, and a plain-English summary of what the customer is actually agreeing to and what to negotiate. For organizations procuring AI repeatedly, the firm can also build a standard set of AI contract requirements so procurement is not negotiating from scratch each time. The objective is simple — that you sign knowing where the risk sits, rather than discovering it after the system fails.

Reviewed in coordination with your security, privacy, and IP counsel

An AI vendor contract rarely sits in a single lane. The same agreement touches data security, privacy, intellectual property, and the rules of whatever jurisdictions the tool will actually be deployed in — including the developer-to-deployer documentation duties that newer state automated-decision laws are beginning to impose (Colorado's revised AI law, for example, moves toward requiring vendors to give deployers specified documentation, with obligations scheduled to begin in the future and best verified against the current statute). The firm leads the AI-specific review — the liability architecture, the data-use terms, the performance and compliance promises — and coordinates with the client's security, privacy, and IP counsel, and with local counsel where a deployment's jurisdiction requires it, so the contract is evaluated as one connected risk rather than reviewed in silos. Leading the AI layer while coordinating the specialist layers is how a procurement decision gets read for the failure modes that actually matter.

What usually goes wrong

The recurring failure is signing on the strength of the demo and the marketing, without reading the liability architecture — then discovering, after the AI produces a harmful or non-compliant output, that the vendor capped its liability at the fees paid and disclaimed everything else. A close second is trusting an indemnification clause because it exists, without reading the carve-outs that exclude the exact AI-specific claims (bias, IP infringement in outputs, data misuse) the customer most needed covered. The third is missing the data-use terms — agreeing, often unknowingly, to let the vendor train its models on the customer's data, with consequences for confidentiality and competitive position that surface much later.

Related

• AI Governance Frameworks & Policy →
• BIPA Compliance →
• AI Risk, Incident Response & Liability →