An AI pilot should not receive further funding simply because the technology works. Before committing more capital, a business needs evidence that the project can improve a defined operating outcome at an acceptable total cost, with manageable risks and enough adoption to produce value.
That distinction becomes important when a pilot moves into production. A controlled test may use clean data, a small user group and substantial support from specialists. Scaling can introduce integration work, training, monitoring, exceptions and recurring oversight. The relevant decision is therefore not “Did the pilot succeed?” but “Does the evidence justify the next tranche of investment?”
CFO Dive reports that Gartner is urging CFOs to take a more disciplined approach as AI adoption moves beyond pilots, including setting realistic time-to-value expectations and knowing when to cut losses. Gartner’s public guidance similarly emphasizes disciplined investment and realized value, while its guidance on structured finance AI roadmaps calls for connecting AI activity to measurable business impact.
Those public statements do not provide a universal timetable or stop-loss formula. The framework below is Make Business editorial synthesis: a practical way for owners and finance leaders to convert that general principle into project-level capital allocation decisions.
Start with a baseline, not an AI capability
Before evaluating the pilot, document the process as it operates without the proposed system. A useful baseline describes the outcome, workload, cost and quality of the current process over a representative period.
Depending on the use case, the baseline might include:
- staff time spent processing each case or completing the relevant workflow;
- cycle time from request to completion;
- error, rework or exception volumes;
- external service or software costs;
- backlog levels and missed service commitments;
- revenue lost through slow response or limited capacity;
- control failures, complaints or escalation rates.
The measure must reflect an operating result, not the amount of AI activity. Prompts submitted, documents generated and users given access can indicate usage, but they do not establish value. A project intended to accelerate customer proposals, for example, should ultimately be assessed against proposal turnaround, staff effort, correction rates and commercial outcomes rather than the number of drafts produced.
Record how the baseline was calculated and what else could change it. Seasonality, staffing changes, demand fluctuations or another software rollout can otherwise distort the comparison.
Count the cost of the operating system around the model
Do not assume that a pilot budget represents production economics. The investment case should include the people, process and control work required to operate the system safely and consistently.
Create a total-cost register with at least four groups:
- Build and transition: workflow design, data preparation, integration, testing, security review, migration and change management.
- Recurring technology: licences, usage charges, infrastructure, data services, support and vendor management.
- Human operation: training, review, exception handling, output correction, user support and process ownership.
- Control and resilience: monitoring, access administration, audit evidence, incident response, compliance review and contingency arrangements.
Include internal labour even when it does not produce a new invoice. If managers and specialists must repeatedly check outputs, investigate failures or help employees use the tool, that time is part of the economic cost. It may still be justified, but excluding it makes the comparison unreliable.
Separate one-off and recurring costs. A large transition cost may be reasonable if benefits persist, while recurring charges can weaken the case as usage expands. The finance model should show what happens when volume, vendor pricing, review effort or exception rates differ from the original assumption.
Fund milestones rather than the whole ambition
A stop-or-scale plan divides post-pilot funding into stages. Each stage has a decision date, evidence requirement, spending ceiling and named decision owner. The dates should reflect the particular workflow, buying cycle and risk exposure; there is no responsible universal timetable.
Four gates can structure the discussion.
Gate 1: Technical and control readiness
The first question is whether the system can operate in the intended environment. Evidence may cover integration, data availability, output reliability, access controls, exception routing and fallback procedures. Passing this gate means the project is ready for limited operational use. It does not establish a return.
Gate 2: Workflow adoption
Next, determine whether the intended users can and do incorporate the system into real work. Look for completion of training, repeat use in the target workflow, appropriate escalation of uncertain outputs and evidence that employees are not maintaining an unofficial parallel process.
Low adoption needs diagnosis. It may indicate poor training, badly placed workflow steps, weak incentives or lack of trust. Those are potentially repairable adoption delays. By contrast, users may reject the system because its outputs are too unreliable, its review burden exceeds the saved effort or it does not fit the actual work. Those findings challenge the underlying design or economics.
Gate 3: Operating outcome
Compare the live result with the documented baseline. Has cycle time, cost, capacity, quality or another agreed measure changed? Is the difference sustained across a representative mix of work? Has improvement in one measure created deterioration elsewhere?
A faster process that generates more corrections downstream has not necessarily created value. Use paired measures where that risk exists: speed with error rate, automation with exception volume, or output volume with approval and conversion outcomes.
Gate 4: Scale economics
Before wider rollout, update the business case with observed rather than assumed data. Replace estimates for usage, oversight, support and exception handling with pilot or limited-production evidence. Then assess whether incremental value is likely to exceed the full cost and whether the project remains preferable to other uses of the same capital and management attention.
Separate a timing problem from a broken investment case
A missed milestone should trigger analysis, not an automatic extension or cancellation. Classify the cause before deciding.
- Adoption delay: The system performs adequately, but training, workflow integration or incentives are holding back use.
- Technical limitation: Reliability, latency, integration or data quality prevents acceptable operation.
- Economic failure: The outcome is technically possible, but review effort, recurring costs or limited benefit makes it unattractive.
- Control constraint: The project cannot yet meet the business’s security, legal, compliance or accountability requirements.
- Measurement failure: The team cannot isolate or credibly measure the promised operating outcome.
An adoption delay may justify a tightly scoped remediation period. A technical limitation may call for redesign or a narrower use case. Economic failure usually requires a more fundamental change, because additional adoption could increase costs without improving returns. A control constraint should prevent expansion until the responsible owner approves an adequate response.
Write the stopping rules before sunk costs intervene
Predetermined stopping rules reduce the risk of continuing to fund a project merely because the organisation has already invested in it. They should be specific to the use case and agreed before the next stage begins.
A business might stop or pause further investment when:
- a critical control requirement remains unresolved by the decision date;
- the project cannot produce reliable evidence against its baseline;
- operating costs exceed the approved range without a credible path to correction;
- human review or exception work removes the expected capacity benefit;
- adoption remains insufficient after the agreed remediation effort;
- the required data or integration cannot be secured within the spending ceiling;
- a competing project offers a stronger expected use of capital or scarce specialist time.
Stopping does not always mean discarding everything. The business may preserve useful integrations, process documentation or lessons, then close the current use case. It may also redesign the project around a narrower task where the evidence is stronger. What matters is that “redesign” receives its own budget, hypothesis and gates rather than becoming an indefinite extension.
Use a one-page decision record at every gate
At each review, the project owner and finance lead should present the same compact record: the original baseline, benefits observed, costs incurred, forecast cost to the next gate, adoption evidence, unresolved risks, opportunity cost and recommended decision.
The decision should be one of four explicit options:
- Scale: evidence supports broader deployment under an approved budget and control plan.
- Continue: maintain the current scope until enough representative evidence exists.
- Redesign: change the workflow, technology or use case, with a new hypothesis and funding limit.
- Stop: end further investment because the evidence, economics or risks do not justify another stage.
This approach turns AI investment time-to-value from a hopeful forecast into a managed sequence of decisions. It does not require every project to deliver an immediate return. It requires leaders to define what progress looks like, identify the cost of waiting and decide in advance how much uncertainty they are prepared to finance.
