P1 · AI Strategy & Leadership · 12 min

AI Roadmap: From Opportunity Inventory to 12-Month Plan

Transforms an abstract discussion into decision, priority, and accountability. A guide + template on artificial intelligence roadmap for leaders and teams needing to convert the topic into decision criteria.

Published on August 24, 2026

CENTRAL THESIS

The organization experiments with AI without a common executive direction.

It translates an abstract discussion into decision, priority, and accountability.

When different areas begin experimenting with artificial intelligence independently, the movement may seem like a sign of progress. There are tests in customer service, marketing, operations, technology, and human resources. Each team finds a tool, assembles a demonstration, and claims priority.

The problem arises when leadership tries to answer simple questions: which initiatives deserve investment, which risks have been accepted, who is responsible for the results, and what needs to be stopped?

Without a common executive direction, the AI portfolio grows by addition. It rarely grows by decision.

The thesis of this guide is debatable but useful: an artificial intelligence roadmap should not start with the available technology. It should start with the decisions the organization needs to improve and the necessary conditions to operate each solution responsibly.

This changes the role of the roadmap. It ceases to be a list of desirable projects and becomes an agreement on priority, responsibility, capability, risk, and learning.

A roadmap is not an inventory with dates

The opportunity inventory answers one question: where could AI be applied?

The roadmap answers another: in what sequence should the organization test, prepare, authorize, scale, or stop these applications?

The difference may seem small but has practical consequences. An inventory can gather dozens of ideas without establishing commitment. A roadmap needs to expose choices. If everything is included, nothing is prioritized.

It is also advisable to separate four elements that the market often mixes:

Artificial intelligence strategy defines why the organization intends to develop this capability and which business objectives justify the effort.
Opportunity inventory records processes, decisions, and activities where AI may be useful.
Initiative portfolio gathers experiments, projects, shared capabilities, and controls that will receive resources.
Roadmap organizes this portfolio over time, makes dependencies explicit, and establishes criteria to advance, review, or stop.

This separation avoids a common trap: turning a collection of tools into strategy.

The tool may be new. The executive decision remains familiar. Where to invest? Who authorizes? What risk to accept? How to measure? When to stop?

The unit of analysis should be the problem, not the tool

A consistent inventory does not start with questions like "where can we use an assistant?" or "which area needs an AI agent?" It starts with the actual work.

For each opportunity, map:

Which process, activity, or decision is involved?
Who performs the work today?
Who receives the result?
What problem needs to be reduced?
What data enters the process?
What consequence could arise from an incorrect response?
Where must human judgment remain?
How will performance be measured?

This framing helps distinguish automation, decision support, and delegation.

Automation executes a defined sequence. A support resource offers information, synthesis, or recommendation for a person to decide. Delegation transfers part of execution or decision to a system within authorized limits.

Not all automation is an AI agent. Not all AI use needs to make decisions. In many cases, the safest and most economically sensible choice will be to keep the decision with a person and use technology only to prepare information.

The degree of autonomy should be a design decision, not an accidental consequence of the chosen tool.

Prioritization requires more than estimating impact

An attractive opportunity may be unsuitable for the first cycle. Expected value may be relevant, but data may be disorganized, responsibility diffuse, or error hard to detect.

Therefore, prioritization needs to combine at least five criteria.

Business value

Define which outcome the initiative intends to improve. Avoid generic benefits like "gain efficiency." Specify the desired change: reduce analysis time, increase service capacity, improve consistency, support revenue, or reduce rework.

When it is not possible to establish an initial measure, record the gap. Do not replace a missing measure with a promise.

Operational viability

Assess whether the process is sufficiently understood. Sophisticated technology applied to an unstable flow tends to amplify existing confusion.

Ask if there is a responsible party, routine, entry criteria, expected output, and capacity to incorporate the result into work.

Data and technology readiness

Map which information will be used, who can access it, and whether its quality allows responsible testing.

The existence of data does not mean they are ready. Format, update frequency, context, permission, and traceability also factor into the decision.

Exposure to risk

Consider the impact of error, leakage, misuse, discrimination, inconsistency, or loss of control. The assessment must include affected people, exposed assets, and possibility of reversal.

The goal is not to eliminate all risk. It is to decide which controls are proportional before authorizing use.

Before authorizing the initiative, forward legal, labor, privacy, and security questions to the responsible areas of the organization.

Capacity to learn

Some initiatives offer less immediate value but help the organization develop reusable competencies. Others promise great impact but depend on capabilities not yet existing.

A good first cycle combines useful deliveries with transferable learning. The test should not only demonstrate that a tool works. It should reveal what the organization needs to know to operate the solution.

The 12-month plan should combine deliveries and scaling conditions

Dividing the roadmap into quarterly waves creates a cadence understandable for leadership. Dates do not need to function as rigid promises. They organize hypotheses, dependencies, and decision points.

Months 1 to 3: decide focus and prepare the ground

The first period should reduce dispersion.

Define the business objectives that will guide the roadmap.
Appoint an executive sponsor and operational leads.
Map opportunities by process, problem, and user.
Establish common prioritization criteria.
Select a few tests with controlled scope.
Identify decisions requiring governance, security, or specialized validation.
Record a baseline for the chosen measures.

The deliverable for this period is not an extensive list. It is an initial authorized portfolio with responsible parties and continuity criteria.

Months 4 to 6: test value and operation

The second period should produce sufficient evidence for a decision.

Conduct tests with real users and explicit limits.
Measure quality, time, adoption, cost, and occurrence of relevant errors.
Record human interventions and unforeseen situations.
Review data, integrations, permissions, and controls.
Compare results with the baseline.
Stop initiatives that do not demonstrate proportional utility or safety.

The test needs an exit decision. At the end, leadership should be able to scale, adjust, keep restricted, or terminate.

Months 7 to 9: consolidate reusable capabilities

After the initial tests, the focus shifts from isolated cases to organizational capability.

Standardize evaluation criteria.
Define responsibilities among business, technology, security, legal, and people.
Create usage guidelines and monitoring mechanisms.
Prepare training according to involved roles.
Reuse components, data, and learnings when compatible.
Review the portfolio in light of obtained evidence.

Scaling without this consolidation multiplies exceptions. Consolidating too early can crystallize an immature model. The criterion should be proven repetition of needs, not the desire to build a complete platform.

Months 10 to 12: scale with control and renew the portfolio

The last period should transform learning into decisions for the next cycle.

Scale only initiatives with defined results, responsible parties, and controls.
Review operational costs and dependencies.
Measure effects on the complete process, not just the automated task.
Update policies and governance mechanisms.
Close redundant or insufficiently adopted solutions.
Incorporate new opportunities into the inventory.
Approve priorities for the next 12 months.

The roadmap ends as a calendar but continues as a management discipline.

Artificial intelligence roadmap template

Identification

Initiative name:
Responsible area:
Executive sponsor:
Affected process or decision:
Users involved:

Problem and value

Observed problem:
Expected outcome:
Baseline measure:
Goal or success signal:
Hypotheses to be tested:

Data, technology, and operation

Required data:
Systems involved:
Process changes:
Operation responsible:
Dependencies:

Risk and governance

Main risks:
People or assets exposed:
Necessary controls:
Decisions reserved for people:
Authorization responsible:

Plan

Planned wave:
Test scope:
Required resources:
Review date:
Criteria to scale:
Criteria to stop:

Fictional example: internal request triage

Consider a fictional company that receives internal requests through different channels. Teams spend time classifying requests, identifying responsible parties, and requesting missing information.

The opportunity would not be described simply as "use AI in internal service." The framing could be:

Problem: requests arrive incomplete and are routed to incorrect areas.
Expected outcome: improve triage quality and reduce inappropriate routing.
Initial scope: suggest category, indicate missing information, and recommend responsible area.
Autonomy limit: the system does not approve requests nor make decisions affecting people.
Measures: proportion of accepted suggestions, human corrections, triage time, and error types.
Criteria to scale: demonstrated operational utility, identifiable errors, and approved controls.
Criteria to stop: low adoption, errors hard to detect, or dependence on data that cannot be used.

In this example, the initiative could enter the second wave. Before that, the company would need to standardize categories, define responsibilities, and prepare a baseline.

The example shows a relevant implication: part of the roadmap may not involve AI. Organizing the process, reviewing permissions, defining measures, and training people are also necessary deliveries.

What should be excluded from the roadmap

Prioritizing also means refusing.

An initiative should be postponed, redesigned, or stopped when:

The problem is unclear.
The activity can already be improved with a simple process change.
There is no responsible party for the outcome.
The benefit depends only on an estimate without verifiable measure.
The necessary data cannot be used safely or legitimately.
Error could cause relevant impact and there is no adequate review mechanism.
The cost of supervision eliminates the expected value.
The solution reduces transparency in a decision that requires explanation.
The organization cannot yet operate the necessary controls.

Not automating can be a mature decision. In certain processes, preserving judgment, human connection, explainability, or the possibility of contestation has more value than accelerating a task.

The roadmap meeting must end with decisions

An executive meeting about AI should not end only with enthusiasm or requests for new demonstrations. It should answer:

Which problems will receive attention in the next 90 days?
Which initiatives are authorized for testing?
Who is responsible for each result?
Which risks have been accepted and by whom?
Which decisions will remain human?
What evidence will be required before scaling?
Which initiatives will be stopped now?
What common capability needs to be built?

These answers make the roadmap executable. Without them, the document may have dates but still lacks direction.

The roadmap is a decision system

An artificial intelligence roadmap for companies should not try to predict everything that will happen in 12 months. Its function is to create a sequence of choices that allows learning without losing accountability.

The quality of the plan is not in the number of projects nor the visual precision of the schedule. It is in the ability to connect opportunity to objective, test to evidence, autonomy to control, and investment to responsibility.

The first step, therefore, is not to choose the next tool. It is to decide which problems justify executive attention and which conditions need to exist for the organization to move forward confidently.

If this decision requires alignment among leadership, business areas, technology, and governance, dooop can conduct a workshop applied to the real context of the organization.

To deepen this topic

NEXT DECISION

Request roadmap workshop

Bring the decision about artificial intelligence roadmap to the real context of your organization.

Content by Danniel Pozza. Registration allows linking this topic to the reader’s journey and tracking interest in the subject.

Sources

Board Oversight and Accountability

The Role of the Board of Directors in AI Governance and Strategy

For supplier selection in the Brazilian legal context, see AI governance and Brazil’s LGPD.