Why AI Works Great on Your Laptop and Breaks Down in Your Business
The numbers being reported right now don’t add up, and they’re worth sitting with for a minute.
Global enterprise spending on AI is projected to hit $2.52 trillion in 2026 — a 44% year-over-year increase. Eighty-nine percent of CIOs plan to grow their AI budgets. Average corporate AI allocations have doubled, now running roughly 1.7% of total revenues.
And yet: 56% of chief executives report that AI has yielded neither increased revenue nor decreased operating costs over the prior twelve months. Seventy-two to seventy-four percent of organizations either break even or lose money on their AI initiatives. Only 16% of AI projects scale beyond a pilot to enterprise-wide deployment.
If this story feels familiar, it should. I watched a version of it play out on a much smaller scale a decade ago with RPA.
The productivity illusion
Let me be clear about what’s not in dispute: AI genuinely works at the task level. Controlled experiments show developers using AI pair-programming tools complete coding tasks 55.8% faster. Writing is faster. Research is faster. Document review is faster. The tool is not a con.
But here’s the thing about speeding up a single step in a multi-step process: it doesn’t speed up the process.
There’s a phrase in the research that I think names the dynamic precisely: productivity theater. If a developer writes code 50% faster, but requirements gathering, security review, compliance audit, and deployment still run on the same manual timelines they always did, you’ve accelerated the part of the pipeline that wasn’t the bottleneck. The process doesn’t get faster. The bottleneck just shifts downstream.
This is why McKinsey can report that 88% of organizations now use AI in at least one business function — and simultaneously report that only 39% attribute any EBIT impact to it. The tools are everywhere. The returns aren’t. Most organizations have less than 5% of their earnings tied to AI use at all.
AI is making a lot of individual contributors more productive. It is not yet making a lot of businesses more profitable. That gap has a specific cause.
The wall is familiar
Sixty percent of enterprise AI leaders identify legacy system integration as their single greatest barrier to deploying agentic AI. More than skill gaps. More than budget constraints. More than data quality. The plumbing.
Legacy systems — the Oracle ERP instances, the SAP environments, the COBOL-based mainframes handling core financial transactions — were engineered for stability, not flexibility. They run on nightly batch cycles. They don’t have event-driven architectures. Many of them lack modern APIs entirely. They update databases silently, without signals that downstream systems can act on.
Agentic AI needs the opposite of all that. It needs real-time data access, event-driven triggers, and structured API endpoints to write back to systems safely. Without those, an AI agent is either working off stale data or trying to screen-scrape its way into a system that was never designed to be automated that way.
That last part should sound familiar. It’s exactly what early RPA deployments looked like. We screen-scraped because there were no APIs. We scheduled batch runs during off-peak hours because the systems couldn’t handle real-time interaction. We built fragile automations that broke whenever the UI changed. We learned, slowly, that the automation was only as good as the integration underneath it.
But even when we solved the integration problem, there was a second wall waiting: what I’d call the happy path trap.
In RPA, the “happy path” is what’s written in the process documentation — the clean, sequential version of how a task is supposed to work. It’s almost never how it actually works. We could automate the happy path in a few weeks. The problem was that the happy path might represent 60% of transactions on a good day. The other 40% were variations, exceptions, edge cases — the things the documentation didn’t mention because the process owners had been handling them by feel for years.
If you stopped building the automation at the happy path, you had a bot that processed the easy stuff and dropped everything else on the floor. To build something that actually worked, we spent as much time with process owners mapping what could go wrong as we did building the automation. And for exceptions that couldn’t be handled programmatically, we built what we called an “off-ramp” — a deliberate handoff to a human, with context, before something broke.
AI deployments have the same problem, with one critical difference: RPA breaks loudly when it hits an exception it can’t handle. The bot stops, throws an error, someone intervenes. An AI model doesn’t stop. It generates a response. That response may be confidently, plausibly wrong — and without explicit exception routing built into the design, it may reach your customer or your system before anyone catches it. The Klarna chatbot didn’t fail loudly. It kept answering, in complete sentences, on questions it had no business answering.
The happy path trap has always been expensive. AI makes it quieter.
The cautionary tale everyone should read
In early 2024, Klarna — the Swedish buy-now-pay-later company — announced that their AI chatbot was doing the work of 700 full-time customer service agents. It had resolved 2.3 million conversations in its first month. Average ticket resolution time dropped from 11 minutes to under two. The company projected $40 million in profit improvement.
By early 2026, Klarna was rehiring human agents on gig worker contracts.
The chatbot had handled routine, high-volume inquiries efficiently — password resets, shipping status, standard account questions. The happy path. But complex financial disputes, fraud cases, and emotionally charged situations? The system couldn’t handle them. It had no mechanism to detect when it was in over its head. No off-ramp. It kept generating plausible-sounding responses to problems it couldn’t solve.
The result: a 340% spike in escalations to the remaining human staff. Customer satisfaction collapsed. The workforce that remained was overwhelmed, because Klarna had already reduced its capacity in anticipation of the AI handling the load.
CEO Sebastian Siemiatkowski offered a candid postmortem: “cost unfortunately seems to have been a too predominant evaluation factor,” resulting in what he called a severe drop in quality.
I’ve heard that admission before. Different technology, same dynamic. RPA implementations scoped to reduce headcount rather than improve process flow had identical failure signatures — the automation handled the easy cases and routed everything messy back to fewer humans at higher volume and higher stress. Klarna is the most visible recent example, but it’s not alone. Block, Inc. (Square, Cash App) cut 8% of its workforce in 2025 to replace human capacity with AI, then watched institutional knowledge losses degrade payment accuracy and fraud detection. Morgan Stanley concluded that the cumulative cost of losing experienced operators exceeded the structural savings. Australia’s Commonwealth Bank deployed a voicebot that couldn’t handle complex inquiries, reversed 45 redundancies, and issued a formal apology.
The pattern repeats because the mistake repeats: using AI as a cost-cutting instrument without accounting for what the humans being replaced were actually doing — and without building the exception handling to cover what they handled by judgment.
What’s actually working
There are organizations getting real returns. Their approach is worth studying — not to replicate the scale, but to extract the sequence.
Walmart is the highest-profile example. They eliminated 30 million unnecessary delivery miles, compressed fashion production timelines by 18 weeks, and processed product catalog data at a rate that would have required 100 times the manual headcount. But the reason to study Walmart isn’t the results — it’s the discipline behind them.
Walmart didn’t deploy a general-purpose AI assistant and ask it to make operations more efficient. They identified specific, well-understood workflows, built purpose-built tools trained on their own data for each one, and created the integration infrastructure first. Every deployment was scoped tightly. Outcomes were defined concretely before deployment, not discovered afterward. When one approach worked, they systematized it and moved to the next workflow.
That sequence — specific problem, owned data, integration first, measured outcome — is replicable without Walmart’s resources. In practice, it means shifting the question. Instead of “how can we use AI across our AP process,” you ask: “What is the one highest-volume, most rule-bound step in our AP process, and what would it take to connect an AI tool directly to the data it needs to handle that step reliably?” The answer usually reveals either a solvable integration problem or a data quality problem you needed to address anyway. Either way, you’ve learned something useful before spending anything significant.
The organizations failing at this are, broadly, doing the opposite — deploying general tools across wide process areas and hoping efficiency emerges. It usually doesn’t, because there’s no integration, no scoping, and no definition of success beyond “we’re using AI now.”
There’s a related finding on investment allocation that deserves more attention than it gets. Organizations that treat AI deployment primarily as a software purchase — heavy spend on licenses, minimal investment in training and change management — achieve an average return of around 47% on their AI investment. Organizations that flip that ratio, spending significantly more on training, workflow redesign, and change management than on the technology itself, achieve returns of 134% to 158%. Add board-level governance and it goes above 171%.
Most AI budgets are heavily weighted toward technology. The empirical evidence says the real multiplier is the human readiness investment. This is a reallocation argument, not a “spend more” argument — and it’s one any operations leader can make to the people holding the budget.
Three questions worth asking before the next AI initiative
For operations leaders handed AI responsibility — often with a mandate from above and an unclear path from below — the research points to a more useful starting frame than “which AI tool should we buy?”
The first question is integration: Is this tool connected to my actual operational systems, or is it working alongside them? Productivity gains at the task level are real, but they don’t move the P&L unless the tool is integrated into the workflows that drive business outcomes. If your finance team is drafting analyses faster but those analyses still feed into a manual approval process and a decades-old ERP, you’ve moved the bottleneck, not removed it.
The second question is scope: Have you mapped the full process — including the exceptions — or just the happy path? That distinction determines whether you’re building something that handles 60% of transactions or 95%. The gap between those numbers is where most AI initiatives quietly fail.
The third question is failure mode: What happens when the AI gets it wrong? Every deployment in an operational context needs explicit, designed handling for the cases it can’t handle — an off-ramp to a human, with context, before the error reaches your customer or your system. Not as an afterthought. As a first-order design requirement.
The echo, one more time
The current AI adoption cycle is not going to play out identically to RPA. The capability is genuinely more powerful. The potential upside is larger. The technology matters more.
But the failure mode is structurally the same. Organizations are buying before they’ve built the integration foundation. They’re measuring individual productivity and calling it organizational ROI. They’re using a new technology to solve a resource cost problem rather than a process problem. And they’re deploying against the happy path without mapping what happens when reality shows up.
The 12% of companies actually getting both top-line and bottom-line results from AI — what PwC calls the “AI Vanguard” — aren’t doing something exotic. They’re doing what good process improvement has always required: understand the whole system before optimizing a part of it, build the infrastructure before deploying the tool, map the exceptions before you go live, and measure outcomes rather than activity.
The train is moving. The question is whether you’re driving it or whether it’s running over your budget.
What’s your experience with the gap between individual AI productivity and organizational ROI? I’d like to hear where you’ve seen it work and where you’ve seen it break.