Why promising AI pilots never become real products
A pilot proves something is possible. A product has to keep working. The gap between the two is predictable, and it can be closed before the money is spent.
Loodos Editorial Desk · Editorial
In this story (6 sections)
General edition. , or use the switcher above.
Most AI pilots do what they were built to do: they impress a room. Far fewer survive contact with the systems, rules and people that surround real work.
This analysis separates two questions a pilot quietly bundles together, can this work? and can this keep working?, and looks at the five places where the second one usually goes unanswered.
The short version
- A pilot answers “can this work?” A product has to answer “can this keep working, for everyone, under supervision, as things change?” Most stalled pilots only ever answered the first.
- The gaps are predictable: hand-picked data and workflows, no agreed definition of success, unclear ownership, and no plan for when the system is wrong.
- Research on production ML systems has argued for a decade that the model is a small part of the system; most of the effort lives in the data, serving and monitoring around it.
- Before approving the next pilot, write down the success measure, the owner after launch and the fallback for wrong output. If those can’t be written, call it a demo.
The demo is not the product
A pilot is an argument. It is built to persuade a sponsor that something is possible, and it is usually very good at that: the data has been tidied, the users are enthusiastic volunteers, and someone on the project team quietly handles the cases the system can’t.
A product makes a different promise. It says the thing will keep working for people who didn’t volunteer, on inputs nobody curated, while the systems, policies and staff around it change. The distance between those two promises is where most pilots stop.
This isn’t a new observation. In 2015 a group of Google researchers argued that in a real machine-learning system the learning code is a small box surrounded by much larger ones: data collection, configuration, serving infrastructure, monitoring. They described how technical debt accumulates in those surrounding boxes (Sculley et al., 2015). A pilot rarely has to build them.
“A pilot is an argument. A product is a promise.”
The data and the workflow were hand-picked
Pilot data is typically a clean extract: one region, one product line, one quarter, reviewed by someone who knows the context. Production data arrives incomplete, duplicated, late and in formats that predate the project.
The workflow gets the same treatment. In a pilot, a person copies the output into the system of record. In production, that step becomes an integration with its own authentication, error handling, audit trail and owner. In many organisations that integration is a bigger project than the model.
- Where will production data come from, and who is accountable for its quality?
- Which system receives the output, and who approved that integration?
- What happens to inputs that don’t resemble the pilot sample?
What “data drift” means
Data drift is what happens when the inputs a system sees in production slowly stop resembling the data it was built and tested on: a new customer segment, a changed form, a new product. The system doesn’t announce it. The answers just get worse. Watching the shape of the inputs and a sample of the outputs is how teams notice.
Nobody agreed what “works” means
Many pilots end in a meeting where half the room remembers a success and the other half remembers a disappointment. The usual cause is that the success criteria were never written down, so the evidence gets interpreted after the fact.
A usable criterion is boring and specific: a measurable outcome, a baseline to compare it with, and a threshold that triggers a decision. Google’s Rules of Machine Learning makes a related point from the engineering side: get the measurement and the pipeline right before investing in model sophistication.
| Element | Weak version | Decidable version |
|---|---|---|
| Outcome | “Improve support quality” | “Reduce the share of tickets reopened within seven days” |
| Baseline | “Better than today” | “Compared with the current process over the same period” |
| Threshold | “Promising results” | “Proceed if the measure improves by the agreed margin; stop if it does not” |
| Review | “The sponsor reviews it” | “Named reviewers sample outputs every week” |
No one owns it at 2 a.m.
A pilot has a sponsor. A product needs an owner: someone accountable for its behaviour, its running costs and its incidents once the project team has moved on.
Ownership is also where governance stops being abstract. The NIST AI Risk Management Framework describes managing AI risk across a system’s life. For a team that translates into mundane questions: who may change the prompt or the model, who reviews what it produced, and who can switch it off.
Then there is failure. Language-model systems can produce fluent, wrong answers and can be manipulated through their inputs; the OWASP Top 10 for LLM Applications catalogues the recurring risks. A production design assumes the output will sometimes be wrong and decides in advance what the user sees when it is.
Where this argument is weaker
Not every failed pilot is a process failure. Some are correct conclusions: the technique wasn’t good enough, the problem wasn’t valuable, or the cost to run it exceeded what it saved. A pilot that ends in a clear no has done its job.
What to ask before the next pilot
- Write the success measure, the baseline and the stop condition on one page before anything is built.
- Name the post-launch owner and what they will be able to change.
- Draw the failure path: what happens when the output is wrong, slow or missing.
- List the real data sources and the system that receives the output, with a named person for each.
- Decide the size of the next step if the pilot works, and what happens if it doesn’t.
If those five things can’t be written down, the pilot is a demonstration. That’s a perfectly good thing to fund, as long as it is called one.
Key takeaways
- 01Decide what “working” means before the pilot starts, in a form that can be measured.
- 02Name an owner for the system after launch, not only a sponsor for the pilot.
- 03Design the failure path first: what happens when the output is wrong, late or missing.
Sources
- Hidden Technical Debt in Machine Learning Systems · NeurIPS 2015 (Sculley et al.) · accessed 1 Oct 2026
- Rules of Machine Learning: Best Practices for ML Engineering · Google for Developers · accessed 1 Oct 2026
- AI Risk Management Framework · NIST · accessed 1 Oct 2026
- OWASP Top 10 for Large Language Model Applications · OWASP · accessed 1 Oct 2026
Terms used (2)
- technical debt
- The accumulated cost of shortcuts in a system: quick decisions that make the next change slower, riskier or more expensive.
- data drift
- A gradual change in the inputs a system sees in production, so they no longer resemble the data it was built and tested on.
Your perspective
A better read starts with knowing what matters to you.
Three quick questions. A publication that adapts to your perspective.
Keep reading
All stories →What does it really take to bring AI into production?
Make four decisions about a hypothetical AI project (scope, data, oversight, rollout) and see what you’d be trading away. A simulation, clearly labelled.
A confidence score is not a probability
Many models emit a number between 0 and 1 that looks like a probability. Unless it has been calibrated, it isn’t one.
The cost of not building
Budgets record what projects cost. They rarely record what it costs to leave an idea untested. A practical way to make “not now” a real decision.