Most enterprise AI pilots never become production systems. The figure in the headline is one of several survey numbers that circulate on this; methods and definitions vary, so treat any single percentage with caution. The pattern behind them is familiar to anyone who has run a pilot: the demo works, the rollout stalls. For established companies, the gap between an impressive pilot and an org-wide capability is governance and engineering discipline, not the choice of model.
Why pilots die
A pilot succeeds in a controlled demo and dies on contact with real data, real volume and real users. The causes are rarely exotic:
- The demo data was clean. Production inputs arrive scanned at an angle, half filled in, in the wrong language or missing the field the prompt depends on.
- No one owns it after the demo. The innovation team built it, the business unit was never staffed to run it, and IT was not consulted on access or hosting.
- There is no definition of "good". Without an evaluation set, every stakeholder judges quality by the last example they happened to see.
- Security and legal arrive late. A review in month five that asks where the data goes can reset the whole project.
- Unit cost was never measured. A workflow that costs more per case than the manual process it replaces will not survive a budget cycle.
The model was never the hard part. The missing pieces are evaluation, observability, guardrails and ownership.
Pick the first workflow deliberately
The first production workflow sets the pattern for everything after it, so choose one that is easy to measure. Useful criteria:
- High volume and repetitive, so small per-case gains add up.
- A clear cost line today (hours, handling time, backlog) that you can compare against.
- Tolerant of review: a person can check the output quickly before it takes effect.
- Contained data: one or two source systems, not ten.
- A business owner who wants it and will staff the review queue.
Support triage, reconciliation and document processing usually pass these tests. Customer-facing decisions on credit, employment or health usually do not, at least not as a first project.
The rollout sequence that works
- Build the evaluation set first. Collect a few hundred real, labelled cases, including the ugly ones, before tuning prompts. This becomes the yardstick for every later change.
- Human-in-the-loop by default. The AI proposes, a person approves. Autonomy is earned per category of case, once evaluation data shows the error rate is acceptable for that category.
- Instrument cost per successful task, not vanity metrics such as prompts sent or users onboarded. Include review time and rework in the cost.
- Ship to a small group, then widen. One team, then one region, then the rest, with a rollback path at each step.
- Templatise. Once one workflow is reliable, its platform, guardrails, evaluation suite and access model become the pattern for the next ten. For examples of the workflows larger companies are standardising on, see what US enterprises are deploying.
A worked example (hypothetical figures)
Say a finance operations team of 12 spends a large share of its week matching supplier invoices to purchase orders. A pilot shows the model can propose a match for most invoices. Before rollout, the team measures three things on a month of real invoices: how often the proposed match is correct, how long a reviewer takes to confirm a correct proposal versus fix a wrong one, and the model and infrastructure cost per invoice. If confirming takes 30 seconds, fixing takes four minutes and the error rate is high, the net saving can be close to zero. That result is still useful. It tells the team to improve extraction on the worst supplier formats before widening the rollout, rather than discovering the problem after 12 people depend on it.
Governance that makes it stick
Governance is what turns a pilot into a capability the board trusts. At minimum:
- Data governance and access control: the AI system sees only the data the person invoking it is entitled to see.
- Audit logging: inputs, outputs, model version, prompt version and the human decision, retained for as long as your record-keeping rules require.
- Human oversight: named owners, an escalation path, and a way to switch the automation off without an engineering deploy.
- Change control: prompt and model changes go through evaluation, exactly as code changes go through tests.
- Regulatory alignment: for regulated or EU-facing work, map each use case to the EU AI Act's risk tiers and to GDPR (our guide covers both).
Platform or one-off builds?
| Approach | Works when | Risk |
|---|---|---|
| One-off build per team | Two or three workflows with very different data | Duplicated guardrails, uneven quality, hard to audit |
| Shared internal platform first | Many similar workflows and strong central IT capacity | Platform built before demand is proven |
| Template from the first success | Most established companies | Needs discipline to extract the reusable parts |
The third route is usually the right one: build the first workflow properly, then extract its evaluation suite, logging and access layer into shared components the next team can adopt.
Common mistakes
- Choosing the use case by executive enthusiasm instead of measurability.
- Letting the pilot team hand over to operations with no runbook.
- Treating prompt edits as content tweaks rather than production changes.
- Rolling out a company-wide chat tool and calling that the AI strategy.
How Velura Labs scales enterprise AI
Velura Labs builds the foundation described above — agentic systems, LLM applications and MLOps with evaluation and observability — and then templatises it across workflows. If you are still choosing the first workflow, start with an AI Strategy & Roadmap.
Our clients for this span US tech hubs (San Francisco, Seattle, Austin, New York), European markets (Paris, Milan, Rome), the Middle East (Dubai, Riyadh, Abu Dhabi) and India. Start a conversation from anywhere.