The AI Production Gap: Why Enterprises Stall Between Strategy and Systems

A few weeks ago I was in Innsbruck, sitting with the IT leadership of a manufacturing company. Good people, serious about what they're doing, not chasing hype. They walked me through their AI strategy — the one they'd been working on for close to a year. Roadmap, maturity model, use case taxonomy, two proof-of-concepts running. Board fully behind it. "So what's actually in production?" I asked. Long pause. "Nothing yet." I've had this conversation — with minor variations — maybe fifteen times in the last six months. Manufacturing in Innsbruck, insurance in Munich, public sector in Vienna. The punchline is always the same. The strategy exists. The PoCs exist. Production doesn't. And every time I walk out of those meetings, I think: this isn't a technology problem. The models work fine. Cloud is ready. The tooling ecosystem is actually pretty solid right now. What's missing is the boring connective tissue that nobody wants to fund — the stuff between a strategic ambition and a system that actually runs, that someone can audit, that operations can own, and that the business trusts enough to depend on. I've been calling this the AI production gap. And honestly, in 2026, I think it's the most expensive problem in enterprise IT. Not because companies are failing to innovate — most of them genuinely want to. They're failing to ship.

Nobody Wants to Admit This Is Still Early

Gartner recently published something they call a "Generative AI Immaturity Model." Love the name. Their argument is refreshingly blunt: GenAI is early-stage technology where best practices haven't been codified. Full stop. You can't apply a traditional maturity framework to something that rewrites its own rules every quarter. I think this lands harder than most leaders want it to. Because most enterprise AI strategies are built on an assumption nobody questions out loud: that we're climbing a known ladder. Phase one, pilot. Phase two, scale. Phase three, transform. It's comforting. It fits in a roadmap. It's also wrong. The rungs keep moving. New models drop. The EU AI Act goes from "something to watch" to "something with real fines." The organizational capabilities you need expand in directions nobody predicted when the original strategy was written. The companies I see actually shipping AI into production? They've accepted the instability. They build to adapt. They treat their architecture as something that will change, not as a destination. Everyone else is still presenting the same PoC to the same steering committee for the third time, hoping this quarter someone will say yes to production. If that sounds familiar, it's not your team's fault. The problem is structural.

Where It Actually Breaks Down

When I dig into stalled AI initiatives — and this is a big part of what I do in early engagements with clients — the blockers are almost never where leadership thinks they are. "We need a better model." "We need more data." "The prompts need tuning." Sometimes, sure. But usually the real problem is much less glamorous. Vague specs kill AI projects. I keep coming back to this because I see it everywhere. My colleague Manuel Klein wrote a whole piece on it, and it resonated with me because I'd been experiencing it from the advisory side for months. The gap between what a stakeholder says they want and what an AI agent needs to actually execute reliably? It's enormous. In traditional software, experienced engineers patch that gap with instinct — they corner a product owner, read between the lines, fill in what's missing from years of domain knowledge. Nobody even notices it's happening. AI agents can't do any of that. They take ambiguity and run with it. Every gap a human used to quietly manage becomes a compounding failure — resolved autonomously, embedded in the codebase, and nobody catches it until it's too late. In regulated industries — banking, insurance, health, public sector — "too late" means an audit, a go-live review, or an incident. DORA, MaRisk, the EU AI Act — these frameworks don't just ask what your system does. They ask why it does it, how you know it's doing it correctly, and how you prove that to someone who wasn't in the room when the decisions were made. This is the problem that led us to develop what we call Intent Engineering. An intent isn't a requirement. It isn't a user story. It captures the actual business problem — with real numbers behind it — plus measurable success criteria, domain rules for edge cases, and hard constraints the system must respect. Precise on the what and why. Open on the how. Get this right, and the intent document becomes the evidence trail connecting every decision back to the business purpose that created it. Get it wrong — or skip it — and you end up with a system that works perfectly but solves the wrong problem. I've seen both. The difference is usually visible within the first two weeks. Nobody's measuring what matters. Here's a number from Gartner that should bother every CDO in the room: only 49% of organizations have business-outcome-driven metrics for their data and AI initiatives. Meaning: more than half can't answer "Is this working?" in terms the business cares about. They'll rattle off model accuracy, token costs, latency. They can't tell you if the system is actually driving the outcome it was built for. I find this genuinely alarming. Because without real evaluation loops — not dashboards, actual feedback mechanisms that change system behavior — AI systems just drift. The model that worked in testing degrades silently because the data shifted. The agent that handled edge cases last month starts hallucinating this month. The team that built it probably knows, but they don't have the instrumentation to prove it or the mandate to fix it. The handover cliff. This one's personal. Back when I ran Corporate IT, I inherited systems built by external teams who understood them inside and out. The problem was that understanding didn't transfer. We got a system we couldn't debug, couldn't evaluate, couldn't confidently modify. So what did we do? We limited its scope. Restricted its autonomy. The thing that was supposed to transform a workflow ended up running in a corner, doing less than it could, because we didn't trust it enough to let it do more. I see this pattern repeat constantly with AI projects now. A specialized team builds something impressive. They hand it over with documentation that's technically complete and operationally useless. The ops team becomes a caretaker of a black box. And slowly, the transformative AI initiative fades into irrelevance. Not because the tech failed — because the organization couldn't absorb it.

AI Is Coming From Everywhere (Whether You Planned For It or Not)

There's a Gartner concept I keep referencing in conversations — the "AI Technology Sandwich." The basic idea: AI is no longer flowing into your enterprise through one controlled channel. It's arriving from SaaS vendors embedding it into existing tools. From platform providers offering model APIs. From open-source projects. From shadow IT experiments. From business units buying their own AI services without telling anyone. (Sound familiar? It should. This is cloud adoption all over again, except faster and the stakes are higher.) And that creates a governance headache that didn't exist two years ago. The question isn't "How do we adopt AI?" anymore. It's "How do we govern AI that's already here — from five different directions, with five different risk profiles and five different accountability gaps?" For organizations that set up governance for one flagship AI project, this is a rude awakening. Every new AI capability brings its own evaluation needs, compliance surface, cost profile, failure modes. Without some kind of platform approach, every single one is a bespoke effort. The cost of running ten AI systems isn't ten times one. It's ten times one, plus the coordination tax, plus the governance overhead, plus the cost of the incidents that happen when they interact in ways nobody thought about. Ask me how I know.

You Can't Strategy-Deck Your Way Out of This

The enterprises that are actually closing the production gap aren't doing it with better slides. They're doing it with engineering platforms that make the hard parts repeatable. I've been working on this across engagements in banking, insurance, public sector, health, manufacturing for the past year. The blockers are remarkably consistent across all of them. So are the solutions. What works is a platform with clear layers that address the structural problems head on. You need an agent framework — the plumbing that every AI system requires but teams keep rebuilding from zero: tool registries, permission models, human-in-the-loop escalation, audit logging, safety constraints. When an agent takes an action, the framework makes sure it's logged, authorized, bounded, traceable. In regulated environments this isn't a feature. It's the price of getting into production at all. You need an LLMOps control plane — the infrastructure that handles life after deployment: prompt and model versioning, eval pipelines, cost routing and caching, release gating. Model update changes behavior? Caught. Costs spike because an agent's making unnecessary calls? Surfaced. Someone asks "what version of the prompt was running when that decision was made?" The answer exists. Without this layer, you're flying blind after launch. And you need a solid knowledge and retrieval layer — connectors, chunking strategies, retrieval, reranking, eval templates, monitoring. Most enterprise AI use cases boil down to getting the right information to the model at the right time. Doing that well — with access controls, freshness guarantees, quality metrics — is real engineering work. It shouldn't be reinvented for every project. The key principle: all of this deploys into the customer's own infrastructure. Their data stays with them. Their governance rules apply. The platform adapts to their constraints. (Not the other way around. That distinction matters more than you'd think.)

Two People and a Bunch of Agents

The platform also enables something I'm genuinely excited about, because it changes the economics of how AI gets delivered. Traditional enterprise AI projects need big teams. Business analysts, data engineers, ML engineers, frontend devs, QA, a PM, a scrum master. I've been on both sides of this — building these teams and receiving their output. It's expensive, it's slow to mobilize, and the handover artifacts are usually something the client's organization can't absorb. (See: handover cliff, above.) The model I've been developing and testing is what we call the Focused Impact Pair: an Intent Engineer and a Systems Engineer, working alongside AI agents. The Intent Engineer captures the business problem with enough structure that agents can actually execute — domain rules, constraints, success criteria, the stuff that used to live in people's heads. The Systems Engineer orchestrates the agents, makes architecture calls, manages quality gates, makes sure things are production-ready. The agents do the implementation work — code, tests, docs, multi-hour autonomous tasks. We recently ran an internal hackathon on this model. Teams of two. Weekend timeframe. Building complete AI engineering platforms. And the results tracked with what I'd been seeing at clients: small teams with clear intent and good tooling deliver what bigger groups struggle to finish. Here's what that means in practice: if the unit economics of delivery shift this much, the bottleneck isn't build capacity anymore. It's specification quality. Teams that invest time getting the intent right before letting agents loose on a codebase move significantly faster than teams that treat spec work as something that sorts itself out along the way. The second group ends up in a correction loop that eats every hour they thought they saved. I've watched it happen in real time.

If You Can't Prove It, You Don't Have It

Gartner's research on realizing value from data and AI makes a point I keep making in conversations, so I'll make it here too: the organizations that win with AI aren't the ones with the best technology. They're the ones where the AI leader has built a real relationship with the CFO. I know that sounds like soft advice. It isn't. Trust is built through evidence. Evidence requires infrastructure. If you can't show your CFO that an AI system cut processing time by 40% — with data from the system itself, not a project team's PowerPoint — you're asking for faith. Faith doesn't survive budget reviews. I've watched promising AI programs get defunded because the team couldn't demonstrate impact in language finance understood. The system was working. The evidence wasn't there. This is why I refuse to ship anything without evaluation infrastructure from day one. Not reporting — a control loop. Missing evidence? Confidence drops, output gets flagged. Deterministic checks and semantic scoring disagree? The contradiction surfaces, it doesn't get buried. System performing well? The metrics exist in a format a business leader can read and a compliance officer can audit. I wrote about this in my last post on building governable agents — three layers of trust. Retrieval trust: did we look in the right places? Decision trust: did we apply constraints correctly? Explanation trust: are we honest about what we know versus what we're guessing? Each layer needs its own evaluation, and each one has to be testable independently. Most agent systems collapse all three into a single LLM call because it's convenient. That convenience is exactly what makes them ungovernable. It works great in a demo. It breaks the first time someone with authority asks "why did it do that?" and nobody can answer.

What I'd Actually Tell You to Do

If you're running AI in a regulated enterprise right now, here's what I'd say — based on what I'm seeing across engagements, and from having been the person on the receiving end of AI projects in a previous life. Stop building everything from scratch. Every AI system needs evaluation, monitoring, governance, cost control, audit trails, knowledge management. If you're reinventing these for each project, you're paying a compounding engineering tax. Build platform capabilities once. Reuse them. The investment pays back on the second project. Spend more time on specification, not less. Gartner's Immaturity Model is right that best practices aren't codified yet. But that doesn't mean you wing it. It means upstream work matters more, not less. Structured intent. Measurable success criteria. Explicit constraints. Two or three conversations with the people who actually know the domain — the ones whose knowledge is locked in their heads because nobody ever asked them to write it down. Those conversations at the start of an engagement are worth more than almost anything in the build phase. Govern the portfolio, not the pilot. AI is arriving from multiple directions. Your SaaS vendors are embedding it. Your teams are building it. Business units are buying it without you. A governance framework that only covers your showcase project is — I'm sorry — a fig leaf. Design for the portfolio. Instrument before you launch. Don't deploy and then figure out how to measure impact. Define business outcomes. Build metrics infrastructure. Create feedback loops. This is the difference between a system that earns trust over time and one that loses it at the first incident.

The Gap Closes From the Engineering Side

The production gap won't close because models get smarter. It won't close because regulators ease up (they won't — not in Europe, anyway). It'll close because enterprises build the engineering infrastructure to ship AI systems they can trust, audit, operate, and measure. Strategy matters. I'm not dismissing it. But strategy without engineering infrastructure is a deck that ages. The organizations pulling ahead aren't the ones with the most ambitious AI visions. They're the ones that have quietly built the platforms, the eval pipelines, the governance layers, and the delivery models that actually turn vision into running systems. In regulated industries the bar is even higher. You can't hand-wave through a compliance review. You can't explain a hallucination to an auditor with "well, the model is probabilistic." You can't ask operations to own something they can't debug. Every shortcut you take in the build phase comes back as a tax in production — and in regulated environments, that tax comes with real penalties. I'll end where I started. The question for every IT leader right now isn't whether AI can deliver value. That debate is done. The question is whether you've built the infrastructure to capture that value reliably, repeatedly, and at a standard you can defend when someone asks hard questions. Because a strategy slide isn't a system. And at some point, you have to ship.

Sources

Gartner, "A Generative AI Immaturity Model" (G00818534, September 2024)
Gartner, "AI Technology Sandwich" (G00822907, October 2024)
Gartner, "Artificial Intelligence Primer for 2025" (G00822433, January 2025)
Gartner, "A Journey Guide to Realizing Value from Data, Analytics and AI" (G00819099, November 2024)
Manuel Klein, "Why We Created the Intent Engineer" (2026)