The tool was approved, the licenses were assigned, and the training happened. The work is still moving the old way.
The rollout that finished without changing anything
A service operations group closes out a rollout. An approved AI system now pulls the account history, drafts the customer response, and proposes a resolution. Access works, the usage dashboard shows steady activity, and the program hits its dates.
Follow one case through, though, and the AI draft turns out to be where the work starts rather than where it settles. Priority order comes off a supervisor's spreadsheet. The agreed disposition gets written into that spreadsheet, the closing note gets retyped into the row instead of carried across from the system that drafted it, and nothing counts as finished until the row says so. She's maintained that file for three years, and she keeps it because it's the artifact she can reconstruct a case from: the last time one went badly, the spreadsheet was what she used to show exactly what she'd done and when. Thursday's review reads from it as well, which is only the visible half of the habit.
Six weeks later the operating numbers look the way they looked in the spring. Cycle time is flat, backlog is flat, and the escalation rate hasn't moved. None of that identifies the spreadsheet as the cause. What it says is that the rollout finished without producing observable operating change. The team says it likes the tool, and they mean it.
A competition nobody set up on purpose is running underneath that story, between a new path that works and an old path that still wins. It takes no bad tool and no unwilling team to produce.
The old path is winning on merit
Reading that as resistance to change is a costly mistake, because it aims the response at attitudes instead of conditions. The merit is narrower than the word suggests. What the old workflow has is alignment: it fits how the work gets reviewed, counted, and defended, which is a different question from which route produces the better answer. It wins for four reasons, and each one is a reason a careful person would pick it.
It's safer when something goes wrong. The old path leaves a record a reviewer already knows how to read, and whoever followed it can show every step they took. The new path may produce a better answer and leave behind an account of itself that nobody in the escalation has seen before.
It's what the measurement reads from. The weekly number, the monthly report, and the quarterly review all pull from a specific artifact, and whoever maintains that artifact is doing the work that gets counted.
It's the output a senior reviewer accepts. An experienced manager who glances at the familiar format and moves on has just completed a five-minute handoff. Send that same manager something produced a different way and they often re-derive it, which costs the sender an hour and proves the new path buys nothing.
It's easy to defend afterward. "I followed the process we've always used" tends to end a conversation. "The system suggested it, and I agreed" tends to start one.
Leave those four conditions in place and you've asked individuals to absorb a personal risk in exchange for an organizational benefit. Declining that trade is a reasonable choice, and the program will record it as low engagement.
Parallel running is the default, and nobody chose it
Add a new path without removing anything and both stay alive. Nobody convenes to choose that. Parallel running is simply what a rollout plan produces when it covers deployment and training and stops there.
The duplicated effort is being paid for twice, once in the licenses and once in the hours somebody still spends keeping the old artifact current.
The harder problem is authority. Two records of the same work now exist and neither one is authoritative, so a disagreement between them has no tiebreak. And while both routes run, the new path may never carry enough representative volume to be judged honestly, which means the program can tell you that it runs and not whether it works.
Meanwhile license activity is genuine, so the dashboard reports adoption to a leader who already paid for the capability. That is the version of "we paid for it, so it must be working" that survived into the AI era. An invoice is evidence of a purchase, and it says nothing about how work actually flows.
Make the new path defensible before asking anyone to rely on it
The order here matters, and it's easy to invert. Before a leader asks anyone to stop using the old route, the new one has to be operationally safer for the person using it, and that takes four things, none of which is a feature of the tool.
Someone has to answer when the output is wrong. One name, reachable, holding enough authority to matter in both directions: they can get the individual case put right, and they can get the workflow or the rule itself changed. A failure that keeps recurring is a signal that owner has to weigh and act on, and the weighing is real work: one serious failure can justify stopping the route the same day, while a run of low-consequence errors may deserve more evidence before anybody rewrites a rule. A person deciding whether to trust the new path is really asking who catches them if it fails.
There has to be a permitted fallback: a documented route back to a manual method for cases the new path shouldn't be handling yet, recorded each time it's used. A recorded fallback is evidence you can act on. Leave it unrecorded and what you have is a second workflow nobody can see.
The evidence trail has to be at least as good as the old one. This is the step that settles the safety question, and it's the easiest one to leave for later. If the old spreadsheet let a supervisor reconstruct what happened and the new path doesn't, the supervisor is right to keep the spreadsheet.
And the senior reviewers have to be told what accepting the new output means. It means the sanctioned format and its evidence trail are sufficient to review from, so nobody asks for the legacy artifact as well and nobody re-performs the work because the layout is unfamiliar. It does not mean waiving judgment, approving something the evidence doesn't support, or dropping a control the work is subject to. That instruction goes to the people receiving the work, not the people producing it. Adoption stalls on the receiving side too, and a team whose new-format work keeps getting sent back stops producing it in that format.
The queue, the approval, and the measurement
The tool sits inside surrounding logic that predates it. Three parts of that logic decide which path wins, and all three belong to management rather than to the implementation. What connects them is artifact authority: whichever artifact those three surfaces treat as the real one is the artifact people will keep maintaining.
The queue controls what work arrives, in what form, and on what clock. If work can still enter through the old channel, some of it will, and that volume is exactly what the new path never learns from.
At the approval gate, who signs off and on what evidence is settled by a form, and a form built around the old artifact keeps asking for the old artifact whatever the rollout plan says. Nobody has to defend that behavior. The form simply has a field on it.
Measurement is what determines which artifact gets maintained. Things get done when things get measured, and here's the corollary leaders skip: whatever the report reads from will be kept current by somebody, for as long as the report keeps reading from it. A team still maintaining a retired spreadsheet because the business review opens it every month is complying with the incentive that's actually in force, and reading that as defiance aims the response at the wrong target.
Of the three, the measurement is the uncomfortable one, because somebody has to rebuild a report they trust and then live with the version they don't yet. One caution applies to all three: the queue, the approval gate, and the report often belong to different functions. A leader who controls one of them and assumes the other two will follow has a coalition to build before an instruction will land anywhere.
The learning window
Someone reliable on the old path is a beginner on the new one, and the performance calendar doesn't pause for that. This part of adoption has nothing to do with willingness. A capable person is being asked to be temporarily worse at their job in front of the people who evaluate them.
That trade needs a window, stated in advance, with an end date on it. Inside the window, a good-faith error that traces back to the new process or to the competence gap everybody expected is handled as a process finding rather than a performance finding, which means it goes into fixing the workflow instead of into somebody's review. A control that was ignored, a step handled carelessly, deliberate misuse, or a decision not to use the sanctioned path at all sits outside the window and stays under ordinary judgment, handled the way it was before the rollout. The named owner and the recorded fallback described above are what make the window usable, because without them there is nobody to escalate to and no legitimate way to handle a hard case.
One thing is worth saying out loud during that window, and worth meaning: a fair amount of what the new path absorbs is repetitive iteration the team didn't value doing. Where that's true, nobody asks for it back.
The window has an end date because it spans a specific gap in competence rather than standing as an exemption from the new path. Someone still learning when it closes needs more support, which is a straightforward call. Someone who has decided the new path won't be used is a different situation, and it belongs to whoever holds the performance conversation rather than to the rollout plan. Confusing those two is how a leader ends up pressuring the people who are trying while shielding the one person quietly holding the change hostage.
Retire the old path on a date, with a name on it
A rollout adds a route; retirement removes one. A program that does the first and waits for the second is waiting on something that doesn't happen by itself.
Retirement is concrete and slightly uncomfortable to write down. On a stated date, the old submission format stops being accepted and the old report stops being produced rather than being produced alongside. Somebody takes the field off the form, and the shared inbox closes with a forward on it. Each of those has an owner, and the date sits next to that owner's name.
One test separates a retirement from an announcement: who can reverse it. If any manager can quietly restore the old report after a single complaint, what happened was a suggestion. Make reversal require the named owner and get it recorded, and the organization can tell the difference between a mistake it's correcting and a change it's abandoning.
Retirement without the four conditions above is a different failure, and a worse one. Turning off a working process before its replacement is defensible breaks the work and then calls the breakage change management. The date applies to the organization's own artifacts. It isn't a deadline aimed at people.
You won't find bypass by asking
Asking isn't useless. It just isn't sufficient. Ask a direct report whether the team is using the new path and the answer arrives faster and more confidently than the evidence supports. Dishonesty is rarely the explanation. What reaches the executive is an accumulation of reasonable summaries, each one slightly rounder than the last, until it lands as a fact, which is how an executive's read of readiness ends up ahead of the work.
The observable signals are more useful than the answer. Somebody is still updating the old artifact. Work arrives in the new queue already finished, meaning it was done elsewhere and entered afterward. The new output gets generated and then rewritten from scratch rather than edited. Usage spikes in the days before a review. One person has become the route everything unusual flows through, which is a workaround with a name and a calendar.
None of that needs an audit to see. What it needs is a safe way to be reported, because the people who know are the ones doing the work. If the first reported bypass costs the person who reported it, it will also be the last one reported.
One boundary is worth stating plainly, because it changes what a leader should do about it. This isn't a tool somebody brought in through the side door, and it isn't a product-selection problem either. Both competing routes were sanctioned. The approved path is losing to the approved path it was meant to replace, and every reason sits inside management's control.
Six questions to run this week
Pick one workflow where an approved AI path is already live.
Which artifact does the review of this work actually read from?
What date does the old submission format stop being accepted, and whose name is on that date?
Who answers, by name, when the new path produces a wrong output?
What is the permitted fallback, and does anyone record it when it's used?
Which senior reviewer has been told that the sanctioned format and its evidence trail are enough to review from, without recreating the legacy artifact?
How would you find out the old path is still running, without asking the person whose answer you can already predict?
A blank answer is the finding.
What an Assessment would look for
Culture and Change Management is the fifth pillar of the Anchor AI Bearing Assessment, and those blanks are where it does its work. The condition it examines is narrow. The approved AI path is live, and the work is still moving the old way. An Assessment locates the observable bypass inside the workflow. It reads the reasons the old route is still the one people trust, and it looks at the queue, the approval, and the report for the incentives that keep rewarding it. What the executive is left holding is a diagnostic finding: which operating changes would have to be owned and dated before the new path carries the work.
The tool was the easy part. The old path is still there because nobody took it away.