Most enterprise AI procurement work still happens inside contract templates designed for conventional software. That worked reasonably well when the product being bought was a stable application with a versioned release cycle. It works less well when the product is a model whose behaviour can shift between Tuesday and Friday, whose outputs depend on training data the buyer cannot inspect, and whose vendor reserves the right to deprecate the specific version the buyer evaluated.
The result is a set of recurring procurement mistakes that show up across industries and buyer sizes. They are not exotic problems. They are predictable consequences of running AI deals through procurement frameworks that were not designed for them.
Treating the model as a stable product
The first and most common mistake is contracting for a model as if it were a fixed product. Procurement teams sign agreements that reference "the service" or "the platform" without nailing down which model version the buyer is actually paying for, how long that version will remain available, and what happens when the vendor moves traffic to a successor model.
This matters because model behaviour is version-specific in ways that conventional software behaviour is not. A buyer who has tested a model against their use case, calibrated their prompts and downstream logic, and signed off on production deployment has done that work against a specific set of weights. When the vendor silently rolls forward to a new version, which most major vendors reserve the right to do on relatively short notice, the buyer's calibration work can degrade overnight.
The procurement fix is straightforward in principle and unfamiliar in practice. Contracts need explicit version-pinning language: which model versions the buyer is entitled to use, for how long after a successor is released, and what notification and migration support the vendor must provide. Most current AI vendor contracts treat versioning as a unilateral vendor right. Buyers who have negotiated harder have generally been able to push back on this, but most do not.
Underweighting the evaluation clause
A second pattern is that buyers spend considerable effort on internal model evaluation before signing, then sign contracts that give them no ongoing evaluation rights. The pre-purchase work tells them how the model performs today. It tells them nothing about how it will perform six months in.
A serious evaluation clause grants the buyer the right to run defined test suites against the production model on a regular cadence, with the vendor obliged to investigate and remediate when performance drifts beyond agreed thresholds. It also covers what happens during version transitions: the buyer's right to test the new version before being migrated, and the buyer's right to remain on the prior version if testing reveals regressions on their specific workloads.
Most buyers do not have these clauses because their procurement teams do not know to ask for them, and because the standard vendor MSAs do not offer them. The asymmetry is significant. A vendor that can change the model and refuse to acknowledge performance drift has effectively unilateral control over the quality of what the buyer is consuming.
Confusing data residency with data handling
Data residency clauses have improved considerably over the past two years. Most major AI vendors now offer documented options for where inference happens and where data is stored, and procurement teams have learned to specify regional requirements. That progress has masked a related set of issues that are less well covered.
Data handling beyond residency includes how prompts and outputs are used, whether they enter any training or evaluation pipeline, how long they are retained, who at the vendor can access them, and what happens to derived artifacts such as embeddings or fine-tuning data. Buyers frequently assume that strong residency language covers all of this. It does not. A model can run inference inside the buyer's preferred region while logs travel through telemetry systems elsewhere, training pipelines retain prompt samples for quality work, and derived embeddings persist in vendor systems indefinitely.
The mistake here is asking the wrong question. Procurement teams ask where the data sits. They should also ask what the data does: every operational system it enters, every retention window it falls under, every party that can read it, and what survives after the contract ends.
Mispricing the cost curve
AI vendor pricing has become more complex and more volatile than conventional SaaS pricing. Per-token costs have fallen sharply on most major APIs over the past two years, but buyers locked into multi-year commitments at older pricing have not always benefited. Reserved capacity arrangements, which look attractive at signing, can become expensive when the on-demand market price falls faster than the reserved rate.
The recurring procurement mistake is signing multi-year deals with fixed pricing in a market that is still seeing meaningful unit-cost compression. Buyers who have negotiated harder have built in pricing review mechanisms: annual market-rate resets, most-favoured-customer clauses against the vendor's published list pricing, or commitment structures that can be partially reallocated to newer model versions if those carry lower per-token costs.
The opposite mistake is also common. Buyers who refuse to make any commitment and stay entirely on pay-as-you-go pricing often end up paying meaningfully more than they would have on a modest committed arrangement, particularly for high-volume workloads where vendors will discount aggressively against committed spend.
Skipping the deprecation and exit work
The final pattern is the one that creates the most expensive surprises later. Procurement teams sign agreements without working through what happens when the relationship ends, whether because the buyer chooses to move, because the vendor deprecates the model the buyer depends on, or because the vendor's business situation changes.
A meaningful exit clause covers data return and destruction, the buyer's right to keep using a specific model version for a defined wind-down period, what happens to any fine-tuning artifacts produced during the engagement, and what migration support the vendor will provide. Few standard AI vendor contracts include strong language on any of this. The presumption sits with the vendor.
This becomes acute when a vendor announces the deprecation of a model the buyer has built production workflows around. Buyers without exit and deprecation clauses are left negotiating from a weak position against a published end-of-support date. Buyers with clauses have a contractual basis for extended support, migration assistance, or a defined credit if the deprecation forces them off the platform.
Where the procurement function needs to evolve
None of these problems are unsolvable. They are the predictable result of contract templates designed for one kind of product being applied to a different kind of product. The fix is not a wholesale rewrite of enterprise procurement but a defined set of AI-specific contract modules that procurement teams can attach to standard MSAs: version-pinning language, evaluation rights, full data-handling specifications, pricing review mechanisms, and structured exit clauses.
The vendors that will face the most pushback over the next two years are the ones whose standard contracts treat these as buyer concessions rather than baseline terms. The buyers who will be best positioned are the ones whose procurement functions have built AI-specific contract expertise rather than treating each deal as a one-off negotiation. The work is operational, not conceptual, and the contract templates that close this gap are the ones that will quietly define the next phase of enterprise AI buying.
