Key takeaways
- 62% of organisations experiment with AI agents, but only 31% have at least one in production. The gap between those two figures is the real adoption problem, not the technology.
- The dominant obstacle is not the model: 46% cite integration with existing systems as their main challenge. Second is the inability to prove the system works consistently.
- Median time-to-value is 5.1 months, with wide variation by case: sales development agents pay back in around 3.4 months, finance and operations agents in around 8.9.
- Our conclusion after reviewing dozens of projects: a pilot designed as a pilot never reaches production. You have to design production version 1 and deploy it at a small scope, which is not the same thing.
An AI pilot fails when it is designed as a demonstration rather than as the first version of a real system. The three factors separating projects that reach production are integration with existing systems, the ability to measure quality objectively, and the existence of a business owner with budget. The model is almost never the problem.
The gap, in numbers
The 2026 data paints a consistent picture: 62% of organisations experiment with AI agents, but only 31% have at least one in production. In other words, half of those who try stall on the way.
And the sector split is revealing:
| Sector | Companies with agents in production |
|---|---|
| Banking and insurance | 47% |
| Global average | 31% |
| Healthcare | 18% |
| Government | 14% |
What explains the difference is not budget or available talent. Banking and insurance have spent a decade building model governance, traceability and risk control out of regulatory obligation. When generative AI arrived, they already had the boring part in place: the framework for putting an automated system into production under control. Healthcare and government handle more sensitive data and slower decision structures.
The practical lesson: maturity in data governance predicts success far better than technical maturity in AI.
The five real reasons a pilot doesn't cross
Having reviewed plenty of stalled projects, the reasons repeat with a consistency that no longer surprises:
1. It was designed as a demo, not a system. The pilot used hand-exported data, a separate environment and admin permissions because it was faster. None of that is promotable to production, and migration turns into rewriting the whole system. This is cause number one.
2. Nobody can prove it works. Without an evaluation dataset or quality metrics, the steering committee conversation degenerates into opinions. "It gave me a wrong answer once" outweighs any positive impression, because there is no number to set against it. It is exactly the problem covered in agent observability and evaluation.
3. Integration was 80% of the work and was left until last. 46% of organisations cite integration with existing systems as their main challenge. A pilot querying an exported CSV has solved none of the hard problem; it has only postponed it.
4. There is no business owner with budget. Pilots driven only by IT or innovation die when the innovation budget ends. The ones that survive have an operations, support or finance lead who wants the outcome because it solves their own problem.
5. The most impressive case was chosen over the most boring one. The case that shines in a demo tends to be ambiguous, hard to evaluate and low volume. The case that reaches production tends to be repetitive, verifiable and clearly owned.
Key market data
- Only 31% of companies have at least one AI agent in production, against 62% that at least experiment with them. By sector, banking and insurance lead at 47%, while healthcare sits at 18% and government at 14%.
- Median time-to-value is 5.1 months, with large differences by case type: sales development agents pay back in around 3.4 months and finance and operations agents in around 8.9 months (Digital Applied, 2026).
- 46% of organisations cite integration with existing systems as their primary challenge, ahead of model choice, cost or talent.
- 57% already deploy multi-step agent workflows, 16% have reached cross-functional agents spanning teams, and 81% plan to expand into more complex cases during 2026.
Our reading of that last figure: 81% plan to expand while only 31% have anything in production. There is an obvious mismatch between intent and execution capacity, and it is solved with method, not with more budget.
What the projects that do arrive do differently
They don't run a pilot. They build production version 1 at reduced scope. The distinction sounds semantic and isn't:
| Classic pilot | Version 1 at reduced scope |
|---|---|
| Hand-exported data | Real integration, even if with one system |
| Separate environment | Production environment from the start |
| Broad permissions "just to test" | Final permission model from day 1 |
| No traceability | Traces and evals from the first version |
| Success = impresses in the demo | Success = metric agreed beforehand |
| Users: the project team | Users: real people from the business |
| Promotion to production = rewrite | Promotion = widen the scope |
The cost of working this way is that the first delivery takes longer. The benefit is that it exists. A pilot that impresses in six weeks and cannot be promoted has cost six weeks and delivered nothing. A scoped version 1 that takes ten weeks and stays in production has cost ten and is still running two years later.
How to pick the first case (and which to avoid)
The first case conditions everything after it, because it determines whether there will be a second. These are the criteria, in order:
- High volume and repetitive. If it happens twenty times a day, the saving is visible within weeks. If it happens twice a month, nobody will notice even if it works perfectly.
- Verifiable outcome. There must be a checkable correct answer. Cases where "it depends on judgement" are impossible to evaluate and to defend.
- Data accessible via API. If the information only exists on a screen or in an unstructured PDF, the project starts with data work: better to know that before committing to dates.
- Identified business owner. Someone with a problem of their own that this system solves, not an institutional sponsor.
- Reversible. Errors must be undoable. Irreversible cases come later, once trust has accumulated.
Cases to avoid as your first: demand forecasting, anything depending on the quality of a long history, decisions about people, and anything requiring five systems integrated at once. They are not bad cases: they are bad first cases.
Common use cases
Case 1: A pilot that could not be promoted.
- Problem: an assistant over internal documentation worked beautifully in the demo, with documents manually loaded into a folder.
- What failed: taking it to production required per-user permissions, automatic corpus updates and traceability. None of that existed, and it meant redoing the architecture.
- Lesson: the pilot validated that the technology worked, which was already known. It validated nothing about the real problem, which was document access control.
Case 2: A scoped version 1 that did arrive.
- Problem: repetitive status queries in the management system.
- Approach: one real integration, user-inherited permissions from day 1, full traces and a 40-case dataset as the acceptance criterion agreed before starting.
- Result: slower delivery than a conventional pilot, but it went to production without a rewrite and expanded to two more cases in the following months.
Case 3: A rescued project.
- Problem: an agent stalled after six months of testing with no deployment decision.
- Diagnosis: there was no agreed success metric, so every meeting reopened the debate about whether it worked.
- Intervention: build the evaluation dataset from historical cases, measure, and present a number instead of a demo.
- Result: the deployment decision was taken in two weeks. The system had not changed; what changed was what could be asserted about it.
How to cross the gap step by step
- Agree the success metric in writing before writing code. "That it works well" is not a metric. "Resolve 80% of type X queries without human intervention, with under 2% incorrect answers" is. That conversation is uncomfortable and it is what saves the project.
- Build the evaluation dataset from real historical cases. 30-50 well-chosen cases. It is what turns opinions into a number.
- Integrate for real from week one, even if with a single system and in read-only mode. Integration is the hard work: postponing it postpones the only relevant uncertainty.
- Define the permission model before the first line of code. User-inherited permissions, never a "temporary" admin account. Temporary accounts never are.
- Deploy to real users as early as possible, at reduced scope. Ten people from the business using it give more information in a week than two months of internal testing.
- Instrument from the start. Traces and evals from version 1. Adding them later costs three times as much and means touching a running system.
- Set a decision date. The project is deployed or cancelled on an agreed date. Pilots with no decision date do not fail: they linger indefinitely, which is worse because they consume attention and produce nothing.
Common mistakes (and how to avoid them)
Mistake: starting with the most impressive case. → Reality: the demo-friendly case is usually ambiguous and low volume. Start with the repetitive and verifiable one: it is the one you can defend with data and the one that frees visible hours.
Mistake: leaving integration to phase 2. → Reality: integration is 46% of the problem according to the practitioners themselves. A pilot that avoids it has reduced no uncertainty; it has proved the model works, which we already knew.
Mistake: using admin permissions "just for the pilot". → Reality: that shortcut makes the system unpromotable and, meanwhile, opens a security hole. The permission model is architecture, not configuration.
Mistake: not agreeing the success metric before starting. → Reality: with no agreed number, the deployment decision depends on the impression of whoever tested the system last. It is the most common reason projects linger.
Mistake: piloting without real business users. → Reality: the project team uses the system as designed. Real users use it as they need to, and that is where the unforeseen cases appear.
Mistake: expecting ROI in month one. → Reality: median time-to-value is 5.1 months and varies widely by case. Promising immediate return guarantees an uncomfortable conversation in month three, exactly when the project needs support.
Realistic timelines and effort
- Case definition, success metric and evaluation dataset: 2-3 weeks. The phase most often skipped and the best predictor of whether the project reaches production.
- Version 1 at reduced scope in production: 6-12 weeks for a read-only case with one integration. Longer if data needs cleaning first.
- Median time to demonstrable value: 5.1 months as a market average, with sales agents around 3.4 months and finance and operations agents around 8.9.
- Expanding to further cases: much faster once the integration, permissions and observability foundation exists. The second case usually costs half the first, and the third even less.
- Where the hidden effort sits: in integration and in the state of your data. Not in the model, which gets the most attention and causes the fewest problems.
Metrics to track from day 1: the agreed success metric, real adoption by business users, human escalation rate with reasons, hours freed versus the baseline, and elapsed time from kickoff to deployment decision. That last one is the best diagnostic of an AI programme's health: if your projects have gone six months without a decision, the problem is not technical, it is governance.
Frequently asked questions
How many AI projects actually reach production?
Only 31% of companies have at least one AI agent in production, against 62% that at least experiment with them. Roughly half of those who try do not cross the gap between pilot and operational system.
Why do AI pilots fail?
Five dominant causes: they were designed as demonstrations rather than real systems, there is no objective way to prove they work, integration was left until last, there is no business owner with budget, and the most impressive case was chosen over the most repetitive and verifiable one.
What is the main technical obstacle?
Integration with existing systems, cited by 46% of organisations as their primary challenge, ahead of model choice, cost or talent. A pilot working on hand-exported data has not addressed that obstacle, only postponed it.
How long does an AI project take to deliver value?
Median time-to-value is 5.1 months, with significant differences by case type: sales development agents pay back in around 3.4 months and finance and operations agents in around 8.9 months.
Is it better to run a small pilot or go straight to production?
Neither. What works is designing production version 1 and deploying it at reduced scope: real integration, final permissions and observability from day 1, but with few users and a single case. Then expanding is a matter of scope, not rewriting.
Which case should be chosen first?
One with high volume, repetitive, with a verifiable outcome, data accessible via API, an identified business owner and reversible actions. Avoid demand forecasting, decisions about people and anything requiring several systems integrated at once as your first case.
Why are banking and insurance so far ahead?
Because they have spent a decade building model governance, traceability and risk control out of regulatory obligation. When generative AI arrived, they had already solved the hard part: the framework for putting an automated system into production under control.
How do you rescue a stalled AI project?
Almost always the same way: build the evaluation dataset from historical cases, measure and present a number instead of a demo. Most blocked projects do not have a technical problem, they have an unagreed decision criterion.
Do you have an AI pilot that has gone months without a decision?
At Naxia we don't run pilots: we design production version 1 at reduced scope. Real integration from week one, final permission model, traces and evals from day 1, and a success metric agreed in writing before starting. We also rescue stalled projects by building the evaluation that makes the decision possible.
If you have a project in limbo or want to start one that actually reaches production, talk to us. No commitment, no 40-slide decks.
Or explore our implementation process first.