A realistic enterprise AI roadmap runs in five phases over about two years: readiness, one deployment, two or three more, platform consolidation, and scale. The phases matter less than the gates between them — each phase should be entered only when the previous one has produced specific evidence, and most failed programmes skipped a gate rather than a phase.
The single most common error is starting at phase 1 without having done phase 0.
What has to be true before the first deployment? (Phase 0)
Four preconditions. A programme that starts without them spends its first deployment discovering them, which is expensive.
A use case selected on evidence. Chosen from ticket volumes and process data rather than from a workshop, and tested against the criteria in AI agent use cases across industries: findable ground truth, sufficient volume, a named outcome owner, recoverable errors, and a measurable number that already exists.
A baseline captured. Cycle time, human touch time, exception rate — measured before anything is built. This cannot be recovered later, and without it the programme cannot demonstrate value at the first gate.
Data reachability confirmed. Can the system reach the required data, under whose identity, with what classification. If the answer is unknown or the data is ungoverned, that work comes first — and it is a data governance project, which is a different plan with a different timeline.
A deployment posture decided. Where inference runs and where logs go. For supervised institutions in Azerbaijan this is usually settled by residency rules rather than by preference, as set out in data residency and personal data law. Deciding it at the start avoids rearchitecting at the point of scaling.
Phase 0 takes four to six weeks and is the phase most often skipped. A structured readiness assessment exists precisely to compress it.
Gate to phase 1: a named use case, a written baseline, a confirmed data path with per-user entitlements, and an agreed deployment posture.
Phase 1 — the first deployment (quarter 1)
One use case, read-only, deployed properly rather than quickly.
The purpose of phase 1 is not the use case. It is to build the foundations every later deployment will inherit: identity propagation, the retrieval pipeline, the evaluation set, the audit trail and the approval mechanism. Building these once, correctly, in a low-risk deployment is far cheaper than retrofitting them across three deployments later.
The sequence within the phase runs shadow mode, then assistive, then supervised — as described in how AI agents automate business processes. Shadow mode is not optional; it is the only honest accuracy measurement available before users are involved.
What phase 1 should produce beyond a working system: an evaluation set of a hundred real questions, a documented failure-mode distribution, a first measurement against the baseline, and an operating cadence with a named owner.
Gate to phase 2: the measured outcome beats the baseline, the evaluation set exists and is being re-run, and the audit trail has been reviewed by whoever will have to defend it.
Phase 2 — two or three more use cases (quarters 2–3)
Now breadth, deliberately chosen to test different shapes rather than to repeat the first success.
A useful selection: one adjacent to the first (same data, different task), one in a different department (different data, similar task), and one that requires a write action so that the approval mechanism gets exercised in production.
The write-action deployment is the important one, because it is where the policy gates, the reversibility classification and the approval workflow stop being design documents. It should be scoped tightly — a single action type, a low threshold, a clear approver.
What usually surfaces in this phase: the retrieval pipeline generalises less well than expected to a new corpus, the second department's data turns out to be less governed than the first's, and the approval interface needs redesigning after real approvers use it.
Gate to phase 3: two or three deployments in production with owners, a write action running under approval without incident, and a clear picture of which platform components are being copy-pasted between projects.
Phase 3 — platform consolidation (quarters 3–4)
The phase that determines whether the programme scales or fragments, and the one most programmes skip because nothing is visibly broken.
By this point the same components have been built two or three times: safety controls, approval flows, audit logging, retrieval pipelines, evaluation harnesses. They have diverged. Consolidating them into a platform layer that projects inherit is what prevents the institution accumulating a set of individually-reasonable systems with collectively-unmanageable risk — the pattern described in how HAVAA enables enterprise AI transformation.
Three consolidation targets:
Safety and policy as platform capability. One approval mechanism, one reversibility classification, one policy engine, one set of rate limits and kill switches.
One audit trail. Uniform across deployments, exportable, reviewed as a whole. Three separate audit implementations are three separate evidence problems.
One retrieval and evaluation stack. So that a retrieval improvement benefits every deployment rather than one.
This phase also usually forces the data governance question that phase 0 deferred: as deployments multiply, the number of assets in retrieval scope grows, and classification stops being tractable without a catalog. Whether that appears in phase 3 or phase 4 varies; that it appears does not.
Gate to phase 4: new deployments inherit safety, audit and retrieval rather than rebuilding them, and time-to-deploy for a new use case has measurably fallen.
Phase 4 — scale (year 2)
Scale is a different activity from deployment, and it has three components.
Throughput. More use cases per quarter, delivered by teams other than the original one. This requires the platform from phase 3 and documentation good enough that a new team does not need the original engineers.
Autonomy. Capability granted more broadly as evidence accumulates — moving deployments up the graduated modes rather than launching new ones at full autonomy. The evidence for each step is the acceptance rate and the incident history of the previous step.
Capacity. On-premise, this is where GPU capacity planning becomes a real constraint rather than a theoretical one. Model routing — cheap models for cheap tasks — moves from an optimisation to a requirement, and the sizing reasoning is in deploying LLMs on-premise.
The failure mode at this phase is different from earlier ones: not that a deployment fails, but that the portfolio becomes unmanaged. Twenty agents with no inventory, no owner list and no retirement process is a governance problem that looks like success.
What does each phase cost in people?
Approximate, for a mid-size institution, and deliberately smaller than vendor proposals suggest.
Phase 0: one analyst and one engineer, part time, four to six weeks, plus the process owner's attention.
Phase 1: two engineers, one process owner at roughly a day a week, and a domain expert for the evaluation set — a week of their time, front-loaded.
Phase 2: the same two engineers plus one, with each deployment carrying its own process owner.
Phase 3: the platform work is two engineers for a quarter, and it competes with new deployments for the same people — which is why it needs to be a decision rather than something squeezed in.
Phase 4: a platform team of two to three, plus delivery capacity per use case, plus one person owning the portfolio: inventory, ownership, retirement.
The role most commonly missing is the last one, and its absence is what turns a successful year-two programme into an ungoverned estate.
What breaks the roadmap?
Five things, in rough order of frequency.
Skipping phase 0. The first deployment discovers that the data is ungoverned, and a quarter is spent on a governance project that was never scoped. This is the most common single cause, and it is why enterprise AI in Azerbaijan so often reduces to a data readiness question.
No baseline. The programme cannot demonstrate value at the first gate, and funding gets questioned at exactly the moment when the foundations have been paid for and the returns have not yet arrived.
Skipping phase 3. Deployments accumulate with divergent controls until a compliance review stops the programme rather than a project.
Treating gates as milestones. A gate that is passed because the date arrived rather than because the evidence exists is not a gate. The specific evidence for each is listed above.
Losing the owner. A programme whose sponsor changes at phase 2 usually restarts at phase 1 with a different use case. Documented baselines and evaluation sets are what survive a sponsor change; enthusiasm is not.
Key points
- Five phases over about two years: readiness, one deployment, two or three more, platform consolidation, scale.
- The gates matter more than the phases. Each has specific evidence attached, and passing on a date rather than on evidence is the common failure.
- Phase 0 requires a use case chosen on evidence, a captured baseline, confirmed data reachability under per-user entitlements, and a decided deployment posture.
- Phase 1's real product is the foundations — identity, retrieval, evaluation set, audit trail, approvals — not the use case.
- Phase 2 should include one write action under approval, to exercise the policy mechanism in production.
- Phase 3 consolidation is the phase most often skipped and the one that determines whether the programme scales or fragments.
- Phase 4 introduces portfolio management: inventory, ownership, retirement. The portfolio owner is the role most commonly missing.
- Staffing is smaller than vendor proposals suggest, but the process owner's weekly time is not optional.
Yukon Labs runs phase 0 as a structured readiness assessment and deploys HAVAA on-premise from phase 1, grounded on governed data through OvalEdge and Starburst. For the mistakes that most often derail this sequence, see common AI implementation mistakes.