This website uses cookies

Read our Privacy policy and Terms of use for more information.

Contracts written for traditional SaaS do not hold up when an AI model sits in the middle of the relationship. Uptime metrics miss model performance. Data return clauses ignore fine-tuned parameters and pipeline logic. Audit rights default to once-a-year frameworks that cannot respond when something actually goes wrong. The result is a stack of provisions that look fine on a first read and fall apart at the exact moment they need to work.

That gap was the focus of a recent How to Contract webinar hosted by Laura Frederick and featuring Matt Kohel, a Partner at Saul Ewing who leads the firm's AI group, and Tamra Moore, Acting General Counsel at Vantage Score. The conversation worked through three Claude-drafted AI slop provisions, one from a vendor perspective and one from a customer perspective. Matt brought the vendor lens and the litigation experience to call out what cannot actually be promised. Tamra brought the in-house customer lens and the operational instinct for where the language quietly leaves money and leverage on the table.

The discussion covered service availability and recovery, data portability and vendor transition, and audit rights. It surfaced the defined-term gaps that swallow whole obligations, the force majeure carve-outs that sweep too broadly, the retention windows that collapse under contentious terminations, and the audit clauses that customers technically have but cannot exercise. It also touched on what happens when a low-stakes AI use case quietly grows into a high-stakes one while the contract stays static.

Here are our top ten takeaways from the speakers' comments during the webinar:

  1. Stop using uptime as the only availability metric. Uptime measures whether the system is responding, not whether it is producing useful output. An AI system can be 99.5% available and still serve degraded, biased, or wrong results. The contractual lever has to pair availability with performance metrics that match what the customer actually bargained for. Otherwise the SLA is measuring the wrong thing, and the most beautiful language in the world cannot save it.

  2. Capitalize defined terms or define them inline, not both inconsistently. The provisions discussed in the webinar randomly capitalized "System," "Customer Data," and other terms in some places while leaving them lowercase in others. That ambiguity is not cosmetic. It changes whether a sentence references a contractual term of art or a generic concept. Lawyers who let this slide are quietly accepting that the heavy lifting in their contracts is being done by undefined words.

  3. Treat force majeure carve-outs as scope traps, not boilerplate. The phrase "factors outside vendor's reasonable control" sweeps in third-party model providers, cloud failures, and API dependencies that the vendor chose to rely on. That is not a force majeure event in any meaningful sense. The fix is to specify that downtime caused by vendor-selected subprocessors and third-party model providers does not excuse performance unless the customer approved that reliance in writing.

  4. Treat scheduled maintenance as a product-change limit, not just a time limit. A scheduled maintenance carve-out without limits on frequency, duration, or scope of changes lets the vendor reclassify model version updates as maintenance and degrade performance under the guise of upkeep. Cap the hours per month, and prohibit model version updates that alter functional outputs without prior written customer consent. A maintenance window that changes how the model behaves is not maintenance.

  5. Recovery point objectives are not obligations unless you write them as obligations. A contract that names an RPO but does not say what happens when it is missed has not created a remedy, just a target. Specify that if actual data loss exceeds the RPO, the vendor must notify the customer within a defined window, identify the scope, and deliver a remediation plan on a defined timeline. Otherwise the RPO is a sentence in an exhibit and nothing more.

  6. Data return is an operational problem, not a file transfer. AI relationships involve fine-tuned model parameters, prompt configurations, output data used as training, and pipeline logic that all live in the vendor's environment. Returning a copy of "customer data" in a "machine readable format" does not mean the customer can operate. Define the format, specify what categories of data are included, and build in an operational transition period, not just a delivery deadline.

  7. Vendor retention windows need to leave room for contentious terminations. A 60-day retention window plus a 30-day delivery window can mean the customer has 30 effective days to request a return, which is not enough when the parties are fighting. Extending retention to 180 days with a 30-day vendor compliance window after a request gives the customer practical room to actually exercise the right. And require notice before deletion, with no deletion while a return request is pending or a dispute is open.

  8. Split audit rights into routine and performance-based. Trying to do both with one annual, notice-required, customer-pays clause does both badly. A routine audit on standard terms covers compliance. A performance-based audit triggered by defined events like material service failures or credible indications of noncompliance, with shorter notice and outside the annual cap, gives the customer the responsiveness that actually matters when something goes wrong.

  9. Shift audit costs when an audit reveals a material breach. Customer-pays-all is the default and creates a disincentive to ever exercise the right. Build in a clause that requires the vendor to reimburse the customer for reasonable audit costs if the audit uncovers a material breach. That converts the audit right from a tax on the customer into a real risk for the vendor.

  10. Revisit your contracts when the use case shifts. A contract signed for a low-stakes AI use does not automatically scale to a high-stakes one. Resiliency, audit, and liability provisions should be treated as living obligations. Building use-case classification triggers into the contract, with amendment obligations when the customer's use moves into higher-risk categories, prevents the slow drift where everyone forgets that the original contract was negotiated for a different deal.

Subscribe to Stay in the Loop

Our weekly newsletter rounds up upcoming How to Contract webinars and recaps like this one, so the practical insights land in your inbox whether or not you caught the session live. Subscribe now to stay current on what is coming next.