Three measured findings explain most of what goes wrong, and none of them is about the model. Google's DORA research programme concluded that AI's role is that of an amplifier — it magnifies whatever an organization already is, rather than supplying something it lacks. A randomised controlled trial by METR found experienced developers were 19% slower with AI tools on their own familiar codebases while coming away convinced they had been 20% faster (Becker, Rush, Barnes & Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv, July 2025). METR has since said it believes developers are “likely” more sped up by AI tools in early 2026 than its early-2025 estimate, while judging its own newer data “only very weak evidence for the size of this increase” — 30% to 50% of participants reported declining to submit tasks they did not want to do without AI (We are Changing our Developer Productivity Experiment Design, METR, February 2026). The trial is cited here for what it measured, not as a current estimate. And Eurostat found that among EU enterprises that considered AI and did not adopt it, the obstacle named most often was a lack of expertise, not cost. Read together: the surrounding system decides the outcome, self-report is not evidence, and the missing ingredient is capability rather than budget. A pilot scoped as a demo rather than a production system never acquires any of the three.
DORA's 2025 report is blunt about the mechanism. Drawing on a global survey of 4,867 technology professionals fielded between 13 June and 21 July 2025, it found AI use nearly universal — 90% of respondents use AI at work and more than 80% believe it has increased their productivity — while 30% report only "a little" (23%) or "no trust at all" (7%) in the quality of AI-generated output. Its headline conclusion is about the organization rather than the tool: "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." Without that foundation, the report says, "AI creates localized pockets of productivity that are often lost to downstream chaos" (Google Cloud / DORA, State of AI-assisted Software Development 2025, 2025). A pilot that demos beautifully and cannot ship is precisely a localized pocket of productivity lost downstream. The same research found AI adoption still increases software delivery instability even now that it improves throughput — teams are moving faster into systems that were never rebuilt to absorb the extra volume of change.
Where that amplification comes from is specific, and it is the part a proof of concept is built to skip. DORA measured which organizational conditions decide whether AI pays, and the strongest is unglamorous: "With a high degree of certainty, we found that AI adoption's positive benefits depend on organizations having healthy data ecosystems" — internal data that is "high-quality, easily accessible, and unified" rather than siloed — "such that, when they do, AI's positive influence on organizational performance is amplified." A proof of concept runs against a hand-picked dataset precisely because that ecosystem does not exist yet, and the hand-picked dataset is what hides the gap. Practitioners describe the same thing from the other side: a general-purpose chat interface is fine for a draft you were going to throw away, and useless for anything that matters, because it forgets every correction the moment the session ends.
That's the specific, checkable difference between a pilot that stalls and one that reaches production: does the system have somewhere to put what it learns? A chatbot wrapped around a general model with no memory of yesterday's correction will plateau at whatever accuracy it launched with, because nothing about using it makes it better. A system with a feedback loop — a place where a correction, an escalation, or a human override gets captured and changes the next run — is the architectural feature that separates the pilots that compound from the ones that flatline. It's also the one line item a demo never has to prove, because a demo only ever runs once.
How early this gets decided shows up in what firms themselves name as the obstacle. Among EU enterprises that considered AI and did not adopt it, Eurostat records 70.89% citing a lack of the necessary expertise, 52.52% a lack of clarity about the legal consequences, and 48.83% concerns about data protection and privacy (Eurostat, Use of artificial intelligence in enterprises, data extracted December 2025). Cost is not the leading obstacle. Capability and confidence are — and both are settled at kickoff, in the scope, not discovered in week ten. The tell is available on day one, before a line of code ships: can anyone point to where a correction goes, and who is accountable for making it?
Three questions catch this before the pilot burns its budget. First: when the system gets an answer wrong, does that correction go anywhere, or does it evaporate at the end of the session? Second: is the scope narrow enough that a wrong answer is cheap to catch — a drafted reply a human still approves, not an autonomous action against a live order or ledger? Third: does the workflow already run somewhere visible enough to benchmark against, so "better than the baseline" has an actual baseline rather than a demo's applause? A pilot that can't answer the first question honestly is the one that will be exactly as accurate in month six as it was on launch day — the failure was scoped in at kickoff, not discovered in production.
The failure mode we see most often looks identical in the demo and different two months later. A support-drafting pilot answers a curated batch of test tickets well, ships, and starts drafting live replies — then plateaus at whatever accuracy the demo showed, because nobody wired its misses back into anything. Every wrong draft a human corrects on the way out the door gets thrown away instead of becoming the next retrieval update or a flagged pattern someone reviews weekly. Three months in, the team is debating whether to kill the pilot — not because the model got worse, but because it never had a way to get better. That gap between "works in the demo" and "works in month three" is exactly what an AI pilot failed to reach production engagement exists to close — not by swapping in a better model, but by building the feedback loop the original scope skipped.
An AI virtual assistant for Amazon sellers we built treats this as core architecture, not an afterthought: alongside the recommendation engine, admins get a dashboard to manage unresolved cases and retrain the model directly — the same correction loop the diagnostic above is asking about, built in before the pilot's first 200 sellers ever saw a recommendation. The pilot was scoped from day one to scale to millions of sellers, and the retraining loop is the reason that scaling plan means more than "run the same static model on more accounts" — each unresolved case a seller flags becomes an input the next version of the model sees, not a support ticket that evaporates.
None of this argues against running a pilot — it argues against scoping one like a hackathon project. The three questions above are cheap to ask before a line of code ships and expensive to skip: DORA's amplifier finding, METR's gap between felt speed and measured speed, and Eurostat's expertise barrier are each describing, from a different angle, what happens to the pilots that skipped them. It is also the difference between a pilot and enterprise AI solutions — a system scoped to keep running is a different artifact from one scoped to be demonstrated once. An AI readiness assessment is built to answer them before budget is committed — a cheaper place to find out than month three of a stalled one.
Related: AI pilot failed to reach production
Find this useful? Tell Google to show you more of it.