Your AI Project Is stalling in the Integration Layer, Not the AI Layer

Let me give you a real number. We worked with a healthcare operator in Ohio last year. Signed in August 2024. The AI vendor showed a demo that was genuinely impressive. Radiological imaging, anomaly flagging, the whole thing. By October they had a signed contract. By May 2026, they were still running a pilot that had not expanded past the first test environment.

Why? The AI worked fine. Still works fine. The problem was buried in a question nobody asked during the sales cycle: how does this thing actually connect to our PACS system from 2007?

That question. It eats projects alive.

The thing I tell clients constantly, and I only half joke about it, is that the AI itself is not the hard part anymore. The models are solid. The inference is good enough for most production environments. What nobody has solved cleanly is the layer underneath. Your integration. Your data pipelines. The infrastructure that feeds the model.

Gartner has been publishing data for years showing that about 70% of enterprises still run on legacy infrastructure. Same research house says roughly 50% of AI projects fail. Combine those two facts and you stop looking at this as an AI problem. You start looking at it as an infrastructure problem.

RAND put the figure higher in a report I keep returning to. 80% of AI projects never reach full production. The most commonly cited reason in that research was integration complexity with existing enterprise systems.

Your legacy stack is what is killing your AI project. Not the model.

That Demo Was Not the Product

I have this conversation with new clients all the time and it never gets easier to explain: the demo environment is not the product. The demo is a stage. Someone spent weeks getting that demo environment right, cleaning the datasets, smoothing the API connections, making sure every output looked exactly as expected.

The product is what happens on day one when you connect it to a system that was built in 2011 and has been patched by four different IT teams since.

Take that radiology example. The pitch showed the AI reading scans and flagging anomalies. What the pitch deck did not include was what happens when the AI tries to pull from a PACS system running on proprietary DICOM variants that have not been normalized since installation. One of our clients ran into exactly this. The vendor told them to plan for two weeks of integration work. It took six months.

Six months.

I have watched this same scene play out in telecom, in logistics, in financial services. The AI gets evaluated on its own, performs well in isolation, the contract gets signed. Then the integration work starts and you find out your CRM has duplicates across 30% of your customer records, or your inventory management system has not been updated since the first Obama administration, or the ERP has a module that nobody on the current staff knows how to touch without breaking something else.

The AI works fine. The AI always works fine. Everything around it is where things slow down and eventually stop.

Start With the Plumbing

When we get involved in a new enterprise AI engagement, the opening conversation is never about the AI. It is always about the existing infrastructure. What systems are in place. How do they communicate today. What happens when you try to thread a new data feed into a workflow that three different teams have modified over ten years without ever being in the same room together.

First deliverable we produce is an integration map. Not a technical spec, not a vendor scorecard. A plain-language diagram of how data moves through the organization right now. Where the data is clean. Where it is messy. Where two systems stopped talking to each other three years ago and nobody documented why.

Clients are consistently surprised by what this map shows. One manufacturing company in Ohio was sure their ERP was solid. Clean exports, well-structured databases. The integration map told a different story. Their ERP was five separate systems from four acquisitions, all running on slightly different schemas, none of which had been normalized since the acquisition closed in 2018. The AI project they were about to sign would have been ingesting garbage from day one.

We caught it before the contract closed. That is the kind of outcome that makes the whole engagement worth it.

The rule I keep returning to: give integration discovery equal time with AI vendor evaluation. If you are spending two months choosing an AI platform, spend two months understanding your own infrastructure. Almost nobody does this. They treat integration as an afterthought, something the vendor will handle.

The vendor will handle it. The timeline will be three times longer than what they told you. The cost will be double.

Better to know that before you sign, not after.

The Data Is Probably Not Ready

Here is the reason most AI projects fail that never appears in the vendor pitch deck. Your data is almost certainly not ready for AI. And when I say almost certainly, I mean that based on what we have seen across more than 120 clients in ten years, the probability approaches certainty in almost every engagement.

Duplicate records. Missing fields. Naming conventions that changed every time a new person took over the system. Dates stored in four different formats across the same database. This is what most CRMs look like after a few years of no formal data governance. This is what most ERPs look like. This is what your system looks like.

A telecom client of ours ran into this directly. They were deploying an AI system to automate first-line customer support responses. The AI performed beautifully in the test environment. In production, it started generating responses that referenced account information from the wrong customers. The CRM had a duplication problem nobody had addressed. The AI was doing exactly what it was supposed to do, and the data was feeding it the wrong inputs.

We spent four months cleaning the CRM data before the AI could operate correctly in production. Four months of work that was not in the original statement of work. The client was frustrated. But there was no alternative.

Data quality work is unglamorous. It does not show up in demos. Vendors do not put it in their contracts. It is also the difference between an AI project that produces genuine value and one that produces a viral post on LinkedIn about a chatbot embarrassing the company on Twitter.

Before you sign anything, run an independent data audit. Not a self-assessment, not a vendor-led review. An independent audit with specific findings about completeness, consistency, and format standards. If it comes back clean, you are in better shape than most organizations. If it does not, you now know what the real first workstream is.

Why Your Vendor Is Not Telling You This

I have spent a lot of time on the other side of the enterprise software sales table, watching how vendors position AI deals. There is a structural problem in the procurement cycle that creates a persistent information gap between what vendors know and what buyers learn during the sales process.

Vendors sell to committees. Those committees are evaluating the AI in a demo. The integration complexity, the data quality issues, the legacy infrastructure challenges, none of that is visible in a demo environment. So it does not get evaluated. So it does not get discussed.

A Gartner analyst I spoke with off the record was direct about this. Vendors are selling to buyers who do not understand what they are buying. Buyers get excited about what the AI can do in a controlled demo. Vendors know that if they open with "you will need to fix your data and rebuild your integration layer before this works," they will lose the deal to a competitor who does not raise those issues.

The outcome is predictable misalignment. The vendor implementation timeline assumes certain conditions about your existing infrastructure. Those conditions do not exist in most enterprise environments. You discover this after you are contracted, after you are past the cancellation window, after you have invested internal resources in the project.

I am not suggesting all vendors are being deliberately misleading. Some are. Most are responding to the incentives the sales cycle creates. The information gap is structural, not malicious.

What you can do: ask specific questions about integration with your specific systems. Do not accept "we have worked with organizations like yours before" as an answer. Ask for case studies with similar technical environments, not just similar industries. Ask what the data looked like on day one for those clients. Ask for the actual implementation timeline from the last three deals in your sector. If a vendor cannot give you specifics, that tells you something.

Integration Is a Product, Not an Afterthought

When organizations decide to move forward with AI, they almost always face a choice that nobody frames as a choice. Bolt the AI onto what you have, or build the integration layer as its own distinct system.

The bolt-on approach looks attractive in the planning phase. Faster, cheaper, less surface area. It works when your existing systems are reasonably current and your data is reasonably clean.

The integration-layer-as-product approach is what we recommend for most complex enterprise environments. You build a dedicated middleware layer between the AI and the legacy infrastructure. This layer handles data transformation, format normalization, duplicate resolution, error handling. It insulates the AI from the mess that exists in most production environments.

The advantage: the integration layer can be updated and maintained independently of both the AI and the underlying systems. When something changes on one side, you update the integration layer rather than rebuilding the whole architecture.

The disadvantage: it is another system to build and maintain. That costs money and time and requires ongoing attention from a team.

In most enterprise environments, the dedicated integration layer is the right call. Bolt-on approaches look efficient in the planning phase and become maintenance nightmares over 18 months. We have seen organizations spend more fixing bolt-on integrations than they would have spent building the layer properly from the start.

There is another model that works in some environments. The phased integration. Do not try to deploy across the whole organization at once. Pick one business unit, one process, one data feed. Get the AI running there. Prove value. Expand gradually.

The phased model has a practical advantage beyond risk management. It forces you to confront your data quality and integration problems in a controlled scope before you have committed the entire organization to a project with uncertain outcomes.

Questions to Ask Before You Sign Anything

These are the questions I think every enterprise buyer should have answered in writing before signing an AI vendor contract. Not because vendors will lie to you, but because the ones who cannot answer these questions are the ones who will surprise you later with budget overruns and timeline slips.

• Walk me through how this connects to our specific systems. Not "it can integrate" but "here is the exact process, here is the timeline, here is what we need from you, here is what can go wrong."
• What will our data look like on day one? The vendor should be running a data assessment before the contract is signed, not after.
• What is the realistic implementation timeline for an environment like ours? Not the pitch deck timeline. The real one.
• What happens when this integration breaks at 2am on a Friday? What is the vendor response process and what does it cost?
• Who owns ongoing maintenance of the integration layer? Of the AI model? Of the data pipeline?
• Can you give me three reference clients with a similar technical environment, not just a similar industry?

If you cannot get straight answers to these questions, the vendor either does not know or is not telling you. Neither option is reassuring.

What an Honest Timeline Looks Like

When a client asks me for a project timeline on an enterprise AI integration, I give them a range, not a date. That range is usually about 60% longer than what the vendor proposed in the sales process.

I have been doing this long enough to know where timelines collapse. It is almost never the AI. It is the integration work that nobody planned for properly. Data that looked clean but was not. Legacy dependencies that nobody remembered until you tried to change something. APIs that had been deprecated two years earlier without any announcement.

A logistics client of ours estimated four months for their AI integration. It took eleven. The AI itself worked from month two. The eleven months were three legacy systems needing custom integration work, a data migration that exposed four years of duplicate records, and a vendor API that had quietly been deprecated with no announcement. Nobody had told us. Nobody had told the client.

The AI works great now. The client just wishes they had known what they were signing up for.

This is the part I find most frustrating about enterprise AI projects. The technology works. The models perform. The outputs are valuable. The problem is always underneath, in the integration layer and the data, and almost nobody wants to have the honest conversation about what that costs to fix properly.

My practical advice: when you build the business case for an AI project, add 50% to the integration timeline and double the integration budget. If that makes the project uneconomical, you have learned something useful before you signed a contract you cannot exit.

The Business Case Nobody Builds

Most enterprise AI project proposals include a section on expected ROI. That section is typically built during the vendor evaluation process. It is based on demo performance, industry benchmarks, and assumptions about how the organization works that may or may not be accurate.

That ROI analysis is missing the integration costs. Almost always.

Labor for integration work. Middleware and data transformation software. Vendor implementation fees. Internal team time. Ongoing maintenance of the integration layer. The cost of schedule delays while problems get solved.

When you add integration costs to the AI project budget, the economics shift. Sometimes they still work. Sometimes they do not. But you should know which one applies before you start.

I now recommend that clients build two separate business cases. One for the AI itself. One for the integration layer as its own distinct workstream, with its own budget, its own timeline, and its own team. When those workstreams are separated, it is much easier to see where the real costs and risks live. It also makes it easier to ask the hard questions about whether the AI project is worth the integration project underneath it.

The Takeaway Nobody Gave You

After doing this for over a decade across more than 120 clients in industries from telecom to healthcare to logistics, my honest read is this.

AI projects fail at the integration layer. Not because the AI does not work. Because organizations do not plan for the integration layer. They evaluate the AI, negotiate the contract, build the business case, and somewhere in that whole process they assume that connecting the AI to their existing systems is a problem the vendor will figure out.

The vendor will figure it out. The timeline will be three times longer than what they told you. The budget will be double.

The organizations that execute AI projects well are the ones that treat the integration layer as the primary workstream, not the secondary one. They ask hard questions before signing. They run independent data audits. They build the business case for the integration layer separately. They plan for the timeline to slip and they have a contingency for when it does.

If you are evaluating an AI project right now, here is what I would do in your position. Before you sign anything with a vendor, map your integration layer. Understand what you are connecting to, what the data looks like, and what "clean" would actually require. Talk to your internal IT team about the legacy infrastructure you are working with. Not just the vendor about the AI you are buying.

If the vendor cannot answer your questions about integration with specific detail, that is your answer.

The AI is ready. Your infrastructure might not be. Find that out before you sign.

The Hidden Cost Nobody Budgets For

There is a line item that appears in almost no AI project proposal. I have been looking for it for years. It does not show up in vendor statements of work. It does not show up in the ROI analysis that gets built during vendor evaluation. It does not show up in the project plan that gets handed to the implementation team.

It is the cost of dealing with your own legacy infrastructure during an AI project.

I am not talking about the planned integration work. I am talking about the unplanned stuff. The three am calls when the middleware stops processing because an upstream system changed a data format without telling anyone. The emergency data cleanse when you discover that 40% of your customer records have a null value in the field the AI needs to run inference. The vendor API that was supposed to be REST but turned out to be SOAP with custom XML namespaces that nobody has documentation for anymore.

We tracked this for a mid-size financial services client last year. They had a well-funded AI initiative with executive sponsorship and a realistic timeline. The original budget for integration work was $340,000. By the time the project reached full production eighteen months later, the actual integration spend was $890,000.

The AI itself was delivered on time and on budget. The integration layer was where the money went.

The gap was not waste. It was not vendor mismanagement. It was discovery. The existing systems had conditions that nobody knew about because nobody had ever tried to connect them to a modern AI platform before. Every time one of those conditions surfaced, it cost time and money to resolve. Some of those conditions took weeks. A few took months.

One of the conditions was a data format issue in a subsystem that handled mortgage underwriting documents. The format had not been updated since 2006. Nobody knew this until the AI tried to process its first batch of underwriting data and the middleware threw errors across three different integrations simultaneously.

This is not unusual. This is typical. Every legacy system has these conditions buried in it. The only question is when they surface and how much they cost when they do.

The organizations that manage this well are the ones who budget for it explicitly. They treat the discovery phase as a line item, not as overhead. They know that the first 90 days of an AI integration project are really a data archaeology project, and they staff it accordingly.

The organizations that do not manage it well are the ones who treat the discovery phase as a formality. They staff it with one junior analyst and expect the vendor to handle everything else. Three months later, they are in a budget review meeting trying to explain why the project is at 200% of its original integration budget and only 40% complete.

This is preventable. Not by predicting every hidden condition, but by budgeting for the ones you will find. Add a contingency of 40% to your integration budget and treat it as a project requirement, not a worst-case scenario. If you do not need it, you have run an unusually clean project. If you do need it, you are not presenting a budget overrun to your board six months in.

That is the practical advice I give every client who is building an AI project business case. Budget for what you will find. Plan for the timeline to extend. Staff for discovery, not just for deployment.

The AI will work. The question is what it will cost to make it work inside your specific environment. That question is worth answering before you sign.