How enterprise AI procurement is changing

The clearest signal that enterprise AI buying is being rebuilt is the gap between spending and results that it is reacting to. In McKinsey's 2026 State of AI survey, only thirty-seven percent of respondents said AI had added anything to their organizations' earnings, a share essentially unchanged from the year before even as more of them reported scaling the technology, and the roughly six percent that McKinsey classes as high performers stood out for redesigning workflows around AI rather than inserting it into existing ones. A procurement process designed to close that gap cannot keep working the way it did for conventional software. The old request for proposal asked vendors to describe what their product can do. The new one asks them to prove what it did, on the buyer's data, before the contract scales. The rest of this explains the mechanism behind that change.

Why the feature-list RFP stopped predicting anything

A request for proposal built on advertised capability assumes the description and the result are close enough to substitute for each other. For deterministic software that assumption mostly held. If a system claimed to export to a given format, it either did or it did not, and a reference call settled the question. Generative systems break the substitution for two reasons. The same model that handles eighty percent of a workflow cleanly can fail the remaining tail in ways the demonstration never surfaces, and the part that matters most, integration into the buyer's existing systems and data, is exactly the part a vendor demo cannot show. McKinsey's high performers point the same way: nearly three-quarters of them reported fundamentally redesigning workflows because of their AI use, against a quarter of other respondents. Gartner names the supply-side version of the same problem. In a June 2025 forecast it warned of agent-washing, the practice of relabeling existing software as agentic, and predicted that more than forty percent of agentic-AI projects will be canceled by the end of 2027. When the label is unreliable and the demonstration is unrepresentative, a procurement process that scores both is scoring noise.

What buyers are asking for instead

The move under way is from a feature checklist toward a bounded production pilot with predefined success metrics. Three changes follow from that. First, the evidence standard shifts from vendor benchmarks to reliability on the buyer's own data. A model's published accuracy on a public test set tells the buyer almost nothing about the documents, exceptions, and edge cases that live in their accounts-payable queue, so the credible vendor runs against a sample of the buyer's real workflow and reports the result. Second, the unit of evaluation becomes a real workflow run end to end rather than a capability shown in isolation, because the failures that sink projects appear at the seams between steps and systems, not inside any single step. Third, and operators tend to underweight this one, the operating model behind the software is weighted more heavily than the model inside it. The question is no longer only which model a vendor uses but who fixes the exception at 4 p.m. on close day, how the workflow gets corrected when it drifts, and whether the provider stays on the result or hands over a configuration and leaves.

What a defensible evaluation now contains

A modern evaluation has roughly four parts. It uses a real workflow, chosen because it is high-volume and currently manual, not because it demonstrates well. It runs against a held-out test, a slice of the buyer's own historical cases the vendor has not seen and has not tuned against, so the reported number measures generalization rather than memorization. It states an exception-rate target up front, the share of cases the system is allowed to route to a human, because no honest provider claims a workflow runs at one hundred percent autonomy, and the target is what makes the result falsifiable. And it carries a reversibility and audit requirement: every action the system takes must be logged, attributable, and undoable, so a wrong write can be traced and reversed rather than discovered in a quarterly reconciliation. The buyer who specifies these four can compare vendors on what they produced, which is the point of the exercise. We walk through how to construct one in how to tell a vendor that ships from one that demos, and the reason the exception-rate target matters so much sits in the 80-to-99% problem.

What the governance frameworks say

The audit and reversibility requirements are not flowscope inventions, although the frameworks that point toward them differ in whom they bind, and only one of them is law. The NIST AI Risk Management Framework is voluntary guidance. It organizes the discipline around measuring and managing risk across a system's life, and it recommends demonstrating a system's performance in conditions similar to deployment and monitoring it in production, while leaving the metrics and thresholds to the organization using it. ISO/IEC 42001, the management-system standard for AI, binds only the organizations that adopt it, and certification against it is voluntary; it expects documented controls and ongoing oversight rather than a one-time sign-off. The EU AI Act goes furthest. For the uses it lists as high-risk, such as hiring, credit scoring and eligibility for public benefits, it requires automatic logging of events, human oversight, and testing against metrics and thresholds defined in advance, and it requires the organizations deploying those systems to monitor them and keep their logs for at least six months. Those duties apply from 2 December 2027, after an amendment adopted in July 2026 postponed them, and they do not reach an accounts-payable workflow. None of the three frameworks sets an exception-rate target or asks for a test on the buyer's own historical cases. A procurement process that asks for a held-out test, an exception target, and a full audit trail goes further than any of them requires, in the direction all three point, and it has the evidence ready before an auditor or a regulator asks for it. The specific controls that satisfy the reversibility half of this are the subject of controls for autonomous actions.

What this does to the vendor field

An empirical procurement process sorts vendors differently than a capability one does. A firm whose strength is the demonstration, the polished interface and the impressive benchmark, scores well on a feature-list RFP and poorly on a held-out test against messy real data. A firm that builds and operates running workflows scores the reverse. The shift therefore moves spending toward providers organized as services, the ones staffed to integrate into existing systems and to stay on the result, and away from the ones organized to license a product and exit. This is also why the internal build-versus-buy question is changing shape. The choice is less about owning the code and more about who can demonstrate a working result and operate it, which we treat in build, buy, or hire an AI capability.

A reasonable counter, answered

A reasonable counter is that bounded production pilots are slow and expensive, that running every candidate against a held-out slice of real data is a heavier procurement than most operators can staff, and that a feature-list RFP at least screens the field cheaply before the costly stage. There is something to this. A real pilot does cost more than reading a slide, and an organization that runs ten of them in parallel will spend more on procurement than one that runs none. But the comparison is not pilot cost against zero. It is pilot cost against the cost of the projects that were bought on the strength of a demonstration and failed in production, each of which consumed integration time and internal credibility before it was canceled. Measured against that, a bounded test on your own data is the cheap option, and it is the demonstration that turned out to be expensive.