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

Laura Frederick, Laura Belmont, and Bill Price tackled standard limitation of liability provisions for data and AI claims, including fee-based caps, data breach and AI categories, consequential damage waivers, and super caps.

Limitation of liability provisions traditionally were designed for property damage, personal injury, and IP infringement, harms that are largely foreseeable and proportional to contract value. That structure does not match what happens when a vendor processes millions of records for a few thousand dollars a year, or when an AI model produces flawed outputs over months that nobody catches until the damage is done.

That mismatch was the focus of a How to Contract webinar hosted by Laura Frederick and featuring Laura Belmont, General Counsel at The L Suite (Tech GC), and Bill Price, a three-time tech General Counsel now doing fractional work. The conversation worked through three core problem areas in standard limit of liability language, with Bill taking the vendor angle and Laura Belmont taking the customer angle on the same AI-drafted sample provisions.

Data and AI contracts introduced a different risk profile for contracts. Laura Belmont made the point that a liability cap tied to twelve months of fees worked as a rough proxy when contract value tracked vendor exposure. Now with vendors processing millions of records for tens of thousands of dollars a year, sometimes less, a data breach causes contractual loss, regulatory exposure, class actions, notification costs, and reputational damage far beyond the fees paid.

The other structural challenge is standard liability limitation provisions assume a single identifiable event with a date and a scope. AI harm did not work that way. Bias in a model, systematically flawed outputs, or compounding errors across iterative don’t show up as a discrete incident. Weeks or months could pass before anyone identified that something was wrong. So how do we apply the calculation to determine the cap in these cases? Was every use of the tool a separate event? Was the whole pattern one event? Contract s usually don’t say.

The exclusions lists face similar problems. Some carve-outs are based on a physical world, such as bodily injury and property damage. The harms that mattered for data and AI claims are more likely to be regulatory fines, consumer protection issues, and reputational injury. They don’t fit those categories. Lawyers have to decide whether to fit AI and data harms into standard exclusions or create entirely new ones.

Bill brought the vendor side of the same picture. The limit of liability provision was almost always the last issue negotiated. By that point, price had usually moved in only one direction, which was down, and the customer wanted limits to move up. The result was an asymmetric trade. The vendor was getting a lower fee and being asked to take on more risk through expanded exclusions and higher caps. That made precision in defining what triggered a super cap or an exclusion essential. Vague terms were where the asymmetry got worse.

Laura Belmont also flagged a holistic point that ran through the entire webinar. Limitation of liability provisions had two moving parts, the cap and the exclusions, and they had to be negotiated together. A customer could win great carve out language and still get nothing if a separate cap somewhere else swallowed the recovery. The same went for definitions. A "confidentiality" exclusion might or might not cover a data security incident depending on how the definitions interacted. The provision had to be read as a system, not as a clause.

Laura Frederick shared this problematic AI-generated draft provision for the speakers to review and discuss:

This provision capped vendor liability at two times the fees paid in the prior twelve months or one hundred thousand dollars, whichever was greater. The language looked familiar. That was part of the problem.

Bill liked the multiplier structure but flagged the floor as a vendor concern. The floor decoupled the cap from contract value. A vendor selling for thirty dollars a month could still get hit with a hundred-thousand-dollar exposure that bore no relationship to the economics of the deal. His preferred structure was a multiplier on fees paid, with an ultimate ceiling, tied back into the overall limit of liability framework. Laura Frederick noted that a knee-jerk acceptance of a floor was the kind of habit inherited from the bricks-and-mortar world that did not survive contact with low-fee, high-record-volume contracts.

Laura Belmont came at the same number from the customer side and reached a different concern. Customer exposure was not tied to fees. It was tied to record volume, regulatory regime, and the type of data involved. Personal information, protected health information, and financial information each pulled in different cost structures for notification, credit monitoring, and regulatory penalties. Her proposed move was to introduce record-volume language into the cap calculation itself. Something along the lines of an enhanced cap for any incident affecting more than a defined number of records would not fall below a defined floor. That kept the cap structure but acknowledged the variable that actually drove exposure.

Two other issues in the sample language deserved attention. The provision pooled data security incidents and AI system failures into a single cap. From the customer side, that meant a breach and an AI error in the same year would draw from the same bucket. The fix was to treat them as distinct and independent events, each subject to its own cap. The other issue was the breadth of "arising out of or related to." That phrase could pull third-party claims into the cap calculation, which was where most of the real exposure lived. Customers had to draw a clear line between direct claims against the provider and third-party claims that should be handled under the indemnification framework instead.

The provision also ended with a reference to the mutual waiver of consequential damages. That was a drafting hygiene problem worth calling out on its own. Stuffing a consequential damages reference into a cap calculation made it easy to miss and easy to conflict with the consequential damages waiver elsewhere in the contract. Keeping subjects together, with cap mechanics in one place and consequential damages mechanics in another, was the kind of structural discipline that paid off when somebody had to litigate the provision two years later. Bill made the counterpoint that vagueness sometimes worked in the vendor's favor, but for an enhanced cap that was supposed to address consequential exposure, the lack of clarity cut against the customer.

The lesson on the cap was that the number was almost the last thing worth fighting over. The structure around the number, including whether it pooled distinct risk categories, whether it pulled in third-party exposure, whether it tied to record volume rather than fees, and whether it interacted cleanly with the consequential damages provision, did most of the actual work. Anyone who skipped that analysis and went straight to negotiating the multiplier was negotiating the wrong thing.

Laura Frederick shared this second problematic AI-generated draft provision for the speakers to review and discuss:

This provision pulled standard exclusions for third-party IP indemnification, gross negligence, and confidentiality breaches, then added a separate enhanced cap for data security incidents. It was a hodgepodge, and the hodgepodge was where the holes sat.

Laura Belmont's first point on the exclusions list was simple. What was on the list mattered, but what was missing mattered more. Exclusion lists were almost always exhaustive. Vendors did not agree to "including but not limited to" language in a carve out. Silence on AI system failures meant AI system failures were not excluded. That negative inference was the entire game, and any customer who assumed otherwise was going to lose that argument.

The second point cut deeper. Confidentiality and data security were not the same thing. A confidentiality breach might or might not cover a data security incident depending on how the contract defined each term. A vendor with a cap interest could argue either direction depending on what helped. The fix was to draw the boundary explicitly. Data security incidents should be a distinct excluded claim, separately defined and separately referenced, so the confidentiality framework did not get pulled in unless that was the result the customer actually wanted.

AI deserved the same treatment. The sample provision had no carve out that acknowledged AI-driven harm as a separate category, even though the harm profile was different from a data breach. A breach was traceable to an event with a date and a scope. AI errors were systematic, often delayed in detection, and rarely tied to a single identifiable trigger. Treating them under the same framework as a data breach lost something. Customers should make sure AI system failures, however defined, appeared as their own excluded claim and not as an afterthought subsumed under a confidentiality or data security category.

Bill's vendor-side reaction to the same language was instructive on what was actually negotiable. The IP indemnity carve out was where he wanted the most protection, particularly because customers tweaking AI tools created infringement exposure the vendor could not control. He also wanted contractual specificity tied to the functionality as of a date certain, with amendments required if functionality expanded. The wrapper problem mattered here too. A vendor wrapping a third-party LLM had limited recourse against the underlying foundational model, which meant the vendor could not promise more than the upstream agreement allowed. Customer-facing commitments had to track what the vendor could actually deliver.

Gross negligence was an easier vendor give. Many jurisdictions did not allow gross negligence to be capped, so giving it up cost the vendor less than it appeared to. Bill's caveat was to put some structure around the gross negligence carve out so it did not become a default super cap on everything. Tying the carve out to a defined standard, including an objective audit standard, was one way to do that.

Bill's second tactical point was on confidentiality. AI vendors needed to verify their insurance actually covered what the contract promised to cover. Insurance policies, like regulations, did not keep up with the technology. A contractual commitment that exceeded coverage was a problem the vendor would notice only after something went wrong.

Laura Frederick added a related warning that was easy to miss. Confidentiality sections sometimes pulled in the DPA by reference. Confidentiality sections sometimes also included publicity provisions about not disparaging the other side or harming reputation. Either could create a backdoor into a much broader exclusion than the parties intended. The rule was to read the confidentiality section every time it got referenced in a limit of liability carve out, because the reference might be doing more work than anybody noticed.

The third sample provision carved out data security obligations and indemnification obligations from the mutual waiver of consequential, indirect, special, and punitive damages.

Here’s the AI-drafted provision Laura shared with the speakers:

On the surface, it looked like a customer win. The customer was getting back the right to recover the damages that mattered most.

Bill's framing on consequential damages was worth pausing on. The waiver was rarely given for a reason. Consequential damages could be unlimited, literally and figuratively. They included both direct and indirect harm, like a customer's bankruptcy cascading into the vendor's bankruptcy because creditors lined up to recover. They were hard to define, hard to quantify, and hard to insure. Cyber policies often excluded consequential damages entirely. A vendor giving up the waiver without defining the scope and capping the amount was taking on a risk it could not price.

That meant the vendor's playbook on consequential damages was less about refusing the carve out and more about controlling it. Bill's approach was to define the damages narrowly, tie them to specific remediation obligations, and cap them in amount and time. Credit monitoring, for example, was something he was willing to take on. Identity theft protection, which could run much longer and cost much more, was not.

He also pointed to an emerging objective standard for AI risk. The Artificial Intelligence Underwriting Company standard, A IUC-1, was modeled on SOC 2 and measured AI vendors across six domains, including safety, society, reliability, accountability, and data primacy. Insurance carriers had started using it to price AI coverage. Vendors who certified to it had a defensible answer to a customer asking what objective threshold triggered the enhanced exposure. The certification was still new, and Bill expected other standards to follow, but the principle was the same. Tying a carve out to a specific external standard made the trigger auditable and made the negotiation cleaner.

Laura Belmont's read of the sample language found a problem that was almost invisible on a first pass. The carve out said the waiver did not apply to damages arising from data security obligations or indemnification obligations. That language could be read narrowly to restore only direct damages, leaving consequential damages still excluded. The biggest exposure, including breach notifications, credit monitoring, regulatory fines, and third-party payments, was almost entirely consequential. A carve out that did not affirmatively restore consequential damages within the listed categories did almost nothing for the customer.

The fix was to draft the carve out so it explicitly restored consequential damages within the carved-out categories. That was also where a customer had a chance of moving a vendor who would never agree to a blanket consequential damages waiver. Leading with the specific consequential damages the customer cared about, including notification costs, credit monitoring, specific remediation expenses, and regulatory fines, gave the vendor a defined exposure to evaluate. A blanket ask got refused. A specific ask got negotiated.

The provision also closed with a clause that subjected the restored damages to the overall limit of liability. Laura Belmont flagged this as the kind of language that quietly killed everything in the provision above it. Restoring the right to recover consequential damages did not help if the recovery was still capped at the same low fee-based number. The fix was a for-avoidance-of-doubt sentence making clear that damages restored under the carve out were not subject to the cap mechanic elsewhere in the contract.

There was also a structural cleanup point that came up at the end. The carve out said "data security obligations" without a defined term. Definitions did the heavy lifting in limit of liability provisions, and an undefined trigger was an invitation to argue. Tying the carve out to a defined data security incident, or to an objective standard like A IUC-1, removed that argument.

The questions section pulled out one more useful tactical move on consequential damages. When a vendor would not move on the cap or the consequentials, the customer could try to extend the look-back period, expand additional insured rights, or pull specific cost categories like mandatory breach notification and regulatory fines out from under the cap entirely. The point was not to get everything. It was to get the specific recovery that mattered most for the specific risks the customer was actually likely to face.

The How to Contract weekly newsletter pulls together upcoming webinars and recaps like this one. Subscribe now to keep these practical insights coming, whether you attend the live sessions or not.