Cyril Parkinson, the British naval historian who gave us Parkinson’s Law, once observed that “work expands so as to fill the time available for its completion.”

He was talking about the British Admiralty in the 1950s, but he might as well have been describing enterprise AI adoption in 2026.

I saw a statistic recently that stopped me mid-scroll. 78% of organisations have adopted AI in some form, but 74% report they’ve seen “minimal to no business impact” from their investment. Nearly four out of five organisations are doing the thing, and nearly three out of four aren’t getting value from it.

Parkinson would have recognised this immediately. The work — in this case, the activity of using AI tools — has expanded to fill the resources available. But activity is not the same as productivity, and that distinction is where the gap between adoption and impact lives.

The Subsidised Token Problem

Here’s the thing nobody tells you about enterprise AI adoption at scale. Most organisations roll out AI tools by giving employees a free token budget. “Here’s your Copilot licence. Here’s your Claude access. Go innovate.”

What happens next is entirely predictable to anyone who’s seen the free-pizza-in-the-break-room phenomenon. When something is free, consumption is unlimited. And when consumption is unlimited, people find ways to consume.

Consider Uber. In early 2026, Uber burned through its entire annual AI budget in just four months. Engineers were spending $500 to $2,000 per month each on Claude Code and Cursor. The company even ranked engineers on internal leaderboards based on usage — gamifying token consumption. The teams driving adoption were not the teams managing the spend, and that organisational gap turned out to be the load-bearing flaw.

Or take Tesla. By mid-2026, Tesla was forced to cap employee AI spending at $200 per week after engineers burned through thousands in tokens weekly. The heaviest users were running up weekly bills in the thousands. Interestingly, the cap didn’t apply to beta versions of xAI products — Elon’s own company’s tools were exempt.

And the trend extends well beyond the usual suspects. Meta’s internal AI costs are approaching billions, forcing the company to impose usage caps across its engineering teams. Amazon scrapped its own token leaderboard after employees gamed the system to boost their usage rankings. Walmart, Cisco, and a growing list of Fortune 500 companies are all pushing workers toward cheaper models and capping internal AI tool budgets.

Enterprise AI expenses jumped roughly 320% between 2024 and 2026. The average annual AI budget rose from $1.2 million to $7 million. Individual engineers were spending $500-$2,000 per month each, and teams burned through quarterly budgets in months.

This is Parkinson’s Law in action. Give people a token budget, and they will find ways to spend it — not because every use case is valid, but because the tokens are there. The gamification of consumption (leaderboards, usage metrics, innovation KPIs) accelerates the problem. Engineers start asking “what can I use AI for?” instead of “what problem am I solving?” And those are very different questions.

The Pre-AI Baseline Problem

There’s another trap that organisations fall into when measuring AI’s impact, and it’s more subtle.

When a company measures the before-and-after of AI adoption, they almost always compare against the organisation’s worst moments. The incident that took 12 hours to resolve. The report that was three days late. The deployment that went wrong at 2am on a Saturday.

Of course AI looks good against those baselines. A chatbot that resolves an incident in 2 hours instead of 12 looks like a miracle. But was the 12-hour incident the norm, or was it the outlier? Were most incidents already being resolved in 4 hours by competent humans with good processes?

This is survivorship bias applied to operational metrics. You remember the disasters because they were memorable. You forget the thousands of routine operations that ran smoothly without AI. By benchmarking against your worst moments, you make the AI uplift appear artificially dramatic.

The honest comparison isn’t “AI versus our worst day.” It’s “AI plus good process versus good process alone.” And when you run that comparison, the gap narrows considerably.

Before You Add AI, Ask: Do You Need Automation Instead?

Here’s a question that rarely gets asked in the rush to adopt AI: does this problem actually need an LLM, or does it need a simple deterministic script?

A huge proportion of the use cases I see being thrown at AI tools are not reasoning problems. They’re pattern-matching problems. Data transformation. Report generation. Alert routing. These are things we’ve been automating with Python scripts, SQL queries, and business rules engines for decades. And those approaches are cheaper, faster, more reliable, and fully auditable.

The risk of skipping straight to AI is that you introduce scope creep. An LLM-based solution invites tinkering. “Can you make it also do this? And this? And what about this edge case?” Because the tool seems flexible, the boundaries of the task expand. Before long, your “simple report generator” has become a sprawling prompt chain that costs $500 a day in tokens and hallucinates quarterly results.

The better approach is to lock the LLM behind a deterministic process. Let the script do the grunt work — fetch the data, validate the inputs, structure the output. Drop the LLM in only at the point where actual reasoning is required. And keep a human in the loop for anything that matters.

The LLM is a component, not a solution. Treat it like one. And be prepared to rapidly switch it out for another component, should that token bill become too big for the benefits it delivers.