Last month’s post on the AI operating model and the workforce post that followed it both ducked the practical question that comes up in every enterprise AI conversation: how do you actually buy this stuff? The contracts look like SaaS contracts but behave differently. The pricing models are unfamiliar in ways that have caught off-guard a meaningful fraction of buyers I’ve talked to over the past year. The lock-in dynamics are stronger than they appear on paper, and weaker in places where buyers think they’re protected. Procurement teams that have spent two decades getting good at SaaS negotiation are discovering that the same playbook produces worse outcomes when applied to foundation model providers, agent platforms, and specialized AI tooling.

The honest May 2026 observation is that AI vendor procurement has become a specialty discipline distinct from SaaS procurement, and most enterprises are still using their 2020-era templates and processes against a vendor category that has evolved past them.

Why AI Vendor Contracts Aren’t SaaS Contracts

A useful clarification: at a contractual surface, an AI vendor agreement looks like a SaaS agreement. There’s a master services agreement, a data processing addendum, usage-based or subscription pricing, service-level commitments. But the substance underneath has diverged in several specific ways.

The pricing models don’t map. SaaS pricing settled around per-seat or per-feature tiers a decade ago, with reasonably predictable annual cost. AI pricing is variable on token volume, on model tier (which the vendor can re-tier), on capability features that may launch and price separately, and increasingly on outcomes (for vendors offering performance-based contracts on specific use cases). Annualizing the cost of an AI vendor relationship requires more than reading the rate card.

The product is non-stationary. A SaaS product I bought in January is functionally the same product in December. A foundation model I licensed in January may behave differently in December — sometimes better, sometimes worse on specific tasks, sometimes both. Model updates, prompt-stack changes, and capability deprecations happen on the vendor’s schedule, and the contract increasingly needs to address what the customer is entitled to under change.

The data-rights surface is more complex. What data the customer sends to the vendor, what the vendor retains, what the vendor can use for training, what model-fine-tuning produces in terms of IP ownership, what happens when the customer terminates. Each of these has substantive answers in modern AI contracts that weren’t questions for typical SaaS.

Output liability is genuinely new. When an AI vendor’s model produces an output that’s factually wrong, defamatory, copyright-infringing, or biased in a way that produces legal exposure, who’s liable? The answers are still being worked out in case law; the contract terms are evolving rapidly; most older contract templates don’t address this at all.

The lock-in dynamics are different. SaaS lock-in is largely about data migration, integration cost, and user retraining. AI vendor lock-in adds: prompt engineering and evaluation harness investment, fine-tuned model artifacts that may or may not be portable, specific behavior characteristics that downstream systems have adapted to, and vendor-specific tool ecosystems (assistants APIs, agent frameworks, retrieval integrations) that don’t port cleanly.

What to Negotiate Hard On

A few specific contract terms that mature AI procurement programs are getting right:

Model version stability and change notification. The customer is entitled to specific model versions remaining available for a specified period after introduction, with explicit notice and migration support for deprecation. Without this, the vendor can shift model behavior under the customer’s production workloads without consent. The leading vendors will negotiate this for serious customers; less mature buyers don’t ask.

Evaluation continuity rights. The right to access the model on terms that allow the customer to maintain their evaluation harness — including the right to compare a new version against the version it replaces. Sounds technical; matters when a model update degrades performance on the customer’s specific workload.

Training-data exclusion. Explicit prohibition on the vendor using the customer’s data (prompts, completions, fine-tuning data, retrieval content) to train future models, with operational and audit mechanisms to verify compliance. Standard at the enterprise tier with the leading vendors; far from standard at lower tiers.

Output indemnification. Coverage for legal exposure arising from the model’s output — copyright claims, defamation, regulatory issues. The leading vendors offer this with caps and conditions; the caps and conditions are negotiable; the absence of any indemnification at all is a flag.

Data residency and processing locations. Where the customer’s data flows during inference, where it’s logged, where it’s retained, who has access. Increasingly important as data-sovereignty regulations have multiplied. The vendor’s standard terms may or may not align with the customer’s regulatory obligations.

Pricing protection mechanisms. Caps on year-over-year price increases, locked rates for committed-volume tiers, the right to migrate to a different tier without penalty if a tier is restructured. AI pricing has been more volatile than SaaS pricing; contractual protection matters.

Termination and transition rights. What happens to the customer’s data, fine-tuned models, and integrations when the relationship ends. The right to a reasonable transition period, with continued access on agreed terms, while the customer migrates to a successor solution.

Capability commitments and SLAs. Commitments about specific capabilities being available, with specific performance characteristics, for the term of the agreement. The standard SaaS uptime SLA isn’t sufficient; the customer also needs commitments about what the model can do.

Audit rights. The right to audit the vendor’s compliance with the data-handling, training-data-exclusion, and security commitments. Often hard to get; worth pushing for in regulated industries.

Red Flags Worth Catching

A few patterns that should slow down the negotiation:

Vague training-data terms. “We may use your data to improve our services” is a flag. Specific, narrow, opt-in or strictly opt-out terms are required for serious enterprise use.

Indemnification that excludes the most likely failure modes. Coverage that excludes copyright claims, claims arising from “user-provided inputs,” or claims involving the customer’s own use of outputs is much less valuable than it appears. Read carefully.

Unilateral termination rights. Vendors that reserve broad termination rights without cause leave the customer exposed if priorities or pricing shift. Mutual termination terms with reasonable notice are the floor.

Model-version language that’s all on the vendor’s side. “We may update the model at any time” with no notice and no migration rights is a flag for any workload where output stability matters.

Pricing flexibility on the vendor’s side without reciprocal protection. “We may adjust pricing with thirty days’ notice” is asymmetric. Push for caps or rate locks.

Limitation of liability that’s a small multiple of fees. Standard SaaS terms cap liability at 12 months of fees. AI vendor agreements increasingly include exceptions for IP indemnification and data breaches that the leading vendors will accept; the standard “capped at fees paid” without exceptions is a flag.

Sub-processor lists without geographic constraints. A vendor’s right to use sub-processors anywhere in the world can produce data flows the customer didn’t anticipate. Restrict to specific regions where regulation requires.

No commitment on regulatory posture. Serious vendors increasingly commit to maintaining compliance with relevant AI-specific regulations (EU AI Act, sector-specific guidance) for the duration of the agreement. Absence of any such commitment is a flag.

Pricing Models and What They Actually Mean

A short tour of how AI vendor pricing has settled by mid-2026:

Per-token pricing remains the dominant model for foundation model access, with input and output tokens priced separately. The granularity is fine; the predictability is poor. Annual cost depends on workload patterns the customer may not be able to forecast accurately.

Capacity-reserved pricing has matured into a real option — committed throughput at a discount to spot pricing, with overage handling on terms. Useful for predictable workloads; the discount versus on-demand is meaningful enough to make capacity planning worthwhile.

Tier-based pricing (Pro, Business, Enterprise) bundles per-token allowances with feature access, support levels, and contract terms. The standard SaaS pattern adapted; the tier transitions are where vendor lock-in tightens.

Outcome-based pricing has emerged for specific use cases — pay per successful customer-service resolution, per qualified lead, per compliant document. More common for specialized AI vendors than for foundation model providers. Requires careful definition of “success” in the contract.

Hybrid commitments combine baseline subscription, capacity reservations, and overage at spot pricing. The most common shape for serious enterprise commitments. Negotiate each component.

Building the Vendor Portfolio

A few patterns mature programs have converged on:

Don’t single-source for capability the business depends on. A serious enterprise application that depends on one frontier model provider has concentration risk that single-vendor SaaS doesn’t have, because the product itself is non-stationary and the alternatives have meaningfully different behavior. Multi-vendor architectures with abstraction layers cost more upfront and pay off in optionality.

Concentrate on two or three primary providers; use specialized vendors for narrow workloads. A portfolio with one major foundation model relationship, a credible backup, and a small number of specialized providers (legal, healthcare, code, voice) covers most enterprise needs. More providers than this produces operational fragmentation without proportional benefit.

Build the evaluation harness with portability in mind. The same harness that evaluates the primary model should be runnable against alternatives. The work is up front; the value is in the moment when the customer needs to migrate.

Maintain a procurement playbook by capability category. Foundation model providers are negotiated differently from agent platforms which are negotiated differently from specialized fine-tuned models which are negotiated differently from open-weight hosting providers. A single template produces poor outcomes across the categories.

Engage legal and risk early. AI vendor contracts have more genuinely novel language than SaaS contracts. Legal review that happens at the end of the negotiation produces redlines that delay close; legal review that happens with procurement during the structure conversation produces deals that close cleanly.

What’s Worth Watching

A few directions visible from this vantage point in mid-2026:

The output indemnification market will continue to develop. The leading vendors offer this; the breadth and depth of coverage is still uneven; expect continued evolution as case law accumulates.

Outcome-based pricing will continue to expand for use cases where success is well-defined. The vendor and buyer interests align well when both can agree on what success means.

The regulatory layer will produce contract template standardization. EU AI Act compliance, NIST RMF alignment, and sector-specific frameworks will increasingly drive standardized language across vendors. The buyer’s leverage will be in capability and performance, not in regulatory boilerplate.

Vendor consolidation will continue at both ends. The foundation model market will continue to thin at the top; the specialized AI vendor market will continue to consolidate around vertical leaders. Procurement strategies built on the assumption of fragmentation will age poorly.

Conclusion

AI vendor procurement in 2026 has become a specialty discipline that rewards explicit attention to contract terms that don’t have SaaS analogs, pricing structures that don’t behave like SaaS pricing, and portfolio strategies that account for the non-stationary nature of the product. For most enterprises, the right pattern is to bring procurement, legal, risk, and AI leadership together for serious AI vendor decisions, develop category-specific playbooks rather than reusing SaaS templates, and build vendor portfolios with deliberate concentration and deliberate redundancy. The capability the vendors provide is valuable; the discipline of buying it well is what separates programs that get full value from programs that overpay, over-commit, or get caught flat-footed by changes the vendor was contractually entitled to make.

References

Gartner (2026). Magic Quadrant for AI Vendor Management.

International Association for Privacy Professionals (2026). AI Procurement and Data Rights.

European Commission (2024). AI Act: Provider Obligations and Customer Rights.

ITAM Review (2026). Software Asset Management for Generative AI.

NIST (2026). AI Risk Management Framework: Procurement Considerations.