Scale is where AI programs most often fall short: in IBM's 2025 study, the 2,000 CEOs surveyed reported that only 16% of AI initiatives had scaled enterprise wide. A narrow roadmap gives the first process a real chance of getting there: one process, five phases separated by decision gates, and a second process chosen from what the first one taught.
Why should an AI roadmap start with one process?
The typical enterprise AI roadmap is a portfolio: forty use cases scored on a matrix, a platform selection, a center of excellence, a three-year business case. It looks thorough. In practice it spreads attention across many pilots, none of which gets the engineering, ownership and redesign it needs to reach production.
Starting with one process concentrates all three. One process owner, one set of systems, one baseline, one team that will run it. The learning is also sharper: when the first process reaches production, you know what your integrations, data, risk reviews and teams can handle, and the second process benefits from all of it.
Speed is the other argument. A portfolio moves at the pace of its slowest dependency: every pilot waits on the same integration team, the same risk review and the same budget cycle, and each one slows the others. Large organizations do not have to be slow, but the breadth of a portfolio roadmap all but ensures it. A roadmap built around one process is how a large company moves at the narrower pace.
Starting narrow does not mean working without a strategy. Keep a short list of candidate processes and a clear view of where AI matters most to the business. The difference is that the list feeds a sequence instead of a simultaneous launch. Executives get a first result they can inspect in operating numbers, which does more for the next budget conversation than any portfolio slide.
How do you choose the first process?
Pick a process that is manual, critical and specific: too important to leave manual, too particular to your business for an off-the-shelf product, and too full of judgment for simple rule-based automation. Then test it against the seven questions set out in the AI for business operations guide, shown here with what good looks like and the red flag for each.
| Criterion | What good looks like | Red flag |
|---|---|---|
| Volume | Hundreds or thousands of cases a week | A few dozen cases a month |
| Cost of failure | Customers, cash or compliance feel the delay | Nobody would notice if it stayed manual |
| Written rules | A policy, contract or tolerance defines a correct outcome | Nobody can say what a correct outcome is |
| Measurability | Cycle time, cost per case, backlog already tracked | No baseline anyone trusts |
| One owner | One leader accountable for the outcome | Ownership split across three departments |
| Reachable data | Systems readable and writable through APIs or exports, at worst through screens | The core system is mid-migration |
| Identifiable exceptions | Known types, handled today by experienced people | Every case is unique |
A process that clears most of these is a strong first candidate. For a first process, add one more test: errors should be catchable and reversible, because a process where one wrong action causes irreversible harm is a poor place to learn. Billing inquiries, invoice exceptions, claims intake and CRM record upkeep often qualify, and the operations guide scores three sample candidates side by side.
What are the phases of an AI implementation roadmap?
| Phase | Question it answers | Output | Gate to pass before moving on |
|---|---|---|---|
| 1. Select | Which process, and why this one? | A named process, owner and business case in one page | The owner commits time from their team |
| 2. Map | How does the work run today, in practice? | Case-level map, exception catalog, baseline numbers | The baseline is agreed with finance |
| 3. Design and prove | What should the process become, and can AI do its part? | Redesigned flow and a proof of concept on real cases | The proof of concept meets pass marks set in advance |
| 4. Pilot | Does it work on live volume in real systems? | A pilot on a controlled share of volume, with limits, approvals, logging and a fallback already on, and exceptions routed to people | Operating metrics move against the baseline |
| 5. Harden and run | Can it carry full volume safely, every day? | The step from the pilot's share to full volume, a controls pack reviewed by risk and IT, and a calendar of operating reviews with the process team | Risk and IT sign off; full-volume operation starts |
The phases are the calendar view of the five steps in the AI implementation guide: Map is See, Design and prove covers Rethink and the first half of Engineer, Pilot completes Engineer, and Harden and run covers the last two steps. The pilot is not a trial without controls: it carries its limits, approvals, logging and fallback from the first live case, and Harden then takes it from a controlled share to full volume. Select comes before all of them.
Phase 3 is where a proof of concept belongs, designed on real data with the exceptions in scope. Phase 4 is where most programs stall, for the reasons set out in why AI pilots stall. Phase 5 has no end date. The roadmap's last phase is an operation.
What decision gates keep the roadmap honest?
A roadmap without gates becomes a schedule, and schedules only move forward. Each gate should be a real decision with three possible outcomes: proceed, rework, or stop.
- Baseline gate. No build starts until the current numbers are agreed. Without them, the return can never be shown, as the post on AI ROI argues.
- Proof gate. The pass marks are written before the test. Moving them afterward is the most common way a weak result becomes a pilot.
- Pilot gate. The decision is made on operating metrics from live volume, judged by the process owner.
- Production gate. Risk, IT and audit review the controls before full volume. Risk teams can use the NIST AI Risk Management Framework, released on January 26, 2023 and "intended for voluntary use," as a common reference for this review.
- Running review. An operating review of the numbers, the exception patterns and the rule changes, weekly in the first weeks after go-live and monthly once the system is stable, with the authority to adjust or pause.
Write each gate's criteria down at the start of the roadmap, name who decides, and keep the decision record. When the next process comes along, those records are the fastest way to see which assumptions held.
Stopping at a gate is a result. A process that fails the proof gate costs a few weeks; the same failure discovered after a year-long program costs the program.
How does the roadmap expand after the first process?
Choose the second process from what the first one built. The strongest candidates share systems, data or people with the first: the integration to billing already exists, the team already knows how to work an exception queue, the risk review already understands the controls. Each process added this way costs less and goes faster than the one before.
Resist launching five at once after the first success. The constraint on an AI roadmap is rarely engineering capacity. It is the number of processes your operations leaders can redesign and run well at the same time. Grow at that pace, and the portfolio builds itself from working systems instead of from a slide.
Ownership of the roadmap should sit with operations. A central AI or technology team can set the standards for security, vendors and model use, and it should. The order of processes is an operations decision, because operations carries the redesign, the exceptions and the running. An outside team, such as the engineers described under AI implementation services, can carry the build and the day-to-day operation with your team, but the sequence stays with the business.
What should an AI roadmap leave out?
A few items appear on most enterprise AI roadmaps and slow the first result without improving it:
- A data platform as a prerequisite. The first process needs access to the data it touches. A platform can follow the evidence of what the processes need.
- An enterprise-wide tool selection before any process is chosen. Tools chosen in the abstract rarely fit the first real process.
- A use-case list longer than the team can run. Forty scored ideas produce forty half-finished pilots.
- A business case measured in years. One process should show its return in operating numbers within its pilot.
Each of these can come later, once one process is running and the next decision can be made from evidence. A roadmap earns its second process with the first.