Defining the AI Technology Roadmap

From Business Strategy to a Sequenced, Architecture-Informed Target State

A practical guide to business outcomes, opportunity portfolios, capability and architecture definition, trust and governance, economics, sequencing, and defensible technology decisions

Definition is the controlled conversion of business strategy into an evidence-based, sequenced plan of capabilities, architecture, technology choices, and investments that an organization can authorize and execute.

---

Contents

• Preface
• Executive Summary
• [Part I. Establish the Meaning and Boundaries]
  • 1. What Is an AI Technology Roadmap?
  • 2. Distinguish the Roadmap from Related Strategies and Plans
  • 3. Define the Scope Before Designing the Roadmap
• [Part II. Start with Business Outcomes]
  • 4. Understand the Business Before Selecting AI
  • 5. Identify Where AI Can Create Value
• [Part III. Build and Prioritize the Opportunity Portfolio]
  • 6. Create a Structured Opportunity Inventory
  • 7. Prioritize Opportunities Transparently
  • 8. Consider the Portfolio, Not Just Individual Use Cases
• [Part IV. Assess the Current State]
  • 9. Establish an Evidence-Based Baseline
  • 10. Identify Constraints and Architectural Debt
  • 11. Define the Gap Between Current and Required Capability
• [Part V. Define the Target Capabilities and Architecture]
  • 12. Define the Target Capability Model
  • 13. Define the Target-State Architecture
  • 14. Determine the AI Technology Strategy
  • 15. Make Build, Buy, Partner, and Reuse Decisions
  • 16. Define Platform Boundaries and Centralization Choices
• [Part VI. Define Trust, Governance, and Operating Requirements]
  • 17. Treat Trust and Governance as Architectural Requirements
  • 18. Define the Operating Capabilities the Roadmap Must Enable
• [Part VII. Evaluate Economics and Investment]
  • 19. Build a Lifecycle Economic View
• [Part VIII. Sequence the Roadmap]
  • 20. Convert Capability Gaps into Roadmap Initiatives
  • 21. Sequence by Value, Dependency, Risk, and Readiness
  • 22. Use Horizons Without Turning Them into Arbitrary Dates
  • 23. Represent Uncertainty Explicitly
• [Part IX. Make Technology Decisions Defensible]
  • 24. Establish a Decision Framework
  • 25. Evaluate Models and Platforms Against Representative Workloads
  • 26. Define Non-Functional Requirements Early
• [Part X. Govern the Roadmap as a Portfolio]
  • 27. Establish Ownership and Decision Rights
  • 28. Define Roadmap Governance
  • 29. Define Portfolio-Level Measures
• [Part XI. The End-to-End Method]
  • 30. A Practical Roadmap-Definition Lifecycle
• [Part XII. Worked Example]
  • 31. Defining a Roadmap for a Financial Services Enterprise
• [Part XIII. Roadmap Artefacts and Templates]
  • 32. Recommended Deliverable Structure
  • 33. Template: Business Outcome Register
  • 34. Template: AI Opportunity Assessment
  • 35. Template: Current-to-Target Capability Gap
  • 36. Template: Technology Decision Record
  • 37. Template: Roadmap Initiative
  • 38. Template: Roadmap Assumption and Trigger Register
  • 39. Template: Executive Roadmap View
• [Part XIV. Common Failure Modes]
  • 40. Mistakes That Weaken an AI Technology Roadmap
• [Part XV. Quality Criteria and Final Checklist]
  • 41. What Makes a Roadmap Decision-Ready?
• Conclusion
• Appendix A. Engineering Practice Crosswalk
• Appendix B. Framework and Regulatory Crosswalk
• Appendix C. Glossary

---

Preface

Most enterprise AI programs do not fail because the models are weak. They fail because the surrounding decisions were never made explicitly: which business outcomes justify the investment, which capabilities are missing, which architecture those capabilities require, and in what order they should be established. A list of use cases, a vendor shortlist, and a set of delivery dates can look like a roadmap while leaving every one of those decisions unanswered.

This guide offers a disciplined method for making those decisions. It translates business outcomes into opportunities, capabilities, architecture, technology choices, investment options, and a defensible sequence. Every commitment carries a rationale and supporting evidence, so that the result can be reviewed by executives, architecture boards, and engineering teams with equal confidence.

Who This Guide Is For

The primary readers are CTOs, CIOs, Chief AI Officers, Heads of AI, principal AI architects, enterprise architects, and engineering and platform leaders who must decide what to build, buy, partner on, or reuse in order to apply AI at scale. The guide assumes familiarity with enterprise architecture, portfolio planning, and technology governance. It does not assume deep knowledge of model training.

Engineering organizations that already operate mature software, data, ML, and reliability practices will find that the method plugs into what they have rather than replacing it. Appendix A maps each stage of the method to familiar engineering artefacts and rituals: design documents, architecture decision records, SLOs, launch reviews, threat models, experimentation, and FinOps.

How This Guide Is Organized

The guide has fifteen parts. Parts I to X define the method. Parts XI to XV show how to apply it, package the result, and assess its quality. Appendices provide an engineering-practice crosswalk, a regulatory and framework crosswalk, a glossary, and suggested reading.

Stage	Question it answers	Parts
Frame	What is a roadmap, how does it differ from neighboring plans, and what is in scope?	I
Anchor in the business	Which outcomes matter, and where can AI contribute to them?	II
Build the portfolio	Which opportunities are worth pursuing, and how do they fit together?	III
Assess the current state	Where does the organization stand, and what constrains it?	IV
Define the target	Which capabilities, architecture, sourcing choices, and platform boundaries are required?	V
Establish trust and operations	Which governance, risk, and operating requirements must be designed in?	VI
Evaluate economics	What will it cost to build and operate, and what value is expected?	VII
Sequence	In what order should capabilities and investments be established?	VIII
Make decisions defensible	How are technology choices evaluated and recorded?	IX
Govern as a portfolio	Who decides, and how is progress measured and the roadmap refreshed?	X
Apply and check	How does the method run end to end, and is the result decision-ready?	XI–XV

Scope and Boundaries

This guide covers roadmap definition: the decisions and artefacts required to authorize execution. Delivery management, engineering implementation, deployment, and day-to-day operations belong to the companion volume, Executing the AI Technology Roadmap.

Using This Guide in a Large Organization

Organizations with established strategy, architecture, and portfolio processes do not need a parallel AI process. The method is designed to connect to existing governance:

• Placement. The roadmap sits between business and AI strategy on one side and the use-case portfolio, reference architecture, and delivery plans on the other. Chapter 2 shows how these artefacts differ so that each is owned and reviewed in the right forum.
• Planning cycles. Scope, horizons, and decision rights are set explicitly (Chapters 3, 22, and 27) so the roadmap aligns with existing planning and funding cycles.
• Decision records. Technology choices are recorded with criteria, alternatives, and evidence (Chapters 24 and 36), which fits architecture review boards and investment committees.
• Living governance. Chapters 28 and 29 describe roadmap governance and portfolio-level measures, including review triggers that keep the roadmap current as evidence changes.

Conventions Used in This Guide

• Technology neutrality. The guide describes capabilities and decision criteria, not specific products or vendors.
• Templates. Tables and templates show the shape of an artefact. Adapt them to your organization's formats and tooling.
• Hypotheses, not commitments. Examples of objectives, opportunities, and technology implications are hypotheses to investigate.
• Illustrative figures. Weights, thresholds, and percentages are examples. Calibrate them to your context.
• Checklists. Checklists use - [ ] so they can be pasted into review documents.
• Callouts. Engineering lens notes connect a concept to common engineering practice. Key takeaways close each part.

A Note on Terminology

Term	Meaning in this guide
Capability	An enduring ability of the organization, independent of any specific product
Initiative	A bounded body of work that establishes, improves, or retires a capability or delivers an outcome
Horizon	A planning band (Establish, Scale, Transform) rather than a fixed calendar date
Decision gate	An evidence-based checkpoint that must be passed before further commitment
Commitment class	The firmness of a roadmap item: approved, planned, conditional, exploratory, deferred, or rejected
Enabler	A shared capability (data, platform, governance, identity, integration) that unlocks multiple use cases

---

Executive Summary

An AI technology roadmap is a strategically sequenced plan to establish, acquire, integrate, govern, and evolve the technology capabilities needed to achieve business objectives through AI.

It is not a product catalogue, a proof-of-concept list, a use-case inventory, or a delivery schedule disguised as strategy. It translates strategic intent through a chain of explicit decisions:

Figure 1. The roadmap translation chain. Each arrow is a decision that should be recorded, evidenced, and reviewable.

The Five Questions

#	Question	What the roadmap must provide
1	Why	The business outcomes AI should help achieve
2	What	The AI-enabled business capabilities and technology capabilities required
3	How	The data, model, platform, integration, security, and operating foundations needed
4	When	The order of capabilities and investments, given dependencies, risk, readiness, and value
5	How will success be judged	The business, technology, operational, adoption, and risk measures that demonstrate progress

Eight Properties of a Sound Roadmap

1. Business-led. It begins with enterprise objectives and measurable business problems.
2. Capability-oriented. It describes enduring capabilities, not only individual projects.
3. Architecture-informed. It establishes coherent principles, boundaries, patterns, and standards.
4. Evidence-based. It reflects the current state, constraints, maturity, and validated assumptions.
5. Economically grounded. It considers total cost, value, opportunity cost, and the cost of operating AI at scale.
6. Risk-aware. It incorporates privacy, security, safety, legal, regulatory, and model-related risks.
7. Sequenced. It exposes dependencies and distinguishes foundational work from use-case delivery.
8. Adaptive. It is reviewed as business conditions, technology, evidence, and readiness change.

The defining principle. An AI technology roadmap is not a plan to adopt AI technologies. It is a plan to establish the enterprise capabilities through which AI can deliver measurable, secure, reliable, and economically sustainable business value.

---

Part I. Establish the Meaning and Boundaries

In this part: what a roadmap is, how it differs from adjacent artefacts, and how to scope it so it stays manageable.

1. What Is an AI Technology Roadmap?

An AI technology roadmap is a business-aligned, time-phased plan defining the capabilities, architecture, platforms, data foundations, governance, skills, and investments required to deliver and sustain the organization's AI ambitions.

The definition contains three ideas.

1.1 It Is an Organizational Plan, Not a Technology Shopping List

A roadmap defines the enterprise's future ability to apply AI across business domains, applications, data, infrastructure, people, processes, suppliers, controls, and operating models.

Choosing a foundation model or a cloud AI service is a decision within the roadmap. It is not the roadmap itself.

1.2 It Is Technology-Focused but Business-Derived

The roadmap does not replace business or AI strategy. It translates their intent into technology direction.

Business objective	Possible AI contribution	Technology implications
Reduce claims-processing cost	Extract, classify, validate, and summarize claims information	Document intelligence, workflow integration, rules, human review, model evaluation
Improve customer retention	Identify churn risk and recommend interventions	Governed customer data, predictive models, decision services, CRM integration
Improve employee productivity	Make enterprise knowledge easier to find and use	Search, retrieval-augmented generation (RAG), identity-aware access, source attribution
Shorten service resolution time	Assist agents and automate suitable workflow steps	Conversational interfaces, knowledge services, agent orchestration, tool controls
Reduce fraud losses	Detect unusual patterns and prioritize investigations	Feature pipelines, anomaly detection, graph analytics, case-management integration

The technology implications are hypotheses to investigate, not automatic commitments to specific products.

1.3 It Is Sequenced and Revisable

A roadmap identifies the order in which capabilities and investments should be established, and recognizes that some capabilities are prerequisites for others. Scaling enterprise RAG, for example, may depend on:

• reliable source systems and clear data ownership;
• identity-aware access to information;
• content classification and retention policies;
• retrieval and evaluation standards;
• application integration and operational monitoring.

The roadmap exposes these dependencies. It is revised when evidence invalidates an assumption or when business priorities change.

Engineering lens. Treat the roadmap as you would a long-lived design document: it has an owner, a change history, explicit assumptions, and review triggers. It is a living artefact, not a one-time deliverable.

2. Distinguish the Roadmap from Related Strategies and Plans

The following artefacts are connected but answer different questions.

Artefact	Primary question	Typical content
Business strategy	Where will the organization compete and what outcomes matter?	Growth, customer, cost, product, market, operating priorities
AI strategy	Where and why should the organization apply AI?	AI ambition, strategic domains, value thesis, risk appetite, adoption principles
AI technology roadmap	What technology capabilities and investments are needed, and in what sequence?	Capability gaps, target architecture, platforms, standards, dependencies, investment horizons
AI use-case portfolio	Which specific opportunities should be explored or delivered?	Descriptions, owners, value hypotheses, feasibility, risk, status
Enterprise AI reference architecture	What reusable structures and patterns should solutions follow?	Architecture views, components, interfaces, controls, deployment patterns
AI implementation or delivery plan	How will an approved initiative be delivered?	Scope, backlog, team, milestones, engineering tasks, testing, release
AI operating model	How will AI capabilities be owned, governed, supported, and improved?	Roles, decision rights, service ownership, controls, support model

A quick diagnostic.

• If the document mainly lists business opportunities, it is a use-case portfolio.
• If it mainly describes products and vendors, it is a technology inventory or selection document.
• If it describes components and their relationships, it is an architecture.
• If it describes tasks, sprints, and release dates, it is an implementation plan.
• If it connects business outcomes to required capabilities, architectural direction, investment choices, and sequencing, it is functioning as a technology roadmap.

3. Define the Scope Before Designing the Roadmap

An enterprise roadmap becomes unmanageable without clear boundaries. Define scope across these dimensions.

Scope dimension	Questions to resolve
Organizational	Enterprise-wide, business unit, geography, subsidiary, or product line?
Business domains	Which processes, products, customer journeys, and internal functions are included?
AI scope	Traditional ML, predictive analytics, deep learning, GenAI, RAG, agents, optimization, or a combination?
Technology estate	Cloud, on-premises, edge, SaaS, legacy applications, data platforms, and integration estate?
Risk and regulation	Which jurisdictions, data classes, industry rules, and assurance obligations apply?
Planning horizon	What is the near-term window, and what longer-term direction is useful?
Investment boundary	Does the roadmap include people, data remediation, platform engineering, licensing, and operating expenditure?
Exclusions	Which systems, domains, experiments, or technology decisions are explicitly out of scope?

Include only technologies justified by business need, risk, existing assets, and organizational capacity.

3.1 Choose a Useful Planning Horizon

Distinguish three horizons:

• Near term: establish urgent capabilities and deliver opportunities with a credible path to value.
• Medium term: scale reusable capabilities, address cross-domain dependencies, and expand adoption.
• Longer term: position the enterprise for emerging capabilities and strategic options without pretending distant forecasts are certain.

A three-year view is common but not universal. Fast-changing environments may need a shorter rolling horizon. Use dates only when they inform investment or governance decisions.

Key Takeaways — Part I

• A roadmap is an organizational plan for capabilities, not a list of products or pilots.
• It is business-derived, technology-focused, sequenced, and revisable.
• Scope it explicitly before designing it, and say what is out of scope.

---

Part II. Start with Business Outcomes

In this part: how to ground the roadmap in measurable business outcomes and decide where AI is, and is not, the right intervention.

4. Understand the Business Before Selecting AI

Start from the organization's strategy, operating model, economics, customers, constraints, and performance, not from a model. A roadmap that begins with fashionable technology tends to produce disconnected pilots. A roadmap that begins with business outcomes can make defensible choices about where AI is useful, where it is not, and what must change around it.

4.1 Examine the Business Context

Review sources such as:

• corporate and business-unit strategy;
• annual operating plans and financial targets;
• product and market strategy;
• customer experience objectives;
• process performance and service-level reports;
• cost, productivity, and quality baselines;
• risk registers, audit findings, and compliance obligations;
• digital, cloud, data, and application modernization plans;
• existing automation and analytics initiatives;
• leadership interviews and domain workshops.

4.2 Express Objectives as Measurable Outcomes

Avoid vague objectives such as "become AI-driven" or "adopt agentic AI." Convert them into observable outcomes.

	Statement
Weak	Use GenAI to improve customer service.
Strong	Reduce average handling time for eligible customer-service interactions by 15% while maintaining or improving customer satisfaction, policy compliance, and first-contact resolution.

A well-formed outcome specifies:

1. the population or process;
2. the metric and its baseline;
3. the target and timeframe;
4. quality and risk guardrails;
5. the accountable owner.

Engineering lens. This is the same discipline as writing an OKR with a guardrail metric, or defining an SLO before building a service. If you cannot state the metric and the guardrail, you cannot tell whether the system worked.

4.3 Build an Outcome Hierarchy

Figure 2. The outcome hierarchy links enterprise objectives to operational measures and candidate AI contributions.

Example:

AI is only one part of the solution. Process redesign, policy, integration, data remediation, and workforce adoption may matter just as much.

5. Identify Where AI Can Create Value

AI is appropriate only when it addresses a meaningful business problem better than feasible alternatives. The presence of data or repetitive work alone does not justify it.

5.1 Recognize the Major AI Capability Families

Capability family	What it does	Illustrative applications
Descriptive and diagnostic analytics	Explains what happened and helps investigate why	Operational dashboards, root-cause analysis
Predictive machine learning	Estimates future outcomes or class membership	Churn, fraud, demand, risk, forecasting
Prescriptive optimization	Recommends or optimizes actions under constraints	Scheduling, routing, inventory, resource allocation
Perception and document intelligence	Interprets images, audio, video, and documents	OCR, document classification, speech processing, quality inspection
Generative AI	Generates or transforms content using learned patterns	Summarization, drafting, code assistance, content generation
Retrieval-augmented generation	Grounds model responses in retrieved information	Enterprise knowledge assistants, policy support
Agentic systems	Coordinate model reasoning with tools and actions to pursue goals	Controlled workflow execution, research and case preparation
Hybrid intelligent systems	Combine models, rules, optimization, retrieval, and human decisions	Claims, underwriting, service operations, compliance workflows

These categories overlap within a single production solution.

5.2 Ask Whether AI Is the Right Intervention

For each opportunity, ask:

1. Is the problem important enough to justify intervention?
2. Is the process understood and sufficiently stable?
3. Is relevant data available, lawful to use, and of adequate quality?
4. Does the problem require learning, prediction, language understanding, perception, or adaptive decision support?
5. Could deterministic rules, conventional software, search, workflow automation, or process redesign solve it more reliably?
6. What happens when the AI system is wrong, uncertain, unavailable, or manipulated?
7. Can a human review or override the outcome where necessary?
8. Can the organization measure whether the intervention improves the business outcome?

A deterministic rule is often preferable when the decision is fully specified, stable, and auditable. An LLM should not be introduced merely to replace a straightforward rule engine.

5.3 Form a Value Hypothesis

A value hypothesis explains how an AI intervention should change a business measure, and under which conditions.

Template

For [user, customer, or process], introduce [AI-enabled capability] into [workflow or decision] to improve [business metric] from [baseline] toward [target], subject to [quality, risk, and operational constraints]. The hypothesis will be tested through [measurement method].

Example

For claims operations, introduce document classification and extraction at intake to reduce manual triage effort and rework, while maintaining agreed extraction accuracy, auditability, and human review for low-confidence or high-impact cases. Measure the change using handling time, rework rate, exception rate, and cost per claim.

Treat untested value hypotheses as hypotheses, not guaranteed benefits.

Key Takeaways — Part II

• Express objectives as measurable outcomes with baselines, targets, guardrails, and owners.
• Build an outcome hierarchy so every AI contribution traces to an enterprise objective.
• Always ask whether a simpler, non-AI intervention would work better.
• Write value hypotheses and treat them as testable claims.

---

Part III. Build and Prioritize the Opportunity Portfolio

In this part: how to inventory opportunities, prioritize them transparently, and reason about them as a portfolio rather than in isolation.

6. Create a Structured Opportunity Inventory

The opportunity inventory connects business outcomes to technology capabilities. It should span relevant domains while supporting consistent comparison.

Field	Description
Opportunity ID and name	Unique identifier and concise title
Business domain	Function, product, journey, or process
Business owner	Person accountable for the business outcome
Problem statement	Current friction, loss, delay, risk, or unmet need
Target users	Customers, employees, partners, or systems affected
Outcome linkage	Enterprise objective and measurable business KPI
Proposed AI contribution	Prediction, classification, generation, retrieval, agentic execution, etc.
Process impact	Steps changed, removed, augmented, or introduced
Data requirements	Sources, sensitivity, quality, access, ownership, freshness
Integration requirements	Applications, APIs, events, workflow systems
Risk profile	Potential harm, regulatory exposure, security and privacy concerns
Feasibility	Technical and organizational readiness
Value hypothesis	Expected benefit and assumptions
Dependencies	Shared data, platform, policy, or process prerequisites
Evidence status	Idea, assessed, tested, validated, or production-proven

Keep the opportunity distinct from its proposed solution. Understand the problem and constraints before selecting technology.

7. Prioritize Opportunities Transparently

Prioritization balances value, strategic relevance, feasibility, risk, and dependencies. Not every opportunity should proceed.

7.1 Suggested Assessment Dimensions

Dimension	Questions
Strategic alignment	Does it directly support a stated business objective?
Economic value	What measurable financial or productivity benefit is plausible?
Customer or employee impact	Does it improve experience, access, quality, or time?
Feasibility	Are data, technology, process, and skills sufficiently ready?
Time to evidence	How quickly can the hypothesis be tested credibly?
Reusability	Will it create capabilities useful to other domains?
Risk and consequence	What is the impact of incorrect, biased, unsafe, or unauthorized output?
Change complexity	How much process, policy, training, and behavior change is required?
Dependency value	Does it unlock several higher-value opportunities?

7.2 Use Scoring as Decision Support, Not as an Automatic Answer

A weighted model exposes assumptions. An illustrative weighting:

Dimension	Illustrative weight
Business value	25%
Strategic alignment	20%
Feasibility and readiness	15%
Reusability and strategic leverage	15%
Time to evidence	10%
Risk manageability	10%
Change complexity	5%
Total	100%

Use a defined scale (for example, 1–5) with agreed scoring guidance. A higher risk score should indicate more manageable risk.

Scoring supports judgment; it does not replace it. Legal restrictions, unacceptable harm, unlawful data access, or inadequate human oversight can disqualify an otherwise high-value use case.

7.3 Classify the Portfolio

Class	Description
Strategic bets	High business relevance, potentially transformative, often requiring foundational investment
Near-term value	Strong value hypothesis and a manageable implementation path
Enabling investments	Shared data, platform, governance, identity, integration, or engineering capabilities that unlock multiple use cases
Experiments	Bounded tests designed to resolve a material uncertainty
Defer or reject	Low value, poor fit, unacceptable risk, or insufficient evidence

Do not run pilots for activity's sake. Each experiment needs a specific question and explicit success, failure, and stop criteria.

Engineering lens. An experiment should look like a well-formed A/B test or a design spike: a hypothesis, a metric, a sample that represents production, a time box, and a pre-agreed decision rule.

8. Consider the Portfolio, Not Just Individual Use Cases

Optimizing use cases independently can duplicate platforms, fragment data access, weaken control consistency, and increase operating cost.

Assess the portfolio for:

• common data sources and data products;
• repeated model or embedding requirements;
• shared retrieval and knowledge needs;
• common identity, authorization, and audit requirements;
• reusable workflow and agent capabilities;
• common evaluation datasets and quality measures;
• integration patterns and application boundaries;
• infrastructure, capacity, and cost constraints;
• concentration risk from vendors or foundation-model providers.

Portfolio analysis shows where shared capabilities are justified economically and architecturally.

Key Takeaways — Part III

• Describe opportunities as business problems, separately from proposed solutions.
• Make prioritization criteria and weights explicit, and allow judgment to override scores.
• Classify the portfolio into bets, near-term value, enablers, experiments, and deferrals.
• Look across use cases to find shared capabilities worth funding once.

---

Part IV. Assess the Current State

In this part: how to establish an evidence-based baseline, surface constraints and architectural debt, and define capability gaps.

9. Establish an Evidence-Based Baseline

Base the roadmap on the organization's evidenced position, not an assumed maturity level. Assess current capabilities across business, data, applications, infrastructure, AI engineering, governance, people, and operations, using interviews, architecture reviews, inventories, data profiling, risk assessments, and evidence from existing initiatives.

9.1 Current-State Assessment Domains

Domain	Assessment questions	Evidence to collect
Business and process	Are target processes documented, measured, and owned?	Process maps, KPIs, operating procedures
Data	Are data sources discoverable, governed, accessible, and fit for use?	Catalogues, lineage, quality reports, access controls
Applications and integration	Can AI capabilities be safely embedded into workflows?	Application maps, APIs, event patterns, interface contracts
Cloud and infrastructure	Can the estate support required performance, scale, resilience, and deployment constraints?	Landing zones, network design, compute, storage, resilience patterns
AI and ML	Are models, datasets, features, and model lifecycle practices established?	Model inventory, experiments, registries, validation records
GenAI and agentic systems	Are retrieval, prompting, tool access, evaluation, and runtime controls mature?	RAG designs, model gateways, tool policies, traces, evaluation results
Security and privacy	Are data, identities, models, and actions protected?	Threat models, IAM policies, privacy assessments, security testing
Governance and compliance	Are accountability, approval, documentation, and monitoring defined?	Policies, risk registers, audit findings, control evidence
Engineering and operations	Can teams build, test, deploy, observe, and support AI systems?	CI/CD, test suites, SLOs, incident records, runbooks
People and organization	Are roles, skills, decision rights, and capacity sufficient?	Skills inventory, team structure, training plans
Procurement and vendors	Are suppliers, contracts, data terms, and exit options understood?	Contracts, service terms, due diligence, vendor assessments
Economics	Are costs and benefits measurable across the lifecycle?	Cloud bills, licences, unit costs, budgets, benefit reports

9.2 Assess Maturity Without Creating False Precision

Level	Name	Description
1	Ad hoc	Activity is isolated, informal, person-dependent, and inconsistently controlled
2	Emerging	Repeatable practices exist in some teams, but standards and ownership are inconsistent
3	Defined	Documented standards, accountable owners, and repeatable processes are established
4	Managed	Performance, quality, risk, cost, and adoption are measured and actively managed
5	Optimized	Capabilities are continuously improved using evidence, automation, and portfolio-level learning

Rate each domain separately and support every score with evidence and a confidence level. An organization may be mature in cloud engineering yet immature in data governance or AI evaluation.

10. Identify Constraints and Architectural Debt

Typical constraints include:

• fragmented or poorly governed data;
• unclear data ownership and access rights;
• legacy applications with limited integration options;
• inconsistent identity and authorization models;
• multiple uncoordinated cloud environments;
• lack of model evaluation and production monitoring;
• duplicated experimentation platforms;
• weak software delivery or testing practices;
• limited AI security expertise;
• procurement restrictions or vendor lock-in;
• insufficient operational ownership;
• regulatory or contractual restrictions on data and model use.

Record each constraint's evidence, impact, affected opportunities, and remediation. Separate genuine blockers from preferences and untested assumptions.

Engineering lens. ML systems accumulate a distinctive form of technical debt: entangled data dependencies, undeclared consumers of model outputs, unversioned prompts and configurations, and glue code around models. Include these explicitly in the debt register (see Appendix D).

11. Define the Gap Between Current and Required Capability

A capability gap is the difference between the current state and what the portfolio and target architecture require.

Figure 3. Deriving capability gaps from current-state evidence and target outcomes.

A useful gap record includes:

Field	Description
Capability	The capability that is missing or insufficient
Current condition	What exists today, supported by evidence
Required condition	What the target state needs
Gap	The specific shortfall
Business impact	Which outcomes or opportunities are affected
Risk of inaction	Consequence of leaving the gap unresolved
Options	Build, buy, partner, reuse, redesign, or defer
Dependencies	Other capabilities or decisions required
Priority	Relative urgency and strategic importance

Key Takeaways — Part IV

• Score maturity per domain, with evidence and confidence, never as a single number.
• Distinguish true blockers from preferences and untested assumptions.
• Gaps are defined against the required capability, not against an abstract maturity ideal.

---

Part V. Define the Target Capabilities and Architecture

In this part: the capability model, target-state architecture, technology strategy by AI family, sourcing decisions, and platform boundaries.

12. Define the Target Capability Model

Define required capabilities independently of vendors and products so the roadmap remains durable as technology changes.

Capability area	Capabilities to consider
Business enablement	Opportunity discovery, process redesign, product integration, value measurement
Data foundation	Data ingestion, quality, cataloguing, lineage, access, governance, feature management
Knowledge foundation	Content ingestion, parsing, chunking, metadata, indexing, retrieval, source authority and freshness
Model capability	Model selection, training or fine-tuning where justified, evaluation, registry, versioning
AI application engineering	Prompt and context design, application orchestration, API integration, user experience
Agentic execution	Planning, task decomposition, tool invocation, workflow state, approvals, action boundaries
AI platform	Model access, gateways, reusable services, deployment environments, tenancy, quotas
Runtime and infrastructure	Compute, storage, networking, accelerators, scaling, resilience, deployment topology
Trust and governance	Identity, authorization, privacy, security, safety, audit, policy enforcement, human oversight
Quality and observability	Evaluation, tracing, monitoring, drift, incident response, feedback
Economics and FinOps	Cost attribution, budgets, usage controls, model routing, capacity and unit economics
People and operating model	Product ownership, architecture, engineering, risk, operations, support, training

This is a reference model, not a mandate for centralization. Select capabilities according to portfolio needs and risk.

13. Define the Target-State Architecture

The target-state architecture shows how business applications, AI services, data, infrastructure, and controls fit together. Make it concrete enough to guide technology decisions, but avoid turning it into a low-level design for every use case.

13.1 A Conceptual Enterprise AI Architecture

Figure 4. A conceptual enterprise AI architecture. Adapt it to combine, split, or distribute capabilities.

Governance, security, identity, evaluation, and observability must cut across layers. They cannot sit only at the bottom of the stack.

13.2 Define Architectural Principles

Principles provide decision guidance when teams face competing implementation options. Illustrative principles:

#	Principle	Intent
1	Business outcome first	Every material AI investment traces to an approved business outcome or a justified enabling capability
2	Simplest sufficient technique	Prefer deterministic software, rules, search, or conventional ML when they meet the need more reliably and economically
3	Data and access are inseparable	Retrieval and model context respect source permissions, classification, purpose, and retention
4	Secure by design	Identity, authorization, privacy, threat modelling, and auditability are built in
5	Risk-proportionate human oversight	Consequential decisions and actions require controls appropriate to their impact
6	Reusable where justified	Shared services reduce duplication without creating unnecessary central bottlenecks
7	Model and provider flexibility	Avoid unnecessary coupling to a single model or provider where portability has material strategic value
8	Observable by default	Systems expose quality, latency, cost, reliability, and relevant decision traces
9	Production readiness designed in	Evaluation, testing, deployment, rollback, support, and incident response are considered from the start
10	Explicit tenant and domain boundaries	Data isolation, authorization, quotas, and operational ownership match the organization's tenancy model
11	Cost is an architectural concern	Optimize lifecycle cost and cost per successful business task, not only the price of a model call
12	Controlled autonomy	Agentic systems receive only the tools, permissions, and action scope necessary for their purpose

Make each principle testable by documenting its rationale, implications, and conformance criteria.

Engineering lens. Express principles the way mature platform teams express "paved road" expectations: a default that is easy to follow, a clear rationale, and a documented exception process.

14. Determine the AI Technology Strategy

Technology strategy defines the technology categories and sourcing approaches needed to realize the target architecture.

14.1 Traditional ML and Predictive Systems

Consider:

• data and feature pipelines;
• experimentation and training environments;
• model validation and approval;
• model registry and versioning;
• online and batch inference;
• feature freshness and drift monitoring;
• explainability appropriate to the use case;
• integration with decision and workflow systems.

Do not assume every predictive problem requires deep learning. Model complexity should be justified by measurable performance, robustness, maintainability, and cost.

14.2 Generative AI and Foundation Models

Consider:

• managed model APIs versus self-hosted models;
• model capability, quality, latency, context limits, and availability;
• model routing and fallback;
• prompt and context management;
• structured output and schema validation;
• grounding and source attribution;
• safety and policy enforcement;
• model evaluation and regression testing;
• token usage, caching, quotas, and cost attribution.

Select models using representative tasks and explicit evaluation criteria, not public benchmarks or demonstrations alone.

14.3 Retrieval-Augmented Generation and Enterprise Knowledge

Consider:

• authoritative source systems and content ownership;
• ingestion and change detection;
• parsing and structure-aware chunking;
• metadata and access-control propagation;
• embedding and indexing;
• lexical, vector, and hybrid retrieval;
• reranking and context selection;
• freshness, deletion, and retention;
• citation and provenance;
• retrieval and answer evaluation.

Semantic similarity alone does not make retrieval trustworthy. Relevance, authority, freshness, sufficiency, permissions, and source quality all matter.

14.4 Agentic AI

Consider agentic architecture only where a workflow benefits from model-mediated planning, tool use, dynamic task coordination, or controlled action execution. Required capabilities may include:

• agent or workflow definitions and versioning;
• task and state management;
• tool and API catalogues;
• identity and delegated authorization;
• policy checks before tool execution;
• input and output validation;
• approval and escalation paths;
• bounded retries, timeouts, and budgets;
• durable execution and idempotency;
• traceability and audit;
• evaluation of task completion and action correctness;
• isolation and containment of runtime execution.

Multi-agent design is not inherently better than deterministic workflow. Choose the least complex architecture that meets business and control requirements.

15. Make Build, Buy, Partner, and Reuse Decisions

Neither building everything nor outsourcing every capability is a sound default. Evaluate sourcing at the capability level.

Option	Appropriate when	Key considerations
Build	The capability is differentiating, requires deep control, or is not adequately served by the market	Engineering cost, ownership, maintenance, security, talent
Buy	A mature product meets requirements with acceptable integration and risk	Product fit, vendor viability, contract terms, data handling, portability
Partner	Specialized expertise or delivery capacity is needed	Knowledge transfer, accountability, dependency, quality
Reuse	An existing enterprise capability meets the need	Fitness for purpose, service ownership, capacity, roadmap alignment
Compose	Multiple managed and internal capabilities must be combined	Integration complexity, failure modes, observability, end-to-end accountability

For each material decision, document:

• business and technical requirements;
• options considered;
• evaluation criteria;
• assumptions and evidence;
• security, privacy, legal, and operational implications;
• total cost of ownership;
• portability and exit strategy;
• selected option and rationale;
• decision owner and review trigger.

16. Define Platform Boundaries and Centralization Choices

An important enterprise decision is the degree of AI centralization.

Model	Strengths	Risks
Centralized platform	Approved model access, common identity and policy controls, reusable retrieval/evaluation/observability services, cost attribution, standard deployment patterns, common audit	Bottlenecks, over-standardization, poor domain fit
Federated (domain-led)	Domain fit and speed within enterprise standards	Duplication, inconsistent controls, procurement fragmentation, uneven maturity
Hybrid	Shared enterprise foundation with domain-owned applications and selected domain services	Requires clear interfaces, standards, and funding models

A common pattern is the hybrid model. The roadmap should decide:

• which capabilities must be centrally controlled;
• which should be shared services;
• which can be owned by domains;
• what standards and interfaces make the model coherent;
• how platform funding and service ownership work.

Centralize only when it delivers measurable enterprise benefit.

Engineering lens. This is the platform-engineering question: treat the shared AI platform as a product with internal customers, a roadmap, service-level objectives, and a feedback loop with the domain teams that consume it.

Key Takeaways — Part V

• Define capabilities independent of vendors; evaluate products against them.
• Make architectural principles testable, with conformance criteria and an exception path.
• Match technology strategy to the AI family: predictive, generative, retrieval, and agentic systems each have distinct requirements.
• Decide sourcing per capability, and plan the exit before you commit.
• Prefer a hybrid platform model: shared foundations, domain-owned applications.

---

Part VI. Define Trust, Governance, and Operating Requirements

In this part: how to turn risk and governance obligations into architectural requirements and a credible operating model.

17. Treat Trust and Governance as Architectural Requirements

AI risk extends beyond model accuracy to data misuse, unauthorized access, harmful output, automation errors, prompt injection, supply-chain exposure, opaque decisions, and uncontrolled actions. Governance requirements should shape architecture and investment from the beginning.

17.1 Establish an AI System Risk Classification

Classify AI systems using factors such as:

• decision impact on individuals or business outcomes;
• sensitivity of input and output data;
• degree of autonomy and action authority;
• scale and reversibility of potential harm;
• regulatory and contractual obligations;
• external exposure and threat surface;
• reliance on third-party models and services.

The classification should determine the level of review, testing, approval, monitoring, documentation, and human oversight required.

17.2 Define Cross-Cutting Controls

Control area	Roadmap questions
Identity and access	How are users, services, agents, and tools authenticated and authorized?
Data protection	How are sensitive data, retention, residency, and purpose limitations enforced?
Model governance	How are models assessed, approved, versioned, monitored, and retired?
Safety and policy	How are prohibited or constrained outputs and actions detected and handled?
Human oversight	Which actions require review, confirmation, or escalation?
Auditability	Can the organization reconstruct inputs, model versions, retrieved sources, tool calls, approvals, and outcomes?
Security	How are prompt injection, data exfiltration, insecure tools, supply-chain risks, and abuse addressed?
Resilience	What happens when a model, provider, retrieval service, or dependent system fails?
Compliance	How are applicable laws, standards, contracts, and internal policies translated into controls?

17.3 Distinguish Answer Generation from Authority to Act

A system that generates a recommendation does not automatically have authority to execute it. For agentic systems, explicitly separate:

1. the model's ability to propose an action;
2. the application's authority to request an action;
3. the identity and permissions under which the action executes;
4. the policy decision that permits or rejects it;
5. any human approval requirement;
6. the system that records and verifies the result.

Figure 5. Separating proposal, request, authorization, execution, and verification for agentic actions.

This separation is essential for safe enterprise automation.

Engineering lens. Apply least privilege and defense in depth exactly as you would for any service that can mutate production state. Treat model output as untrusted input to the next system, validate it, and make every action reversible or approval-gated in proportion to its blast radius.

18. Define the Operating Capabilities the Roadmap Must Enable

Although this guide addresses roadmap definition, the target state must include a credible operating model. Determine:

• who owns business outcomes and AI products;
• who owns shared AI platform services;
• who approves models and high-risk use cases;
• who owns data quality and access;
• who is accountable for security and privacy controls;
• who operates production services and responds to incidents;
• who manages vendor relationships and technology standards;
• how architecture exceptions are reviewed;
• how model, prompt, retrieval, and agent changes are approved;
• how business feedback drives continuous improvement.

A responsibility model should clarify decision rights, not merely list committees.

Key Takeaways — Part VI

• Classify AI systems by risk and scale controls to the class.
• Distinguish a model's ability to propose from the authority to act.
• Design the operating model, including change control for prompts, retrieval, and agents, as part of the target state.

---

Part VII. Evaluate Economics and Investment

In this part: how to model lifecycle cost and benefit, and how to use unit economics to keep the roadmap honest.

19. Build a Lifecycle Economic View

Evaluate AI economics across design, development, deployment, operation, and change. Prototype costs can understate production costs once usage, context, retrieval, evaluation, support, and resilience are included.

19.1 Cost Categories

Cost category	Examples
Data	Integration, cleansing, labelling, storage, cataloguing, governance
Platform	Cloud services, networking, storage, compute, accelerators
Models	API usage, hosting, fine-tuning, embeddings, reranking
Engineering	Product, data, ML, platform, security, architecture teams
Integration	APIs, workflow changes, application modernization
Risk and assurance	Security testing, privacy reviews, validation, audit
Operations	Monitoring, support, incident response, reliability engineering
Adoption	Training, process redesign, change management
Vendor and procurement	Licences, support, professional services, contractual commitments

19.2 Estimate Value Conservatively

Potential benefits include reduced manual effort, lower error and rework rates, faster cycle times, improved conversion or retention, lower fraud or loss, improved quality and consistency, increased capacity without proportional headcount growth, and improved employee or customer experience.

Separate the following benefit types:

Benefit type	Meaning
Cashable savings	Expenditure removed or avoided
Released capacity	Time available for other work
Revenue impact	Incremental revenue attributable to the capability
Risk reduction	Lower expected loss or exposure
Strategic option value	Future choices without a defensible near-term financial estimate

Do not count released employee time as cash savings unless the operating plan specifies how that capacity will be converted into financial benefit.

19.3 Use Unit Economics

Aggregate cost can conceal poor economics. Define a unit that reflects the business task, for example:

• cost per successfully processed claim;
• cost per resolved customer interaction;
• cost per validated document;
• cost per completed research task;
• cost per qualified lead;
• cost per successful agentic workflow.

Cost per successful task =
    Total attributable AI system cost
    / Number of successfully completed tasks

Define "success," the included costs, and the measurement period. Include material human-review and exception costs.

Engineering lens. This is the AI counterpart to cost-per-request and cost-per-transaction in conventional services. Attribute cost by workload and team, set budgets and alerts, and review unit cost alongside latency and quality in operational reviews.

19.4 Compare Options Using Total Cost of Ownership

For each major platform or sourcing decision, estimate:

• initial implementation cost;
• recurring infrastructure and model cost;
• licensing and support;
• integration and migration;
• security and compliance;
• staffing and operations;
• scaling and capacity;
• exit, portability, and replacement cost.

Use ranges and explicit assumptions. Transparent uncertainty is better than false precision.

Key Takeaways — Part VII

• Model cost across the full lifecycle, not just model API fees.
• Distinguish cashable savings from released capacity.
• Use cost per successful task as the anchor metric, and include human-review cost.
• Present ranges and assumptions rather than single-point estimates.

---

Part VIII. Sequence the Roadmap

In this part: how to turn gaps into initiatives, sequence them, express horizons honestly, and make uncertainty visible.

20. Convert Capability Gaps into Roadmap Initiatives

A roadmap initiative is a coherent body of work to establish, improve, or retire a capability, or to deliver a business outcome. Examples:

• establish governed enterprise model access;
• implement identity-aware knowledge retrieval;
• create a model evaluation and release framework;
• modernize a source application to expose secure APIs;
• deliver a predictive fraud-detection capability;
• introduce a controlled agent runtime for selected workflows;
• establish cost attribution for AI workloads.

Each initiative should have:

• a clear outcome or capability objective;
• an accountable owner;
• scope and boundaries;
• measurable acceptance criteria;
• dependencies;
• indicative effort and cost range;
• risk and assurance requirements;
• target horizon;
• assumptions and confidence;
• a decision gate or review point.

Avoid initiatives such as "implement AI" or "adopt an LLM." They are too unbounded to guide investment or architecture.

21. Sequence by Value, Dependency, Risk, and Readiness

The highest-value use case is not always the first priority. A foundational capability may unlock several opportunities while reducing future cost and risk. Consider four sequencing forces:

Force	Question
Value	How much business benefit can be realized, and how soon?
Dependency	What must exist before the initiative can succeed?
Readiness	Are data, process, technology, people, and controls sufficiently prepared?
Risk	What must be validated or controlled before broader deployment?

A dependency example:

Figure 6. An illustrative dependency chain for enterprise knowledge assistance.

This sequence is illustrative. Activities may run in parallel, and bounded pilots can test assumptions before all foundations are complete. Distinguish experimentation from production-scale commitment.

22. Use Horizons Without Turning Them into Arbitrary Dates

Horizon	Primary intent	Typical initiative types
H1 — Establish	Prove priority value and address essential foundations	Current-state remediation, initial use cases, governance baseline, platform decisions
H2 — Scale	Reuse capabilities across domains and improve operational maturity	Shared services, domain expansion, standard evaluation, integration patterns
H3 — Transform	Enable broader process and product transformation where evidence supports it	Advanced decision systems, controlled agentic workflows, new AI-enabled products

For each horizon, show intended business outcomes, capabilities to establish, initiatives and major milestones, dependencies, investment envelope, key risks, decision gates, and the evidence required to move to the next horizon.

Avoid implying that every initiative in a distant horizon is an approved commitment. Label items as options, directional intent, or conditional investments where appropriate.

23. Represent Uncertainty Explicitly

Because business and technology assumptions change, distinguish commitment levels.

Commitment class	Meaning
Approved	Funding and sponsorship are authorized, subject to stated controls
Planned	Intended for a defined horizon, but not necessarily fully funded
Conditional	Proceeds only if specified evidence, dependencies, or conditions are met
Exploratory	A bounded investigation to reduce uncertainty
Deferred	Deliberately postponed pending a trigger or prerequisite
Rejected	Not pursued, with rationale recorded

Record the assumptions that would change a roadmap item, such as model quality thresholds, data access approval, regulatory interpretation, vendor capability, unit economics, and adoption evidence.

Key Takeaways — Part VIII

• Initiatives must be bounded, owned, measurable, and gated.
• Sequence by value, dependency, readiness, and risk; foundations often precede the highest-value use case.
• Use horizons for intent, not as dates the organization is falsely committed to.
• Label every item with a commitment class.

---

Part IX. Make Technology Decisions Defensible

In this part: how to record decisions, evaluate candidates against representative workloads, and set non-functional requirements early.

24. Establish a Decision Framework

A consistent decision framework makes interdependent choices comparable and reviewable. For each significant decision, record:

1. Decision statement: what exactly must be decided?
2. Business driver: which outcome or constraint makes the decision necessary?
3. Requirements: functional, non-functional, security, regulatory, and operational.
4. Options: credible alternatives, including doing nothing or deferring.
5. Evaluation criteria: quality, latency, scale, resilience, cost, integration, portability, support, risk.
6. Evidence: tests, benchmarks, vendor assessments, architecture analysis, stakeholder input.
7. Trade-offs: what is gained, what is sacrificed, and what new risks are introduced.
8. Decision: the selected option and rationale.
9. Consequences: required changes, dependencies, and constraints.
10. Review trigger: conditions that would justify revisiting the decision.

Maintain these as architecture decision records (ADRs) or an equivalent decision register.

25. Evaluate Models and Platforms Against Representative Workloads

Do not select models, vector databases, agent frameworks, or serving platforms from feature checklists alone. Create representative workload tests reflecting:

• real input distributions;
• expected context lengths;
• language and domain requirements;
• retrieval corpus characteristics;
• concurrency and traffic patterns;
• output format and tool-use requirements;
• security and access constraints;
• acceptable latency and availability;
• evaluation criteria and failure costs.

Measure quality, latency, throughput, cost, reliability, operational effort, and failure behavior. Generic benchmark strength does not guarantee domain performance.

25.1 Treat Evaluation as a First-Class Capability

The most durable asset in a technology evaluation is often the evaluation harness itself. Plan for:

Element	Purpose
Golden datasets	Curated, representative, versioned examples with agreed expected behavior
Offline evaluation	Repeatable comparison of candidates before release
Regression gates	Automatic checks that block changes degrading quality, safety, latency, or cost
Online evaluation	Controlled experiments and shadow or canary traffic to validate in production conditions
Human review	Calibrated expert grading where automated judgment is insufficient
Failure taxonomy	A shared classification of error types to focus improvement

Automated graders, including model-based graders, should themselves be validated against human judgment before being trusted as release gates.

Engineering lens. Evaluation-driven development is the AI analogue of test-driven development and continuous integration: changes to models, prompts, retrieval configuration, and tools are evaluated on every change, and a failing evaluation blocks the release as a failing test would.

26. Define Non-Functional Requirements Early

Quality attribute	Questions
Availability	What service availability is required, and during which business periods?
Latency	What end-to-end response time is acceptable for each workflow?
Throughput	What are expected average, peak, and burst workloads?
Scalability	How should capacity respond to growth and concurrency?
Resilience	How does the system degrade or recover when a dependency fails?
Security	What threat model, trust boundaries, and authorization rules apply?
Privacy	What data may be processed, retained, or transferred, and under what conditions?
Explainability and traceability	What evidence is needed to understand or challenge an output?
Maintainability	How can models, prompts, retrieval, tools, and application logic be changed safely?
Portability	What degree of provider, model, or platform substitution is strategically necessary?
Cost efficiency	What unit economics and budget limits must be met?
Accessibility and usability	Can intended users understand, use, and appropriately challenge the system?

Set requirements by workload and risk class, not uniformly across applications.

Key Takeaways — Part IX

• Record significant decisions with options, criteria, evidence, and review triggers.
• Test candidates on representative workloads, and invest in a reusable evaluation harness.
• Define quality attributes per workload and risk class before selecting technology.

---

Part X. Govern the Roadmap as a Portfolio

In this part: ownership, decision rights, governance mechanisms, and the measures that keep the roadmap accountable.

27. Establish Ownership and Decision Rights

A roadmap needs named, accountable owners. Committees cannot replace them.

Role	Primary accountability in roadmap definition
Executive sponsor	Confirms strategic intent, resolves major trade-offs, sponsors investment
Business outcome owner	Defines the business problem, target measures, process impact, and adoption
AI or technology strategy leader	Connects AI ambition to enterprise capability and investment direction
Principal AI Architect / Enterprise Architect	Defines target architecture, principles, standards, dependencies, and technology options
Data leader	Assesses data readiness, ownership, quality, access, and data investment
Security and privacy leaders	Define risk requirements, controls, and assurance expectations
Risk, legal, and compliance leaders	Interpret obligations and review higher-risk use cases
Engineering and platform leaders	Assess feasibility, delivery capacity, platform needs, and operational readiness
Finance and procurement	Validate investment assumptions, sourcing options, and commercial constraints
Product and change leaders	Assess user needs, workflow redesign, adoption, and value realization

Titles and reporting lines vary. Accountability for business outcomes, architecture, data, risk, engineering, and investment must not.

28. Define Roadmap Governance

Governance must answer:

• Who can propose an initiative?
• Who validates the business case?
• Who approves architecture and technology standards?
• Who classifies AI risk?
• Who approves data use and model deployment?
• Who authorizes investment?
• Who can accept an exception?
• Who can stop or defer an initiative?
• How are dependencies and conflicts resolved?
• How are roadmap changes communicated?

Scale governance to impact. A low-risk experiment does not need the same approvals as a system making consequential decisions or taking external actions.

29. Define Portfolio-Level Measures

Manage the roadmap through a balanced set of measures.

Dimension	Example measures
Strategic alignment	Share of investment mapped to approved business objectives
Business value	Validated benefit, value realized, outcome attainment
Portfolio health	Initiative status, dependency health, decision latency
Capability maturity	Progress against defined capability gaps
Reuse	Adoption of shared capabilities, reduction in duplicated services
Technology quality	Reliability, latency, quality, scalability
AI quality	Task success, groundedness, error and escalation rates
Risk and control	Control coverage, unresolved high risks, incidents, audit findings
Economics	Total cost, cost per successful task, budget variance
Adoption	Active usage, workflow adoption, user confidence, override patterns

Separate leading from lagging indicators:

• Leading: data readiness, platform availability, evaluation coverage, user adoption.
• Lagging: cost reduction, revenue impact, lower losses, improved customer outcomes.

Technical milestones do not guarantee business value. Measure both.

Key Takeaways — Part X

• Name accountable owners; do not substitute committees.
• Scale governance to risk and impact.
• Balance leading and lagging indicators, and measure outcomes, not activity.

---

Part XI. The End-to-End Method

30. A Practical Roadmap-Definition Lifecycle

Use this lifecycle to define an enterprise AI technology roadmap. Activities may overlap, but the sequence provides a logical progression.

Figure 7. The eleven-step roadmap-definition lifecycle.

Step 1 — Establish Mandate and Scope

• Activities: confirm executive sponsorship and business drivers; define organizational and technology boundaries; agree planning horizon and decision authority; identify stakeholders and source documents.
• Outputs: roadmap charter; scope and assumptions; stakeholder and decision-rights map.

Step 2 — Understand Business Strategy and Outcomes

• Activities: review strategy and operating plans; interview business leaders; identify target processes and performance gaps; translate goals into measurable outcomes.
• Outputs: business outcome map; KPI baseline and target register; strategic constraints.

Step 3 — Discover and Assess AI Opportunities

• Activities: conduct domain workshops; identify candidate AI contributions; challenge whether AI is the right intervention; form value hypotheses and identify risk.
• Outputs: AI opportunity inventory; initial value hypotheses; early risk and feasibility assessment.

Step 4 — Prioritize the Opportunity Portfolio

• Activities: apply agreed criteria; compare value, feasibility, risk, readiness, and dependencies; identify bets, near-term opportunities, enablers, and experiments; record deferred and rejected items.
• Outputs: prioritized AI portfolio; portfolio rationale; experiment and decision backlog.

Step 5 — Assess Current-State Capabilities

• Activities: review business processes, data, applications, cloud, AI, security, governance, skills, and operations; inspect existing pilots and production systems; identify constraints; rate maturity using evidence.
• Outputs: current-state capability assessment; architecture and technology baseline; constraint and risk register.

Step 6 — Define Target Capabilities and Architecture

• Activities: derive capabilities from the prioritized portfolio; define target-state architecture and principles; establish platform boundaries and shared-service candidates; define non-functional and control requirements.
• Outputs: target capability model; architecture views; principles and standards; non-functional requirements.

Step 7 — Evaluate Technology and Sourcing Options

• Activities: identify viable technology categories and sourcing options; benchmark representative workloads; assess build, buy, partner, reuse, and compose alternatives; document trade-offs and decisions.
• Outputs: technology strategy; option assessments and ADRs; vendor and platform decision criteria.

Step 8 — Establish the Capability Gap and Investment View

• Activities: compare current and target capabilities; define initiatives to close material gaps; estimate lifecycle costs and potential benefits; identify skills, operating model, and change requirements.
• Outputs: capability gap register; investment options and cost ranges; resource and sourcing implications.

Step 9 — Sequence and Construct the Roadmap

• Activities: map dependencies; balance quick evidence, foundational work, and strategic investments; assign horizons and decision gates; label commitment levels and uncertainty.
• Outputs: time-phased roadmap; dependency map; investment and milestone view; assumptions and trigger register.

Step 10 — Validate and Obtain Decisions

• Activities: review with business, architecture, engineering, data, security, risk, finance, and operations; test feasibility and economic assumptions; resolve conflicts and record exceptions; obtain sponsorship and investment decisions.
• Outputs: validated roadmap; decision log; approved, conditional, exploratory, and deferred portfolio.

Step 11 — Establish Review and Refresh Mechanisms

• Activities: set review cadence and ownership; define trigger events for reassessment; track outcomes and changing assumptions; feed execution evidence back into roadmap decisions.
• Outputs: roadmap governance process; review calendar; KPI and portfolio reporting model.

---

Part XII. Worked Example

31. Defining a Roadmap for a Financial Services Enterprise

This example is illustrative. It demonstrates a reasoning process, not a universal financial-services architecture.

31.1 Business Context

Assume the enterprise has identified four objectives:

1. Reduce the cost and cycle time of claims administration.
2. Improve fraud detection and investigation effectiveness.
3. Improve customer-service resolution.
4. Strengthen information governance and auditability.

31.2 Translate Objectives into Candidate Opportunities

Business objective	Candidate opportunity	Potential AI contribution	Important constraints
Reduce claims cost	Automate document intake and triage	Document intelligence, classification, extraction	Accuracy, exceptions, source quality, human review
Reduce fraud losses	Prioritize suspicious claims	Predictive ML, anomaly detection, network analysis	Label quality, explainability, false positives
Improve service resolution	Assist service representatives	RAG, summarization, workflow assistance	Permission-aware retrieval, grounded answers
Strengthen governance	Improve policy and procedure discovery	Enterprise search and RAG	Authority, freshness, access control, audit

31.3 Assess Shared Capability Needs

The opportunities reveal shared requirements:

• governed access to enterprise data and documents;
• reliable identity and authorization;
• document ingestion and metadata;
• model access and evaluation;
• application and workflow integration;
• observability and audit;
• human review and exception handling;
• cost attribution and operational ownership.

These are potential roadmap enablers. Validate them against the current estate before funding.

31.4 Define Target Capabilities

Capability	Target condition
Data governance	Named data owners, classification, quality controls, lineage, approved access
Document intelligence	Reusable ingestion, extraction, classification, validation, exception handling
Predictive ML	Repeatable training, validation, deployment, monitoring, and review
Enterprise knowledge	Governed content ingestion, permission-aware retrieval, source attribution
Model services	Approved model access, versioning, evaluation, routing, usage controls
Workflow integration	Secure APIs and event-driven integration with claims and service applications
Trust controls	Identity, policy enforcement, human oversight, audit, security testing
AI operations	Monitoring for quality, reliability, latency, incidents, and cost

31.5 Construct an Illustrative Roadmap

Horizon	Initiatives	Intended outcome
Establish	Confirm data ownership; assess claims and service processes; define AI risk classification; establish approved model access; validate document-intake opportunity	Reduce uncertainty and establish minimum viable foundations
Scale	Build reusable document ingestion and evaluation; deploy selected claims triage capability; establish governed enterprise retrieval; integrate service-assistance workflow	Deliver measurable domain value and reusable services
Transform	Expand validated capabilities across eligible processes; introduce controlled workflow agents where justified; optimize model routing and unit economics	Broader transformation with managed risk and cost

Adjust the sequence when evidence shows that data access, integration, or another constraint is a greater blocker than model availability.

31.6 Define Decision Gates

• Do not scale document extraction until accuracy and exception-handling thresholds are met on representative documents.
• Do not deploy knowledge assistance broadly until retrieval respects source permissions and answer quality is evaluated.
• Do not permit an agent to execute a consequential action until identity, authorization, policy, approval, idempotency, and audit controls are validated.
• Do not expand a workload until its cost per successful task is within an approved range.

These gates make roadmap assumptions testable.

---

Part XIII. Roadmap Artefacts and Templates

32. Recommended Deliverable Structure

The roadmap package must support executive decisions and detailed architecture and investment planning.

1. Executive summary and decision requests
2. Business context, objectives, and measurable outcomes
3. Scope, assumptions, constraints, and planning horizon
4. AI ambition and opportunity portfolio
5. Opportunity prioritization and rationale
6. Current-state capability and architecture assessment
7. Capability gaps and risk exposure
8. Target AI capability model
9. Target-state architecture and principles
10. Technology and sourcing strategy
11. Security, privacy, governance, and responsible AI requirements
12. Operating model and skills implications
13. Investment options and economic assumptions
14. Sequenced roadmap and dependencies
15. Measures, decision gates, and review triggers
16. Decisions required, unresolved questions, and appendices

33. Template: Business Outcome Register

ID	Business objective	Outcome measure	Baseline	Target	Target date	Accountable owner	Constraints
BO-01	[Objective]	[Metric]	[Value]	[Value]	[Date]	[Owner]	[Constraints]
BO-02	[Objective]	[Metric]	[Value]	[Value]	[Date]	[Owner]	[Constraints]

34. Template: AI Opportunity Assessment

Field	Entry
Opportunity ID and name	[ID and name]
Business domain and owner	[Domain / owner]
Problem statement	[Problem]
Business objective	[Linked objective]
Current baseline	[Measured condition]
Proposed AI contribution	[Capability]
Non-AI alternatives considered	[Rules, workflow, search, process redesign, etc.]
Data and integration needs	[Requirements]
Expected benefit	[Hypothesis, not unsupported promise]
Feasibility and readiness	[Assessment and evidence]
Risk and controls	[Risk class, mitigations, oversight]
Dependencies	[Prerequisites]
Recommendation	[Advance / experiment / defer / reject]

35. Template: Current-to-Target Capability Gap

Capability	Current state and evidence	Required state	Gap	Business impact	Proposed initiative	Priority
[Capability]	[Evidence]	[Target]	[Gap]	[Impact]	[Initiative]	[Priority]

36. Template: Technology Decision Record

Field	Entry
Decision ID	[ID]
Decision statement	[Question to resolve]
Business driver	[Outcome or constraint]
Requirements	[Functional and non-functional]
Options considered	[Option A, B, C, defer]
Evaluation criteria	[Criteria and relative importance]
Evidence	[Tests, analysis, due diligence]
Trade-offs	[Benefits and disadvantages]
Decision and rationale	[Selected option and why]
Consequences	[Dependencies, changes, risks]
Owner and approvers	[Roles]
Review trigger	[Condition for reconsideration]

37. Template: Roadmap Initiative

Field	Entry
Initiative ID and name	[ID and title]
Business outcome or capability	[What it enables]
Scope	[Included and excluded]
Accountable owner	[Owner]
Target horizon	[H1 / H2 / H3]
Commitment class	[Approved / planned / conditional / exploratory]
Dependencies	[Prerequisites]
Cost range	[Estimate and confidence]
Benefit hypothesis	[Expected measurable change]
Risks and controls	[Key risks and required assurance]
Success criteria	[Acceptance and outcome measures]
Decision gate	[Evidence required to proceed]

38. Template: Roadmap Assumption and Trigger Register

ID	Assumption or uncertainty	Why it matters	Evidence needed	Owner	Review trigger	Consequence if false
A-01	[Assumption]	[Impact]	[Validation]	[Owner]	[Trigger]	[Response]

39. Template: Executive Roadmap View

An executive roadmap shows business outcomes and major capability investments, not engineering tasks.

Strategic theme	Near term	Medium term	Longer term
Business value	[Priority outcomes]	[Scale outcomes]	[Transformation outcomes]
Data and knowledge	[Critical foundations]	[Reusable data/knowledge services]	[Advanced data products]
AI platforms	[Initial platform decisions]	[Shared platform capabilities]	[Optimization and evolution]
Architecture and integration	[Reference patterns and priority integrations]	[Domain expansion]	[Modernization and simplification]
Trust and governance	[Risk baseline and essential controls]	[Automated assurance and monitoring]	[Continuous governance improvement]
People and operations	[Ownership and critical skills]	[Scaled operating model]	[Continuous capability development]

Populate the view only after initiatives, dependencies, and investment assumptions have been validated.

---

Part XIV. Common Failure Modes

40. Mistakes That Weaken an AI Technology Roadmap

#	Failure	Why it fails	Better approach
40.1	Starting with products and vendors. The roadmap becomes a list of models, cloud services, vector databases, and frameworks.	Technology choices are detached from business outcomes and workload requirements.	Start with objectives, assess opportunities, derive capabilities, then evaluate products against explicit requirements.
40.2	Treating every problem as an AI problem. AI is applied where rules, workflow automation, conventional software, or process redesign would be simpler.	Complexity and cost rise without proportional benefit.	Compare AI with viable non-AI interventions and choose the simplest sufficient solution.
40.3	Building disconnected proofs of concept. Demonstrations have no production owner, integration path, evaluation criteria, or operating model.	A successful demo does not establish production readiness or business value.	Give each experiment a hypothesis, representative test data, success and stop criteria, and a follow-on decision.
40.4	Ignoring data readiness. The roadmap assumes data can be used because it exists somewhere.	Data may be incomplete, stale, poorly classified, inaccessible, or legally restricted.	Treat ownership, quality, lineage, permission, purpose, and freshness as explicit prerequisites.
40.5	Treating governance as a late approval step. Controls are added after architecture decisions.	Rework is expensive, and some designs cannot be made compliant afterward.	Translate risk and governance requirements into architecture, platform, and delivery capabilities from the outset.
40.6	Over-centralizing the platform. Every domain must use one central service.	The platform becomes a bottleneck and may not fit domain needs.	Centralize where consistency or economics justify it; federate where domain ownership produces better outcomes.
40.7	Underestimating operating cost. The case includes model API cost but omits retrieval, evaluation, data, infrastructure, support, human review, and change.	Production economics differ materially from prototype economics.	Estimate lifecycle cost and track cost per successful business task.
40.8	Confusing autonomy with value. Multi-agent or autonomous designs are chosen because they seem advanced.	More autonomy adds failure modes, security exposure, and operational complexity.	Use bounded autonomy only where it improves the workflow and can be governed, observed, and evaluated.
40.9	Creating a static multi-year plan. The roadmap is approved once and treated as fixed.	Priorities, model capabilities, regulations, vendor terms, and evidence change.	Maintain a rolling roadmap with explicit assumptions, review triggers, and decision gates.
40.10	Measuring activity instead of outcomes. Success is reported as pilots, models, prompts, or agents deployed.	These are activity measures, not evidence of value.	Measure business outcomes alongside technical quality, adoption, risk, and economics.
40.11	Skipping the evaluation harness. Quality is judged by demos and anecdotes.	Regressions go unnoticed and model or vendor comparisons are not defensible.	Build versioned golden datasets and regression gates before scaling.

---

Part XV. Quality Criteria and Final Checklist

41. What Makes a Roadmap Decision-Ready?

A roadmap is decision-ready when these questions can be answered with evidence or explicit assumptions.

Business Alignment

• Are the organization's strategic objectives understood?
• Are target outcomes measurable and owned?
• Does every major initiative trace to an outcome or a justified enabling capability?
• Have non-AI alternatives been considered?

Opportunity Portfolio

• Are opportunities described as business problems rather than technology demonstrations?
• Are value hypotheses explicit?
• Have feasibility, readiness, risk, and dependencies been assessed?
• Are experiments bounded by success and stop criteria?

Current State

• Is the current technology and capability baseline evidence-based?
• Are data, application, infrastructure, security, governance, skills, and operational constraints understood?
• Are maturity ratings supported by evidence?
• Are architectural debts and dependencies visible?

Target State

• Are required AI capabilities defined independently of specific products?
• Is the target architecture coherent and aligned to enterprise architecture?
• Are architecture principles explicit and testable?
• Are non-functional requirements defined by workload and risk?
• Are platform boundaries and ownership decisions clear?

Trust and Operations

• Are security, privacy, safety, compliance, and auditability built into the target state?
• Are human oversight and action authority defined where relevant?
• Are evaluation, observability, incident response, and lifecycle management included?
• Is there a credible operating model?

Economics and Sequencing

• Are lifecycle costs and benefits estimated transparently?
• Are unit economics considered?
• Are dependencies and prerequisite capabilities mapped?
• Are initiatives sequenced by value, readiness, risk, and dependency?
• Are commitment levels and uncertainties explicit?

Governance and Adaptability

• Are decision rights and accountable owners defined?
• Are investment and architecture decisions recorded?
• Are success measures and review triggers established?
• Is there a process to refresh the roadmap as evidence changes?

Record unanswered material questions as open decisions or conditions. Do not conceal them behind confident dates or diagrams.

---

Conclusion

Defining an AI technology roadmap is strategic translation expressed through architectural and investment decisions.

It begins with the organization's business objectives, not with a preferred model, framework, or cloud service. It identifies where AI can create measurable value, assesses whether the organization can realize that value, defines the capabilities and architecture required, evaluates technology and sourcing options, and sequences investments by value, readiness, risk, and dependency.

The roadmap connects six elements:

1. Business outcomes: the results the organization intends to achieve.
2. AI opportunities: the problems where AI can make a defensible contribution.
3. Enterprise capabilities: the enduring capabilities needed across use cases.
4. Target architecture and technology choices: the structures, platforms, standards, and controls that enable those capabilities.
5. Investment and sequencing: the initiatives, dependencies, and horizons that make the target state attainable.
6. Measures and governance: the evidence and decision mechanisms that keep the roadmap accountable and adaptable.

An AI technology roadmap is not a plan to adopt AI technologies. It is a plan to establish the enterprise capabilities through which AI can deliver measurable, secure, reliable, and economically sustainable business value.

This guide produces a validated, business-aligned roadmap and the decisions required to authorize execution. The next step is to translate it into owned initiatives, engineering plans, delivery milestones, production systems, and measurable outcomes.

---

Appendix A. Engineering Practice Crosswalk

The method is intentionally compatible with practices that mature engineering organizations already run. Use this table to connect each roadmap concept to an existing artefact or ritual rather than creating parallel processes.

Roadmap concept	Familiar engineering practice	How to connect them
Business outcome with guardrails (Ch. 4)	OKRs with guardrail metrics; product requirements	Express each outcome as an objective and key results plus guardrail metrics for quality, risk, and cost
Value hypothesis and experiments (Ch. 5, 7)	A/B test design; design spikes; experiment review	Require hypothesis, metric, sample, time box, and decision rule before an experiment starts
Capability model (Ch. 12)	Service catalog; platform capability map	Map each capability to an owning team and service in the catalog
Architecture principles (Ch. 13)	Engineering principles; paved road or golden path	Publish principles with defaults, rationale, and an exception process
Target-state architecture (Ch. 13)	Reference architecture; system design review	Review at the architecture board; keep per-system designs in design docs
Technology decision record (Ch. 24, 36)	ADRs; RFCs	Store ADRs alongside code or in the architecture repository; link to roadmap initiatives
Representative workload evaluation (Ch. 25)	Load testing; benchmark suites; offline evaluation	Version golden datasets and run them in CI for every model, prompt, retrieval, or tool change
Non-functional requirements (Ch. 26)	SLIs, SLOs, error budgets	Set SLOs by workload and risk class; add quality and cost SLOs alongside availability and latency
Risk classification and controls (Ch. 17)	Threat modeling; security and privacy review; launch review	Use risk class to determine review depth; require threat models for tool-using and agentic systems
Authority to act (Ch. 17.3)	Least privilege; scoped service identities; approval workflows	Give agents scoped, auditable identities; gate high-impact actions with policy and approval
Unit economics (Ch. 19)	FinOps; cost per request and per transaction	Tag and attribute AI spend by workload; review cost per successful task in operations reviews
Platform boundaries (Ch. 16)	Platform engineering; internal developer platform	Run the shared AI platform as a product with customers, SLOs, and a roadmap
Decision gates (Ch. 22, 31)	Launch readiness review; stage-gated rollout; canary and shadow deployment	Define quantitative entry criteria per gate; stage releases with rollback and kill switches
Observability (Ch. 13, 26)	Tracing, metrics, logging; incident response	Trace prompts, retrieved sources, tool calls, and outputs; include AI incidents in on-call and postmortems
Architectural debt (Ch. 10)	Tech-debt register; ML technical debt analysis	Track entangled data dependencies, undeclared consumers, unversioned prompts, and glue code
Roadmap refresh (Ch. 28)	Quarterly planning; architecture review cadence	Align refresh triggers and cadence to existing planning cycles

---

Appendix B. Framework and Regulatory Crosswalk

This appendix helps relate roadmap activities to widely used frameworks. It is a navigational aid, not legal or compliance advice. Confirm applicable obligations with your legal, risk, and compliance functions.

Framework or reference	Relevance to the roadmap	Where it connects
NIST AI Risk Management Framework (AI RMF 1.0)	Organizes AI risk work into Govern, Map, Measure, and Manage functions	Govern → Ch. 27–28; Map → Ch. 5, 6, 17.1; Measure → Ch. 25, 29; Manage → Ch. 17, 23
ISO/IEC 42001 (AI management systems)	Management-system requirements for governing AI within an organization	Ch. 17–18, 27–28
ISO/IEC 23894 (AI risk management guidance)	Guidance on integrating risk management for AI	Ch. 17
EU AI Act	Risk-tiered regulation of AI systems with obligations that vary by risk category	Ch. 3 (jurisdictions), 17.1 (risk classification), 17.2 (controls)
OWASP Top 10 for LLM Applications	Catalog of security risks specific to LLM-based systems, including prompt injection	Ch. 17.2, 14.4, 26
Sector regulation (for example, model risk management in financial services, medical-device and health-data rules)	Domain-specific validation, documentation, and oversight expectations	Ch. 3, 9.1, 17

---

Appendix C. Glossary

Term	Definition
ADR	Architecture decision record: a short, versioned record of a significant decision, its options, and rationale
Agentic system	A system in which a model plans and invokes tools or actions to pursue a goal, within defined limits
Capability	An enduring organizational ability, defined independently of products
Commitment class	The firmness of a roadmap item: approved, planned, conditional, exploratory, deferred, or rejected
Decision gate	An evidence-based checkpoint required before further commitment
Enabler	A shared capability that unlocks multiple use cases
Evaluation harness	The datasets, graders, and automation used to measure and gate quality
FinOps	Practices for attributing, governing, and optimizing technology spend
Golden dataset	A curated, versioned set of representative cases with agreed expected behavior
Groundedness	The degree to which an output is supported by the provided or retrieved sources
Horizon	A planning band expressing intent rather than a fixed date
Model gateway	A shared service that mediates model access, policy, routing, quotas, and logging
RAG	Retrieval-augmented generation: grounding model output in retrieved information
SLI / SLO	Service-level indicator and objective: a measured quality signal and its target
Unit economics	Cost and value expressed per unit of business work, such as per successful task
Value hypothesis	A testable statement of how an AI intervention should change a business measure

---

Companion Volume

Executing the AI Technology Roadmap takes the approved roadmap forward: mobilizing teams, operationalizing governance, delivering foundations, engineering and integrating solutions, validating readiness, deploying safely, operating services, measuring value, and adapting the portfolio.