Evidence-Based AI Adoption Roadmap and Change Management Plan

Create a decision-ready AI adoption roadmap and change management plan using only the context and evidence supplied below.

## Business inputs
Business context: [Business context]
Industry: [Industry]
Company size: [Company size]
Current goals: [Current goals]
Current AI usage: [Current AI usage]
Teams involved: [Teams involved]
Important workflows: [Important workflows]
Known pain points: [Known pain points]
Available tools: [Available tools]
Data readiness: [Data readiness]
Leadership support: [Leadership support]
Employee skill level: [Employee skill level]
Privacy or compliance constraints: [Privacy or compliance constraints]
Budget or resource constraints: [Budget or resource constraints]
Timeline: [Timeline]
Definition of done: [Definition of done]

## Input and evidence rules
Treat current goals, important workflows, known pain points, privacy or compliance constraints, budget or resource constraints, timeline, and definition of done as blocking inputs. If any are absent or too ambiguous to support prioritization, ask up to seven concise clarification questions before producing the roadmap. Explain why each answer affects a decision.

Current AI usage, available tools, data readiness, leadership support, employee skill level, and team details are important supporting inputs. If these remain unavailable, continue only where bounded analysis is safe. Mark the relevant fields as unknown, state the resulting limitation, lower confidence, and assign any affected initiative to discovery or validation rather than presenting it as implementation-ready.

Classify material statements as one of the following:
- Supplied fact: directly stated in the inputs or supporting materials.
- Assumption: a bounded premise needed to continue and requiring confirmation.
- Unknown: information that cannot be inferred safely.
- Conflict: supplied information that is inconsistent.
- Recommendation: a proposed course of action, not an executed decision.
- Execution evidence: dated proof of an action or measured result supplied by the user.

Do not manufacture baselines, costs, savings, adoption rates, legal conclusions, integrations, data quality, vendor features, employee sentiment, approvals, test results, or implementation status. Cite the relevant supplied input or source-material label when supporting a consequential conclusion. Where evidence is weak, provide a validation method instead of a definitive claim.

## ChatGPT operating and authority boundaries
Use ChatGPT to organize supplied information, compare opportunities, expose assumptions and conflicts, calculate transparent prioritization scores, and draft roadmap artifacts. Unless the user supplies content directly in the conversation, ChatGPT cannot inspect company systems, workflow logs, contracts, policies, data stores, vendor configurations, employee records, or actual tool behavior.

This is planning work only. Do not claim to have contacted stakeholders, surveyed employees, approved tools, changed policies, configured integrations, trained teams, run pilots, measured outcomes, deployed AI, or obtained legal, security, privacy, finance, HR, or executive approval. Label all such work as proposed, pending, blocked, or unverified unless dated execution evidence is supplied.

Do not recommend entering personal, customer, employee, financial, health, credential, trade-secret, legally privileged, export-controlled, or otherwise restricted data into ChatGPT or any unapproved AI service. Use sanitized descriptions and aggregated evidence. Require authorized privacy, security, legal, HR, finance, procurement, or executive review where their remit applies.

Require named human approval before any initiative can:
- process sensitive or regulated data;
- generate customer-facing, employment, legal, financial, safety, eligibility, pricing, or other consequential outputs;
- connect to production systems or perform write actions;
- send communications, alter records, trigger transactions, or make autonomous decisions;
- materially change employee responsibilities, monitoring, or performance evaluation.

Recommend stopping or holding an initiative if there is no accountable owner, no lawful and approved data path, no reliable baseline, no defined human review, unacceptable error impact, unresolved security or compliance risk, vendor capability is unverified, or the pilot cannot be contained and reversed.

## Analysis workflow

### 1. Establish the planning basis
Summarize the business outcomes, scope, affected teams, constraints, timeline, and definition of done. Create an evidence ledger containing an ID, statement, classification, source, confidence, decision affected, and validation needed. Record unresolved conflicts without silently choosing one version.

### 2. Assess AI readiness
Rate each dimension from 0 to 3, where 0 means no evidence or not established, 1 means ad hoc, 2 means repeatable but incomplete, and 3 means governed and measurable:
- strategic alignment and executive sponsorship;
- workflow definition and process ownership;
- data availability, quality, classification, and permitted use;
- approved tool and integration readiness;
- workforce skills and manager capability;
- governance, privacy, security, legal, and procurement maturity;
- measurement baselines and operational monitoring;
- change capacity and support model.

For every rating, provide evidence, gaps, confidence, and the next validation action. Do not award a maturity score above 1 when the supporting evidence is unknown. Identify readiness dependencies that could block pilots.

### 3. Build the opportunity inventory
Identify only use cases connected to the supplied goals, workflows, and pain points. Do not force coverage of every department. For each use case, specify:
- business outcome and current workflow step;
- user group, process owner, and accountable decision owner;
- current pain point and proposed AI assistance pattern;
- inputs, outputs, data classification, and data owner;
- approved-tool or integration dependency;
- required human review and prohibited autonomous action;
- likely failure modes, including inaccurate output, bias, privacy leakage, prompt injection, overreliance, inconsistent use, and workflow disruption where applicable;
- baseline needed, candidate metric, validation method, estimated effort range, and confidence;
- reversibility, fallback process, and stop conditions.

Exclude or defer opportunities whose value is unrelated to a supplied goal, whose necessary data use is not permitted, or whose risk cannot be bounded.

### 4. Prioritize transparently
Score each candidate from 1 to 5 on business value, feasibility, data readiness, time to value, change capacity, and risk controllability. Define what 1, 3, and 5 mean for every criterion before scoring. Propose weights totaling 100 percent and explain how the goals and constraints justify them. Calculate the weighted score visibly, but do not use the score to override a mandatory risk gate.

Assign each use case to one disposition:
- Pilot candidate: evidence and controls are sufficient for a contained test.
- Discovery required: potentially useful, but critical evidence is missing.
- Strategic initiative: valuable but dependent on larger process, data, or system changes.
- Hold or reject: value is weak, risk is unacceptable, or prerequisites are absent.

Include score rationale, evidence IDs, confidence, dependencies, and the decisive reason for the disposition. Highlight trade-offs and sensitivity where uncertain ratings could change the ranking.

### 5. Design controlled pilots
For the highest-ranked feasible candidates, create pilot charters containing the problem statement, scope, exclusions, owner, participating team, approved data and tools, baseline, target, sample or test approach, human-review procedure, quality rubric, error log, incident path, fallback process, duration, resource estimate, training prerequisite, and approval gates.

Define acceptance criteria before proposed execution. Include expected observation, evidence to collect, responsible reviewer, review date or phase, minimum threshold, and decision rule for scale, revise, pause, or stop. If no actual pilot evidence was supplied, set actual observation and acceptance status to not measured and pending execution.

### 6. Define governance and decision rights
Create practical controls for acceptable and prohibited use, tool approval, data classification, retention, access, vendor review, prompt and output quality checks, disclosure where appropriate, recordkeeping, intellectual-property concerns, incident reporting, exception handling, periodic review, and decommissioning.

Provide a decision-rights matrix showing the accountable owner, consulted functions, required approver, evidence required, and escalation path for tool approval, sensitive-data use, customer-facing output, production integration, consequential decisions, policy exceptions, pilot continuation, and scale-up.

### 7. Plan change management and enablement
Map stakeholders by impact, influence, likely concern, desired behavior, message, messenger, channel, timing, and feedback method. Address job-displacement concerns honestly without promising that roles will be unaffected. Identify process confusion, shadow AI, skill gaps, manager inconsistency, excessive reliance, weak ownership, and uneven adoption.

Design a role-based enablement plan covering AI limitations, approved use, privacy and security, workflow-specific practice, verification habits, escalation, manager coaching, internal champions, office hours, refresher training, and competency checks. Distinguish attendance from demonstrated competence.

### 8. Build the 30-60-90 day roadmap
Sequence discovery, governance, baseline collection, tool due diligence, pilot preparation, training, contained testing, review, and scale decisions. For each work item include phase, outcome, owner, contributors, dependency, effort range, required approval, evidence produced, risk or stop condition, and exit criterion.

Do not present 30, 60, or 90 days as guaranteed completion dates when the supplied timeline, procurement, data remediation, or approval dependencies make them unrealistic. Reframe them as decision stages and show schedule alternatives where needed.

### 9. Define measurement and verification
Create a metric dictionary for each proposed measure: business question, metric definition, formula, data source, baseline status, target type, collection frequency, owner, segmentation, quality check, and gaming risk. Cover value, output quality, error or rework, cycle time, adoption, employee confidence, customer effect, incidents, and control compliance only where relevant.

Separate forecast benefits from measured benefits. A forecast must include its assumptions and confidence range. A measured result requires a dated baseline, comparison period, data source, sample or denominator, and responsible reviewer.

Reconcile the final roadmap against these acceptance checks:
- Every pilot candidate traces to a supplied business goal and defined workflow.
- Every priority score can be recalculated from stated criteria, weights, and ratings.
- Every consequential or sensitive workflow has an accountable human reviewer and approval gate.
- Every proposed metric has a definition, owner, source, and baseline status.
- Every roadmap work item has an owner, dependency, evidence artifact, and exit criterion.
- Every unknown or conflict affecting priority, legality, safety, cost, or timing is visible.
- Actual observations remain not measured unless execution evidence was supplied.
- Recommendations stay within the stated budget, capacity, timeline, tool, and data constraints, or clearly identify the variance.

For each check, report expected condition, actual observation from the completed analysis, evidence reference, status as pass, fail, blocked, or unverified, and corrective action. Do not mark a check passed without visible support in the deliverable.

## Required deliverable
Produce the following sections in order:

1. Decision brief: recommended starting point, major constraints, decisions needed, and a clear statement that the roadmap is proposed rather than executed.
2. Planning basis and scope: outcomes, included and excluded workflows, constraints, timeline interpretation, and definition of done.
3. Clarifications, assumptions, unknowns, and conflicts: include impact and owner for resolution.
4. Evidence ledger: ID, statement, classification, source, confidence, decision affected, and validation needed.
5. AI readiness scorecard: dimension, 0-to-3 rating, evidence IDs, gap, blocker status, confidence, and next validation action.
6. Opportunity inventory: use-case fields, data and tool dependencies, human oversight, failure modes, validation needs, fallback, and stop conditions.
7. Prioritization method and matrix: scoring anchors, weights, calculations, risk gates, sensitivity, disposition, and rationale.
8. Pilot charter portfolio: one charter for each recommended pilot candidate, including predefined acceptance and rollback rules.
9. Governance control register: control, risk addressed, owner, approver, required evidence, review frequency, escalation, and implementation status.
10. Decision-rights matrix: decision, accountable owner, consulted functions, required approval, evidence, and escalation path.
11. Change impact and communication plan: stakeholder group, impact, concern, desired behavior, message, messenger, channel, timing, and feedback loop.
12. Training and enablement plan: audience, competency, learning activity, practice evidence, assessor, support mechanism, and completion criterion.
13. 30-60-90 day decision roadmap: work item, owner, dependencies, approval, evidence artifact, risk, exit criterion, and handoff state.
14. Measurement framework: metric dictionary, baseline status, forecast assumptions, collection method, quality check, and review owner.
15. Verification and acceptance register: expected condition, actual observation, evidence, status, and corrective action.
16. Leadership decision queue: decision required, options, trade-off, recommendation, approver, deadline or phase, and consequence of delay.
17. Status and handoff: identify items as proposed, ready for human review, blocked, pending approval, pending execution, measured, or unverified. State the next owner and evidence needed for each blocked or pending item.

Use concise tables where they improve comparison. End with the five most important next actions for authorized leaders. Do not end with unsupported claims of approval, implementation, testing, deployment, training completion, savings, or successful adoption.