AI Vendor Contracts: Why 92% Want More Data Than Needed

The clause that turned a three-week negotiation upside down

Priya runs procurement at a mid-size insurance company. Last spring, her team spent three weeks hammering out pricing, uptime guarantees, and implementation timelines with an AI vendor. On the last day, the vendor's lawyer sent back a redline that changed four words in Section 14.7, the one labeled "Miscellaneous." Nobody had touched that section in ten days.

Those four words gave the vendor the right to use "aggregated customer data" to "improve and develop its models." No opt-out. No expiration. No definition of "aggregated."

She caught it. Most people don't.

The numbers tell the story. Research from TermScout, cited in Stanford's CodeX legal tech coverage, found that 92% of AI contracts in one study claimed data usage rights beyond what's necessary for service delivery. The market average across all contracts? 63%. That's a 29-point gap, and it says something uncomfortable about how AI vendors write their deals.

The gap between what an AI service needs and what its contract asks for is where the real risk lives. And it rarely sits in the sections anyone reads first.

Direct answer: AI vendor contracts routinely claim more rights over your data than the service requires. Those claims hide in standard-looking phrases, "improve our services," "aggregated data," "business purposes", that procurement teams sign without a second look. The fix isn't refusing AI. It's reading the data section as carefully as you read the price.

What "data usage rights" actually means

Ask ten people to define "data usage rights" and you'll get ten answers. In an AI vendor contract, it's a bundle of at least five separate permissions. Vendors rarely spell them out that way. They roll them into one sentence and count on you reading it quickly.

Direct answer: Data usage rights are the permissions a vendor claims over your content, how long it keeps it, what it does with it, who else sees it, and whether it trains models on it. Treat them as five distinct rights, because each carries a different kind of risk.

Here's how they break down:

1. Processing rights. Can the vendor run your data through its system to deliver the service? Usually yes, and that's fine.
2. Retention rights. How long does it keep your data after you stop paying? Watch for "for as long as necessary" or "in accordance with our internal retention policy." Both mean "we decide."
3. Training rights. Can it use your content to improve its models? This is the clause that turns a vendor into a research lab with your files inside it.
4. Sharing rights. Can it pass your data to subprocessors, affiliates, or "third-party partners"? That last category is the vaguest and the most dangerous.
5. Derivative rights. Can it create new data from yours, embeddings, scores, summaries, and treat the output as its own property?

Most contracts address processing explicitly and bury the other four. That isn't an accident. It's drafting.

The practical wrinkle is that these rights often live in different documents. Processing sits in the main agreement. Retention lives in a data processing addendum. Training language hides in a security exhibit or a trust center webpage. To see the full picture, you have to pull them together, which is exactly the kind of task that eats an afternoon.

The clauses where the real grab hides

Drafting is a skill, and vendors are good at it. The clauses that change your risk the most rarely sit under a heading that says "Data Rights." They sit in the sections people skim: assignment, liability, dispute resolution, and the catch-all "Miscellaneous."

Direct answer: Hidden risk usually sits in miscellaneous sections, where assignment, liability caps, dispute forum, or incorporation by reference language can quietly override more visible business terms. A single sentence there can undo three weeks of negotiation elsewhere.

Here's where to point the flashlight:

• Assignment clauses that let the vendor transfer the contract to a parent, subsidiary, or acquirer, along with your data, without your consent.
• Incorporation by reference that pulls in an online policy, an exhibit, or a "data processing addendum" that wasn't in the version you reviewed.
• Unilateral change rights that let the vendor update terms by posting a new version.
• Liability carve-outs that exempt data misuse from the general liability cap, leaving you with a refund as your only remedy.
• Dispute forum clauses that require arbitration in a jurisdiction you can't reasonably reach.

A single sentence in a miscellaneous section can undo three weeks of negotiation. That's why the last redline matters as much as the first.

There's a broader pattern here. The clauses with the biggest consequences tend to have the smallest font. Auto-renewals, assignment, audit rights, and data-use language all tend to appear in the back half of a document, after the sections that read like a sales brochure. If you only review the first thirty pages, you've reviewed the pitch, not the deal.

Why "service delivery" is a moving target

The phrase that does the most work in AI contracts is "as necessary to provide the service." It sounds narrow. In practice, it's elastic, because the definition of "the service" keeps expanding.

Direct answer: "Necessary for service delivery" is only as narrow as the service description in the contract. If that description is vague, "AI-powered analysis and related services", the vendor can justify almost any data use. Tighten the service definition, and the data rights tighten with it.

Consider what happened at one legal ops team I spoke with. Their AI review vendor's contract defined the service as "document analysis, related insights, and service improvements." That middle phrase, "related insights", covered a new analytics dashboard the vendor launched a year later, built on customer data the client believed was ring-fenced.

Same words. Different meaning. No renegotiation required.

If your contract says "and related services," you've given away the argument before it starts. Write the service definition the way you'd write a statement of work, specific outputs, specific formats, specific limits. Then attach the data rights to that definition, not to a general category that grows every time the vendor ships a feature.

One more quiet risk: "service improvements" often survives contract termination. The service ends. The improvement rights don't. If the clause doesn't have an expiration date, assume it doesn't have one.

The privacy policy vs. product behavior gap

A privacy policy and a vendor contract do different jobs. The policy is public-facing. The contract is enforceable. Companies often assume the contract is stricter because it's private. That assumption is worth testing.

Direct answer: Compare the vendor's privacy policy against the actual product defaults before you sign anything. Policy language can be broader or narrower than what the tool actually does. The gap between the two is where compliance exposure hides.

AI privacy guidance from regulators and outside counsel flags three recurring issues: cloud processing with no local-only option, default retention settings that are hard to change, and permission to use customer data for model training that's technically opt-out but buried three clicks deep in an admin panel.

Take one vendor that markets itself as "privacy-first." The policy says it doesn't train on customer content. The admin console has a setting labeled "Help improve the product", enabled by default, with a tooltip warning that turning it off "may reduce response quality." That's a choice-architecture problem dressed up as a feature.

Here's the test to run before signing:

• Open the admin settings. Are retention, training, and sharing controls visible, or buried?
• Compare the policy's stated retention period against what the dashboard actually shows.
• Ask for the subprocessor list in writing, then check whether it matches the policy's "third parties" language.
• Run one low-sensitivity document through the tool and check whether it shows up in analytics or training reports.

A privacy policy is a promise. Product defaults are the truth. When they disagree, the defaults win, and you find out the hard way.

Regulators are catching up

For years, the practical answer to lopsided AI terms was "negotiate better or walk." That's changing. Regulators on both sides of the Atlantic are starting to treat data promises as enforceable commitments.

Direct answer: The FTC has authority to act against companies that break their own privacy and confidentiality promises, and the EU AI Act introduces transparency obligations for certain systems. Both shift the risk calculation from "can I negotiate this out" to "is this term legally survivable?"

The FTC's business guidance is blunt about this. If you say you won't share data with third parties, and then you do, that's a deceptive practice, regardless of what a contract clause says. The EU AI Act adds disclosure requirements for higher-risk systems, including documentation about training data and how systems are monitored after deployment.

Meanwhile, the NIST AI Risk Management Framework has become a de facto scorecard for enterprise buyers. It doesn't carry the force of law, but procurement teams increasingly use it as a checklist, and vendors know it.

What does this mean in practice? A vendor that promises something in a policy and contradicts it in a contract now has two problems, not one. And a buyer that missed the contradiction has exposure of its own. The strongest clause in your contract is the one a regulator would read out loud.

A negotiation playbook for AI contracts

Most negotiation advice is either too vague ("build trust") or too specific ("redline Section 12.3"). AI contracts need something in between: a short list of terms worth fighting for, and language you can actually send back.

Direct answer: Prioritize five clauses, purpose limitation, retention caps, a training opt-out, audit rights, and deletion certification. These cover the highest-risk data uses and are negotiable with most vendors. Everything else is secondary.

1. Purpose limitation. "Vendor may process Customer Data solely to deliver the Services as described in Exhibit A. Vendor may not use Customer Data for any other purpose, including model training, benchmarking, or product development, without Customer's prior written consent."

2. Retention caps. "Vendor will delete Customer Data within 30 days of contract termination or upon Customer request, whichever comes first."

3. Training opt-out. "Vendor will not use Customer Data, or any derivative thereof, to train, fine-tune, or evaluate any machine learning model."

4. Audit rights. "Customer may audit Vendor's compliance with this Section annually, or upon reasonable suspicion of breach, with 30 days' notice." Audit rights are the enforcement mechanism that turns the rest of the list from words into commitments.

5. Deletion certification. "Upon request, Vendor will certify in writing that Customer Data has been deleted." A signature is worth more than a settings toggle.

A word on symmetry, because it matters. If the vendor wants flexibility, ask for reciprocal rights, clearer limits, or shorter retention periods in exchange. Symmetry is a fair ask even when it isn't a realistic one, because it forces the other side to justify what they're keeping.

And stage your disclosures. If you can't get training language you're comfortable with, start with low-sensitivity data and hold the rest. Escalating access is easier than walking back a mistake.