# Why AI Pilots Stall — and What Unsticking One Takes *Most stalled AI pilots aren't failing for the reason everyone in the room thinks. The model is usually fine. What's missing is almost always one of five unglamorous things — and knowing which one changes whether the pilot ships in six weeks or dies in six months of polite status meetings. Here's the diagnostic I run when a team brings me a pilot that won't move.* I meet a lot of AI pilots in the same condition: demo went well, everyone was excited, budget was found — and then months passed. Not failed, exactly. Stalled. Still "two months away," the way it was two months ago. The team is good and working hard, which makes it more confusing, not less. When I'm brought in to unstick one, I'm checking for five causes, in order of how often I find them. ## 1. Nobody wrote down what "done" means The most common cause, by a wide margin. The pilot was built to a feeling — "it should answer questions about our policies well" — not to a bar: *this task, this accuracy, measured this way, on this data, signed off by this person.* Without a written bar, the pilot can't finish, because finishing isn't defined. Every stakeholder holds a private, different standard; every review surfaces new wishes; the team polishes forever because they can't prove they're done. The fix is almost embarrassingly cheap: get the stakeholders in a room and leave with a one-page agreement — task, bar, evaluation data, who signs. I've watched pilots that drifted for a quarter ship four weeks after that page existed. ## 2. It was proven on data the real world doesn't send The demo ran on the clean cases — the well-formed documents, the typical tickets. Production sends the other kind: scans, half-filled forms, the weird edge cases that are 20% of volume and 80% of risk. A pilot that stalls here usually *knows* it, quietly: everyone has seen it fumble real inputs, so nobody wants to be the one who flips the switch. The fix is to stop avoiding the evidence — pull a genuinely representative sample, including the ugly tail, evaluate against the bar from cause #1, and then either close the specific gaps that show up or renegotiate scope honestly ("we handle these three document types now; the fourth goes to a human"). A narrower system that's trusted ships; a broader one that's feared doesn't. ## 3. The integration was always the real project The AI part worked months ago. What's stalled is everything around it: access to the system of record, an identity for the service, a security review nobody scheduled, an API that turned out to be a person named Dave. Teams under-scope this because it isn't AI work — but it was always most of the work. The fix is to re-plan the remainder as an integration project with the AI as a solved component: name every system boundary, every approval, every owner, and work that list like the dependency chain it is. This is also the cause where an outside engineer helps most, bluntly, because an embedded outsider can escalate "we've been waiting three weeks for a service account" in ways a polite internal team sometimes won't. ## 4. The fear never got retired Sometimes the pilot works and still can't ship, because someone with veto power — security, legal, compliance, the process owner — has an unaddressed fear: data leaving, a wrong answer reaching a customer, an agent doing something no one can explain afterward. The team hears the fear as obstruction; the stakeholder experiences the team as cavalier; the pilot sits between them. The fix is to treat the fear as a requirement: name it precisely, design the specific control that retires it (human review on this class of output, this logging, this kill switch, this data boundary), and demonstrate the control working on real cases. In my experience the feared conversation is almost always easier than the months of stall it's causing — because the stakeholder usually *wants* to say yes and has never been given the evidence to. ## 5. Nobody owns the outcome A pilot has builders; shipping needs an owner — one person whose problem it is that this isn't in production yet, with the authority to make the calls causes 1–4 require. If the answer to "who owns this going live?" is a committee, a vendor, or a shrug, that is itself the diagnosis. The fix is organizational, not technical, and it's usually a ten-minute decision for the sponsor once the question is put that plainly. ## What unsticking actually looks like The pattern across all five: a stalled pilot is almost never short of effort or talent — it's short of *definition* (what's done), *evidence* (real data, retired fears), or *ownership* (who ships it). That's why unsticking one is usually weeks, not months: the work is running the diagnostic honestly, writing the one-pager, running the real-data eval, naming the controls, and sequencing the integration list. It's also, candidly, the work I do as a [forward deployed engineer](/services/poc-to-production-rescue/) — embedded with the team, on their data, until the thing is live or there's an honest answer that it shouldn't be. If your pilot has been "two months away" for more than two months, the free [readiness check](/ai-readiness/) will usually point at which of the five is yours — and if you'd like a second pair of hands, [that's an easy conversation to start](https://calendar.app.google/x7W5bAdst4J6MT2u7). ## Key takeaways - Stalled pilots rarely have a model problem — the diagnostic is five causes: **no written bar**, **unrepresentative data**, **under-scoped integration**, **an unretired fear**, **no owner**. - The cheapest, most common fix: a one-page agreement — task, bar, eval data, sign-off — turns "polishing forever" into a finishable project. - Prove it on the real tail, then ship the honest scope: a narrower trusted system beats a broader feared one. - Treat stakeholder fear as a requirement: name it, build the specific control, demonstrate it — vetoes usually want evidence, not victory. - Shipping needs **one owner** with authority; "a committee" is the diagnosis, not the answer. ## Further reading - [Proof of concept — what a pilot does and doesn't prove](https://en.wikipedia.org/wiki/Proof_of_concept) - [Pilot experiment — the trial stage and its limits](https://en.wikipedia.org/wiki/Pilot_experiment) --- Author: Pratik Dhanave (https://pratikdhanave.com) | Published: 2026-11-09 Canonical: https://pratikdhanave.com/blog/posts/why-ai-pilots-stall.html Attribution: please link the canonical URL when citing or quoting this post.