AI contracting keeps running into the same wall. The cyber framework we have used for two decades was built around personal data breaches, unauthorized access, and statutory notification clocks. AI risks do not fit cleanly inside that frame. Model output drift, prompt injection, model extraction, and data poisoning may involve no personal data at all and no access in the traditional sense. So we keep bolting old language onto new risks and hoping it holds.
A recent How to Contract webinar hosted by Laura Frederick worked through this problem with John Pavolotsky, Partner at Stoel Rives and Co-Chair of the firm's Privacy, Cyber, and AI practice. John has spent the last twenty years on privacy, cybersecurity, and complex technology transactions, including time as in-house counsel at Roku and Intel, which made him an unusually practical voice on where vendor-friendly language quietly gives away the store and what customers should actually push back on.
Laura and John reviewed three sample AI provisions, an incident definition, a 72-hour notification clause, and an industry-standard security obligation, and pressure-tested each from both sides of the deal. The conversation covered why current incident definitions miss entire risk categories, why the 72-hour clock is sometimes the wrong shape for AI, how to layer AI-specific controls on top of existing cyber baselines, and where audit rights can bridge the gaps that drafting cannot close today.
Here are our top ten takeaways from the speakers' comments during the webinar:
AI incidents do not fit inside the personal data breach definition. The cyber framework was built around unauthorized access or acquisition of personal information. AI failures, model manipulation, prompt injection, and data poisoning may involve no access at all and no personal data. If your contract's incident definition is built only on the data breach model, you are missing entire risk categories. Map the risks to your specific deployment first, then write the definition.
"Material adverse effect" plus "vendor's reasonable discretion" is a vendor's gift. Both phrases sound balanced. In practice, they push every close call to the vendor and force the customer to argue unreasonableness with facts the customer does not have. If you are on the customer side, push for objective triggers, defined performance bands, or at least a duty to share the underlying facts when discretion is exercised.
"In accordance with the documentation" only helps if you have read the documentation. John's exact point was that you can drive a truck through this language if the documentation is silent on the relevant operational promise. Before signing, dig into the documentation and confirm the operational commitments live there. If they do not, the contract reference is decorative.
Question every carve-out the same way you question every commitment. Scheduled maintenance, routine performance fluctuations, customer's failure to follow published guidelines. Each of these can swallow the obligation if the underlying terms are not defined. Ask how long, how communicated, and whether the vendor can change the rules unilaterally.
There is nothing magic about 72 hours. It is a carryover from data breach statutes that does not fit every AI incident. For some incidents you want a kill switch first, notification later. For others you want rolling updates. Build a tiered notification regime that matches severity, rather than copying a single deadline from the personal data world.
Customer-side kill switch capability is undervalued. The customer often sees outputs the vendor cannot see, and the incentives during an incident usually align. The right to stop the system, then talk, can save both sides from a worse outcome. Include it where the use case justifies it.
Match the drafting effort to the deal's exposure. If the limitation of liability caps damages at twelve months of fees on a small deal, perfecting the notification clause is the wrong place to spend an hour. Calibrate effort to risk. The notification clause matters more in proportion to how much the vendor stands to lose if it fails.
Use "industry standard" as a floor, then layer AI-specific controls on top. Existing cyber baselines (NIST, MA regulations, GLBA, HIPAA) are a reasonable starting point but do not address API rate limiting, adversarial input monitoring, training data sanitization, or model extraction defenses. List the AI-specific measures separately, in the contract or a security exhibit, rather than relying on a generic standard to cover them. The vendor knows what protections it actually runs, and there is no good reason it cannot put them in writing. Talk to your CISO before finalizing the list.
"Reasonable efforts" and "confirmed security vulnerability" are weak hooks. Push for specifics on what the vendor actually does, and tier the remediation timeline by severity, the way the cyber world tiers patching SLAs. "Reasonably suspected" is a stronger trigger than "confirmed" because it kicks in earlier in the response cycle. The patching analogy is useful here. Critical vulnerabilities patched within X days, lower-severity within Y days, applied to AI-specific issues like adversarial inputs and model extraction the same way it applies to traditional cyber.
Audit rights bridge the gaps you cannot close today. The state of AI contracting means the right number, threshold, and scope are often unknown when you draft. Broad third-party audit rights, exercised on agreed parameters, give the customer a way to maintain comfort that the vendor's controls are actually in place and working. Annual penetration testing summaries do similar work. So does the right to revisit security commitments as the use case expands or becomes more sensitive.
Subscribe to Stay in the Loop
Sessions like this run weekly, and the recap lands in our newsletter alongside the next set of webinars. Subscribe now to get the practical takeaways delivered, whether or not you make it to the live event.
