The top 5 contract terms AI vendors should watch out for in 2026
How to handle artificial intelligence restrictions from enterprise buyers.
In 2026, it’s hard to find a vendor that is not using Artificial Intelligence. Whether directly as part of its core offerings or for productivity and back-office use cases, basically every firm today leverages AI.
And customers have taken notice.
I myself have advised buyers to investigate how their suppliers process data with AI. And while that guidance still applies, I have found vendors often have trouble tackling contractual restrictions and addenda from their customers regarding AI use.
Many are well-intentioned but poorly drafted, causing problems for both parties during high-stakes sales processes. That’s why I put together this list of issues I see in AI-related contract negotiations, and how to tackle them.
Before we dive in, note that:
This is not legal advice.
“You” in this context refers to AI-powered vendors.
“Confidential Information” should be defined as part of a broader NDA.
PRODUCT_NAME(S) refers to one (or more) of your specific AI offerings.
With that said, here are the top 5 contract terms AI vendors should watch out for, and how to close deals without painting themselves into a corner:
1. A blanket prohibition on processing Confidential Information with AI
Problem language
"Vendor shall not process Confidential Information using artificial intelligence or machine learning."
Why vendors should resist
This is basically impossible to comply with. Even spell-checkers include some kind of AI today. And if this is a two-way restriction, you can be sure the customer can’t comply either.
It also treats several fundamentally different activities as the same:
Inference.
Retrieval-augmented generation.
Customer-requested fine-tuning.
Support and debugging.
Security and abuse detection.
Aggregating service telemetry.
Training a model shared with other customers.
Each activity should not have the same rules because each one has different security and compliance implications.
Recommended alternative
Each Party may process the Confidential Information of the other using machine learning or artificial intelligence systems so long as the receiving Party obtains commercially reasonable assurances the system in question is not trained using Confidential Information.
This explicitly allows AI use, but prohibits training on Confidential Information. When combined with a broader non-disclosure requirement extending to 3rd parties, this reduces the risk of sensitive data being reproduced to those without a need to know and not under an obligation of confidentiality (i.e. unintended training).
If you have a valid business need to train on the customer’s confidential data, I wrote an entire separate article about how to negotiate and structure these types of deals.
Additionally, I recommend adding a carveout for usage data or telemetry:
Vendor may use information about Customer’s configuration and use of the Software that does not identify Customer or reveal Customer’s Confidential Information (“Usage Data”) to provide and improve the Software and provide insights, service, and feature announcements, and other reporting. Vendor owns Usage Data and may use it for any business purpose during or after the term of this Agreement, including to develop and improve Vendor products and Software and to create and distribute insights, reports, and other materials.
This allows you to do some important things like:
Identify usage patterns.
Track error rates over time.
Aggregate values and behaviors across many customers to publish useful data.
The devil is in the details here, and I have previously advised buyers to get vendors to clarify exactly how such aggregation or anonymization happens. From the vendor perspective, I think it’s reasonable to commit to not exposing the customer’s identity and its Confidential Information. I see many anonymization clauses that only touch on the first part, but not the second. This is important because if your customer is Coca-Cola, and you train AI on the secret formula for their signature beverage without revealing who created it, Coca-Cola would still be rightly concerned about their trade secrets leaking.
2. Bans on using “public” AI
Problem language
“Vendor will not upload Customer’s Confidential Information to publicly available artificial intelligence software like ChatGPT, Claude, or similar applications.”
Why vendors should resist
“Publicly available” is not a well-defined term. Does it mean something anyone can purchase on the internet? Use for free? Powered by open-source models?
Many companies use business or enterprise versions of ChatGPT and Claude to process their most highly-sensitive and -regulated information. They feel confident doing so because of the security representations the vendors of these tools make.
Recommended alternative
Delete this entirely.
An NDA covering information provided to 3rd parties combined with the language from section #1 addresses the underlying customer concern: that their confidential information gets trained on and/or retained by a 3rd party beyond their (or your) control.
If the customer has additional data handling, retention, and security concerns, incorporate them into a broader security addendum.
3. Requiring customers to approve vendor AI use
Problem language
“Customer will designate an individual with the exclusive authority to provide any permissions required under this Agreement in connection with the use of Artificial Intelligence...Customer may, at any time and for any reason in its sole discretion, revoke any authorization set forth for Vendor to use Artificial Intelligence.”
Why vendors should resist
This gives the customer complete control over whether and how you use AI. If AI is core to your product offering, it gives them the ability to force you to shut it down while still requiring you to deliver the service.
You would thus be on the horns of a dilemma because you would either have to:
Violate the AI restriction, exposing yourself to litigation over alleged breach.
Stop providing the service, also exposing you to litigation over alleged breach.
Even if the customer does not actually trigger the clause, they could use this (implied) threat as leverage to renegotiate the contract on highly unfavorable (to you) terms.
Additionally, especially in large organizations (usually the ones who draft these provisions), there is little incentive for an individual person to ever approve anything in writing, especially for a vendor. It’s quite possible you could sign the contract, request permission to use AI, and then never get it.
Your main leverage point is the contract negotiation itself: use it.
Recommended alternative
Striking this entirely would be preferable.
If that’s not an option, you can either:
Change the pre-approval mechanism to an objection one, combining it with Data Protection Addendum (DPA) requirements regarding subprocessors, e.g.:
Customer grants general authorization to Vendor to appoint third parties as subprocessors to support the performance of the Services. Vendor will maintain a list of subprocessors, provide Customer with such list promptly on request, and will provide Customer at least thirty (30) days’ advance notice of any new and replacement subprocessors prior to adding them to the list. If Customer has a reasonable objection to any new or replacement subprocessor, it shall notify Vendor of such objections in writing within thirty (30) days of the notification and the parties will seek to resolve the matter in good faith.
If you aren’t signing a DPA with the customer, and they still want knowledge of and control over your AI processing, replace “subprocessor” with “AI system.”
This approach requires the customer to object rather than approve. And while the likelihood of someone in a large organization objecting in writing is higher than that of them approving in writing, it is still a low-probability outcome.
While you should certainly track specific AI tools, features, or models (on top of the vendors providing them) in use as part of your inventory, I advise against committing to use (or not use) AI at this level of granularity. If someone at your customer sees something in the news about GPT-5.6-sol autonomously hacking another company, they might decide to object to its use. The likelihood of them objecting simply to “OpenAI, LLC” is lower.
4. A blanket prohibition on “high-risk” or “consequential” AI
Problem language
“Vendor shall not provide, use, or permit the use of any AI System that is high-risk, consequential, safety-critical, or capable of materially affecting an individual.”
Why vendors should resist
These labels are meaningless without an intended use or definition. The same ranking algorithm might be low-risk when ranking restaurant choices and regulated by a range of jurisdictions when ranking job candidates.
The customer may also create an undesired use case by:
Changing the intended purpose.
Rebranding the product.
Combining it with other systems.
Substantially modifying it.
Selecting decision thresholds.
Removing human review.
Using it as the basis for an employment, credit, insurance, healthcare, or other consequential decision.
Under the EU AI Act, for example, a distributor, importer, deployer, or other third party becomes the provider of a high-risk AI system if it places its name or trademark on an existing high-risk AI system, substantially modifies a high-risk AI system, or changes the intended purpose of an AI system in a way that causes it to become high-risk.
Furthermore, if you decide to use AI-powered hiring tools (which can trigger “high-risk” designation under the EU AI Act)—and meet all applicable requirements—that isn’t something a customer should be able to block.
Finally, I have even seen enterprise AI addenda that specifically ban the use case for which they are considering contracting with a vendor, e.g. the customer is considering using an AI-powered healthcare tool but has a requirement that the vendor “not use artificial intelligence for healthcare purposes.”
Recommended alternative
Force the customer to be specific about their concerns and document appropriate controls for both parties contractually.
For example, is the customer trying to avoid being a “Deployer” of a “Covered automated decision-making technology (ADMT)” per Colorado’s SB26-189? If so, ensure the contract doesn’t let them entirely offload responsibility to you.
"Vendor represents that PRODUCT_NAME is not developed, offered, sold, leased, licensed, or otherwise made commercially available by Vendor as a Covered ADMT and is not designed, marketed, intended, documented, advertised, configured, or contracted by Vendor to Materially Influence a Consequential Decision or to be used as part of a Covered ADMT, in each case as defined by Colorado SB26-189. Customer shall not configure, modify, market, contract, or use PRODUCT_NAME to Materially Influence a Consequential Decision or as part of a covered ADMT."
This increases the customer’s confidence they won’t accidentally trip a regulatory red line by using your product. It gives you assurance as well because this language helps establish that you are not a “Developer” under SB26-189 with respect to this product’s use by this customer.
5. “Bias-free,” “fair,” or zero-disparate-impact warranties
Problem language
“Vendor represents and warrants that PRODUCT_NAME is not biased, unfair, or discriminatory and will not result in disparate impact against any protected class.”
Why vendors should resist
“Bias” is an ambiguous term and not every statistical distinction, model assumption, or differential outcome constitutes unacceptable discrimination. Certain types of bias are also legal and might even be a business requirement of the AI system.
“Fairness” is not a single mathematical condition. Definitions may vary and outcomes may also depend on:
The customer’s data.
The target population.
Selection thresholds.
Sample size.
Protected attributes and proxies.
Workflow design.
Reviewer behavior.
Accommodations.
The legal theory and jurisdiction.
Furthermore, the FTC has acted against a company making unsupported claims that its facial-recognition software was free of racial or gender bias.
Recommended alternative
One option is to commit to a risk management process and disclose key information to the customer:
“Vendor must maintain a documented, risk-based process designed to identify, evaluate, and mitigate reasonably foreseeable material risks of unlawful discrimination arising from Customer’s use of PRODUCT_NAME in accordance with its product documentation.
Vendor must provide Customer with material information concerning applicable testing methods, limitations, and results (“Bias Testing Results”). Bias Testing Results constitute Confidential Information.”
From the business perspective of vendors, though, the most effective thing here is to educate Customers about ISO 42001 and commit contractually to maintaining an external certification:
“Vendor must maintain an externally-audited ISO/IEC 42001:2023 (or mutually-agreed successor standard) certification, issued by an accredited certification body, whose certification scope covers the development and provision of PRODUCT_NAME.”
This gives you, the vendor, flexibility to adjust your program over time and continually improve without “hard-coding” specific requirements regarding disclosures, testing, etc.
AI addenda and contract restrictions are here to stay. Don’t get boxed in.
StackAware has negotiated these types of agreements directly (during our own sales process with customer procurement teams) and on behalf of our clients. While it may be tempting to accept strict requirements to get a deal done, these types of things can come back to bite you.
Oftentimes, AI-powered companies use ISO 42001 certification as a way to navigate many of these discussions (and StackAware has also done so itself).
If you are a security or AI leader in:
B2B SaaS
Fintech
Healthcare
and need help getting ISO 42001-ready: