Companies negotiating AI-related contract provisions increasingly have to balance innovation flexibility with evolving regulatory rigidity. In this episode of We Get Privacy, co-hosts Joe Lazzarotti and Damon Silver discuss the AI clauses increasingly appearing in vendor and customer agreements and share practical strategies for negotiating them in alignment with a company’s AI governance program.
Transcript
Joe Lazzarotti
Principal, Tampa
Welcome to the We Get Privacy podcast. I’m Joe Lazzarotti. I’m joined by my co-host, Damon Silver. Damon and I co-lead the Privacy, AI, and Cybersecurity group here at Jackson Lewis. In that role, we receive a variety of questions every day from our clients, all of which boil down to the core question of how do we handle our data safely? In other words, how do we leverage all the great things we can do for our organizations without running headfirst into a wall of legal risk? How can we manage that risk without unnecessarily hindering our business operations?
Damon Silver
Principal, New York City
In each episode of the podcast, Joe and I talk through a common question that we’re getting from our clients, and we talk it through in the same way that we would with our clients, meaning with a focus on the practical. What are the legal risks? What options are available to manage those risks? And what should we be mindful of from an execution perspective?
Joe, our question for today is: many of our clients are now finding that when they receive contracts from a counterparty, whether our client is a vendor to another party or entering into some type of partnership, that agreement has a number of provisions that impact how our client uses AI or what type of liability exposure our client has based on its use of AI.
What I thought we could talk about today is what some of the key things are that our clients and listeners should be mindful of when reviewing an MSA or DPA they receive from a counterparty, both from the standpoint of negotiating that agreement and from the standpoint of whether they have to make changes to what they’re doing from an AI governance perspective, either broadly or specific to that particular engagement.
Lazzarotti
That’s a great question, Damon. If I’m in-house counsel, or we’re outside counsel working with in-house counsel to deal with these questions about these kinds of agreements, the first thing I’m probably thinking is: can we even agree to this? What are we doing? Does the individual negotiating have visibility into the use cases and the operationalization of those use cases? Where do we go to find out whether we can feel comfortable with them? What’s our risk? That’s really the first issue. How confident do we feel in our controls and how we manage AI in our organization?
Before I even get to any of the provisions in the agreement, I want to have a good handle on that and probably some good documentation so that if there is a dispute down the road as to whether our use of AI was in violation of the terms, we can safely assert, with documentation, that we were acting in a compliant manner.
Putting that aside, another question is: how important is that customer? Maybe we realize we have more gaps in our AI use than expected. Do we need this customer? How important is the relationship? We might not want to go down that road if the gap is too large and it’s simply not worth it. We may not want to negotiate in a way that appears to downplay those issues.
If we reach the point where we feel we have a reasonably strong program, or it makes sense to move forward, and we start digging into some of those clauses, one thing that comes to mind is: what exactly are the restrictions the customer is trying to impose, and can we live with them? I don’t know if you’ve seen particular restrictions that are of concern when customers are in that situation.
Silver
That’s a great question, and you made some good points around the importance of understanding what you can and cannot agree to.
To add to that, one question is how siloed your AI use is. Are there certain uses of AI that permeate everything you’re doing, making them impossible to unwind for a particular customer? Or are they more targeted, such that for specific engagements you can change how you use AI or even cease using it without disrupting what you’re doing elsewhere?
I haven’t seen too many blanket restrictions on the use of AI, but I’ve seen restrictions on what data the AI can process. For example, prohibitions on processing confidential information or personal information. That can be challenging because confidential information is often defined very broadly in MSAs. It may encompass virtually anything related to the counterparty’s business. One thing to think about is whether you need to redefine confidential information or use another term to create a narrower category of data that cannot be processed using AI.
I’ve also seen requirements to use enterprise AI tools, so the data remains within a controlled environment. Along similar lines, parties often want assurance that the data won’t be used to train the models underlying those tools.
I’ve also seen restrictions on using AI to make decisions. The concern there is that a client’s use of AI could trigger obligations for the counterparty under laws such as the CCPA regulations, the Colorado AI Act, or the EU AI Act.
Those are some of the places where I’ve seen parties attempting to contractually restrict AI use. In some cases, those restrictions may not be an issue. In others, they may be impossible to accommodate unless they’re narrowed. That might mean limiting the restriction to a specific subset of data or focusing on particular AI-enabled activities. For example, can we use AI to create transcripts and notes from meetings between the parties? Can we use AI to perform certain analyses on our end? Usually, there’s some interplay between restrictions and responsibility. Some counterparties may say that you can use AI, even to process confidential information, but you must assume responsibility for breaches, inaccuracies, or biases.
That’s another thing to consider. Is your AI governance program mature enough that you’re comfortable assuming those risks? Or do you lack visibility into whether data remains secure and whether the appropriate testing has been done to ensure tools function properly and are free from bias? Those two pieces fit together: the restrictions and the responsibility if things go awry.
Lazzarotti
We were talking earlier about disclosure requirements, and that ties into governance. The contract can be signed, everyone can be happy, and then suddenly you have a change management issue because AI develops rapidly. New features and capabilities are constantly being added.
You may have a clause requiring you to notify the customer whenever you make changes involving AI. If you don’t have a strong governance structure, including a solid inventory of AI use cases and how they change, as well as a record of contractual obligations, managing compliance becomes difficult. A lot of times we focus on legal obligations, upcoming amendments, and new regulations. Managing contractual obligations is also critical.
Related to that, what are you seeing with traditional “compliance with all laws” clauses? Most agreements contain them. Now we’re seeing provisions requiring parties to represent, warrant, or agree that they comply with all AI-related laws. That’s an important distinction. How do you address those provisions?
Silver
The key point is that you want to narrow those provisions as much as possible and be as clear as possible about which laws you’re agreeing to comply with and in what role. Many of these laws impose different responsibilities depending on the role you’re playing. You want clarity regarding your role, the counterparty’s role, and even the role of third parties such as AI developers.
Generally speaking, I try to push back on those provisions as much as possible. My concern is that they can be weaponized if a dispute arises. Even if a dispute is unrelated, someone may discover that you failed to comply with a notice requirement or missed an opt-out obligation and use that fact to create leverage.
For example, in a DPA context, parties often try to include language stating that you represent and warrant compliance with all applicable data privacy and security obligations. That could include notice requirements or obtaining consent. If the other party later experiences a breach, they might argue that the breach was broader than it should have been because you failed to obtain consent and represented that you had done so.
I’ve had mixed results negotiating these provisions. Sometimes I can eliminate them entirely or heavily narrow them. Other times counterparties insist on them because they don’t control those aspects of your compliance and want assurance that you’re meeting your obligations. To the extent the law doesn’t require a representation to the other party, I’m generally reluctant to make one. Still, some counterparties feel strongly that at least some version of that language belongs in the agreement.
Lazzarotti
I agree. There’s often a tendency, for good reasons, to insert qualifiers such as “material” so that parties agree to avoid material violations of applicable laws rather than incidental issues.
Sometimes it’s difficult to know at the time of contracting what will ultimately be material. It may be better to be more specific about what you’re asking us to comply with rather than relying on broad, general language. Occasionally the other side says, “What do you mean? You can’t agree to comply with all laws?” But it’s not that simple. You need to think carefully about what representations you’re making and which role you’re playing.
That also gets back to managing services and managing the contract. Sometimes you’re helping a customer, and they ask for a small additional task outside the agreed scope. You want to help, but suddenly you’ve stepped outside carefully negotiated provisions regarding responsibility and liability allocation. That can create increased risk.
It’s imperative to maintain communication between the individuals negotiating the agreement and the teams implementing it. There should be ongoing dialogue about whether the organization can comply with these obligations and how changes will be handled if circumstances evolve.
Another issue relates to audit rights. Sometimes we’re required to accept terms granting customers audit rights. What does that mean when our systems contain other clients’ data or proprietary operational information? How should organizations approach those provisions?
Silver
Two thoughts come to mind.
First, proactively think about whether you have intermingling of data and systems. This is important not only for AI-related terms but also for broader privacy and security obligations. Intermingled systems create complications when a party seeks to exercise audit rights or when you’re responding to an incident involving a particular customer. As part of data mapping and other governance activities, organizations should think about how to structure operations to better handle those situations.
Second, regarding audit obligations, a good starting point is providing documentation that you control, whether internally generated or created by an independent third party. That’s often sufficient. If the other party seeks something more invasive, which sometimes happens, you should tailor audit rights to the specific activities relevant to that engagement. Sometimes broad contractual language gives a customer rights to review all systems and all AI usage. That may not even be their intention, but the language can be drafted broadly enough to create that result.
Again, this comes back to governance. If your AI use is structured and segmented, you can credibly explain that a specific set of AI activities relates to that customer, while other AI uses have nothing to do with them. That’s much easier when you’ve done the front-end analysis and implemented a framework that keeps activities controlled and distinct rather than intertwined across the organization.
Lazzarotti
Another provision worth focusing on involves insurance clauses. Often, when we’re representing clients, we want vendors to maintain certain levels of insurance coverage. When those requirements are imposed on our clients, they need to understand exactly what coverage exists, what the sub limits are, how different policies interact, and what the policies actually cover.
It’s also important to remember what representations were made during the underwriting process. If an organization changes course and begins providing services that differ materially from what was represented to insurers, that can create problems.
This all reinforces the importance of understanding your business, your risks, and any hidden issues before negotiating these provisions. You need to know what range of contractual commitments is acceptable.
I don’t know if you have additional thoughts on the insurance side, Damon, but it’s another issue that frequently arises when dealing with AI-related contractual obligations.
Silver
A related area to be mindful of is indemnification and limitations of liability. I’ve seen situations where the use of AI changes those provisions. A counterparty may propose a carveout from a liability limitation or even a higher liability cap specifically because AI is involved. In some cases, organizations may be comfortable with that. One reason may be confidence in insurance coverage. Another may be that AI is central to the services being provided. It’s still something to approach carefully and push back on where appropriate.
Similar to the privacy and security context, it’s not unusual for violations of DPA to be carved out from general liability caps. The question is whether AI should automatically receive the same treatment. I wouldn’t say yes reflexively. It depends heavily on how AI is used and whether it materially changes the risk profile for the counterparty. If it does, perhaps a reasonable adjustment is appropriate. If it doesn’t, the argument should be that AI isn’t creating any additional meaningful risk, so the standard liability cap should continue to apply.
Lazzarotti
One other provision worth focusing on relates to subcontractors. We may be relying on subcontractors to help us satisfy contractual obligations, but we may not fully understand how they’re using AI. As part of evaluating these provisions, it may make sense to increase visibility beyond internal operations and ask whether we can comply not only because of what we’re doing, but also because of what our subcontractors are doing. Their use of AI may not align with our obligations under the agreement.
Any other thoughts on this?
Silver
One final term I’ve seen frequently is human review or human-in-the-loop requirements. What have you been advising clients when they receive obligations requiring a human to review every AI output or requiring significant human involvement whenever AI informs a decision?
What are some of the key things you’re considering in those situations?
Lazzarotti
Part of it depends on the nature of the services. Is this a high-risk AI service or a lower-risk one? Accuracy is always important, but it’s necessary to balance those concerns against the nature of the service being provided.
One issue that comes up frequently in organizations managing cybersecurity threats is the concept of “eyes on glass.” How many people are actively monitoring systems, alerts, threats, and patching activities? There can be concern that there isn’t sufficient staffing to perform all those tasks. Organizations should understand whether their teams can meet the service level commitments they’ve made while also complying with any human review requirements.
Those are two of the major considerations that come to mind.
Silver
That might be a good place for us to wrap up, Joe.
There’s a lot to discuss in this area, and it’s evolving rapidly. If new developments arise as we continue reviewing agreements and negotiating these terms, perhaps we’ll do a supplemental episode.