AI risks do not fit cleanly inside traditional cybersecurity approaches. Model output drift, prompt injection, model extraction, and data poisoning may involve no personal data at all and no access in the traditional sense.
Laura Frederick worked through this problem in a How to Contract webinar 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.
Laura and John reviewed three sample AI provisions: an incident definition, a 72-hour notification clause, and an industry-standard security obligation. John analyzed 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 ten takeaways from the webinar:
AI incidents do not fit inside the personal data breach definition. The traditional cybersecurity framework was built around unauthorized access or acquisition of personal information. AI failures, model manipulation, prompt injection, and data poisoning may not involve any access at all and no personal data. If your contract's incident definition is built only on the data breach model, you may be missing entire risk categories. Map the risks to your specific deployment first, then write the definition.
"Material adverse effect" plus "vendor's reasonable discretion" leave the customer with few choices. When the vendor gets to decide what meets these criteria, the customer is left having to argue unreasonableness. But customer may not have enough facts in these situations to do that. 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 pointed out that if the documentation is silent on the relevant operational promise, requiring the vendor perform “in accordance with the documentation” doesn’t help. Before signing, dig into the documentation and confirm the operational commitments are there. If they do not, the contract reference is decorative.
Question each carve-out the same way you question every commitment. Be careful about carveouts for scheduled maintenance, routine performance fluctuations, and customer's failure to follow published guidelines. The underlying terms have to be defined clearly. 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 may be 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 like NIST, MA regulations, GLBA, and 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 security team or CISO before finalizing the list.
"Reasonable efforts" and "confirmed security vulnerability" can be hollow. 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 regularly and the recap lands in our newsletter in case you didn’t attend or want to share the insights with your team. Subscribe now to get the practical takeaways delivered, whether or not you make it to the live event.
