The Procurement Team Cannot Buy What It Cannot Specify
A procurement team is, structurally, a comparison engine. Vendors arrive with proposals. Procurement evaluates them against a specification. The specification was written before the procurement cycle began, usually by some combination of business stakeholders, IT, and a consultant. The evaluation produces a recommendation. A contract gets signed. The vendor delivers, more or less, what the specification asked for.
This system worked, imperfectly, for forty years of enterprise software. It is breaking down for AI procurement – and the breakdown is not the vendors’ fault.
What Specifications Used to Look Like
A traditional enterprise software RFP was a list of features. “The system shall support single sign-on via SAML 2.0.” “The system shall provide role-based access control with at least four pre-defined roles.” “The system shall integrate with the customer’s existing ERP via REST APIs documented in the technical appendix.”
Features were tractable to specify because they corresponded to user-visible behaviors and documentable contracts. Vendor X had it; vendor Y did not; the RFP scored accordingly. Two vendors with the same feature checkmark were, for procurement purposes, interchangeable.
The vendors knew the game. They built feature parity to clear the checkmarks. They invested in the things the RFP measured. They invested less in the things the RFP did not measure – usability, performance under load, day-two operability, the experience of actually running the system for three years. The RFP got what the RFP asked for, and the operational reality was whatever the operational reality turned out to be.
This was acceptable when the operational reality was bounded and predictable. It is no longer.
Why AI Is Different
An AI product is not a feature list. An AI product is a behavior, parameterized over inputs that the buyer has not yet seen. The features that matter are emergent: how the system behaves on the specific data, in the specific workflows, against the specific users that the buyer will throw at it.
The traditional procurement question – “does the product do X?” – does not produce a useful answer here, because the answer is “it depends on the inputs, the prompt, the version of the model, the temperature, the retrieval index, the user, and the phase of the moon.” The vendor’s demo, run on the vendor’s data, with the vendor’s prompts, will look good. The same product, run on the buyer’s data, may or may not.
This is not a vendor problem. It is a category problem. The procurement specification is asking about a thing that cannot be specified in advance without doing the work the specification is trying to outsource.
The Symptoms
We see this regularly. Procurement issues an RFP for “an enterprise AI platform.” The RFP runs for ninety days. The eventual winner is the vendor with the largest customer list, the best demo, and the most plausible-sounding security narrative. The contract is signed. Twelve months later, the project is in the middle of an “expanded pilot.” Eighteen months later, the pilot has not converted to a production deployment. Twenty-four months later, the executive who signed the contract is in a different role.
The vendor delivered exactly what the RFP asked for. The buyer got something that does not do the work the buyer needed done. Neither side is in the wrong. The procurement process produced the wrong artifact.
The artifact was wrong because the buyer could not specify what they actually needed. They could specify what the platform should be, but not what it should do in their context. The vendor, in good faith, sold them the thing the spec described. The thing the spec described was not the thing that would have worked.
A Better Question
The procurement question that actually produces useful answers is structurally different from the feature checklist. It looks like:
“Show me your product running on a representative sample of our data, in a representative sample of our workflows, evaluated against an outcome we agreed on in writing.”
This is harder than running an RFP. It requires the buyer to assemble representative data, agree on an outcome, and commit to a paid evaluation period – typically weeks, sometimes months – during which the vendor is paid to integrate and the buyer is committed to participating. It is not a free demo; it is a contracted evaluation.
The vendors who can deliver under those conditions are not always the vendors with the best logos or the largest customer lists. They are the vendors who have done this before, who have an integration playbook, and who can produce measurable outcomes on data they have not seen. That is a much smaller pool than the RFP responder pool. It is also the pool where the working vendors actually live.
Where Procurement Has to Change
A procurement team that wants to buy AI well needs three capabilities that most do not currently have.
Outcome literacy. The team has to be able to read a business problem, articulate the outcome that would resolve it, and write that outcome into a contract. This is not a procurement skill in the traditional sense. It is a product skill. Procurement teams without an embedded product or domain partner cannot do this work alone, and pretending they can produces the RFPs that produce the failed deployments.
Evaluation infrastructure. The team has to have, or have access to, the data, environments, and measurement tools required to run an evaluation. The vendor cannot bring these. They have to be the buyer’s, because the whole point of the evaluation is that the vendor’s product is being tested on the buyer’s reality.
Tolerance for paid evaluation. A real evaluation is not free. Vendors charge for the integration work. Buyers spend internal time. Both sides commit to a measurable outcome and a timeline. The buyer who insists on “free pilots” is selecting for vendors willing to do unpaid integration work, which is a different population than the one that will deliver in production. The cheap-feeling part of the process is the part that costs you the most downstream.
The Vendor Side
Vendors are not innocent here. The dominant strategy on the vendor side has been to chase RFP checkmarks rather than build for outcomes, and the procurement system rewards that strategy. The vendors who do build for outcomes are often penalized by procurement processes that cannot read what they are offering.
If you sell AI products and your sales conversations bottom out in “what features are on your roadmap,” you are inside the wrong conversation. The buyers who matter are the ones asking “what outcome will this produce on my data,” and the procurement teams who serve them are slowly learning to ask the same.
The Honest Statement
The procurement function was built for an era when products were specifiable in advance and comparable on features. AI products are neither. The function has to adapt, and adapting is expensive. It requires new skills, new tooling, new contract structures, and a new relationship between procurement and the business units that will actually use the software.
The organizations that adapt will buy AI well – meaning, they will buy systems that produce the outcomes they were trying to produce. The organizations that do not will continue to issue RFPs, sign contracts, run pilots, and accumulate AI platforms that nobody uses.
You cannot procure your way out of a specification problem. You have to fix the specification problem first.
