Vol. III · Essays on work after AI
Saturday, October 3, 2026
evolving.work
Org Design · Strategy · Essay № 015

Why AI Initiatives Fail — And It Is Not the Technology

Most AI initiatives fail not because the technology underperforms, but because it is applied to systems that were already misaligned.

Most AI initiatives do not fail because the models do not work. They fail because they are applied to systems that were already broken.

I work with organizations deploying AI across operations, reporting, and decision support. The technology performs. It generates outputs faster, handles complexity at scale, and in controlled settings regularly exceeds baseline human performance. The failures I see happen one layer above — where those outputs collide with processes that were never designed for that level of capability. The assumption is intuitive: better tools produce better outcomes. In practice, they produce faster versions of existing problems.

The Numbers All Point the Same Direction

More than 80% of AI projects fail — twice the failure rate of non-AI IT projects — with root causes RAND traces to organizational misunderstanding, not technology limitations. MIT NANDA’s 2025 GenAI Divide report, spanning 150 executive interviews, 350 employee surveys, and 300 public AI deployments, found that 95% of enterprise gen AI pilots fail to deliver measurable P&L impact. Their conclusion is worth quoting directly: “The core issue is not the quality of the AI models, but the learning gap for both tools and organizations.” BCG, surveying 1,000 CxOs across 59 countries, reached the same place from a different angle: 74% of companies have yet to show tangible value from AI, with only 4% achieving capabilities that consistently generate returns.

And the problem is accelerating. S&P Global / Snowflake’s 2025 survey found that 42% of companies abandoned most of their AI initiatives last year, up from 17% in 2024 — a 2.5x rise in twelve months. Deloitte’s 2026 State of AI report confirms the gap: worker access to AI rose 50%, yet only 34% of leaders report genuine business reimagination. PwC puts it bluntly: technology delivers about 20% of an initiative’s value — the other 80% comes from redesigning work. Gartner-cited commentary suggests organizations are allocating roughly 10% of their transformation budgets to the change management that drives that 80%.

An industry that sells pattern recognition cannot seem to recognize the pattern in its own failure rates.

You Are Automating a Broken System Faster

Here is a pattern I have seen multiple times, composited from several engagements. A large financial services firm identified a bottleneck in their monthly management reporting cycle — 12 business days across four teams. They deployed generative AI to automate report assembly and analysis. Generation time dropped from 12 days to 3. The pilot was declared successful and scaled across business units.

Decision speed? Unchanged.

The reports arrived faster, but nobody changed how they were consumed. No one redesigned who owned decision inputs or how strategic priorities flowed across divisions. Output volume increased as teams requested variations and custom analyses. The verification bottleneck expanded — analysts spent more time reviewing AI-generated outputs than they had producing manual ones. The initiative was abandoned after 14 months. The post-mortem attributed failure to process misalignment, not technology limitations.

This is the core failure pattern. Organizations identify a slow process, apply AI to accelerate it, and see genuine local improvement. But the surrounding system remains unchanged. Decision rights are unclear. Objectives are loosely defined. Dependencies are misaligned. The faster component amplifies the weaknesses of the slower ones.

What strikes me is how the misalignment runs deeper than process. More than half of generative AI budgets go to sales and marketing tools, yet the biggest ROI is in back-office automation — a systematic strategic misallocation. Organizations are not only automating broken processes; they are investing in the wrong ones entirely. And the people who have to live with the result are often the last consulted: Kyndryl research found 45% of CEOs say their own employees are reluctant or hostile toward AI adoption. That is not a model problem.

RAND identifies the most common root cause explicitly: “misunderstandings about the intent and purpose of the project.” HBR reinforces this: without aligned incentives, redesigned decision processes, and an AI-ready culture, even advanced pilots will not become durable capabilities.

The reporting cycle was never the constraint. The connection between reports and decisions was.

Generating reports four times faster does not help the people making decisions if those reports still go unread.

Why Pilots Succeed and Rollouts Fail

Another pattern I encounter regularly, drawn from composite engagements. A European manufacturing conglomerate ran a pilot — AI-powered predictive maintenance at a single plant in Germany. Clear ownership, dedicated data engineering team, clean data, executive attention. The result: 34% reduction in unplanned downtime, 18% decrease in maintenance costs.

The board approved enterprise-wide scaling to all 23 facilities. Same technology. Different organizational conditions. Fragmented data systems across plants. No local data engineering support. Plant managers uninvolved in design, viewing it as corporate mandate. KPIs prioritizing production volume over maintenance optimization.

The result across the portfolio: 6% downtime reduction — below the investment justification threshold. Only 3 of 23 facilities matched pilot results. Total investment exceeded budget by 2.3x.

Pilot success is a function of controlled conditions, not technology capability. Seventy-one percent of companies use gen AI in at least one business function, but fewer than 10% of use cases survive the pilot stage. Eighty-eight percent of AI proofs of concept never reach widescale deployment — driven by governance gaps, infrastructure readiness, and lack of executive ownership. IBM’s Global AI Adoption Index, as cited in 2025 practitioner analysis, names the single most common scaling obstacle: 35% of enterprises point to fragmented data infrastructure — the same data living across Salesforce, SAP, Snowflake, legacy systems, and shadow spreadsheets that worked fine for a controlled pilot and breaks the moment you try to clone it. The distance between “deployed” and “transformed” is where most initiatives die.

The gap between a recipe working in a test kitchen and working across a franchise is not the recipe.

Where this explanation needs limits

Three objections deserve direct responses.

Sometimes the technology IS the problem. In narrow, high-stakes domains — healthcare diagnostics, legal reasoning, financial projections — model reliability can be the binding constraint. This is real. But the available data does not cleanly disaggregate technology-caused failures from organizational ones — which is itself telling. RAND identifies organizational misunderstanding, not model quality, as the most common root cause. MIT reaches the same conclusion. Technology limitations are genuine in specific domains, but they do not explain the systemic pattern. The risk of accepting the technology objection too readily: it gives organizations a comfortable excuse to skip the harder work.

We cannot pause to redesign — competitors are deploying now. This is the strongest practical objection. The timing pressure is real — and a 2026 Forbes-cited survey of CIOs and CTOs at firms above $500 million in revenue found 71% saying their executive teams hold unrealistic expectations about AI ROI. That pressure is the air technology leaders breathe. But it creates a false binary between redesign-everything and deploy-immediately. The thesis does not require a complete organizational overhaul before any AI work begins. It requires that implementation be preceded by design — understanding where value is created, how decisions flow, and where real constraints lie. The data on the alternative is clear: companies that deployed fast without design are abandoning at 2.5 times last year’s rate. That is not iteration. That is accelerating failure.

“System misalignment” is too vague to be actionable. Fair. If the diagnosis cannot be operationalized, it becomes a consulting platitude that explains everything and prescribes nothing. The next section provides the diagnostic. But the limitation deserves honesty: specific implementations will vary by organization. The risk of over-specifying — a rigid alignment checklist — is equally dangerous. It would treat transformation as compliance.

Design Before You Deploy

Here is what I have seen work. A mid-sized legal services firm approached AI-assisted document review after watching two competitors stall at pilot stage with similar technology. Instead of deploying immediately, they conducted a three-month operational review. They found structural misalignment unrelated to speed: inconsistent review criteria across associates, senior partner overrides based on experience rather than documented standards, and informal handoff chains with no single quality owner.

They fixed the system first. Defined explicit review criteria. Established clear decision rights. Created a single quality owner per engagement. Redesigned the handoff sequence with verification checkpoints. Only then did they deploy AI-assisted review.

Review speed improved 40%. Client revision requests dropped 52%. Senior partner override time decreased 60%. Three months of design work prevented the 14-18 month failure cycles their competitors experienced. Organizations that invest in these capabilities see measurable returns. IBM’s 2026 CEO study, conducted with Oxford Economics across 2,000 CEOs in 33 countries, found that AI-first CEOs delivered 17% higher revenue growth over the past three years, and the most future-focused CEOs had scaled 23% more AI initiatives across the enterprise. Behavioral upskilling that fosters genuine change shows 2.7x higher implementation success rates.

The System Alignment Diagnostic provides five steps before any AI deployment:

1. Map the Decision Flow. Trace how decisions actually move — not the org chart, the real path from data to action. If the gap between data-available and action-taken exceeds 48 hours in a workflow you plan to accelerate, that workflow has a decision flow problem AI will amplify.

2. Test Ownership Clarity. At each consequential decision point, ask: “If the AI gives you a recommendation right now, can you act on it without calling a meeting?” If the answer requires a committee, the workflow will stall regardless of model quality.

3. Assess Process-Outcome Alignment. Ask: “If we stopped this process entirely for two weeks, what would break?” If nothing measurable breaks, AI acceleration is waste at higher speed. This is the most immediately actionable test — run it before anything else.

4. Design the Verification Architecture. If the cost of checking AI output exceeds 60% of manual production cost, the deployment will not achieve meaningful ROI without first redesigning verification. AI generates at 10x speed; verification remains at 1x. The backlog grows, quality drops, and the initiative gets labeled a technology failure.

5. Run a Misalignment Stress Test. After a successful pilot, remove the executive sponsor for two weeks. Introduce a competing priority. Generate an intentionally ambiguous AI output. If any scenario produces breakdown, the system is aligned to pilot conditions, not organizational reality.

When you trace a decision through your organization, you will notice where it stalls. That stall point is your real bottleneck — not the speed of generation.

A caveat: small teams under 15 where ownership is naturally clear, contained tool replacements with no workflow integration, and situations without an executive sponsor who can act on findings — the diagnostic adds overhead that exceeds its value when alignment is already obvious through proximity.

The Difference Is Not Execution

The distinction matters: implementation assumes the underlying structure remains valid. Transformation implies it does not.

When organizations treat transformation as implementation — executing faster within a broken system — they reinforce the failures the transformation was intended to address. Activities are completed. Tools are deployed. Processes are updated. But the system continues to exhibit the same constraints because no one redesigned the structure. I keep seeing organizations celebrate the deployment milestone while the original problem persists, now running at higher speed.

Pick one workflow where AI has stalled or underperformed. Run the two-week test: if you stopped it entirely, what would break? Trace one decision through the system and find where it stalls.

That is your starting point. Not a new model. Not a new vendor. Not a faster pipeline.

The technology can work while the surrounding system remains misaligned. Start with the decision or handoff that stalls, and give the faster output a path to a useful outcome.


References

About the author
Héctor Reinoso writes about how organizations should be designed when intelligence becomes abundant. He works on enterprise AI adoption inside a large industrial organization, after 25 years as a strategy consultant and transformation executive across four continents. Harvard MBA, industrial engineer, and still writes the code he writes about. More →