You'll hear the failure attributed to "the model not being good enough," or "the data not being ready," or "change management." Sometimes those are real. More often they're the way people describe the problem when they don't want to point at the actual cause — which is that the pilot was set up in a way that made production impossible from day one.

Here are the three patterns we see repeatedly when we're called in to figure out what went wrong.

1. The data plumbing nobody owns

The model demo works because someone exported a CSV, cleaned it in a notebook, and ran the inference offline. To put that model in production you need a continuous pipeline: the source system feeding it must stay available, the transformations must run reliably, the schema must be versioned, and someone must be paged when any of that breaks.

That pipeline crosses team boundaries. The source data lives in a system owned by Team A. The transformation logic the data scientist wrote was bespoke. The platform that's supposed to run it in production is owned by Team B. The on-call rotation is owned by Team C. Nobody put a name next to "if this breaks at 2am, who fixes it?" — and that's the moment the pilot stalled.

This is a solvable problem, but it has to be addressed in the first two weeks of the pilot, not the last two. We force the conversation up front: who owns the data pipeline in production, and what is their SLO? If that question can't be answered, the pilot is a science project, not a path to production.

2. Use cases picked for demo-ability, not business value

"Generate a draft email." "Summarize a long document." "Answer questions about our knowledge base." These are easy to demo because the output is text and the audience can evaluate it instantly. They're also weakly tied to business outcomes — which is why six months later, the executive who funded the pilot can't explain what changed in the P&L.

The use cases that survive are the ones where the AI sits inside a workflow that already has a number attached: cycle time on a claims case, first-contact resolution rate in a service queue, percent of contracts processed straight-through. The AI doesn't replace the workflow — it shortens the slowest step in it. You measure the workflow metric before and after, and the answer is a number, not a vibes assessment.

If you can't draw a straight line from the AI output to a number on a dashboard someone already cares about, the pilot will not reach production. It will reach "interesting demo."

3. Governance gates designed after the fact

The pilot reaches the end of the experimentation phase. It works. Now it has to clear legal, risk, security, model risk management, data privacy, the AI ethics council, and three signature workflows that didn't exist when the project started.

Each gate is reasonable on its own. Together they form a moat that the project takes nine months to cross — by which time the executive sponsor has moved roles, the data scientist has left, and the model has drifted enough that the original evaluation is no longer credible.

The fix is to make governance a parallel workstream from week one, not a gate at the end. The risk team should be in the room during scoping. The legal review should happen on the use case definition, not the production system. The model evaluation framework should be the same framework that governance approves against. Done this way, "going to production" is a one-week exercise, not a six-month one.

What an engagement that actually ships looks like

The shape of an AI engagement that crosses the finish line looks different from one designed only to prove a capability:

  • Week 0: Pick a business metric. Identify the workflow that owns it. Identify a single AI intervention that could move it.
  • Weeks 1–2: Stand up the data pipeline with a named production owner. Get the governance team aligned on the use case definition.
  • Weeks 3–6: Build the system end-to-end against production-shaped data. Evaluate against business outcomes, not just model accuracy.
  • Weeks 7–10: Run a controlled rollout to a real subset of users. Measure the metric. Iterate.
  • Weeks 11–12: Hand off to operations. The team running the workflow now owns the AI inside it.

That timeline is achievable when the pilot is designed for production from the start. It is not achievable when the pilot is designed to demo a capability and "we'll figure out production later." Later is exactly when the friction shows up — and later is when the project dies.

The honest takeaway

If you're sitting on a portfolio of AI pilots and wondering why none of them are in production, the question to ask is not "are these models good enough?" The question is: does each pilot have a named production owner, a business metric on a dashboard, and governance in parallel?

The pilots without all three will not ship. The pilots with all three usually will. The technology is the easy part.