What to Do When Your AI Pilot Passes but Production Stalls

The pilot worked. The data scientist showed the chart. Everyone clapped. That was nine months ago. Here is a practical sequence for getting it unstuck — based on what actually moves these programs inside regulated financial institutions.

There is a specific kind of frustration that sets in around month eight or nine of a stalled AI initiative. The pilot is not the problem — everyone agrees on that. The model performed. The proof of concept was real. What's less clear is why, nine months later, the program has produced a long series of meetings and a short list of tangible progress.

The board is asking pointed questions. The CFO wants to know when the budget produces something. The data science team is demoralized. The vendor is restless. And the person responsible for the program — which may be you — is spending most of their time managing frustration rather than making progress.

I've been brought into this situation enough times to have a view on what works and what doesn't. What follows is the sequence I actually use.

Before you do anything else: triage, don't diagnose

The instinct when a program is stalled is to call a meeting, map the blockers on a whiteboard, and produce a remediation plan. I've seen this done well, but more often it produces a thorough understanding of the problem and no discernible change in momentum. The issue is that diagnosing a stalled program and moving a stalled program are different activities, and most organizations are much better at the former than the latter.

What I do first is triage — not to understand the full picture, but to identify the one or two things that, if resolved, would allow the program to move. Not everything. The one or two things.

To find them, I ask a narrow question: what would have to be true for this program to move to the next stage in the next 30 days? Not six months. Not "eventually." Thirty days. The answer almost always points directly at the actual blocker, because it forces people to be concrete. "MRM has to sign off" is an answer. "We need better stakeholder alignment" is not — it's a symptom description masquerading as a root cause.

Once you have the one or two concrete things, you have a triage list. That's where to spend the first 30 days.

Days 1–30: Resolve the gate, not the symptoms

A stalled AI program almost always has a gate — a specific function, decision, or artifact that is blocking progress. It might be a Model Risk Management validation that's been in review for five months. It might be an IT security review that no one is actively driving. It might be a budget approval that got deferred when the original executive sponsor changed roles.

The mistake most program managers make is working around the gate rather than through it. They build more documentation. They run more stakeholder updates. They add workstreams that don't depend on the blocked one. None of this resolves the gate. It adds activity to a program that already has plenty of activity and not enough forward motion.

Working through the gate means getting the right person in the room with the right question. If MRM has thirty unresolved questions, the right move is not to write better answers to all thirty — it's to get fifteen minutes with the head of MRM and find out which three of those questions are actually blocking approval. Usually, it's three. The other twenty-seven are clarifications that will get resolved once those three are addressed. But nobody asks that question directly, because it feels confrontational, and so the program sits for months answering questions that weren't really the issue.

This requires someone who is comfortable having direct conversations with senior risk, compliance, and technology leaders — and who has enough credibility with those functions that the conversations are productive rather than defensive. That's often not the data science team, who reasonably feel that they've already submitted everything that was asked of them. It's usually a program leader who can sit between functions and translate.

Days 30–90: Rebuild the execution structure

Once the gate is open — or moving — the second problem usually becomes visible: the execution structure that was adequate for the pilot is not adequate for production.

A pilot has one team, one objective, a sandboxed environment, and a fixed endpoint. Production has multiple teams, competing objectives, live systems, and an indefinite timeline. The coordination mechanisms that worked for the pilot — usually a project manager and a weekly status meeting — are not enough for production. And most programs don't discover this until they're already in trouble.

The structural fix has four components:

A steering committee that actually steers. Not a status update forum. A decision-making body with the authority to resolve cross-functional disputes, approve scope changes, and hold functions accountable for their commitments. The executive sponsor needs to chair this personally, not delegate it. A steering committee chaired by a delegate is a coordination meeting with a fancier name.

A single program lead with cross-functional authority. Someone who can walk into IT, MRM, Compliance, and the business unit and get things done — and who is accountable for the production date, not just for managing their slice of the work. This is the role that most stalled programs are missing. The data science team is accountable for the model. The IT team is accountable for the infrastructure. Nobody is accountable for the whole thing reaching production on a specific date.

A realistic, fully-scoped plan. Not a project plan that covers the model work. A plan that covers the model work, the integration work, the MRM validation, the security review, the change management, the training, and the operational readiness. The integration work alone is typically three to five times the effort of the model work, and it's almost never in the original plan. Surfacing the real scope — even when the number is uncomfortable — is usually the thing that actually unblocks the budget conversation.

A 90-day milestone with teeth. A specific, binary, demonstrable thing the program will have in production in 90 days. Not "significant progress toward production." A thing. The specificity is what creates urgency. Vague timelines produce vague effort.

What the programs that actually reach production do differently

After watching a fair number of these programs succeed and fail, the pattern among the ones that make it to production is consistent enough to be worth naming.

They treat governance as a workstream, not a hurdle. The institutions that move quickly through MRM and Compliance validation are not the ones with the best models. They're the ones that brought MRM and Compliance into the design conversation early — before the model was built — and treated their questions as design inputs rather than review criteria. By the time formal validation starts, most of the questions have already been answered, because they were built into the system from the beginning.

They scope for production from day one. The pilot was scoped as a pilot. Reasonable. But the institutions that get to production fastest are the ones that, even in the pilot stage, kept a running list of what would be different in production — what data pipelines would need to exist, what audit logging would be required, what the operational team would need to know, what SLAs the system would need to meet. The pilot team handed that list to the production team at the transition. The list was never complete, but it was a starting point, and a starting point is worth a lot.

They have a sponsor who stays engaged. This is, in my experience, the single most reliable predictor of production. Not the quality of the model. Not the sophistication of the technology. Whether the executive sponsor is actively attending the steering committee, resolving cross-functional disputes in real time, and treating this program as a priority that competes with their other priorities for their personal attention. The programs that stall have sponsors who were engaged during the pilot and disengaged afterward. The programs that make it have sponsors who are visibly present through deployment.

A stalled AI program is almost never a technology problem. It is an organizational one — and the organizational problems are fixable, but they require someone willing to name them directly and push on the structures that are producing them.

The thing most people don't want to say out loud

Sometimes, at the end of a triage, the honest answer is that the program is not recoverable as currently structured. The scope is wrong, the team is wrong, the vendor relationship is not salvageable, or the executive sponsor has moved on and no equivalent has stepped in. Trying to unblock a program in that situation produces more meetings, more documentation, and more frustration — but not production. The full cost of remaining stalled — team attrition, vendor leverage loss, board credibility — is usually larger than the number on the budget slide suggests.

In those cases, the most useful thing is to say clearly that the program needs to be restructured before it can be rescued. That means new scope, possibly a new vendor conversation, definitely a new executive champion, and a clean reset rather than a series of patches on top of a failing structure. This is an uncomfortable conclusion to reach, but reaching it in month ten is better than reaching it in month eighteen.

I've had that conversation enough times to know that it almost always goes better than the person asking for help expects. The people running these programs usually know, at some level, that what they're doing isn't working. Hearing it said directly — with a specific view of what would need to change — is usually a relief rather than a setback.

If you're in that situation, or if you're not sure which situation you're in, I'm glad to take a look. The first conversation is free, and it's not a sales call.