Why AI pilots stall, a field guide to the graveyard
Most AI pilots do not fail. They stall, which is worse, because nobody writes down why. The four stall patterns and what each one is trying to tell you.
Failed pilots are rare and useful: something broke, everyone learned, the postmortem writes itself. Stalled pilots are common and corrosive. The demo went fine. The steering committee nodded. And then nothing shipped, no one said stop, and eight months later the project exists only as a line item and a slightly haunted product manager. I have toured a lot of this graveyard. The headstones say four things.
Nobody owned the workflow, so the pilot owned nothing. The demo answered questions; the job requires answering them inside a claims process, a support queue, a code review. A pilot that does not name the workflow it will change, and the person who owns that workflow, is a technology looking for a sponsor. It stalls the day the demo ends because there is no next desk for it to land on.
The data prerequisite was discovered, not planned. Retrieval over documentation nobody maintained, automation over a process three people do three ways. The pilot stalls while someone cleans up, and "while" quietly becomes the project's tombstone.
Success was never a number. Without a baseline and a target ("first-response time down 20% on this queue"), the pilot's end state is a vibe. Vibes do not survive budget season.
It threatened someone and nobody noticed. The team whose work the pilot touches can stall anything without ever saying no. Slow-walked access requests are a form of feedback. The fix is not pressure; it is making those people the pilot's beneficiaries in week one, or choosing a different pilot.
A diagnostic you can run this afternoon on any pilot currently in limbo: ask its owner what happens next month, specifically. A healthy pilot's owner answers with a date and a number. A stalled pilot's owner answers with a dependency ("waiting on security"), a hope ("once people see the value"), or my favorite, a synonym for momentum. Then ask who wants the pilot to fail, and watch whether the answer is "nobody", which is always wrong. Something is threatened by every pilot worth running; naming it is the beginning of finishing.
The pattern underneath all four: pilots stall at the seams between the technology and the organization. The technology mostly works. The seams are the work, and they are exactly what a readiness audit is for.