AI Pilot to Production: A Funded Decision Made on Numbers
Why do AI pilots stall before production?
AI pilots stall before production because they prove the technology works and leave the business case unanswered. Nobody owns the problem, nobody measured the starting point, the pilot never touched real systems, governance was never asked, and there is no budget line for running costs.
A proof of value fixes that. It tests one production-relevant problem, with an executive sponsor, against a measured baseline. It runs on your real systems inside your own cloud account and ends in a go or no-go decision made on numbers, in weeks.
| Question the executive asks | Open-ended pilot | Proof of value |
|---|---|---|
| Who owns the result? | The IT or innovation team | A named business sponsor who owns the problem |
| What does "worked" mean? | Decided after the demo | Success criteria signed before the build |
| What is it compared against? | Nothing measured | A baseline of today's cost, time and errors |
| Does it touch real systems? | Sample files and a sandbox | Live data, read access to your ERP or document store |
| Has security signed it off? | Usually not yet | Reviewed before any data moves |
| What does it cost to run? | Unknown | Estimated per transaction and per month |
| How does it end? | It drifts | A dated go, pause or stop decision |
If you are a CIO, COO or operations head who has already watched one pilot fade, the rest of this guide answers the questions in the order you are likely to ask them.
Working out whether this fits your business? Book a free 30-minute review
How common is the AI pilot to production gap?
- MIT NANDA, "The GenAI Divide: State of AI in Business 2025" (July 2025): 60 percent of organisations evaluated enterprise-grade AI tools, 20 percent reached pilot stage and just 5 percent reached production. The report says most "fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations."
- Gartner (July 2024) predicted at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025. It cited poor data quality, inadequate risk controls, escalating costs and unclear business value.
- RAND, in "The Root Causes of Failure for Artificial Intelligence Projects" (August 2024), notes that by some estimates more than 80 percent of AI projects fail, twice the rate of IT projects without AI. Its interviews found misunderstanding of a project's intent and purpose was the most common cause.
None of these sources blame the models. MIT found the barriers people reported most were change management, lack of executive sponsorship, poor user experience and output quality concerns. Those are design decisions, and they are made before anyone writes a line of code.
Already read our technical guide? The AI proof of concept 4-week framework covers the build. This post covers the business side: who owns it, what it is measured against, and how the money gets approved.
Where exactly does a pilot lose its funding?
A pilot usually loses its reason to exist at one of five points.
No one owns the problem
The pilot belongs to IT or an innovation team. The person whose team does the work every day was consulted once. When the pilot ends, no budget holder argues for it, because none of them asked for it.
No baseline was measured
The demo shows the AI coding an invoice or answering a question in seconds. Nobody recorded how long it takes today, how often it goes wrong, or what that costs. With no starting number, there is no improvement to report.
It never touched real systems
The pilot ran on a folder of sample PDFs and a sandbox account. Production means reading from the ERP, writing back to the document system and respecting existing permissions. That integration is usually most of the work, and it was never priced.
Governance was asked last
Security, privacy and risk see the pilot for the first time when someone asks to go live. They raise reasonable questions about where data goes and who checks the outputs. The answers take months, and momentum dies.
Nobody budgeted for running it
A working AI system has monthly costs: model usage, hosting, monitoring, and someone who owns it. If that line is not in next year's budget, the pilot has nowhere to land. Our guide to operating AI agents after go-live covers that tail in detail.
For a broader look at failure patterns, see why AI projects fail in Australia.
How does a proof of value get to a production decision?
A proof of value has a fixed shape. Each step produces something the go or no-go meeting will use.
How a proof of value reaches a funded production decision
The order matters. The criteria are signed before anything is built, so the result cannot be argued after the fact.
Who should own an AI proof of value?
Two named people own a proof of value, and their jobs differ.
The executive sponsor owns the outcome and the budget. That is usually the COO, CFO or general manager whose cost line carries the problem. They chair the go or no-go meeting and they are the person who funds production.
The business owner runs the team that does the work today: the AP manager, the service centre lead, the maintenance planner. They supply the baseline, nominate the reviewers, and decide whether the output is good enough to use.
IT is a partner in both roles. It owns architecture, access and security. It should not be the owner of a business problem it does not feel each month.
The Australian Government's Guidance for AI Adoption, published by the National AI Centre on 21 October 2025, puts this first. Its opening practice is "Decide who is accountable." The implementation guidance asks organisations to "assign, document and clearly communicate who is accountable" for each AI system, including ongoing human control and oversight.
Which problem should go first?
Pick a problem that is expensive, repetitive and measurable. If you cannot count it today, you cannot prove an improvement tomorrow.
Problems that suit a first proof of value, across industries:
- Technical document search: Engineers, estimators or service staff hunting through drawings, manuals and specifications.
- Maintenance knowledge: Planners and technicians looking up fault history and procedures, whether for a mine site, a fleet depot or a building portfolio.
- Operational reporting: Weekly packs assembled by hand from three systems that disagree.
- Accounts payable: Invoices keyed, coded and matched by hand. See our guides to Peppol e-invoicing without rekeying and month-end close automation.
- Customer service correspondence: Emails and portal requests triaged, answered or routed by hand.
- Quoting: Requests read and priced from a price book. Our self-hosted AI quoting agent guide shows one way to keep pricing data onshore.
MIT's research found budgets lean towards sales and marketing, while back-office automation often yields better return. It put that down to easier metric attribution in the front office. A dull back-office queue with a clean count is often the better first candidate.
Is this problem ready for a proof of value?
What baseline makes the business case hold up?
The baseline is the number the sponsor will defend at the budget meeting. Measure it before the AI runs, using the people who do the work.
Record at least:
- volume per week or month
- average handling time per item, from a sample timed by the team
- error or rework rate, and what an error costs downstream
- queue length and wait time, if the work backs up
- the loaded hourly cost of the people doing it
Here is how the arithmetic works with illustrative numbers. Replace each one with your own measured figures.
Baseline worksheet (illustrative numbers only)
The last line is the point. A proof of value reports handling time, error rate and run cost per item side by side. The sponsor sees the net figure, with run cost already deducted. Our AI business case template shows how to present it to a board.
How do you agree success criteria before anything is built?
Write them down, get them signed by the sponsor, IT and risk, and do not change them mid-test.
Good criteria cover four things:
- Accuracy threshold: The share of outputs a reviewer accepts without change, set by the business owner. Shadow mode graduates to co-pilot mode only above it.
- Time or cost: The improvement in handling time per item the sponsor needs to fund production.
- Adoption: Whether the reviewers would choose to keep using it.
- Guardrails: Failure types that stop the test outright, such as personal information appearing where it should not.
This lines up with the Government guidance. Under its "Test and monitor" practice, the implementation guidance asks organisations to "define and communicate clear acceptance criteria and test methodologies that reflect the intended use, context and potential risks." It also calls for a deployment process that "maps business targets to system performance metrics." A proof of value with signed criteria is that practice applied to one problem.
Will it work with our systems and stay in our cloud account?
It has to, or it proves nothing about production.
A proof of value connects to the systems the work already lives in: the ERP, the document store, the ticketing or maintenance system. It uses read access first and writes back only after the threshold is met. It runs in your own Azure, AWS or Google Cloud account in an Australian region, under your enterprise agreements, with credentials your team holds.
That choice answers the security lead's first questions before they are asked. Data stays in your tenant. Under the major cloud providers' enterprise terms, the model provider does not train on it, and your contract confirms it. Your team can switch the whole thing off.
If your people are already pasting company data into public chat tools, start with a shadow AI inventory and policy. If Microsoft 365 Copilot is on the roadmap, a Copilot readiness permissions audit finds overshared files before an AI tool surfaces them.
Will security, risk and governance sign it off?
They will if they are in the room from week one and the design gives them controls they recognise.
The Guidance for AI Adoption evolves the 2024 Voluntary AI Safety Standard into six essential practices:
- Decide who is accountable
- Understand impacts and plan accordingly
- Measure and manage risks
- Share essential information
- Test and monitor
- Maintain human control
It comes in two versions. Foundations is for organisations early in AI use. The implementation guidance is for complex or higher-risk use; its current PDF is dated 5 May 2026. A proof of value can produce evidence against each practice: a named owner, an impact note, a risk register entry, an AI register record, test results and a human approval step.
If your organisation is a Commonwealth entity, or supplies one, the Digital Transformation Agency's Policy for the responsible use of AI in government also applies. Version 2.0 took effect on 15 December 2025, with minor updates published as version 2.1 on 21 October 2026. Its mandatory requirements include AI use case accountability, internal use case registers and AI use case impact assessment.
Human oversight is the control that settles most debates. In shadow mode the AI's output goes to a comparison screen, never to a customer or a ledger. In co-pilot mode a person approves every output before it is used. Our guide to AI agent governance, data access and human override sets out the access model in more detail.
How is a proof of value evaluated without risking customers?
In shadow mode, against the same work your team is already doing.
The AI processes live items alongside the team. Each week the business owner compares its output with what the team actually did. The comparison counts accepted outputs, corrected outputs, misses and time per item.
That gives three things a sandbox demo cannot. The accuracy figure comes from your real work mix, including the awkward cases. The reviewers see the tool improve as their corrections are fed back. And the run cost is measured on real volume.
If the accuracy threshold is reached, the system moves to co-pilot mode. The AI drafts and a person approves every output before it is used. Nothing reaches a customer until the threshold is met.
What does the go or no-go gate look like?
A one-hour meeting with a one-page pack, chaired by the sponsor.
Proof of value to production decision
The pack answers six questions:
- Did the system meet the signed accuracy threshold on live work?
- What is the measured change in handling time and rework against the baseline?
- What will it cost to run each month at full volume?
- Who owns it in production, and who supports it?
- What did security and risk conclude, and what controls remain?
- What is the next problem it could extend to?
Each answer leads to one of three decisions. Go funds co-pilot mode and handover, with the run cost added to next year's budget. Pause names the one blocker, such as data access, and a date to revisit. Stop keeps the baseline, the integration work and the lessons, and moves to the next candidate.
A stop is a good result. It costs a few weeks, and the next proof of value starts from a measured baseline.
What changes when a pilot is run as a proof of value?
Stalled pilot versus proof of value
| Metric | Open-ended pilot | Proof of value | Improvement |
|---|---|---|---|
| Owner | Innovation or IT team | Named executive sponsor and business owner | Someone argues for funding |
| Starting point | Not measured | Baseline of volume, time, errors and cost | Improvement can be shown |
| Success definition | Agreed after the demo | Signed before the build | No moving goalposts |
| Data and systems | Samples in a sandbox | Live data in your own cloud account | Proves production fit |
| Governance | Asked at go-live | Reviewed from week one | No late veto |
| Run cost | Unknown | Measured per item and per month | Budget line ready |
| Ending | Drifts | Dated go, pause or stop | A decision on numbers |
MIT's report describes the organisations crossing the divide in similar terms. They benchmarked tools "on operational outcomes, not model benchmarks" and sourced AI initiatives from frontline managers, paired with executive accountability.
How do you start a proof of value this month?
- Ask each business unit head to nominate one expensive, repetitive problem and a sponsor willing to own it.
- Pick the candidate with the cleanest count and the easiest data access.
- Start timing the work now, so the baseline exists before any build.
- Book security and risk into the first workshop.
Solve8 runs proof of value engagements inside your own systems, in shadow mode first, with a dated go or no-go gate and a named exit point at the end of each phase. Our AI strategy service covers choosing the problem, and process automation and system integration cover the build. If you would rather keep everything on infrastructure you control, see private AI infrastructure.
Book a scoping call and leave with a straight answer on which problem to test first, what to measure and whether it is worth a proof of value.
Common Questions
What is the difference between an AI proof of concept and a proof of value?
A proof of concept tests whether the technology can do a task, often on sample data. A proof of value tests whether doing it on your real work, in your systems, saves enough to justify running it, measured against a baseline and signed success criteria.
Why do most AI pilots fail to reach production?
MIT NANDA's 2025 research found 60 percent of organisations evaluated enterprise-grade AI tools but just 5 percent reached production. The common causes are organisational: no owner of the problem, no baseline, no integration with real systems, late governance review and no budget for running costs.
How long does an AI proof of value take?
A typical shape is about three weeks for discovery, baseline and signed criteria, then six weeks or so of build and shadow mode, ending in a go or no-go meeting. Data access approvals are usually the longest wait, so start them first.
Who should sponsor an AI proof of value?
The executive whose cost line carries the problem, usually a COO, CFO or general manager. They own the budget and chair the go or no-go meeting. The manager of the team doing the work owns the baseline and decides whether outputs are good enough.
Does the Australian Government have guidance for moving AI into production?
Yes. The National AI Centre's Guidance for AI Adoption, published 21 October 2025, sets out six essential practices, including deciding who is accountable, testing and monitoring, and maintaining human control. Commonwealth entities must also meet the DTA's Policy for the responsible use of AI in government.
What happens if the proof of value says no?
You keep the baseline, the integration work and the lessons, and move to the next candidate problem. A clear stop after a few weeks costs far less than a pilot that drifts for a year with no decision.
Related Reading:
- AI Proof of Concept: A 4-Week Framework - The technical week-by-week build that sits inside a proof of value.
- Running an AI Pilot That Survives Go/No-Go - The 90-day playbook and kill criteria for the pilot itself.
- Operating AI Agents: The Real Cost After You Build - What the run-cost line in your go decision needs to cover.
- What an AI Strategy Consulting Engagement Gives You - How to choose which problem to test when there is no obvious first candidate.
Sources: MIT NANDA, "The GenAI Divide: State of AI in Business 2025" (July 2025); Gartner press release, "Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025" (29 July 2024); RAND Corporation, Ryseff, De Bruhl and Newberry, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed" (RR-A2680-1, 13 August 2024); National AI Centre, Guidance for AI Adoption (21 October 2025) and implementation guidance (updated 5 May 2026); Digital Transformation Agency, Policy for the responsible use of AI in government, version 2.1 (21 October 2026).