1. Frame
Define the business problem, the workflow, the owner, the baseline, and the reason this change deserves attention.
Implementation field guide · Checked August 13, 2026
An AI change management plan for the part after the demo
The hard part of AI adoption is rarely getting a model to produce an impressive example. It is helping a real team use the workflow safely, repeatedly, and willingly when the work is messy. This 90-day plan gives leaders and employees a shared way to test that.
Michael Okeje
AI implementation and workflow research · Last updated August 13, 2026
The change is the work, not the model
I have seen too many AI projects treated as procurement exercises. A leader buys licenses, a vendor demonstrates a polished result, and the organization announces that it is now an AI company. Then the project reaches the people who must use it on a Tuesday afternoon, with incomplete information, a deadline, a customer waiting, and a system that does not fit the existing handoff. Usage falls. The post-mortem blames resistance. The actual problem was that nobody designed the change.
A useful AI change management plan starts with a narrower promise. We are not trying to make every employee enthusiastic about artificial intelligence. We are trying to make one defined piece of work better, while protecting quality, privacy, judgment, and the people affected by the outcome. That means the plan must describe the work before it describes the tool. It must give employees a voice before it gives them a login. It must measure accepted outcomes rather than activity that looks busy in a dashboard.
This guide is written for US businesses that are introducing generative AI, an internal assistant, an AI-enabled SaaS feature, or an agent into an existing workflow. It works for a small business without a transformation office and for a larger team that needs a practical operating layer between strategy and implementation. I use a 90-day structure because it is long enough to observe real work and short enough to maintain urgency. It is a starting design, not a promise that every organization will adopt at the same speed.
The six-stage adoption cycle
Use these stages as a decision path. Do not jump from a vendor demonstration to enterprise-wide rollout because the stages are where the operational evidence is created.
2. Listen
Interview the people doing the work and identify incentives, fears, exceptions, hidden steps, and existing workarounds.
3. Design
Place AI at a bounded point in the workflow, specify review and fallback, and decide what the system must never do.
4. Pilot
Run a supervised experiment with representative cases, visible feedback, and a pre-agreed decision threshold.
5. Embed
Train the team, update the operating procedure, assign support, and make the useful path easier than the unofficial one.
6. Govern
Monitor quality, incidents, drift, cost, and changing vendor behavior; improve or retire the workflow when evidence requires it.
Frame the first use case so it can succeed or fail honestly
Start with a work unit that has a visible owner and a measurable current state. “Use AI across marketing” is too broad to manage. “Draft the first version of the weekly customer-insight memo from approved survey data, with a research lead reviewing every claim before publication” is specific enough to test. The second description gives you a boundary, a reviewer, a source, an output, a cadence, and a definition of failure.
Write down what the workflow is not allowed to do. An assistant may summarize approved material but not make an employment decision. It may prepare a customer reply but not issue a refund without the existing approval. It may suggest a forecast explanation but not replace the system of record. Negative boundaries are not bureaucracy; they prevent a successful experiment from quietly expanding into a higher-risk use.
Before choosing a tool, interview at least one person who performs the work, one person who reviews it, and one person who receives the result. Ask them to walk through the last five examples, including the awkward ones. The exceptions are often where the value and the risk live. A clean demo usually represents the happy path. A real change plan must represent missing fields, ambiguous requests, unusual customers, urgent deadlines, and corrections after the first output.
Create a baseline without embarrassing the team. Record the time, volume, quality measure, rework, escalation, and existing software cost for a representative period. Do not select only the slowest old examples or the easiest AI examples. If the process varies by case, segment it. Averages that hide the difficult cases are how adoption programs create impressive slides and disappointing operations.
NIST's AI Risk Management Framework is useful here because it treats governance, mapping, measurement, and management as continuing activities. I would translate those ideas into ordinary operating questions: who owns this, who can be affected, what can go wrong, how will we know, what happens when we learn something, and who can stop the workflow? That translation makes the framework usable without copying a large-enterprise template.
A useful one-sentence charter
“For [eligible work], we will use [AI capability] to produce [draft, classification, suggestion, or summary]. [named person] will verify [quality and risk checks] before [permitted action]. We will continue only if [measured outcome] improves without exceeding [risk and cost boundary].”
Resistance is evidence about the design
A team that asks difficult questions is giving you implementation data. Record the concern, identify what could test it, and change the design when the evidence supports the concern. The goal is not unanimous excitement; it is informed participation within a safe boundary.
“This will replace my job”
Do not answer with a slogan about augmentation. Explain which tasks are changing, which judgment remains accountable, what training is funded, and how the pilot will affect workload. Ask the employee to identify failure cases that the design must handle.
“The output is not reliable”
Agree on the quality bar and test it on ordinary and difficult cases. If the output needs so much repair that the workflow is not useful, record that result. Trust is not created by telling people to use an unreliable tool more enthusiastically.
“I do not want company data in it”
Take the concern seriously. Document the approved data path, vendor terms, redaction rules, retention assumptions, access controls, and prohibited information. Offer a lower-risk test using synthetic or public data while the real data path is reviewed.
“This adds work to my day”
Measure review time and redesign the handoff. A workflow that saves drafting time but creates a new queue of checking, correction, and escalation is not automatically a win. Either remove the new burden or count it honestly in the business case.
“Leadership already chose the tool”
Separate the decision to explore from the decision to scale. A named tool is not a successful workflow. Give the team a fair test with an exit condition, then allow evidence to change the implementation.
Measure adoption as a useful outcome
License counts and prompt counts are activity measures. They can tell you whether access exists, but they cannot tell you whether the change helps. Use a small scorecard that connects behavior to the work and leaves room for a negative result.
| Dimension | Question | Evidence to collect |
|---|---|---|
| Reach | Who was trained, who tried the workflow, and who completed the required practice? | Training attendance alone; a completed task or observed practice case is stronger. |
| Use | How often is the approved workflow used for eligible work? | Eligible cases, attempted cases, completed cases, and reasons for bypassing it. |
| Quality | Does the result meet the operational standard without unacceptable errors? | Rubric score, correction rate, escalation rate, sampled failure types, and customer impact. |
| Experience | Does the workflow make the job clearer and more manageable? | Short pulse survey plus interviews with users, reviewers, and people receiving the output. |
| Economics | Does the value exceed the full cost at the observed adoption level? | Time, review, software, integration, support, training, incidents, and opportunity cost. |
Keep an adoption diary for the first month. Ask users what they tried, where they stopped, what they corrected, and what they did instead. A bypass is not automatically failure; it may show that the case was ineligible, the workflow was slower, the output was unsafe, or the training was unclear. Classify the reason rather than hiding it in an average.
The 90-day rollout
Days 1 through 15 are for framing and listening. Name the executive sponsor and operational owner, write the problem statement, map the current process, collect baseline cases, and interview the people affected. Publish what is known and what is still uncertain. This early transparency matters because employees can tell when a decision has already been made and the consultation is theatre.
Days 16 through 30 are for design. Select the smallest useful workflow, define the input and output, choose the tool or feature, document permissions and data handling, write the human review step, and prepare the incident route. Decide what evidence would make you stop. A pilot without an exit condition is a rollout with delayed honesty.
Days 31 through 60 are for supervised use. Start with a limited group and representative cases. Keep a lightweight run log that records whether the workflow was used, how long review took, whether the output was accepted, what failed, and what the user did instead. Hold a short weekly review with the users, not just the sponsor. Change the workflow when a repeated failure is found; do not wait for the end of the pilot to demonstrate that you listened.
Days 61 through 75 are for stress testing and decision preparation. Look at the difficult cases, the people who bypassed the workflow, and the work that moved downstream to reviewers or support. Compare quality and economics with the baseline. Ask whether the result works for different experience levels, shifts, locations, languages, and customer segments. A pilot that works only for its champion is not ready to scale.
Days 76 through 90 are for embedding or stopping. If the evidence meets the agreed bar, update the standard operating procedure, train the next group, assign ongoing support, and set a review trigger. If it does not, narrow the use, redesign it, choose a different tool, extend the experiment for one named question, or stop. Stopping a weak workflow is a successful governance decision, not a failed innovation identity.
- Approve the charter and baseline before access is expanded.
- Train on ordinary cases, difficult cases, and a clear stop-or-escalate case.
- Review the pilot log weekly with the people doing the work.
- Publish failures and fixes so the team sees learning, not hidden blame.
- Make the scale, redesign, extend, or stop decision against the original threshold.
Pair this plan with the site's AI pilot plan, AI evaluation guide, small-business governance guide, and AI ROI framework.
Questions to ask before you scale
Can the team explain the approved purpose in one sentence?
Do users know which data must stay out of the workflow?
Is there a named person with time and authority to review important output?
Did we test difficult cases rather than only the demo path?
Can we identify where an error would be detected and corrected?
Are we counting review, support, training, and failure costs?
What evidence would make us narrow, redesign, or stop?
Who owns the workflow after the project team leaves?
What changes in the vendor, model, data, or policy trigger a review?
Can an employee report a concern without being punished for slowing the rollout?
Frequently asked questions
What is AI change management?
AI change management is the people, workflow, training, communication, measurement, and risk work required to introduce AI into real operations. It covers how a team understands the change, tests it, adjusts responsibilities, preserves human accountability, and decides whether to continue or stop.
Why do AI projects fail after the demo?
A demo proves that a tool can produce an impressive output under selected conditions. Adoption requires a defined owner, useful input data, a place in the existing workflow, a quality standard, review time, training, permission boundaries, and a response when the output is wrong. Many projects fund the demo and neglect those operating conditions.
How long should an AI adoption plan take?
A focused workflow can be assessed in 30 days and piloted in roughly 60 to 90 days. The timing depends on data sensitivity, integration, decision risk, and whether the team is changing job responsibilities. A short pilot should answer a named business question rather than promise a complete transformation.
How should leaders respond to employees who resist AI?
Treat resistance as information before treating it as attitude. Employees may see a privacy risk, a quality problem, an unrealistic workload, a threat to their job, or a tool that adds review work. Ask what would need to be true for the workflow to be useful, test those concerns, and keep a clear line around what decisions remain human.
What should be measured during AI adoption?
Measure usage, completion, time, quality, error and escalation rates, review effort, user confidence, customer or employee impact, and total cost. Adoption is not the number of licenses assigned or prompts generated. It is the number of useful outcomes produced within the agreed quality and risk boundary.