In a survey published in May 2024, Gartner found that only 48 percent of AI projects make it into production on average, and the move from prototype to production takes eight months. Two months later Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs, and unclear business value. In 2025, S&P Global Market Intelligence surveyed 1,006 IT and business professionals in North America and Europe and found that 42 percent of companies had abandoned most of their AI initiatives, up from 17 percent a year earlier.
Some of those pilots should have stopped, and stopping them was the right call. The expensive pilot is the one that neither scales nor stops. It keeps running in one team, on one workflow, while nobody makes the call.
The end of a pilot is a decision with three valid answers: scale it, revise it, or stop it. This piece is about that decision: who owns it, what they need to make it, and how to set it up before the pilot begins.
Name the owner before the pilot starts
Ask who will decide whether this pilot goes to production. If the answer is a steering committee, the innovation team, or "we'll see how it goes", nobody owns it.
McKinsey's March 2025 State of AI report, based on a July 2024 survey of 1,491 participants, found that CEO oversight of AI governance was the factor most correlated with higher self-reported bottom-line impact from generative AI. Only 28 percent of respondents said their CEO was responsible for that oversight. Two cautions apply. The impact figures are self-reported, and correlation does not show that CEO oversight caused the results. What the finding does support is a narrower point: ownership at the top of the organization travels with better reported results, and most respondents' organizations did not have it.
For the pilot-to-production decision, our recommendation is one named owner per pilot, chosen by three tests:
- Their budget pays for production. The person who decides should be the person whose P&L carries the run cost after the pilot ends.
- Their team changes how it works. If the workflow belongs to claims, the owner sits in claims, not in IT.
- They can say stop. An owner who cannot end the pilot without escalating will defend it rather than judge it.
The technology lead, finance, and risk each have a seat. They inform the decision. The owner makes it. The technology lead says what production will cost to build and run. Finance checks that the numbers include the full cost. Risk and legal say what controls production requires.
Put the owner's name in the pilot charter on day one. If you cannot find a name, do not start the pilot.
Write the decision rule before you see the results
A pilot that starts without a decision rule ends in a debate. The results arrive, everyone reads them through their own interest, and the safest move is another quarter of piloting.
Write four things into the charter before the pilot runs:
- The baseline. How the workflow performs today, measured the same way the pilot will be measured.
- The threshold to scale. The result, against that baseline, that justifies production.
- The threshold to stop. The result below which the pilot ends, whatever else it shows.
- The decision date. A calendar date, not "when we have enough data".
An illustrative example, with made-up numbers: an insurer pilots AI-assisted triage on incoming claims. Today, a claim waits an average of four days before an adjuster first touches it. The charter says: scale if the pilot gets that under two days with no rise in reopened claims; stop if it stays above three days or reopened claims rise; decide on 30 June. On 30 June the owner reads the result against a rule written in January, and the meeting is short.
Business metrics belong in the rule. Model metrics do not. "The model is 94 percent accurate" says nothing about whether the claim reached an adjuster sooner. Accuracy is an input the technology lead should report. The threshold should be in the units the owner's P&L uses.
Price production, not the pilot
A pilot is cheap because it is protected. Look at how yours is set up: often a curated extract of data, with a small group of motivated users, outside the systems that matter, and with an engineer on hand to fix things. Production removes every one of those protections.
Before the decision date, ask the technology lead to price the production version, line by line:
- Data on real inputs. Pipelines from the live systems, with their missing fields and inconsistent formats, not the cleaned extract.
- Integration. Getting the output into the system where the work happens, such as the claims platform, the CRM, or the ERP, rather than a separate screen.
- Monitoring. Who watches output quality each week, and what triggers a rollback.
- Human review. The staff time to check outputs at production volume, which does not shrink just because the pilot looked good.
- Usage and licensing. Per-call or per-seat costs at full volume, not pilot volume.
- Change. Training, new procedures, and the time it takes a team to trust a new way of working.
- Controls. Logging, documentation, and audit trails that a regulator or auditor could ask for.
Gartner's 2024 list of reasons for abandonment (data quality, risk controls, cost, value) maps almost exactly onto that list. Each of them can be checked before the decision date if someone prices production while the pilot is still running.
Compare the full production cost to the value the pilot showed against its baseline. Report the comparison as a range, with the assumptions that would move it most. If the low end of the range does not cover the cost, the honest answer may be to revise the scope or stop.
Make stopping a respectable result
If stopping a pilot reads as failure, owners will avoid stopping, and pilots will drift. Make stop a respectable outcome:
- Record what was learned. A one-page note: what was tested, what the baseline was, what happened, why it stopped, and what would have to change to try again.
- Credit the decision. An owner who stops a weak pilot on its decision date has saved the cost of production. Say so in the same forum where scaled pilots are celebrated.
- Keep the assets. The baseline measurement, the data work, and the cost model are reusable for the next candidate.
Revise is a valid result too, but only with a new decision rule and a new date. A revision without both is how a pilot becomes permanent.
Track decisions at the executive level
A count of running AI pilots tells an executive team little. Ask instead how many pilots reached a decision on their date, and what the decisions were.
Keep one list. For each pilot: the owner, the decision date, the thresholds, the production cost estimate, and the outcome when the date arrives. Review it monthly. A pilot past its date with no decision is the first item on the agenda.
That list also shows patterns no single pilot can. If most stops trace back to the same data problem, fix the data before starting the next three pilots that depend on it. If most scales come from one function, ask what that function does differently in how it sets up pilots.
What to do this month
List every AI pilot running in your organization. For each one, write down three things: the owner's name, the decision date, and the threshold to scale. Any pilot missing one of the three gets it assigned this month, or it stops on the last day of the month.
GradeCircle builds and runs six products of its own: AfroSynergy, CallerBridge, HealthSquire, Heyzl, Lexfora, and LukeAPI, two of them in beta. The assumptions in our models come from operating those systems, not from a framework. See what we run.
If you have a specific decision in front of you, scope it in five questions and see the engagement, price band, and timeline before sharing contact details.
