A pilot is optimised for the part of the business it was given
The pilot succeeds. The metrics improve in the narrow area that was examined, and the presentation to the executive committee is convincing. Then somebody asks the question that was avoided for six months: what now. The answer turns out to be more expensive and more contested than the pilot was.
This is not a failure of execution. It is a structural property of how pilots are commissioned. A pilot gets a narrow scope because a narrow scope is what finishes inside a funding cycle, and the narrowness is invisible in the results because they are measured inside the boundary. Every element the pilot was allowed to ignore is the element scaling requires.
The pilot produced an answer rather than a capability
The first scaling failure is that the pilot was built for one process and cannot be pointed at the next one. The extraction logic, the validation rules, the exception handling, the prompt structure, the connection to the source system: all of it was written for a single instance, and all of it must now be rewritten for each new one.
When that happens, the organisation does not scale a success. It starts unrelated projects that each consume a discovery phase, repeat the same integration work, and arrive at their own inconsistent answer to the same question. The second project costs more than the first, and the tenth more than the ninth, because nothing learned in the first is available to the others. The remedy is a shared layer of business model, connectors, workflow patterns and test methods, which is the subject of building reusable enterprise AI capabilities.
Nobody owned the outcome once the pilot team moved on
Most pilots are owned by a temporary team — a small group inside operations, or a central innovation unit — and that team is the reason the work was fast. The arrangement works until the pilot ends, at which point the outcome has to be carried by somebody permanent. Often nobody has been named.
The consequence is that the system enters production with the accountability of its pilot sponsor rather than of the function whose work it changes. Questions go unanswered. The people who should be able to change the rules cannot, because the rules are in code written by people who have left. The organisational dimension is covered in why enterprise AI projects fail between departments.
The integration cost was never in the plan
A pilot typically talks to one system, in one way, for a small volume. Enterprise use means writing to a system of record, reading from several others, respecting the permissions of the person on whose behalf the system acts, and surviving a change in any of them without a conversation. Each is a separate piece of engineering, and each is invisible in a pilot because the pilot avoids it.
The consequence is that the cost curve is not linear and not visible at the point of approval. By the time the roll-out begins, the pilot has proved the concept and the harder half of the work has not started. Organisations that planned for this treat the pilot as a discount on a production build rather than the beginning of one, and the discipline that follows is set out in enterprise AI deployment.
Controls arrived after the fact
A pilot frequently runs with lighter controls than the eventual production use requires, and this is often rational: the volume is small, the audience is internal, and the harm from a mistake is limited. The problem is that the controls become a formality at the point of expansion rather than a design input.
In practice this means traceability is missing when it is needed, human approval is inserted late as a patch on an automated path, and the audit question — what did the system do, on what basis, and who authorised it — has no answer assembled for it. Adding review after the fact costs more than designing the path with review inside it. The mechanisms are in building auditability into AI-enabled business processes.
The people who would use it were not in the room
The last and most common failure is social. The people whose daily work would change were usually consulted once, early, to confirm the problem was real, and then not consulted again. They learned about the system when it appeared.
In most cases the system is technically acceptable and the organisation quietly declines to use it. The old way continues, because removing it is nobody's explicit responsibility, and the reported results come from the small population that did adopt the new way. This is the pattern in how to make enterprise AI maintainable after the pilot ends.
What scaling actually requires
The practical implication is that a pilot should be judged on one question: does it make the next instance cheaper, or does it only make this instance better? A pilot that answers the second alone has produced evidence, not capability.
- Before the pilot starts, name the function that will own the outcome after it ends, and put that agreement in writing.
- Define the reusable part explicitly: the business model, the connections, the workflow pattern, the test set, the control design.
- Budget the production build rather than the pilot, and treat the pilot as a discount on the first part of it.
- Agree the review date and the measures, including adoption, before anything is built.
- Involve the people who will do the work in designing the work, not only in confirming the problem.
None of this is an argument against pilots. A pilot remains the most efficient way to find out whether something is possible. It argues for deciding at the start what a pilot is for: either it is evidence for a decision, in which case it should be cheap and narrow, or it is the first increment of production, in which case it should be built to be maintained.