Buying AI: A Procurement Guide for Technology Leaders.

What does this guide cover, and what does it not?

A note on what this is, because the phrase has been taken. Search for AI procurement and you will get agents that run purchase orders, three-way match invoices and chase suppliers. That is a real and well-funded software category. This is the other thing. This is about buying AI itself, the arc that starts when someone asks whether we should build this and ends, if you did the work, with a signed contract you can walk away from.

I have run this arc from both sides. What follows is the pillar view, the shape of the whole decision. Two parts of it are deep enough to deserve their own treatment and are linked where they belong: the RFP and the due diligence.

Should you be buying this at all?

The first mistake is treating this as a vendor-selection problem. It is a build-or-buy problem that has already been half-answered by whoever wrote the requirements document, usually in the direction of buy, usually without saying so.

The economics changed underneath this question in a way that is easy to get backwards. AI collapsed the cost of producing a feature and did nothing to the cost of owning one, which I have argued at length in build vs buy when building just got cheap. The short version for a procurement context: if your build estimate went down 60% because an agent writes the first draft of the code, your maintenance estimate did not move, and maintenance is where the money was. A buy decision that was correct in 2023 on production cost may be wrong now. A buy decision that was correct on ownership cost is still correct.

Run that first. If the answer is buy, the rest of this page applies. If the answer is build, most of it still applies, because you will be buying the model access underneath the thing you build, and a foundation-model contract is a procurement decision wearing an engineering costume.

What is actually different about buying AI?

Enterprise software procurement is a mature discipline and most of it transfers. Four things do not.

The thing you bought gets withdrawn underneath you

This has no real equivalent in conventional software, where a version you licensed keeps running until you choose to move. Model providers retire models on a published schedule. OpenAI's deprecation policy commits to at least 6 months of notice before retiring a generally available model, at least 3 months for specialised variants, and states that preview models may be retired "with much shorter notice, such as 2 weeks" (OpenAI deprecations). Anthropic commits to "at least 60 days' notice before model retirement for publicly released models" (Anthropic model deprecations). Those are the floors, and the published history sits close to them. Claude Sonnet 3.5 was deprecated on 13 August 2025 and retired on 28 October 2025, which is 76 days. Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August 2026, 61 days. Claude Sonnet 4 ran 14 April 2026 to 15 June 2026, 62 days. Sixty days is not a migration window at enterprise scale. It is a notice period, and the difference between those two things is the whole subject of the negotiation section below.

The unit you are billed on is one you do not control

A seat is a decision your HR system makes. A token is a decision your users and your retry logic make. Under agentic workloads the ratio between a unit of business value and a unit of billed consumption is not stable, and it moves in the direction of more consumption as the product gets better. If you want the modelling for the seats-versus-tokens version of this, what frontier-model access should cost and the LLM cost calculator do that arithmetic properly.

The lock-in does not live in the contract

It lives in the artifacts you accumulate while the contract runs. Prompt logic tuned to one model's refusal behaviour. An evaluation harness whose thresholds were calibrated against one provider's output distribution. Fine-tuned weights. Embeddings in a vector store with one provider's dimensionality. Retrieval chunking tuned to one context window. None of that appears in the commercial terms and all of it is what makes leaving expensive. Procurement's job is to buy the right to take those artifacts with you, at the start, while you still have leverage.

The counterparty duty is now written down

Article 25(4) of the EU AI Act requires that a provider of a high-risk AI system and a third party supplying AI systems, tools, services, components or processes "shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance" (Article 25). Chapter III obligations apply from 2 August 2026 under Article 113, so this is live now rather than pending. If your use case lands in the high-risk tier, the information you need from a vendor is not a nice-to-have you have to negotiate for. It is a regulatory requirement on you that only the vendor can satisfy, which changes who has to be reasonable. Which tier you are in is an AI compliance question, and it should be answered before the shortlist, not after the demo.

How fast does the door close?

The one-way-door framing is the right instrument here and I am not going to rebuild it. The reversibility framework works through six AI governance gates and which side of the door each one sits on, including compute commitments and fine-tuning.

The procurement-specific addition is this. A decision's reversibility is not fixed at signature. It decays. Model selection starts as a two-way door and becomes a one-way door through accumulation, at a rate set by how much provider-specific behaviour you weld into your system in the first eighteen months. Nobody makes that decision. It happens as a side effect of shipping.

So the useful question in a procurement review is not which door is this. It is how fast does this door close, and what did we buy that slows it down. The honest answer, for most organisations, is that nothing in the contract slows it down at all.

There is a way to price this rather than argue about it, and I wrote it up separately because it deserved the room. Pricing AI vendor optionality, on aistrategy.guide, runs the real-options arithmetic on a foundation-model commitment using Myers and Luehrman, and lands somewhere uncomfortable: on the discount spreads and migration costs I keep seeing, the flexibility premium is frequently not worth paying, and the money is better spent making migration cheap, because migration cost is a multiplier on every exit right you will ever hold rather than an input to one deal. Read that before you argue for an exit clause. It is the strongest version of the counter-argument to the section you just read.

How do you build the shortlist?

Two structural rules, both of which I have watched get broken at cost.

Disqualify before you demo. A demo is a persuasion event and its function is to make a vendor's strengths salient and its constraints invisible. Anything that is a hard constraint for you, data residency, retention posture, the ability to run evaluations against your own data, indemnification for output, subprocessor disclosure, needs to be answered in writing before anyone books a call. This is cheap to run and it typically removes half a longlist.

Keep a real second. Not a courtesy second that everyone knows will lose. A second vendor that could actually be selected, taken far enough into evaluation that you know what it would cost to switch to it. That knowledge is the asset. It is what makes the renewal conversation different in eighteen months, and it is the only version of leverage that survives the point where your users already depend on the incumbent.

If the market has consolidated to the point where there is no credible second, that is a finding, and it belongs in the risk section of the business case rather than being quietly absorbed. Vendor capture risk works through what that looks like when it goes wrong. The board-facing version of all of this belongs in the AI business case, which carries the build-versus-buy matrix and the questions a CFO will ask.

What should the RFP and the due diligence do?

Most AI RFPs are theatre. They ask for a feature matrix, receive a feature matrix, and select on it, which selects for the vendor with the best proposal writer. The version that works replaces claims with tests: your data, your evaluation harness, your acceptance thresholds, run by you. That is a full subject with its own page: the AI vendor RFP that isn't theatre.

Diligence on an AI vendor asks a different set of questions than diligence on a SaaS vendor: what the model was trained on, what happens to your inputs, who the subprocessors are, what the indemnity actually covers when the output is wrong, and what the vendor's own dependency chain looks like when it is reselling somebody else's model with a margin on top. Also its own page: AI due diligence: what to ask before you sign.

How do you price usage you have never measured?

Skip the standard levers. You know how to negotiate a discount. Two things here behave differently, and this is the first.

You are being asked to forecast a quantity you have never measured, for a product whose consumption per user rises as the product improves. Every organisation I have seen do this has produced a forecast, and I have no primary source for how far off those forecasts typically run, so I am not going to put a number on it. What I can say is what the forecast error costs you, which depends entirely on the contract shape you signed it into.

Two clauses do most of the work regardless of shape. A price-protection clause fixing your unit rate for the term, because published token prices move in both directions and you want the downside without the upside. And a true-up mechanism that lets you reset the committed volume at a defined point, rather than discovering at renewal that you committed to a number from a workload that no longer exists.

What should the model-change clause say?

This is the clause that does not exist in your standard software template and it is the one I would spend the negotiation on.

The vendor will change the model underneath your contract. Sometimes by retirement on a published schedule, which is the honest case. Sometimes by updating a model behind a stable alias, which is the case that breaks things silently, because your evaluation suite drifts by a few points and nobody attributes it to the vendor for a month.

The deprecation numbers above are the reason this matters. Sixty days from an announcement to a hard API failure, on a workload with a tuned prompt layer and a calibrated eval harness, is not enough time to migrate carefully. It is enough time to migrate badly.

What to ask for, in order of how likely you are to get it:

1. Pinned versions, and a commitment that a version identifier you deploy against will not change behaviour without a new identifier. Vendors that already publish dated model IDs are most of the way there and this is largely a matter of writing it down.
2. Notice that exceeds the public policy, tied to your term rather than the general policy. If the public floor is 60 days, ask for 180, and expect to trade something for it.
3. A regression right. If a model change degrades your measured performance against an agreed benchmark by more than an agreed threshold, you get a defined remedy: continued access to the prior version, engineering support, or an exit without penalty. The threshold has to be a number you can compute from your own evaluation harness, which is another reason the RFP has to establish that harness before you sign.
4. Behavioural-change notification for anything that alters output distribution, including safety-filter and system-prompt changes. This is the one vendors resist most, and the resistance is informative.

How do you leave?

The last section of the contract and the first one that gets skipped. Almost nobody negotiates the exit, because at signature everyone in the room is optimistic and the exit clause reads as a lack of confidence in a decision they just made.

Two regulatory anchors are worth knowing, because they set a reference standard even in contracts they do not govern.

The EU Data Act sets a mandatory maximum transitional period for switching between data processing services of 30 calendar days (Article 25(2)(a)), caps the notice period for initiating a switch at two months (Article 25(2)(d)), and provides that from 12 January 2027 providers "shall not impose any switching charges on the customer for the switching process" (Article 29). Whether a given foundation-model API is a data processing service within the meaning of that regulation is genuinely arguable and I have not seen it settled, so do not assume coverage. Use the numbers as a benchmark. If a vendor tells you a 30-day exit is technically impossible, the EU legislature disagreed with that position for cloud services, and you can say so.

On the public-sector side, OMB Memorandum M-25-22 of 3 April 2025 tells federal agencies to include terms reducing lock-in risk, "such as requirements regarding knowledge transfer, clear data and model portability practices, clear licensing terms, and pricing transparency," and to secure "rights to code and models produced in performance of a contract." At contract closeout it directs agencies to implement "contractual terms related to ongoing rights and access to any data or derived products resulting from the services provided under the contract," including "a mutual understanding of format and usability of any data." The requirements attach to solicitations issued 180 days after issuance, which is 30 September 2025. Whatever you think of the surrounding policy, that is a public, citable statement of what a sophisticated buyer asks for, and it is useful to point at.

The private-sector version reduces to a short list of rights you either bought or did not:

• Export of your data in a documented, usable format, with the format specified in the contract rather than at the vendor's discretion at the time you ask.
• Export of derived artifacts. Embeddings, fine-tuned weights where the terms permit, evaluation results, prompt and configuration history. This is the one that is almost never asked for and it is the expensive one to lose.
• A transition assistance period with named hours and a rate, not best-efforts language.
• Deletion certification after transition, with a deadline and a defined artefact.
• Survival of your usage rights for a wind-down window after termination, so that a contract dispute cannot become an outage.

Then the test that makes the rest real. Once a year, cost the migration. Not a plan, a costed estimate with a named owner: what would it take to move this workload to the second vendor we kept warm. If that number is rising, the door is closing and your negotiating position is decaying on a schedule nobody is tracking. If nobody can produce the number, you have already lost the leverage and the renewal will show it.

The short version

The buying arc has one property that matters and it is not the price. It is whether the decision stays reversible for as long as you need it to. Everything above is a way of buying that property at the point where it is cheap, which is before signature, rather than discovering its price at renewal.

Which does not mean always buy the flexibility. Sometimes the arithmetic says take the discount and spend the difference on making migration cheap, and the optionality piece shows the numbers where that is true. What it means is that the question gets asked with a number attached, by someone whose job it is to ask, before the demo makes everyone want to sign.