At a Glance
-
-
- The Mobley v. Workday case gives us insight into why AI vendors are riskier when they play a direct role in a regulated business decision.
- Even if there are legitimate claims against the vendor, the contract may still shift a lot of the financial risk back to the customer.
- Depending on the use case, liability caps, indemnities, warranties, and information rights need to be negotiated with a different lens when the AI affects hiring, finance, regulated data, or other high-impact decisions.
- Legal teams should ask whether the risk of the AI tool sits with the party that actually controls that risk.
-
Your head of HR forwards a demand letter. An applicant says your hiring process discriminated against him. The alleged problem isn’t an interview. It wasn’t what a recruiter had said. It’s the AI screening tool your company signed up for six months ago.
You call the vendor and they just point you right back to the contract.
The contract’s liability is capped and its warranties aren’t great. Your company may have agreed to indemnify the vendor for certain third-party claims. And when you ask for the information behind the system’s decision to reject an applicant, you find out that your access is limited.
AI vendor liability is about who bears the legal and financial responsibility when a third-party AI system contributes to discrimination, privacy violations, intellectual property claims, financial loss, or some other harm.
And there are really three questions:
-
- Who can be sued?
- Who controlled the conduct that created the risk?
- Who agreed to pay when something goes wrong?
Those answers aren’t necessarily clear.
The Mobley v. Workday litigation is shining a spotlight on this exact issue.
What Mobley v. Workday Tells Us About AI Vendor Liability
In Mobley v. Workday, job applicants alleged that Workday’s algorithmic hiring tools discriminated based on protected characteristics, including age, race, sex, and disability.
Workday argued that it was a software vendor, not an employer subject to the federal employment discrimination claims asserted against it.
The court wanted to go deeper.
Initially the court ruled that plaintiff had plausibly alleged that Workday could qualify as an agent of its employer customers because employers delegated hiring functions, including screening and recommending candidates, to Workday’s tools. The court allowed disparate-impact claims under federal anti-discrimination laws to proceed on that theory.
If the software is simply storing résumés or moving information between systems, the vendor’s may have a fairly limited role.
But what if the technology scores applicants? Ranks them?
The central question that should be behind the contract is simply what’s the technology actually doing.
That doesn’t mean every AI vendor becomes its customer’s legal agent. But it does mean that calling a vendor a “software provider” won’t necessarily end the liability.
In May 2025, the court in Mobley granted preliminary certification of a nationwide ADEA collective involving certain applicants over 40 whose applications were scored, sorted, ranked, or screened using Workday AI features. In June 2026, the court again allowed significant portions of the amended case to continue.
The court denied Workday’s request to for an immediate interlocutory appeal on an ADEA issue.
For businesses buying AI, that’s crucial.
The vendor may face liability. The client could face it too.
What’s the AI Vendor Contracts’ Liability Squeeze
There is a procurement pattern when it comes to how the business starts to bring on vendors.
The business finds an AI tool they want. The demos goes well. Security starts its review, procurement works out the pricing, and everyone has a launch date in mind.
Where’s the next stop? Legal.
And Legal opens the limitation of liability section.
The liability squeeze is the gap between the AI technology’s impact and consequences and the vendor’s putting the exposure in limited SaaS terms.
The majority of AI vendor agreements still heavily uses traditional SaaS contracting practices. They allow disproportionate liability caps, warranty disclaimers and exclude damages from the limitation of liability. The vendor indemnity shouldn’t revolve around IP infringement. And we often see there’sa broad customer indemnity too.
These provisions on their own may not be unreasonable.
The issue is that the contract isn’t aligned with the AI use case, and legal may have negotiated as if kay concerns is what happens if there’s a service outage.
Utilizing a scheduling tool and an AI platform screening applicants don’t hold the same risk.
Neither do an internal drafting assistant and a system that can approve transactions, process health information, interact directly with customers, or make recommendations affecting legal rights.
The contract needs to account for what the technology has the power to do.
That sounds obvious but we see deals often where it isn’t.
What Happens When the Customer Carries the Claim but the Vendor Controls the Technology?
Lets say the company is using AI to screen job applicants.
The company knows how the tool fits into its hiring process. But it may not know exactly how the model function.
Now imagine a discrimination claim gets filed. Legal starts with reviewing the agreement, and sees the below:
| Contract Issue | Why It Matters When a Claim Arrives |
| Liability cap tied to annual fees | The customer’s contractual recovery may be far below the actual cost of the claim. |
| No meaningful compliance commitments | The customer may have limited recourse if the system creates a regulatory or discrimination problem. |
| Narrow vendor indemnity | The third-party claim facing the customer may fall completely outside the indemnity. |
| Limited audit or information rights | The customer may not have enough information to determine why the challenged result occurred. |
| Weak cooperation obligations | The vendor may have limited contractual responsibility to help with litigation, discovery, or a regulatory inquiry. |
| Broad customer indemnity | The customer may have agreed to defend claims involving conduct partly controlled by the vendor. |
And the gap now plays out in a real world scenario.
The company may be liable because it knowingly chose to use the tool that the discrimination claim comes from.
The vendor controls main parts of the technology that formed the risk.
But the contract can still leave the company carrying most of the financial exposure and risk.
Key Takeaway: If the vendor contract says the vendor controls the AI tool that leads to the discrimination risk, the contract shouldn’t have the customer liable for that the exposure.
Why a Standard Technology Agreement Liability Cap Doesn’t Work for High-Risk AI
Another example we’ve seen is a company is paying $100,000 a year to the AI vendor.
The vendor’s liability cap is the last 12 months of fees paid.
The AI screens job applicants. The discrimination claim comes up. The company has to pay defense costs, an agency inquiry, and internal investigation costs. There is a disruption to hiring, reputational damage, and potentially claims that may involve multiple applications.
That $100,000 cap doesn’t come close to the customer’s liability.
This doesn’t mean every AI vendor needs to accept unlimited liability. But in a sophisticated contract negotiation, it means the cap should be evaluated against the foreseeable harm created by the actual use case, not simply the subscription price.
Depending on the deal, legal teams may negotiate:
- a higher cap for specified AI-related claims;
- separate caps for particular categories of exposure;
- exclusions from the general cap for defined vendor conduct;
- different treatment for privacy, security, intellectual property, discrimination, confidentiality, or violations of law; and
- indemnification for specified third-party claims.
The point isn’t to demand everything.
It’s to know what you’re giving up.
AI Indemnification Only Helps If It Covers the Claim You Actually Have
We often see technology agreements with a vendor IP indemnity.
Good. Keep it.
But what happens when the claim isn’t about copyright or patent infringement?
What if an applicant alleges discriminatory screening?
What if personal data was used in a way neither the company nor the affected individual expected?
What if the system generates a representation to a customer that creates liability?
What if both the vendor’s model and the customer’s configuration contributed to the problem?
A beautifully drafted IP indemnity won’t answer any of those questions.
When reviewing AI indemnification clauses, look closely at the trigger.
Does the vendor indemnify only for third-party intellectual property claims?
For breach of its contractual warranties?
For claims caused by the vendor’s violation of law?
For claims resulting from the vendor-controlled portions of the AI system?
And what happens when responsibility is shared?
This is where generic language gets expensive.
If the vendor controls the model, model updates, technical testing, system architecture, and information your company can’t independently access, the liability allocation should recognize that control.
The customer shouldn’t own every consequence simply because they bought the product.
Information Rights May Matter as Much as the Damages Clause
Legal teams love negotiating numbers.
Two times fees. Three times fees. Supercap. Uncapped carveout.
But when an AI-related claim actually arrives, another provision may become just as important:
What does the vendor have to tell you?
You may never get source code and you may actually not need it.
But for a higher-risk AI system, your company may need access to some combination of:
-
- testing and validation documentation;
- known system limitations;
- bias or performance assessments;
- information about material model changes;
- incident notices;
- relevant records and logs;
- documentation needed for a regulatory response; and
- reasonable cooperation in an investigation, audit, or litigation.
The worst time to discover your vendor has no obligation to explain its own technology is after opposing counsel asks you to explain it.
The discovery fights in Mobley are a reminder that access to data and technical information can become a very real part of AI litigation.
For contracting teams, the lesson isn’t that every customer needs unrestricted model access.
Key Takeaway: Negotiate access to the information you’ll need to defend the system before that information becomes evidence.
The AI Contract Should Follow Control
We think one of the most useful questions in an AI vendor negotiation is:
Who controls what?
The customer may control the data it provides, user access, prompts, configuration, internal workflows, and the final human decision.
The vendor may control the underlying model, model updates, architecture, testing methodology, development practices, and technical information the customer can’t independently see.
Let’s start there.
If the vendor controls the conduct that creates a particular risk, the customer should push for meaningful contractual protection around that risk.
If the customer controls it, the customer should expect to carry more responsibility.
This gets you much further than arguing about whether the liability cap should be two times or three times fees before anyone has explained what the product actually does.
A Good AI Contract Won’t Fix Bad AI Governance
There’s another side to this.
You can negotiate excellent vendor terms and still create your own liability but if your company deploys an AI tool, a plaintiff or regulator may want to know:
-
- Who approved it?
- What diligence was performed?
- What did the vendor tell you about its limitations?
- Who decided the system could be used for this particular purpose?
- Was anyone testing its actual outcomes?
- Where was human review required?
- Could the human reviewer really override the system, or was the “human in the loop” essentially clicking approve all day?
That last question matters.
Human review isn’t magic language.
A person who has neither the information nor the authority to challenge the AI recommendation isn’t much of a control.
Your contract and your internal AI governance should tell the same story about how the technology is actually being used.
What Should General Counsel Ask Before Approving an AI Vendor?
You don’t need a 75-question checklist for every AI tool.
But you do need answers to the questions that change the risk.
Before approving a higher-impact AI vendor, ask:
- What business decision does this system influence or make?
- What happens if it gets that decision wrong?
- What does the vendor control that we can’t independently inspect?
- What information will the vendor give us if an output or decision is challenged?
- Which party pays if vendor-controlled technology contributes to a third-party claim?
- Does the liability cap make sense when compared with the actual downside?
- Where is meaningful human review required?
- Can we suspend or exit the system if the risk changes?
Then negotiate the agreement. Not the other way around.
What Mobley v. Workday Really Means for Businesses Using AI
The takeaway from Mobley isn’t that every AI vendor will be responsible for everything its technology does.
It also doesn’t mean customers can avoid their own legal responsibility simply by using someone else’s software.
The more important point is that courts man look beyond the label “software provider” and focus on the the role the vendor and its technology actually played in the underlying decision.
At the same time, the contracts between the vendor and customer can determine how the financial consequences are divided between them.
So legal teams need to separate three questions:
-
- Who can a third party sue?
- Who controlled the conduct that created the problem?
- Who agreed to pay between the vendor and customer?
If the answers to those questions don’t line up, that can create significant risk.
The best AI vendor agreements bring them closer together.
Takeaway on AI Vendor Liability
AI vendor liability analysis should start early on when a company determines how an AI tool will be used. That includes how much decision-making power the tool will have, and what the contract says about who is responsible for when something goes wrong.
If the AI technology can influence employment decisions, financial outcomes, regulated data, legal rights, customer communications, the contract should be treated as a much higher risk than a standard SaaS.
First, business teams need to understand what the system actually does. In other worst, the use case. That should be conveyed to legal early. And legal needs to ask before they dive into reviewing the EULAS and Terms of Use.
Who has control for the risks created by the technology.
Only then can lawyers efficiently address liability, indemnification, information rights, warranties, assistance in the contract a way that’s aligned with how the technology actually works in the specific use case.
Your internal processes should also match what you agreed to in the contract.
Rarely can you completely eliminate AI tool risk. But you should know and make an educated recommendation on which risks you’re willing to take on before the contract is executed.
Gouchev Law’s technology practice group advises on AI vendor contracts, technology transactions, data use, privacy, and AI governance. We help companies negotiate the legal terms around how AI actually works, before those terms are tested by a claim.
Frequently Asked Questions About AI Vendor Liability
Who is liable if a third-party AI tool causes discrimination?
It depends on the role each party played, the law governing the claim, and the facts. A company deploying an AI tool may face liability for its use of the system, while the vendor may face separate claims based on its role in designing, operating, or participating in the challenged decision.
Does Mobley v. Workday mean every AI vendor is an employer’s agent?
No. The court’s decision was based on allegations about the role Workday’s technology played in screening and recommending job applicants. Other AI vendors and use cases may produce very different results.
What should an AI vendor contract say about liability?
The agreement should address liability caps, indemnification, warranties, data use, information and audit rights, cooperation, model or functionality changes, and the division of responsibility between the vendor and customer. Those provisions should reflect the AI system’s actual use.
Should AI vendor liability always be uncapped?
No. The right structure depends on the technology, use case, bargaining leverage, governing law, insurance, and the party controlling the conduct that could create the loss. Some deals warrant uncapped treatment for particular risks, while others use separate or higher caps.
About the Author
Jana Gouchev is recognized as one of the leading corporate lawyers in the country. Jana is a frequent speaker and commentator on business law, and recently ranked by Chambers 2026 New York. She’s a strategic partner for SaaS, AI, and tech-driven businesses looking to scale, secure enterprise deals, and stay ahead of evolving regulations.
Ready to make bold moves? LET'S TALK.
More Resources For You
A termination for convenience clause can look simple until notice is delivered. Here are the exit terms SaaS vendors and enterprise customers should negotiate before they need them.
Corporate structures with holding and affiliated companies face greater scrutiny. Mortimer v. McCool shows courts are willing to pierce the corporate veil if entities don’t operate separately. Maintaining real separateness is now critical to protect liability.
Artificial intelligence regulation reached an inflection point in 2026. What was once a patchwork of voluntary frameworks, agency guidance, and sector-specific rules is rapidly evolving into a more structured and enforceable compliance regime.