When an AI adoption plan begins with “transform productivity across the company,” it is hard to explain what changed 90 days later. The goal is too broad, ownership is vague, and there is no baseline against which success can be measured.

Ninety days is not enough to turn a company into an AI-native organization. It is a timebox for turning one measurable workflow into an operational candidate. The sequence should test whether the use case creates value, works repeatedly, keeps human workload within limits, and can be stopped and recovered when something goes wrong.

The NIST AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage. A useful roadmap follows the same logic: define the context, collect evidence, measure behavior, and build the controls required for operation.

The Roadmap at a Glance

Period	Core Question	Work	Required Evidence	Gate
Days 0–15	What are we changing, and why?	Establish the baseline, stakeholders, data, permissions, and potential harm	One-page problem definition, baseline, RACI, allowed and prohibited boundaries	Is there a workflow owner and a success metric?
Days 16–30	Which use case goes first?	Score candidates, map the user journey, draft Build/Buy options, design evals	Priority matrix, evaluation plan, target architecture, risk register	Is there value, feasibility, and evaluability?
Days 31–60	Does it succeed repeatedly under controlled conditions?	Run multiple trials, classify failures, measure permissions, logs, and cost	Results, traces, unit cost, security review	Does it pass consistency and critical-failure gates?
Days 61–75	Can people use it safely in real work?	Shadow and canary operation, approvals, training, rollback drills	Pilot report, SOP, exception and recovery records	Are human workload and exceptions acceptable?
Days 76–90	Who will own it continuously?	Define SLOs, budget, change control, and reassessment cycles	Operating dashboard, runbook, Go/Revise/Stop decision	Are owner, budget, monitoring, and kill switch in place?

Days 0–15: Baseline the Work Before Choosing the Model

Record how long one case takes today, how long it waits, the error and rework rates, monthly volume, and full cost. Without this baseline, an improvement claim cannot be proven.

Answer eight questions at the same time:

Who actually owns this workflow?
Who uses it, and who is affected by its results?
What are the current volume, time, cost, and error rates?
Who decides whether it succeeded, and with what evidence?
Which data and system permissions does it require?
Can a mistake be reversed, and what is the maximum harm?
Where is human approval mandatory?
Who can stop the system, and who responds to an incident?

If the Accountable role is empty or success means only “looks good,” the project is not ready for a PoC.

Days 16–30: Narrow the Candidates and Design Evaluation First

“Put AI in customer support” cannot be evaluated. A testable task sounds more like: “A support agent receives the order policy and conversation history, drafts a reply, and a human reviewer approves policy compliance, factual accuracy, and resolution.”

Compare five to ten candidates with the same criteria, then send only one or two to PoC. Build the task set from real failures and edge cases before development. This reduces the temptation to move the goalposts after seeing the results.

Anthropic’s guide to agent evaluations distinguishes tasks, trials, graders, and traces, and explains why stochastic systems require multiple attempts rather than a single demo.

Days 31–60: Inspect the Distribution, Not Just Average Accuracy

One successful run says little about repeatability.

Run the same task several times and measure success and variance.
Record tool calls, permission requests, retries, and intermediate state, not only the final answer.
Track p50 and p95 latency, model and tool costs, human intervention, and recovery time.
Start with de-identified data and sandboxes before using production data.
Treat unauthorized transmission, personal-data exposure, and irreversible unapproved actions as automatic failures.

The useful economic metric is not cost per token. It is the fully loaded cost of one verified success.

Cost per verified success = model + tools + infrastructure + retries + monitoring + human review + recovery cost, divided by verified successful cases

Days 61–75: Measure Human Work in Quiet Parallel Operation

Do not begin with automatic execution. Start in shadow mode beside the existing process, then move to a canary covering a small group and low-risk work.

This is where hidden labor appears. Measure not only the time the AI saves but also the time managers spend approving, handling exceptions, training users, answering questions, and reworking outputs. A faster model with a longer approval queue is not an operational improvement.

Days 76–90: Create an Operating Contract, Not a Launch Announcement

The final 15 days should document:

The accountable owner for business outcomes and service operation
Approval rules for model, prompt, tool, and permission changes
Monthly budget limits and abnormal-usage alerts
Log retention, incident reporting, stopping, and recovery procedures
Reassessment cadence for quality, cost, and risk
Vendor change and data-export plans

One person may hold several roles, but the Accountable role must not be empty across business outcomes, technology and data, risk and compliance, and operations and change.

The Day-90 Decision

Decision	Conditions	Next Action
Go	Targets passed, no critical failure, and an owner, budget, and runbook exist	Move to operation without expanding scope yet
Revise	Value signal exists, but variance, human workload, integration, or permission issues remain	Name the next experiment, owner, and end date
Stop	No value over baseline, evaluation is impossible, or irreversible risk is unacceptable	Record why it stopped and what would justify review

Stop is not a failed outcome. It is a decision that prevented a small experiment from turning into a large recurring cost.

At day 90, the company does not need a presentation saying it “adopted AI.” A successful PoC is not grounds for launch without evidence that the system can be operated.