Why Your AI Pilot Died in Procurement

The pilot worked. That was never the question. The demo landed, the accuracy was defensible, the users liked it, and then it spent five months in a queue and quietly stopped being mentioned. Nobody killed it. It expired. If you have watched this happen twice, you have probably concluded that the organization is broken, and I want to argue for a less satisfying explanation: the pilot was scoped to answer a question nobody was blocking on.

The demo answers "can the model do this?" The organization was never unsure about that. What it does not know is who is accountable when the model is wrong, where the data goes, what happens at renewal, and who signs. Those questions have owners, those owners have queues, and none of them saw your pilot coming.

Procurement is not the villain

The engineering read is that procurement is a tax: risk-averse people slowing down obvious value. That read is comfortable and mostly wrong, and holding it is expensive, because you cannot design around a process you have decided is illegitimate.

Procurement is the function that asks whether the company can live with this thing for three years. Every question it asks encodes a previous incident, usually one that predates you. The vendor that got acquired and tripled its price. The tool with a data breach that nobody could scope because there was no inventory of what it held. The renewal that auto-executed for a product two people used. These are not hypotheticals to the person reviewing your form. They are the reason the form exists.

The friction is real, and some of it is genuinely waste. But the correct response to a slow gate is to enter it early with good answers, not to hope it is not there.

The four gates that actually stop things

Security review

The questionnaire is not really about your vendor's TLS configuration. It is trying to establish what the tool can reach and what happens when it misbehaves. AI tools score badly here for a structural reason: they ask for broad read access to be useful. "Read every document in the tenant so it can answer questions about them" is a legitimate product requirement and a genuinely alarming access request, and both facts are true at once.

The pilot that clears this gate is the one that can state its permission model in a sentence. Read-only by default, with write access as a separate, explicitly consented step, is a fundamentally easier review than a single scope that does both, no matter how good the audit log is. If the tool cannot describe its blast radius, security will find out, slowly, in writing, over six weeks.

Data processing agreements

This is where most AI pilots actually die, and it dies on one question: is our data used to train your models?

If the answer takes a paragraph, the answer is functionally yes, and legal will read it that way. The DPA needs sub-processors named, retention stated in days, deletion on termination specified, and the training question answered in one clause. Every hedge adds a review cycle, and review cycles are two weeks each because the person reading it has forty other things.

The compounding problem is that AI vendors change sub-processors more often than the DPA cadence assumes. A model provider swap is an amendment. Nobody plans for the amendment.

The AI-specific overlay

New since roughly last year, and inconsistently applied: an internal AI review asking for a risk classification, a human oversight description, and evidence you know what your obligations are. Where this exists it is often the fastest gate, because it is new enough that the owner has time. Where it does not exist yet, its questions get asked anyway, ad hoc, by whoever noticed, at the worst possible moment. As the August 2 transparency obligations land, expect this gate to formalize in more places, and expect that to be an improvement, because a defined gate with a queue beats an undefined objection raised in a steering committee.

Budget ownership

The quietest killer. A pilot runs on someone's discretionary budget or a free tier. Production needs a line item, a cost center, and an owner who will defend it next cycle. If the pilot's sponsor is an enthusiastic engineer rather than a budget holder, there is no path from pilot to production regardless of the results, and this is usually visible on day one to anyone who looks.

Why the pilot itself sets the trap

Pilots are designed to be easy to start, and the things that make them easy to start are the things that make them impossible to finish. Synthetic or sanitized data, so the DPA question never arises. A sandbox tenant, so the access model is never reviewed. A free tier, so no budget owner is needed. An enthusiastic team, so no accountability question is asked.

Every one of those choices defers a gate rather than clearing it. Then the pilot succeeds and all four arrive at once, at the moment when everyone believes the hard part is done and the remaining work is paperwork. The organization has not moved a millimetre toward production, and now it is disappointed as well.

Scope pilots to the gates

The fix is not more governance in the pilot. It is picking a pilot whose success answers the questions that block deployment.

Use real data on a real tenant, on the smallest possible scope. One department, production data, actual permission model. A pilot on real data with three users clears more gates than a pilot on synthetic data with three hundred, because it produces answers rather than promises.
Get the DPA read in week one, not week twelve. Send it to legal before the demo. If the training clause is a problem, you have learned the outcome for the price of an email rather than a quarter.
Name the budget owner before you start. If nobody will own the line item, run the pilot as research and say so out loud. That is a legitimate thing to do. What is not legitimate is calling it a path to production.
Write the security answers before the questionnaire arrives. Permission model, data flow, sub-processors, retention, deletion. One page. Most of the six-week delay is round trips, and round trips are latency, not work.
Run the gates in parallel with the build. They are queue-bound, not effort-bound. Nothing about legal reading a DPA requires your code to exist.

This makes pilots slower to start and dramatically more likely to finish, and that trade is only obvious after you have lost one. The counter-argument is real: front-loading gates onto exploratory work kills exploration, and some pilots deserve to be cheap experiments that die fast. Fine. Just be honest about which kind you are running, because the failure I am describing is not a bad experiment. It is a good experiment that everyone mistook for a deployment plan.

The takeaway

AI pilots rarely die of accuracy. They die because the demo answered a question nobody was blocking on, while security review, the DPA, the AI overlay, and budget ownership went untouched until the end and then arrived together. Procurement is not obstruction; it is the organization asking whether it can live with this for three years, and those questions are coming whether or not you scheduled them. Scope the pilot so that succeeding means clearing a gate. The teams that ship are not the ones with better models. They are the ones who started the twelve-week clock in week one.