9 traps in AI implementation contracts: pricing, SLAs, data rights, and exit

In a recent AI implementation contract review, a manufacturing company's quote appeared well-organized with clear line items and a total within budget. The problem was on page 14 in fine print: "All model fine-tuning output weights shall be owned by the Vendor." That meant the model trained on their production data, at their own expense, wouldn't belong to them. Such clauses don't surface during the demo. You discover them only when you need to switch vendors or move the system in-house.

AI contract traps are intentional, not accidental. They're vague by design. Vagueness favors whoever controls delivery. Here are nine recurring traps and the questions to ask at the negotiating table.

Pricing and billing: what does the bill look like three months in?

Vendors use three main pricing tricks. The first splits one-time costs into separate "implementation," "consulting," and "integration" line items, the same work, billed three ways. The second hides usage costs for tokens or API calls behind "billed at actual consumption," with no spending limit. The third uses per-seat licensing where you think you're buying one system but actually pay per active account, month after month.

Request a "scaled monthly bill simulation." Use a scenario: six months from launch with 3x growth in daily active users. What's the total cost? A vendor that can answer this has planned their pricing. If they can't, you're carrying all the billing risk.

SLA: promises without numbers mean nothing

A vague promise like "we guarantee stable operation" has no legal weight. An enforceable SLA requires three components: clear numbers, how you'll measure them, and what happens if they're not met. Many contracts promise "99.9% availability" without defining availability itself. Does the API simply need to respond, or does it need to respond correctly? The difference is substantial for AI systems.

Data rights and model rights: separate them, lock them down

This section often gets overlooked but carries high stakes. Break the discussion into four separate points: Who owns the original data? Who owns derived data after cleaning and labeling? Who owns the fine-tuned model weights? Can the vendor use your data to train general models for other clients? That last point matters most. Standard SaaS contracts let vendors do this unless you explicitly prohibit it.

Lock-in and exit: negotiate your exit upfront

Solid partnerships include clear exit paths. Lock-in doesn't announce itself with that label. Instead it hides in data export formats, API dependencies, and terms like "all data deleted 30 days after service ends." Thirty days seems reasonable until you discover exports are in a proprietary format with no documentation or migration support. In practice, the vendor controls when you lose access to your data. Thirty days isn't time to migrate. It's a countdown to forced renewal.

Use this checklist at the negotiating table. The vendor's responses are as revealing as the contract itself.

Trap	What They'll Say	What to Ask
Pricing charged twice	"This is standard line-item breakdown"	Consolidate quotes; itemize actual deliverables per line
Unbounded usage costs	"Pay-as-you-go, very economical"	Require scaled monthly forecast and hard cost cap
Undefined SLA	"We guarantee stable operation"	Define "available"; specify outage penalties and compensation
Data rights unclear	"Of course your data is yours"	Original, derived, and model rights, all four, in writing
Your data trains others	Buried in default terms	Explicitly prohibit use for general or competing models
Vendor owns fine-tuned weights	"The weights are our technology"	Document ownership and portability of fine-tuned weights
Export lock-in	"We delete everything after termination"	Open-format exports, migration support, documentation
Acceptance on demo	"Live deployment = acceptance"	Tie acceptance to actual usage or accuracy rates
Liability unclear	"AI output for reference only"	Assign liability for errors; define human review role

Acceptance criteria: demo or live deployment

This point is commonly missed. Most contracts define acceptance as "system delivered and demo successful." You pay the final invoice when the demo passes. But passing a demo is not the same as working in production. A customer service system performed well during its demonstration. Three months after launch, actual usage was 4%. The contract had already been paid. No one was responsible for adoption.

When negotiating, tie part of the final payment to metrics that matter: actual usage rates or accuracy measures N weeks after launch, not the demo. This identifies vendors prepared for production. Those willing to tie payment to real results tend to be serious about deployment. A smooth demo doesn't predict real usage. Actual usage with real users is what matters.