Every AI vendor demo ends the same way: "And it integrates easily with your existing systems via our API." This is, at best, a half-truth. Integration is where enterprise AI initiatives spend the majority of their time and budget, and it's the part that nobody wants to talk about during the sales process.
What You Need to Know
- Integration with existing systems consumes 60-70% of the total effort in enterprise AI deployments. The AI model itself is typically 15-20% of the work.
- "Easy API integration" assumes your source systems have clean, accessible APIs. Most legacy enterprise systems don't.
- The integration tax is not a one-time cost. Every upstream system change, data schema update, or workflow modification creates ongoing maintenance.
- Organisations that build shared integration infrastructure pay the tax once. Those that don't pay it on every project.
65%
of enterprise AI project effort goes to data integration and pipeline engineering
Source: Gartner, Data Engineering for AI Survey 2024
Where the Tax Hides
The Data Extraction Problem
Your AI system needs data from source systems. Those source systems were built 5, 10, or 20 years ago. They store data in proprietary formats, behind authentication schemes that predate OAuth, in databases with schemas that evolved organically over decades.
Getting data out of these systems is the first integration tax. It's not glamorous work: writing custom connectors, parsing legacy file formats, handling character encoding issues, managing rate limits on APIs designed for occasional human use rather than continuous machine consumption.
Real example: A document processing AI needs access to the claims management system. The claims system has an API. Technically. It returns XML with inconsistent field naming, paginates differently depending on the query type, and times out if you request more than 50 records. Building a reliable data pipeline from this API takes 3-4 weeks of engineering time. The AI model training took 3 days.
The Data Quality Problem
Source systems contain messy data. Duplicate records, inconsistent formats, missing fields, data entered by humans in creative ways ("N/A", "NA", "n/a", "-", "none", and "0" all meaning the same thing in different records).
AI models don't handle messy data gracefully. They amplify the mess. A classification model trained on inconsistent data produces inconsistent classifications. A document extraction model processing poorly scanned documents produces unreliable extractions.
Cleaning, normalising, and validating data before it reaches the AI model is a significant engineering effort. And it's ongoing. Data quality isn't a problem you solve once.
The Workflow Integration Problem
Getting AI to produce output is one thing. Getting that output into the workflows people actually use is another.
The claims officer doesn't want to check a separate AI dashboard. They want AI insights inside their existing claims management tool. The underwriter doesn't want to copy-paste from an AI output. They want the AI assessment to appear in their workflow at the right moment, in the right format, with the right context.
This means building integrations that push AI output into existing systems, which have their own data formats, validation rules, and workflow constraints. An AI system that produces brilliant analysis but requires users to change their workflow will be ignored.
3.2×
typical cost overrun on enterprise AI projects, primarily driven by integration complexity
Source: McKinsey, State of AI 2024
The Authentication and Security Problem
Enterprise systems have complex authentication: SSO, role-based access, data classification, audit requirements. Your AI system needs to respect all of these. It needs to access data with appropriate permissions, log every access for audit, handle PII according to your data classification policy, and integrate with your identity provider.
This is table-stakes security work, but it's rarely accounted for in AI project estimates. Building secure, auditable integrations that satisfy your information security team adds weeks to every project.
Why "Easy API Integration" Is a Lie
AI vendors demonstrate their product with clean, prepared data in a controlled environment. The demo works perfectly because:
- The data is already extracted, cleaned, and formatted
- There are no legacy system constraints
- Authentication is a simple API key
- The output goes to a purpose-built UI, not an existing workflow
- Edge cases have been carefully excluded
None of these conditions exist in enterprise production. The vendor's product may be excellent. The AI capability itself may work exactly as demonstrated. But the 70% of work required to connect it to your reality is your problem, not theirs.
Paying the Tax Once
The integration tax is unavoidable. But you can choose to pay it once or pay it on every project.
Paying it every time: Each AI initiative builds its own data connectors, its own authentication layer, its own data cleaning pipeline, its own workflow integrations. Project #3 costs as much as Project #1 because nothing is shared.
Paying it once: Build shared integration infrastructure: reusable data connectors, a common authentication layer, standardised data cleaning pipelines, an integration framework for pushing output to downstream systems. Project #1 is expensive. Project #3 is 40-60% cheaper because it reuses the foundation.
This is the compound advantage in practice. The integration tax doesn't go away, but a shared foundation means you pay the bulk of it once and each subsequent project adds incrementally.
What to Budget For
If your AI vendor says the project will take 8 weeks, here's a more realistic breakdown:
| Phase | % of effort | Typical duration |
|---|---|---|
| Data extraction and pipeline | 25-30% | 4-6 weeks |
| Data cleaning and normalisation | 15-20% | 2-4 weeks |
| AI model development and tuning | 15-20% | 2-4 weeks |
| Workflow integration | 15-20% | 3-5 weeks |
| Security, auth, and governance | 10-15% | 2-3 weeks |
| Testing and edge cases | 10% | 2-3 weeks |
Total: 15-25 weeks for a meaningful enterprise AI capability. Not the 8 weeks in the vendor's proposal.
The good news: if you've already built shared infrastructure from a previous initiative, the data extraction, cleaning, and security phases shrink dramatically. That's the compound effect.
- Should we build our own integration layer or use an integration platform?
- For most enterprises, a combination works best. Use integration platforms (MuleSoft, Azure Integration Services, etc.) for standard connector patterns. Build custom integrations only for legacy systems that don't have standard connectors. The key is standardising the approach so each new AI project doesn't invent its own integration architecture.
- How do we estimate integration effort for a new AI project?
- Count the source systems. For each, assess: Does it have a modern API? Is the data clean? Is authentication standard? Each "no" adds 2-4 weeks. If you have existing shared infrastructure, reduce by 40-60%. If this is your first AI project with no shared infrastructure, multiply the vendor's estimate by 2.5-3×.
- Can we reduce integration cost by choosing AI tools that work with our existing stack?
- Partially. AI tools that integrate with your cloud provider's ecosystem (Azure AI with Microsoft stack, for example) reduce some friction. But the core integration tax (extracting data from legacy systems, cleaning it, and pushing output into workflows) exists regardless of which AI tool you choose. The tool doesn't eliminate the tax; it might reduce it by 15-20%.