Building an Enterprise AI Roadmap That Survives Reality

The annual plan has a shorter shelf life than its contents

Most enterprise AI roadmaps are still built like ERP roadmaps: a twelve- to thirty-six-month sequence of use cases, each tied to a chosen platform, a chosen model and a cost estimate, approved once a year. That format assumes the inputs hold still long enough for the plan to be executed. In generative AI they do not.

Consider one month. In September 2026 Anthropic announced three frontier releases: Claude Fable 5.1 on 1 September, Claude Opus 5.5 on 22 September and Claude Sonnet 5.5 on 28 September. Anthropic says Opus 5.5 performs at the level of Fable 5.1 on most work and costs 40% less to run than Opus 5, which was itself a current model weeks earlier. On 30 September it gave notice that Claude Sonnet 4.5, a model snapshot dated September 2025, will be retired from its API on 30 November 2026.

The churn is not limited to models. On 3 June 2026 OpenAI told developers it was deprecating Agent Builder, its Evals platform and reusable prompt objects, all shutting down on 30 November 2026. A few days later it scheduled the retirement of its August 2025 GPT-5 snapshots for 11 December 2026.

None of this is a criticism of the vendors. It is what a fast-improving technology looks like. But it means a roadmap whose line items are "deploy model X on platform Y at cost Z" will be wrong in at least one of those three terms within a quarter. The organizations that cope are not the ones with better forecasts. They are the ones whose plans were designed to be revised.

The argument of this article is that an AI roadmap that survives contact with reality has four properties:

1. It commits to durable capabilities, not to specific models or tools.
2. It treats volatile choices as options and keeps the cost of switching low.
3. It makes its assumptions explicit, with owners and dates.
4. It runs on a rolling horizon with pre-agreed re-planning triggers.

This is a planning discipline, not a governance structure. Who decides, and through which forums, is covered in the enterprise AI operating model. How to judge whether an initiative is creating value is covered in From AI Experimentation to Enterprise Value.

Prices move, and not only downwards

The common planning shortcut is to assume AI gets cheaper every year. At a fixed level of capability, that is well supported. Epoch AI found that the price of reaching a given benchmark score fell by between 9 and 900 times per year depending on the task, with the price of GPT-4-level performance on PhD-level science questions falling about 40 times per year. Stanford's 2025 AI Index reported that inference cost for a system performing at GPT-3.5's level fell more than 280-fold between November 2022 and October 2024.

But enterprises rarely buy a fixed level of capability. They buy the current model in a tier, and the list price of "the current model in a tier" has moved in both directions.

As of 1 October 2026, the official price pages show:

• Anthropic's Opus-tier output price fell from $75 per million tokens on Claude Opus 4.1 to $25 on Opus 4.5 and $20 on Opus 5.5, while its newer Fable tier lists output at $50.
• OpenAI's GPT-5 lists output at $10 per million tokens; GPT-5.5 lists it at $30, with a higher rate again above 272,000 tokens of context.
• Google's Gemini 2.5 Flash lists output at $2.50 per million tokens; Gemini 3.5 Flash lists it at $9.00. Gemini 3.8 Flash carries an introductory price that doubles on 1 January 2027.

Two further effects sit under the headline price. Anthropic notes that its tokenizer for Claude 4.7 and later produces roughly 30% more tokens for the same text, so a per-token price comparison across generations understates the change. And newer models may finish the same task in fewer steps: Anthropic reports that on its agentic coding tasks Opus 5.5 matched Opus 5's quality in about half the turns and output tokens. Both are vendor statements, and both show why cost per completed task, measured on your own workload, is the only cost number worth putting in a roadmap.

The practical consequence: a roadmap should carry cost as an assumption with a range and a review date, not as a fixed number in a business case approved twelve months earlier.

Separate what lasts from what churns

If the model, price and tooling layers change every few months, what is left to plan? Quite a lot. Most of the work that determines whether AI creates value changes slowly, and most of it is not about models at all.

Durable for three to five years: the business outcomes and workflows you are redesigning; the data products, document collections and knowledge you curate; the evaluation sets and acceptance criteria that define "good enough" for each task; your risk classification and control library; and the skills of the people doing the work. These carry over from one model generation to the next. An evaluation set built for Opus 4.5 is exactly what you need to decide whether Opus 5.5 is worth switching to.

Medium-lived, twelve to twenty-four months: the AI platform, model gateway, orchestration patterns, observability and vendor contracts. These should be chosen deliberately but designed to be replaceable.

Volatile, three to nine months: the specific model behind each use case, its price, the agent framework of the moment and vendor-hosted builder tools.

The roadmap should commit firmly to the durable layer, budget the medium layer, and treat the volatile layer as a set of options to be exercised and re-exercised. A useful test: if a line in your roadmap would need rewriting after a vendor's next model launch, it belongs in the volatile layer and should not carry a multi-year commitment.

Keep the cost of changing your mind low

Options only have value if exercising them is cheap. Three design choices keep switching costs down, and all of them are cheaper to make at the start than to retrofit.

Keep logic you own in systems you own. OpenAI's reusable prompts deprecation advises developers to move prompt content into application code. Prompts, agent definitions, tool schemas and evaluation cases are intellectual property; keep them in version control rather than only inside a vendor's console.

Keep your own evaluation harness. When a model is deprecated with sixty days' notice, the minimum Anthropic commits to for publicly released models, the bottleneck is not engineering. It is proving the replacement is at least as good on your cases. Teams with a maintained evaluation set re-qualify in days. Teams without one start an unplanned project.

Negotiate for change, not just for price. Contract terms worth more than a headline discount include deprecation notice periods, price protection for the contract term, the right to move committed spend between models, and data export. Ask, too, whether regional endpoints or residency options carry a premium. Anthropic's price page lists a 10% premium for regional over global endpoints on Amazon Bedrock and Google Cloud for recent Claude models.

Write the assumptions down

Every AI roadmap rests on assumptions. Most leave them implicit, which means nobody notices when they stop being true. An assumption register turns them into something that can be monitored.

Values are illustrative. The point is the structure: each assumption has a current value, a source with a date, a named owner and a threshold that forces a decision.

The Gulf illustrates why residency assumptions belong on the list. In February 2026 AWS announced global cross-Region inference for Claude models from its UAE and Bahrain Regions; AWS states that customer data is not stored in the destination Region, while inference requests may be processed elsewhere. Whether that is acceptable for a given Saudi or UAE workload is a legal judgement under the applicable data protection rules and sector regulation, and both the vendor options and the regulatory guidance can change during a roadmap's life. A plan that records the assumption and its owner can respond. A plan that buried it in an architecture decision two years ago usually cannot.

Plan on a rolling horizon with explicit triggers

Replace the annual roadmap with a rolling one in three horizons, reviewed quarterly and re-opened between reviews when a trigger fires.

Now (zero to three months): committed. Funded initiatives with named owners, a value case and a measurement plan. Model and vendor choices are made here, for this horizon only.

Next (three to nine months): planned. Candidate initiatives with capacity reserved but not allocated, re-scored every quarter as prices, capabilities and pilot evidence change. This is where a use-case selection process feeds the roadmap.

Later (nine to twenty-four months): directional. Stated as capabilities and outcomes, not use cases: "decision support for all credit analysts", "multilingual service across channels". Specific solutions are deliberately left open.

Quarterly reviews keep the roadmap current. Triggers keep it honest between reviews. Agree them in advance, so that a vendor announcement prompts a defined response rather than a debate:

Weak and strong roadmaps side by side

What to do in the next 90 days

1. Split the current roadmap into durable, medium and volatile layers. Most organizations find that the majority of their committed line items sit in the volatile layer.
2. Build an assumption register for every initiative in the Now and Next horizons, with an owner and a re-plan threshold for each assumption.
3. Inventory every model, model version and vendor tool in production, with the vendor's published retirement date or commitment beside each one.
4. Stand up a standing evaluation set for the three highest-volume AI workloads, so the next model release or deprecation can be assessed in days.
5. Move prompts, agent definitions and evaluation cases into version control wherever they currently live only in vendor consoles.
6. Agree the trigger list with the executive sponsor and finance, including the cost-per-task margin that forces a re-score.
7. Hold the first quarterly re-plan at the end of the period and publish what changed and why.

Frequently asked questions

How long should an enterprise AI roadmap be?

Use a rolling horizon rather than a fixed length: a committed zero-to-three-month horizon, a planned three-to-nine-month horizon re-scored quarterly, and a directional nine-to-twenty-four-month view expressed as capabilities and outcomes rather than specific solutions.

Why do AI roadmaps go out of date so quickly?

Because the inputs change on a timescale of months. Vendors release new models several times a year, retire older snapshots after notice periods as short as sixty days, change list prices in both directions and withdraw developer tools. A roadmap that fixes model, vendor and price for a year is built on assumptions that will not hold.

What should an AI roadmap commit to if not specific models?

Durable capabilities: redesigned workflows, curated data and knowledge, evaluation sets and acceptance criteria, risk controls and people's skills. These carry over across model generations. Model and vendor choices should be made per horizon and kept cheap to change.

What are re-planning triggers?

Pre-agreed events that reopen the roadmap between scheduled reviews, such as a deprecation notice, a price or capability change that moves cost per task beyond an agreed margin, a regulatory change, or adoption and quality falling below agreed thresholds. Each trigger has a defined response.

Sources and further reading

• Model deprecations, Anthropic documentation, accessed 1 October 2026.
• Pricing, Anthropic documentation, accessed 1 October 2026.
• Introducing Claude Opus 5.5, Anthropic, 22 September 2026. Vendor material.
• Anthropic newsroom, release announcements for September 2026.
• Deprecations, OpenAI API documentation, accessed 1 October 2026.
• Pricing, OpenAI API documentation, accessed 1 October 2026.
• Gemini Developer API pricing, Google AI for Developers, last updated 1 October 2026.
• LLM inference prices have fallen rapidly but unequally across tasks, Epoch AI, 12 March 2025.
• The 2025 AI Index Report, Stanford HAI, 2025.
• Amazon Bedrock global cross-Region inference for Claude in the Middle East Regions, AWS Machine Learning Blog, 24 February 2026.