Drafting Limitations of Liability for Data and AI Claims: Webinar Recap

The standard limit of liability template no longer matches the risk profile. The clause allocated risk for foreseeable, discrete harms that tracked contract value. Data and AI exposure does not work that way. A vendor processing millions of records for a few thousand dollars a year can generate breach exposure orders of magnitude larger than the cap. Recognize that the starting template is the problem, not just the numbers inside it.

Read the cap and the exclusions as a single system. Beautiful carve out language did nothing for the customer if a separate cap somewhere else swallowed the recovery. The cap and the exclusions had to be negotiated together. Map out what an actual incident would cost, then walk it through the full provision to see what got recovered and what got eaten by another clause. That exercise also surfaced the interplay with consequential damages, which often did more to limit recovery than the cap itself.

A floor on the super cap is a vendor problem when fees are low. A hundred-thousand-dollar floor sounded reasonable in the bricks-and-mortar world. It looked very different when the contract value was a few thousand dollars a month. Tying the super cap to a multiplier on fees, with an ultimate ceiling, kept the cap proportionate. Vendors selling low-fee AI tools should push back on inherited floor structures that no longer match the economics.

Tie the customer-side cap to record volume, not fees. A cap based on fees paid did not track exposure. Exposure tracked the number of records affected, the regulatory regime, and the type of data involved. Personal information, protected health information, and financial information each pulled in different notification and remediation costs. Adding language that triggered a higher cap for incidents above a defined record threshold pulled the provision closer to the variable that actually drove damages.

Treat data breaches and AI failures as distinct categories. Pooling them into a single cap or a single exclusion meant a customer who got hit with both in the same year drew from the same limited bucket. The harms had different profiles. A data breach was a traceable event. An AI failure was usually systematic and delayed in detection. Draft each as its own defined term with its own cap and its own exclusion treatment.

Watch the "arising out of or related to" language in cap provisions. That phrase looked like ordinary breadth-of-coverage drafting. It could also pull third-party claims into the cap calculation, which was where most of the real exposure lived. The vendor could argue every downstream consumer claim was "related to" the incident and therefore counted against the cap. Customers should make sure cap language addressed direct claims against the provider, and that third-party claims rode under the indemnification framework instead.

Confidentiality and data security are not the same thing. A confidentiality exclusion might or might not cover a data security incident depending on how the contract defined the terms. Vendors with a cap interest argued either direction depending on what helped. The customer's protection turned on a definitional question that often went unexamined during negotiation. Draw the boundary explicitly so a data security incident did not get pulled into a confidentiality framework that handled it differently.

Always read the confidentiality section when it gets referenced in a limit of liability provision. Confidentiality sections sometimes incorporated the DPA by reference. They sometimes added publicity clauses that pulled in reputational harm. Either could create exposure or recovery the parties did not intend. The reference is doing more work than it looks like.

A consequential damages carve out that does not restore consequential damages does nothing. The standard drafting pattern carved out specific categories from the consequential damages waiver but then left language in place that could be read to restore only direct damages. The biggest exposure, including notification costs, credit monitoring, and regulatory fines, was almost entirely consequential. A carve out that did not affirmatively restore consequential damages within the listed categories was decorative. Add a for-avoidance-of-doubt sentence making clear that restored damages are not subject to the cap mechanic elsewhere in the contract.

Vendors should verify insurance actually covers what the contract promises. Cyber policies often excluded consequential damages. Insurance carriers had not kept up with AI risk. A contractual commitment that exceeded coverage was a problem the vendor would notice only after something went wrong. The A IUC-1 standard was an early attempt to give vendors an objective AI risk framework, and more standards were likely to follow.