How to Draft Performance Warranties in AI Contracts (PDF Checklist)

“Materially in Accordance With.” Question whether “materially in accordance with the Documentation” promises something less than the documentation. Flag a qualifier that may turn a documented 80 percent into a warranted 75 percent. Query the use of “materially” and “substantially” in one sentence, which raises whether the two terms mean different things.

“Outputs Will Be Substantially Accurate.” As the customer, keep conformance and accuracy as separate promises, as this sentence does. Replace “substantially accurate” with a precise definition. Test the definition against a tool that cites its sources 100 percent of the time but gives a problematic answer 75 percent of the time. Identify what you need to be accurate and negotiate those points, especially in a high-risk use case where one error can be a problem.

“Customer’s Intended Use.” Vendors may want to avoid tying the warranty to “Customer’s intended use.” Expect the customer to control that use, often out of the vendor’s view. Expect the use to change, even in a custom development build. Explore naming the use cases in an exhibit, with a metric, a data set, and a threshold for each one.

“Vendor’s Benchmark Testing.” Agree on who conducts the benchmark testing and on the testing methodology, and lay out both in detail. State the data set, the standard, and the period, such as 10,000 application programming interface (API) calls over a week. Write objective terms that help both sides resolve differing results.

“At General Availability.” Expect general availability testing to use the vendor’s own data set, not the customer’s. Plan for your own messy data, which was not built for the system, to produce different results. Ask for testing on a customer data set, re-measured on each model change, with the results provided to the customer.

“Free From Material Errors.” As a vendor, strike the promise that Outputs will be free from material errors. Expect wrong answers as part of a model’s normal operation. Weigh the risk that one bad output can support a breach claim. Offer an error rate stated as a percentage across a defined sample and a stated volume of transactions.

“Warranty Period” and Model Versions. Define the length of the “Warranty Period,” which this agreement never sets. On the vendor side, watch for a promise that applies to every model the vendor ships during the period, including retrained models it has not benchmarked. Propose a period that starts at each release and a fresh benchmark whenever the model changes.

“Sole Remedy” for Vendors. As a vendor, consider naming correction, re-performance, or a credit as the exclusive remedy, because a commitment with no stated remedy leaves general damages available. Watch for the argument that an exclusive remedy fails of its essential purpose where the fix never works. Expect that argument, if it succeeds, to remove the limit on the customer’s recovery.

“Next Scheduled Release.” As the customer, avoid a cure tied to “the next scheduled release,” which lets the vendor’s release calendar set the cure date. Ask for a specific cure period the vendor can meet, and discuss it up front. Require a termination right with a refund of prepaid fees if the cure period passes without a fix.

Remedies Beyond Termination. Name the consequence of a warranty failure, because giving the customer recourse is the purpose of a warranty. Look beyond termination, which vendors tend to offer, to a correction within a stated number of days, a credit, a cure for nonconforming parts, or a performance-based audit. As the customer, weigh the difficulty of onboarding and embedding a tool before accepting termination as the only remedy.

Cure, Escalation, and Termination. Weigh a structured process of a remedy period, then escalation, then arbitration or termination, for problems that are not severe. As the customer, keep the right to terminate on day one for a problem serious enough to threaten the business. Review existing agreements for this cure and escalation structure, because tools that added AI features may still operate under older terms.

Damages Exclusions and Liability Caps. Work out what damages your organization could suffer before relying on litigation or arbitration as the ultimate remedy. Determine whether those damages count as direct damages. Check whether they fall under a gross negligence, intentional misconduct, or fraud carve-out to the exclusions of consequential and indirect damages. Compare the limitation of liability, such as 12 months of fees, against the harm from a significant issue.

“Modifies Any Prompt.” Distinguish the standard software as a service (SaaS) exclusion for code changes the vendor did not approve, which can be reasonable, from an exclusion for modified prompts, inputs, or configurations. As the customer, confirm that the exclusion leaves you recourse for a tool built for customization. Limit the exclusion to use outside the documentation, with a carve-out for configurations the vendor recommended.

Indemnity Carve-Outs for Configuration. Check the indemnity for a similar carve-out for custom configuration. Align the warranty exclusion with the indemnity carve-out, because both can remove the customer’s protection for the same customization. Mark up both provisions together rather than one at a time.

Customer Prompts and Agent Data. As a vendor, consider conditioning any quality warranty on the documented use and the stated input requirements, because a poorly written prompt tends to produce poor output. Factor in customer-permitted agents that pull data from the internet or other databases. The vendor may have no insight into those sources.

Acceptable Use Policy Compliance. As the customer, answer a vendor’s argument that you control prompts and inputs by pointing to your compliance with the vendor’s acceptable use policy (AUP). Tie the argument back to the job the tool is expected to do. Check how the hyperlinked AUP interacts with the enterprise agreement you are negotiating.