The phrase "compliance with applicable AI laws" is only five words long, and almost every one of them now carries a different load than it did a few years ago. The parallel-path compliance model that contract lawyers grew up with, where the vendor's obligations and the customer's obligations rarely touched, has been shattered by AI products that require continuous cooperation between the two sides. Old boilerplate keeps clearing redlines and then quietly failing in practice, which is why so many of these provisions are worth a fresh look.
This was the focus of a recent How to Contract webinar hosted by Laura Frederick with Shavon Smith, an attorney in Washington, DC who serves as fractional general counsel for growing businesses, and Deborah Weisman, Deputy General Counsel at HireVue. Shavon brought the vendor lens, including the cross-industry exposure that smaller AI vendors live with every day. Deborah brought a daily customer-side compliance perspective from inside an AI-driven talent acquisition company. Between them, they pressure-tested how these clauses actually behave once the product in question is built on AI.
The conversation walked through three sample provisions drafted by Claude, a definition of applicable law, a vendor compliance representation and warranty, and a change of law clause with a sole-remedy notice-and-cure. Each one looked reasonable on the page. Each one fell apart on closer inspection. The panel pulled out where the words sound innocent but quietly shift risk, where the structure of the clause undercuts the protection it appears to offer, and what to do differently.
Here are our top ten takeaways from the speakers' comments during the webinar:
The parallel-path compliance model is dead for AI products. Old contracts treated vendor compliance and customer compliance as separate tracks that rarely intersected. AI products require continuous cooperation between vendor and customer to satisfy each party's own obligations. Drafting that does not reflect that interdependency is drafting from a world that no longer exists. We have to start by recognizing that compliance is now a shared workflow, not a parallel one.
Treat the definition of applicable law as the most important provision in the contract. Compliance with laws is a clause that depends entirely on what gets pulled into the defined term. A definition that snapshots law as of the effective date, omits supervisory guidance, ties jurisdiction to the contract's subject matter rather than to the actual activities, or ignores cross-border reach hands every downstream clause the same gaps. Get the definition right or expect to lose the argument later about what was actually covered.
Use both a rep and a covenant for ongoing compliance. A rep and warranty answers a yes/no question about a moment in time. A covenant carries an ongoing obligation across the term. AI compliance needs both. The rep covers delivery. The covenant covers every update, every regulatory change, and every operational moment after that. Picking one form and not the other leaves coverage gaps that look invisible at signing.
Pay close attention to the limitation of liability for AI compliance breach. The old approach of leaving compliance-with-laws indemnities uncapped was built for a world where non-compliance was rare, severe, and the sole responsibility of one party. AI compliance involves shared responsibility, and that breaks the assumption. Indemnities now need carve-outs for breach caused by the other party's failure, and super caps need to be rethought for AI obligations that look like compliance and behave like operational uptime.
Watch for the words that look harmless. "In all material respects" is set by the customer's industry, which a cross-industry vendor cannot control. "As delivered" turns into ambiguity about whether each update creates a fresh rep. "Made by or on behalf of Customer" can sweep in routine prompt engineering and configuration. "Inconsistent with the Documentation" is a moving target whenever the vendor controls the documentation. Each of these is small on its own and serious when combined.
Documentation is unstable, so build that instability into the contract. AI documentation often cannot keep pace with weekly or daily product changes. Pointing warranties and carve-outs at "the documentation" without addressing whether and how the documentation can be updated leaves the standard floating. Customers should constrain the vendor's right to amend documentation unilaterally. Vendors should standardize what they produce so a thousand customers do not ask for a thousand variants.
Run the "sole remedy" check on every compliance clause. A sole remedy that consists of more notice and another opportunity to cure is not a remedy. It is a delay. When the only thing the customer can do after the vendor fails is ask the vendor to try again, the customer has no leverage. At minimum the clause needs a termination right when cure fails. A reduction in fees during the cure period is usually appropriate too.
Allocate change-of-law costs explicitly. "Each party bears its own costs" sounds neutral and is not. It defaults to whichever party can absorb the surprise bill. Better drafting names which kinds of modifications belong to the vendor (core product changes), which belong to the customer (redeployment and integration), and what happens when the work splits across both. Multi-tenant platforms will not customize for one customer's regulatory environment, so customers in regulated industries should call their specific obligations out by name.
Distinguish the design-and-development role from the deployer role. The most common mistake the panel flagged was vendors warranting things they cannot see and customers expecting coverage for choices they actually controlled. Vendors should not warrant permitted use they have no visibility into. Customers should not assume the vendor's operational rep covers what the customer chose to do with the product. Using the terminology that fits each party's actual role is one of the few clean ways to keep liability where it belongs.
Understand the technology before negotiating the clause. Both veterans and newer lawyers fall into the trap of fighting over words on the page without first understanding what the product actually does. From the in-house seat, that context usually comes with the job. From the law firm seat, it is a day-one question. The clauses look complicated because the underlying technology is complicated, and skipping the technology will produce a contract that is correct on the page and useless in the real world.
Subscribe to Stay in the Loop
If you want more of these recaps and a heads-up on upcoming How to Contract webinars, our weekly newsletter is the easiest way to keep up. Subscribe now and the next one will land in your inbox.
