Why AI Rollouts Stall in Regulated and Legacy Enterprises

The purchase order cleared. The seats are provisioned. Someone in a leadership all-hands said the word “transformation” with conviction. And then, six months later, the dashboard nobody wanted to look at says the quiet part out loud: a third of the licenses have never been opened, the developers who do use the tools use them for autocomplete and little else, and the security team has quietly added “AI” to the list of words that trigger a review meeting.

This is not a tooling problem. The tools work. The models are capable. If anything, the gap between what the technology can do and what your organization actually gets out of it has never been wider — and in regulated, legacy, mature enterprises, that gap is widest of all.

What stalls an AI rollout in a bank, a hospital network, an insurer, or a forty-year-old industrial software shop is rarely the AI. It is the organization. The entrenched process, the compliance gate that nobody can find the owner of, the procurement cycle measured in quarters, the senior engineer who has been burned by three previous “this changes everything” initiatives and is in no hurry to be burned by a fourth. These are not bugs in your company. They are, in many cases, the features that kept a regulated company solvent and out of court. Which is exactly why they are so hard to move. Treat the stall as an organizational-change problem, and you have a fighting chance. Treat it as a “people just need more training on the tool” problem, and you will be back here in another six months with another unopened license report.

The stall is predictable, which is good news

Decades of change-management research describe what you are experiencing with almost uncomfortable precision. The most cited diagnosis comes from John Kotter, whose 1996 book Leading Change laid out an eight-step model — establish urgency, build a guiding coalition, form a vision, enlist a volunteer army, remove barriers, generate short-term wins, sustain acceleration, and anchor the change in the culture. Kotter’s central observation, drawn from studying more than a hundred corporate transformations, is that most change efforts fail not because the idea was wrong but because organizations skip steps and declare victory too early. Buying licenses is roughly step zero. Most enterprise AI programs have done the procurement and skipped everything that makes the procurement matter.

There is a second, more emotional model worth internalizing: the Satir change model, which maps the feeling of change rather than the management of it. It describes a predictable performance dip — sometimes called the J-curve — that arrives after a new element is introduced. Productivity gets worse before it gets better, as people pass through resistance and chaos before reaching integration and a new, higher baseline. This matters enormously for AI coding, because the dip is real and measurable. METR’s 2025 randomized controlled trial found that experienced open-source developers working in large, mature codebases were 19% slower when allowed to use early-2025 AI tools — even though they believed they had been sped up by 20%. If your senior engineers feel like the new tools are slowing them down, they may be right, at least at first. That is the chaos phase. The mistake is to interpret the dip as proof that the tools don’t work and pull the plug at precisely the moment the curve was about to turn upward.

The third lens is Everett Rogers’ Diffusion of Innovations and Geoffrey Moore’s adaptation of it. Rogers grouped adopters into five categories — innovators, early adopters, early majority, late majority, and laggards — and Moore’s Crossing the Chasm added the crucial wrinkle: there is a chasm between the visionaries who adopt anything new and the pragmatic early majority who adopt only what has been de-risked by someone like them. In a legacy enterprise, your innovators already found the tools on their own. The hard part — the part that determines whether the rollout succeeds — is getting the pragmatists across the chasm. And pragmatists do not respond to enthusiasm. They respond to evidence, references from peers they trust, and the removal of risk.

Why “regulated and legacy” makes every step harder

A startup with thirty engineers can adopt a new tool over a long weekend. A regulated enterprise cannot, and the reasons are structural — not cultural failings to be coached away.

The compliance gate has no clear owner

In most regulated orgs, an AI coding assistant touches at least three review domains: data governance (does code or context leave our boundary?), security (what is the threat surface of an autonomous agent with repo access?), and legal (what are the IP and licensing implications of generated code?). Each domain has a veto. None of them has a mandate to say yes. When a control function’s incentive is to avoid being the team that approved the breach, the rational individual move is to schedule another review. The rollout doesn’t get rejected; it gets deferred indefinitely, which feels the same to the developer waiting on it.

The diffusion of responsibility here is the real killer. In a flat startup, one person owns the yes-or-no and lives with the consequences. In a mature enterprise, the decision is distributed across functions that were deliberately separated so that no single team could move too fast — a structure that is excellent for preventing reckless decisions and terrible for making timely ones. The way out is not to bypass the gates but to give them a deadline and a decision owner, so “we’re still reviewing” stops being an indefinite state and becomes a dated commitment someone is accountable for.

Procurement runs on a different clock

Enterprise procurement is built to extract favorable terms and manage vendor risk over multi-quarter cycles. AI tooling moves on a monthly cadence — new models, new pricing, new capabilities. By the time a tool clears procurement, the evaluation that justified it may be stale. Teams that win here treat tool selection as an ongoing discipline rather than a one-time purchase — a live evaluation rubric they revisit each quarter, instead of a single bake-off they run once and call done.

The culture has earned its skepticism

Legacy enterprises are full of engineers who have survived multiple hype cycles. Their skepticism is not ignorance; it is pattern matching. And on AI specifically, that skepticism is now backed by data. Stack Overflow’s 2025 Developer Survey found that while 84% of developers use or plan to use AI tools, trust has gone the other direction: more developers actively distrust the accuracy of AI output (46%) than trust it (33%), and only about 3% say they “highly trust” it. The single biggest frustration, cited by 66% of respondents, is “AI solutions that are almost right, but not quite.” The most experienced engineers — the ones whose buy-in you most need — are the most skeptical of all. You cannot tell these people the tools are magic. They have used the tools. They know.

Accountability is a feature, and it makes people cautious

In a regulated environment, someone signs off on the code that ships. If that code came partly from an AI and it causes a compliance failure, who is accountable? Until that question has a clear, blame-free answer, the safest career move for an individual engineer is to use AI as little as the rollout will let them get away with — or to use it quietly and not mention it. Which brings us to the thing that is actually happening while your official rollout stalls.

Shadow AI is filling the vacuum

Here is the uncomfortable truth about a stalled rollout: the demand did not disappear. It went underground. When the sanctioned path is slow, blocked, or absent, developers route around it. A November 2025 survey by the security firm BlackFog found that 49% of employees admit to using AI tools their employer never approved. The risk tolerance is striking: 60% said the speed gains are worth the security risk, and 63% considered it acceptable to use AI without IT oversight when no approved option exists. More uncomfortable still, the same survey found leadership is often complicit — 69% of C-suite respondents were reportedly fine with the unsanctioned use.

This is the worst of both worlds. You are not getting the governance benefits of saying no, because people are using the tools anyway. And you are not getting the productivity benefits of saying yes, because the usage is invisible, unmanaged, and pushing potentially sensitive context — the BlackFog data found employees sharing internal research, employee data, and financial information — into tools nobody is monitoring. A stalled rollout doesn’t keep AI out of your enterprise. It just guarantees the version you get is the riskiest possible one. The deeper risks of unmanaged generated code are worth understanding in their own right; we cover them in our piece on AI code security risks.

The strategic reframe is this: shadow AI is not a discipline problem to be punished. It is a demand signal. It tells you precisely where developers see value, and it tells you that your official path is slower than the unofficial one. Punishing it drives the behavior deeper, not away — people simply get better at hiding what they were already doing. Close the gap between the sanctioned and unsanctioned path, and the shadow recedes on its own, because there is no longer a reason to take the risk. Engineers do not route around IT for fun; they route around it because the approved option does not exist or does not work. Give them one that does, and the incentive to freelance evaporates.

How to unstick the rollout

Nothing below is about choosing a better model or a different vendor. The stall is organizational, so the fixes are organizational.

Get sponsorship that survives the J-curve

Kotter’s first two steps — create urgency, build a guiding coalition — exist because change driven from the middle dies when it hits the first compliance gate. You need a sponsor senior enough to convene the security, legal, and data-governance leads in one room and ask them not “should we?” but “what would have to be true for you to say yes, and by when?” Just as important, that sponsor has to be told about the performance dip in advance. If leadership expects a clean upward line and sees the Satir chaos phase instead, they will lose nerve at the worst moment. Set the expectation that productivity may wobble before it climbs, and that the wobble is a sign the change is real, not a sign it failed.

Clear the compliance path first, and clear it publicly

The fastest way to kill shadow AI is to make the sanctioned path genuinely faster than the workaround. That means resolving the data-boundary, security, and IP questions up front and writing the answers down where developers can find them. A published, concrete AI coding governance framework does more than satisfy auditors — it removes the ambiguity that pragmatic engineers cite as their reason for hanging back. When the rules are clear, accountability stops being a personal risk. “I used the approved tool within the approved boundaries for the approved task types” is an answer an engineer can give with confidence. Ambiguity is what drives usage into the shadows; clarity is what brings it back.

Meet developers where they actually are

Crossing Moore’s chasm means converting pragmatists, and pragmatists adopt what their trusted peers have already de-risked. That argues for a beachhead strategy: pick a small number of teams, get them genuinely productive, and let their concrete results — not a vendor’s slide deck — become the reference that pulls the early majority across. It also argues for honesty about where AI helps. The METR result is a reminder that AI is not uniformly faster everywhere; it shines on greenfield work and well-scoped tasks and struggles in dense, idiosyncratic legacy code. Telling engineers “use it for everything” sets them up for the “almost right, but not quite” frustration that 66% of the Stack Overflow respondents already feel. Telling them where it pays off builds credibility. If a team is fighting the tools more than the tools are helping, that is worth catching early — we wrote a whole piece on how to prevent AI coding doom loops.

Measure adoption honestly, not theatrically

This is where most stalled rollouts quietly deceive themselves. A license-utilization number tells you who logged in, not who got value. Lines of AI-generated code tells you volume, not quality — and optimizing for it invites exactly the kind of gaming that Goodhart’s Law warns about, where a measure that becomes a target stops being a good measure. The DORA team’s 2024 research found the trap empirically: as AI adoption rose, teams reported productivity and job-satisfaction gains, but those same increases were associated with a 1.5% drop in delivery throughput and a 7.2% reduction in delivery stability for every 25% rise in adoption. More AI was not automatically better software delivery. If your dashboard only shows the activity going up, you will miss the part where the outcomes might be going sideways.

Honest measurement means watching adoption and delivery outcomes together, across whatever mix of tools your teams actually use, and being willing to see a number you don’t like. The point is not to prove the rollout succeeded; it is to learn fast enough to make it succeed. A model-agnostic, privacy-respecting view of how AI is actually being used — rather than which vendor’s seat got assigned — is the difference between managing the change and merely hoping it worked. For the deeper organizational version of this, our enterprise AI coding strategy guide goes further than we can here.

Account for the dip in the timeline

If the Satir J-curve is real, then a rollout plan that promises a productivity gain in the first quarter is a plan that will look like a failure exactly when it is working as designed. Build the dip into the narrative you give leadership. Generate Kotter’s short-term wins deliberately — a team that automated a tedious migration, a backlog of small tasks cleared in a Friday afternoon — and broadcast them, because in a skeptical culture, one credible peer story outweighs a quarter of executive enthusiasm. Short-term wins are not vanity metrics here; they are the references that pragmatists need before they will move.

The Takeaway

AI rollouts in regulated and legacy enterprises do not stall because the technology underdelivers. They stall because organizations buy a tool and skip the change. The compliance gate has no owner, procurement runs on a slower clock than the technology, the culture has earned its skepticism, accountability makes individuals cautious, and into that vacuum rushes shadow AI — the riskiest, least governed version of exactly the thing the official program was supposed to deliver safely.

Every one of those obstacles was described by change-management researchers decades before anyone wrote a line of generated code. Kotter told you not to skip steps or declare victory early. Satir told you to expect the dip and not panic in the chaos phase. Rogers and Moore told you the whole game is getting the pragmatists across the chasm with evidence rather than enthusiasm. The Stack Overflow, METR, BlackFog, and DORA data tell you what happens when you ignore them: high usage, low trust, invisible risk, and outcomes that quietly diverge from the story on the slide.

So stop treating the stall as a training gap and start treating it as what it is — an organizational change that was begun in the middle. Get sponsorship that can survive the dip. Clear the compliance path so the sanctioned road is genuinely the fast one. Meet developers honestly about where the tools help and where they don’t. And measure adoption in a way that can tell you the uncomfortable truth, because the rollout that can see its own problems is the only kind that ever gets unstuck.