Why AI pilots stall, and the three questions that unstick them

Most companies we speak to are not short of AI pilots. They have a chatbot someone built in a weekend, a document tool the finance team trialled, and a vendor demo that impressed the board. What they are short of is a pilot that made it into the way the business runs, with a number attached.

That gap is common. In RSM’s 2026 survey of 1,030 mid-market companies in the US and Canada, 86% said they had put AI into their operations, but only 17% were pursuing it across the whole business (RSM Middle Market AI Survey 2026).

Pilots rarely stall because the technology failed. They stall because nobody answered three questions before the pilot started.

1. What number will this change, and what is it today?

A pilot without a baseline can only ever be “promising”. If you don’t know how long proposals take today, you can’t show that the new tool made them faster. If you don’t know how many hours finance spends matching invoices, you can’t show the hours it saved.

Before any build starts, write down:

• the one number the use case is meant to move, such as hours per week, cycle time, cost per transaction or qualified pipeline
• its value today, measured, not estimated
• the value that would make the work worth continuing

This takes a week at most, and it changes the conversation at the end of the pilot. “People like it” becomes “turnaround fell from five days to two, measured over a month”. The second sentence gets budget. The first gets a polite nod.

2. Who owns it after the pilot ends?

Pilots are often run by an enthusiast or an outside team. When the pilot ends, the enthusiast goes back to their day job and the outside team moves on. The tool sits in a folder.

Production needs an owner inside the business: a named person who is responsible for the result, has the authority to change how their team works, and has time set aside to do it. That person should be involved from the first week, not handed the tool at the end.

If you can’t name the owner before the pilot starts, that is useful information. It usually means the use case isn’t a priority yet, and the money is better spent elsewhere.

3. Does it work inside the systems people already use?

A pilot that lives in a separate tool asks people to change where they work. Most won’t, however good the tool is.

The pilots that reach production are the ones built into existing systems: the CRM where sales already log calls, the ERP where finance already matches invoices, the shared drive where proposals already live. That means integration work, permissions and edge cases, which is exactly the work a quick pilot skips.

Plan for it from the start. If the pilot can’t connect to the real systems, it can’t prove anything about the real business.

What this looks like in practice

When we run an AI Pilot-to-Production Sprint, the first week is spent on these three questions, not on the model. We agree the baseline in writing, name the owner, and map the systems the use case has to work with. Only then do we build.

It feels slower at the start. It is much faster at the end, because the result is a number your CFO recognises and a tool your team already uses.

Where to start

If you have several pilots and aren’t sure which one deserves to go to production, rank them by two things: the value of the number they move, and how close they are to the systems where the work happens. The one that scores highest on both is usually the right first bet.

If you’d like a structured view of where you stand, the AI Readiness Index scores your company across strategy, data, systems, people and governance in about six minutes.