Enterprise AI roadmap: from pilot to operations

An enterprise AI roadmap is usually written as a list of use cases with quarters attached. That format hides the decisions that determine whether any of them reach operation: which shared dependencies get built first, what the gate out of pilot tests, who runs the result, and how the run is funded once the project closes. This article covers the parts of the roadmap that decide that outcome.

Why an AI pilot is weak evidence for production

A pilot is typically run on an extracted dataset, cleaned once, covering a period chosen because the data was good. An engineer is close by. When something looks wrong, someone notices within the hour. The evaluation is a metric computed on a holdout sample.

Production has none of those properties. Data arrives continuously, with the gaps and late corrections the source systems produce on a normal week. Nobody is watching the output distribution. The evaluation that matters is whether the process the model feeds produces better decisions than it did before, which is not the same measurement and often not measured at all.

This is why a pilot that performs well is compatible with a programme that never operates anything. The pilot answered the question of whether the method can work. The unanswered questions are whether the required data can be obtained at decision time rather than in an extract, whether the surrounding process can absorb an output that is sometimes wrong, and whether a named team can keep the thing calibrated for years.

A roadmap that treats pilot success as the main gate is sequencing on the wrong signal. The useful reframing: the pilot is a test of feasibility, and the expensive uncertainty sits after it.

What an enterprise AI roadmap contains beyond a list of use cases

A list of use cases with dates is a wish register. A roadmap that survives contact with delivery contains four more things.

A dependency layer, named and sequenced. The data access paths, the feature definitions, the serving mechanism, the monitoring, the model registry, the review process. These are shared across use cases and they are the reason the second one can be cheaper than the first.

A gate definition per stage. What has to be true to leave exploration, to leave pilot, to enter production, and to stay there. Written before the work, with an owner who can say no.

An operating model. Who retrains, on what trigger, with what approval. Who is paged. Who owns the business decision the model informs.

A funding shape. Which parts are project cost and which become standing run cost, with the run cost accepted before the build starts.

The order matters more than the contents. A roadmap whose first year delivers three use cases and no shared dependency layer has delivered three prototypes that each carry their own private data pipeline, and the fourth will cost what the first did.

Sequencing an enterprise AI roadmap by shared dependency

The common sequencing heuristic is business value, sometimes crossed with effort. It produces a defensible-looking matrix and it systematically picks the wrong first project, because it ignores what each candidate leaves behind.

A more useful ordering asks, for each candidate, what infrastructure it forces into existence and how much of that the next candidates need.

Consider a first project that scores documents arriving by email, and a second that predicts equipment failure from telemetry. The first requires document ingestion, a text pipeline, a human review path and an audit trail. The second requires time-series storage, sensor data quality handling and a streaming path. Almost nothing transfers. Two first projects that both read from the order and invoice history, by contrast, share the extraction, the entity resolution, the feature definitions and the serving route.

So the sequencing question becomes: which two or three candidates sit on the same data foundation, and which of those has the clearest decision attached. Start there, and accept a first project of moderate visible value if it builds the layer the next four need. This is the same argument as paying down the constraints described in our article on technical debt and AI projects, applied to sequencing rather than to remediation.

One caveat worth stating: a first project of no visible value is also a mistake, because the programme needs credibility to obtain the next budget. The target is a candidate that is both foundational and legible to the people funding it.

The gate between AI pilot and production

This is the single most useful artefact in the roadmap, and it has to be written before the pilot runs. Once a result exists, any threshold set afterwards becomes a discussion about that result.

A gate that holds contains:

• An accuracy floor tied to the process, not to a benchmark. The question is what level of error leaves the process better off than the current practice, given how errors are handled downstream. A model at 82 percent can be valuable where a wrong answer is cheap to correct and worthless where it is not.
• The error profile, separately from the rate. Which direction of error is tolerable. A false negative and a false positive rarely cost the same thing, and the acceptable ratio is a business decision.
• A data availability test at decision time. The pilot used an extract. Confirm the same fields are present, populated and fresh at the moment the decision is made in the live process. In DNA Solutions engagements, this is where a meaningful share of pilots fail on inspection.
• A named process owner who has agreed to change how the work is done. Without this, the model ships into a process that continues unchanged, and the output is ignored politely.
• A monitoring plan with defined thresholds. What is measured, at what cadence, and what value triggers intervention.
• A defined stop condition. What causes the model to be switched off, and what the process falls back to. A production model with no fallback path forces the answer to be yes.

The AI operating model: who retrains and who is paged

Most organisations postpone this until several models are running, at which point it is designed under pressure and inherits whatever the first team improvised.

Three questions have to be answered in the roadmap.

Who retrains, and on what trigger. Options are a schedule, a drift threshold or a manual review. Each has a cost and a failure mode. A schedule retrains when nothing has changed and misses a sudden shift. A drift threshold requires monitoring that works. Manual review requires someone whose job includes looking.

Who is paged when the output degrades. A model failing loudly is a good outcome. A model that continues returning plausible values computed from a broken input is the real risk, and it needs an owner with the access and mandate to intervene. The mechanics of this are covered in our article on MLOps.

Who owns the decision. If a model informs credit, pricing, maintenance scheduling or triage, an accountable person owns that decision and its outcomes. Where the model sits inside a regulated process, the classification work under the EU AI Act belongs here as well, at design time rather than at release.

There is no single correct structure. A central platform team with embedded analysts in the business works; so does a federated model with a strong review function. What does not work is leaving it undefined, because the default is that the team who built the pilot keeps it alive informally until they are reassigned.

Funding the run cost of an enterprise AI roadmap

A model funded entirely as a capital project has a predictable life. It is built, it is celebrated, the project closes, the team disperses, and roughly nine months later its output has drifted far enough that people stop relying on it. Nobody decides to abandon it. It stops being maintained, which produces the same result more quietly.

The roadmap needs a standing line for each production model covering monitoring, periodic retraining, revalidation against the current process, and the engineering time to follow schema changes in the source systems. That last item is the one most often omitted and the most reliably needed, because upstream systems change without reference to the models reading them.

A reasonable planning assumption is that the run cost of a model over several years is comparable to its build cost. Presenting that at approval time is harder than omitting it, and it is the difference between a portfolio that accumulates working systems and one that accumulates abandoned ones.

Enterprise AI capability that stays in house

Whatever the delivery arrangement, a few things should end up internal, because outsourcing them permanently makes the organisation unable to judge its own systems.

Feature and target definitions, in business language, owned internally. The evaluation method, including who computes the metric and how the holdout is maintained. The monitoring interpretation, meaning someone internal who can look at a drift report and say whether it matters. And the decision rights described above.

Model implementation, platform engineering and the initial pipeline build are all reasonable to source externally. Judgement about whether a model is still fit for the process is not.

What the first year of an enterprise AI roadmap looks like

A pattern that works, for an organisation with no production models yet: one quarter establishing the data access and the evaluation discipline on a single candidate; a second quarter taking that candidate through the pilot gate and into production with monitoring in place; the second half adding two further use cases on the same foundation, which cost less than the first, while the operating model is exercised on something real rather than designed in the abstract.

The visible output after twelve months is modest, two or three operated models. The durable output is a route to production that the next use case can follow. Programmes that instead run six pilots in year one usually end it with six pilots.

Talk through your enterprise AI roadmap

DNA Solutions works through this sequencing with teams as part of our AI and machine learning practice, most often starting with the dependency layer and the gate definition rather than with model selection. Where the roadmap has to be reconciled with an existing modernisation programme, that work sits under IT consulting, because the sequencing constraints usually come from the estate rather than from the models. Talk to us.