Why AI pilots stall
Every company I talk to has the same artifact sitting somewhere: a demo that impressed everyone, built in a hackathon or a sprint, that six months later still is not live. The usual diagnosis is that the model was not good enough, or the use case was not real. In my experience both diagnoses are almost always wrong. The use case was fine. The model was fine. The pilot hit four walls that nobody had budgeted for, because none of them show up in a demo.
Wall one: identity
A demo runs on someone’s API key. A production tool runs as a person, with that person’s permissions, inside your identity provider. The gap between those two sentences is real engineering: OAuth against Entra ID or whatever you run, token refresh, per-user scopes, offboarding. Skip it and you have a tool where everyone acts as the intern whose key it was. Your security team will find that, and they should.
Wall two: data
Most stalled AI projects turn out to be stalled data projects. The demo worked because someone hand-fed it a clean extract. Production means the model reads from systems as they actually are: inconsistent definitions, three tables that each claim to be the source of truth, metrics that two departments compute differently. If nobody can say which number is right, the model cannot either, and it will confidently repeat the wrong one.
Wall three: governance
At some point a reasonable person asks: what data is this thing sending where, and who said that was fine? If the answer is a shrug, the pilot stops there. The fix is boring and cheap relative to the alternative: a written data-handling policy, an approved-tools list, and logging that can answer who asked what, what the model did, and what changed as a result. I have watched this single artifact set move a security review from hostile to cooperative.
Wall four: ownership
A demo has an author. A production tool needs an owner: someone on the hook when it breaks at quarter end, a place its costs land, a plan for the month its author leaves. Pilots stall here quietly, because nobody says no. The tool just never acquires an owner, and unowned software does not get deployed.
The order of operations
The pattern that works is to invert the usual build order. Auth, data access, logging, and an owner come first, before the interesting parts, because they are the parts that kill projects. The model layer moves fast once the ground under it is real. When I scope an engagement, this is most of what the first two questions are about: not what the AI should do, but what it will run as, and who will own it. If those two have answers, the pilot-to-production gap mostly disappears.