If you've run an AI pilot at your company, there's a good chance it's still a pilot. That's not a reflection on your team, and the picture is shifting faster than most people realize.
IDC's most recent research with Lenovo, fielded in late 2025 across roughly 3,100 IT and business decision-makers, is the source of both numbers above. That's real momentum. It also means a narrow majority still don't make it, and when we're brought in to find out why, the model is rarely the reason.
We work with mid-market and enterprise clients modernizing Oracle ADF systems, Java and Spring Boot applications, and legacy AWS environments, and the pattern is consistent. The AI works fine in isolation. It's the moment it has to talk to the system that actually runs the business where things fall apart.
Your pilot succeeded because it was built to
Proof-of-concept environments are easy mode by design. A clean data source, a well-documented API, scope narrow enough that nothing unexpected happens. That's the right way to validate an idea quickly, and it's also exactly why the pilot can't become the product on its own.
Production doesn't offer that luxury. It comes with years of accumulated complexity: undocumented internal services, schemas that represent the same concept differently across tables that were never meant to be queried together, batch-only data access where the workflow needed something closer to real time, and error handling written for a person debugging by hand, not a system parsing responses automatically.
None of that shows up in a demo. All of it shows up the week you try to go live.
The real bottleneck is the stack underneath the model
This isn't a fringe read of the situation. In Deloitte's 2026 survey on agentic AI readiness, fielded between April and June among 501 senior US decision-makers, 67% said integrating AI into their existing systems is too costly and complex, and 72% said they lack the unified, accessible data an agent needs to act on. Legacy infrastructure, not model capability, is the recurring theme.
It shows up sharper still in specific industries. A December 2025 survey of 100 mid-market decision-makers by Kaufman Rossin, reported by MarketScale, found 55% of manufacturers named legacy ERP integration as their top AI obstacle, against a 41% average across the broader mid-market. Every company in that survey runs an ERP system, and those systems were built for stability and predictability, not for exchanging data with a language model in real time.
For most mid-market companies, the barrier usually isn't the AI strategy. It's whatever the team built, or inherited, between 2008 and 2018, still running the parts of the business that matter most.
What "legacy" actually means here
Worth being precise, because the term gets used loosely. What actually blocks AI integration is a specific set of conditions:
The same concept, a customer, an order, a claim, represented differently across tables or services that were never designed to agree with each other.
Systems that only talk to one other system, in one direction, making it hard to insert a new consumer without touching everything upstream.
Data that updates overnight instead of on demand, which breaks any workflow that needs current information to act.
Institutional knowledge that lives in one engineer's head instead of anywhere written down.
None of these are exotic. They're the ordinary residue of running a business on software for a decade or more. They're also exactly what a rushed AI rollout runs into, and exactly what a careful one plans around from day one.
The gap between a working demo and a production system is almost entirely engineering discipline, not AI capability.
Three patterns that get AI into production
None of this requires ripping out what's already running the business. The organizations that get from pilot to production tend to lean on a small set of patterns that predate AI entirely, applied early rather than bolted on afterward.
An integration layer, not a rewrite
A middleware layer sits between the legacy system and the AI application, translating and normalizing data as it passes through instead of asking the old system to change. This is the anti-corruption layer from domain-driven design: the new system is protected from the old one's inconsistencies rather than inheriting them.
Shadow deployment before anything goes live
The agent runs alongside the existing process on real inputs, with its outputs logged and compared, before it's ever trusted to act independently. This is a standard MLOps pattern, sometimes called a dark launch, and it's built into the deployment tooling of AWS SageMaker, Google Vertex AI, and Azure ML for exactly this reason.
The strangler fig pattern
New capability gets built around the legacy core and gradually takes over specific pieces of functionality, so the system the business depends on keeps running the whole time instead of getting frozen for a rewrite. Martin Fowler described the underlying idea as the "strangler application" in a June 2004 post, still maintained today as the strangler fig pattern on martinfowler.com. It's a general answer to modernizing something you can't afford to break, and it applies just as well to AI integration.
Where this is headed: the agent as the strangler layer
A newer variant of this is starting to show up in engineering writing, sometimes called the agentic strangler. It's not an established pattern the way the original is; you won't find it in AWS's or Microsoft's official architecture guidance yet. But it names something real, and it's really the three patterns above collapsing into one.
Instead of a person writing static routing rules to decide whether a request goes to the legacy system or the new one, the agent makes that call at runtime: it discovers what's available through its own tools, checks the legacy system before trusting its own output, and falls back automatically when it isn't confident. The migration layer stops being infrastructure someone builds once and becomes a capability the agent exercises continuously.
Worth treating as a direction things are moving, not a shortcut. It still requires the same discipline as everything above (scoped tool access, an audit trail, a human able to override it), applied to a system that's now making more of its own routing decisions. That raises the stakes on getting the guardrails right. It doesn't lower them.
Layered on top of all of this, two things are worth building in from day one rather than retrofitting after an incident: a human-in-the-loop review step modeled as an explicit workflow state (proposed, approved, executed) rather than a vague fallback for when the agent is "not sure," and guardrails implemented as infrastructure the team owns, not prompt instructions the model might ignore under adversarial input. On AWS, that typically means Bedrock Guardrails wired into the request path from the start.
What this means if you're a mid-market company
Companies in this range are in a specific bind. Big enough to carry real legacy complexity: years of customizations, systems nobody fully documented, institutional knowledge scattered across a handful of long-tenured employees. Usually not big enough to have a dedicated platform team whose full-time job is untangling that before AI even enters the picture.
That's the gap that matters most to close. Not "can we build an AI pilot," most teams can, and most already have. It's "can we get it talking to what already runs the business, without a year-long replatforming project first."
The honest caveat
None of this is a guarantee. Some systems genuinely are too brittle, too undocumented, or too central to risk connecting to anything new without real investment first. If the underlying problem is data readiness rather than integration architecture, no pattern above fixes that by itself. Worth diagnosing which one you're actually dealing with before committing to either approach.
Where this leaves you
If your AI pilot has stalled, it's worth asking a more specific question than "why isn't this working." Ask instead: is this a model problem, or is this the fifteen-year-old system underneath it? In most engagements we see, it's the second one, and that's actually the better problem to have. It's solvable without starting over.
Have a stalled AI pilot?
We scope a narrow, production-ready first deployment, integrated with the systems already running your business, on Amazon Bedrock with the guardrails and observability regulated industries require.
Book a discovery call →