System Integration: The Real Bottleneck in AI Adoption

Why Everyone Is Suddenly Talking About System Integration Again

For a few years, the AI conversation was almost entirely about models: which one reasons better, which one hallucinates less, which one is cheapest per token. That conversation has quieted down, not because model quality stopped mattering, but because most businesses have already picked tools and hit the actual bottleneck — getting those tools to talk to everything else they run.

I'm seeing this show up in almost every strategy conversation I have right now. A company has a CRM, an ERP or a patchwork of spreadsheets that function like one, a support desk, a handful of AI copilots bolted onto different departments, and no coherent way for any of it to share data without a human copying and pasting between tabs. That gap has a name — system integration — and it's the reason a lot of AI pilots that looked great in a demo never make it into daily operations.

Part of what's driving the renewed attention is a genuine shift in the tooling itself. Anthropic released the Model Context Protocol as an open standard in November 2024, giving AI models a common way to connect to external tools, files, and data sources instead of requiring a custom-built API bridge for every single connection. Other model providers have since adopted or built compatible support for it. That's a real structural change, not hype — it means the cost of connecting an AI system to, say, your document store or your project management tool is dropping. But a cheaper connector doesn't solve the harder problem underneath it, which is deciding what should be connected, in what order, and who's accountable when the connection breaks.

What "System Integration" Actually Means in an AI Context

Before AI entered the picture, system integration mostly meant getting two pieces of business software to exchange data — your accounting system talking to your e-commerce platform, say. The discipline hasn't changed. What's changed is the number of systems in play and the fact that one of them is now making decisions, not just moving data.

I think about AI system integration as three layers stacked on top of each other:

• Data integration — getting the AI system access to the information it needs, from the places that information actually lives, in a form it can use. This is unglamorous and it's where most projects actually die.
• Workflow integration — embedding the AI's output into the sequence of steps a person or another system already follows, so the output triggers the next action instead of sitting in an inbox waiting for someone to notice it.
• Governance integration — making sure the connections themselves are logged, permissioned, and reviewable, so when something goes wrong you can trace it back to a specific data source or handoff instead of shrugging.

Most vendors selling AI tools talk almost exclusively about the first layer, because it's the one their product touches. The second and third layers are where the actual value — or the actual risk — shows up, and they're usually the client's job, not the vendor's.

The Four Ways Companies Actually Connect Their Systems

There isn't one right way to integrate AI into an existing stack. There are four common patterns, and each one trades speed for maintainability in a different place.

The mistake I see most often is a company defaulting to whichever option their current vendor happens to sell, rather than matching the approach to how many systems they actually need connected and how much internal capacity they have to maintain it. A ten-person company gluing together six point-to-point APIs has quietly taken on a part-time integration engineer's worth of maintenance work, usually without realizing it until something breaks during a busy week.

I've written before about how this plays out when nobody notices the accumulation happening — see why too many apps are killing your business growth — but integration debt and app sprawl are really two faces of the same problem. Every new tool is a new integration decision, whether anyone frames it that way or not.

Where Integration Projects Actually Fail

In my experience, integration failures rarely come from the technology itself. APIs generally work as documented. What fails is the planning around them.

Nobody owns the connection after launch. A developer or a consultant sets up the link between two systems, it works on day one, and then six months later a vendor changes their API version and nobody notices until data stops flowing. Integration is not a project with an end date. It's an ongoing operational responsibility, and it needs a name attached to it, not just a line item in a project plan.

The integration becomes a person instead of a system. This is the failure mode I probably see most often in small and mid-sized companies. An employee starts manually re-entering data from one system into another because building the real connection felt too expensive or too slow, and eighteen months later that employee's job has quietly become "the thing that keeps our systems synced." I've written a full breakdown of this pattern and how to fix it in when employees become the integration layer, because it's more common, and more expensive, than most leadership teams realize.

Data quality problems get exposed, not caused. AI integration projects have a habit of surfacing years of inconsistent data entry that nobody had to reconcile before because no automated process was reading it closely. The AI isn't the problem. It's the flashlight.

Governance gets bolted on after the fact, if at all. This is the one I'd flag hardest to any leadership team moving quickly. ISO/IEC 42001:2023, the international standard for AI management systems, requires under clause 6.1.2 a formal AI risk assessment — and that assessment has to account for the data flowing into and out of the AI system through its integrations, not just the behavior of the model itself. If your AI tool pulls customer records from three different systems and writes decisions back into a fourth, each of those connections is a place where access control, data accuracy, and audit trail all need to be designed in from the start, not patched in after an incident. The NIST AI Risk Management Framework, published in January 2023, makes a similar point under GOVERN 6.1, which calls for organizations to identify and manage risks tied to third-party and supply-chain dependencies. Most integrations are exactly that kind of dependency. NIST treats them as a distinct risk category, not an afterthought.

A Simple Framework for Deciding What to Connect First

When a client asks me where to start, I usually push back on the instinct to integrate everything at once. Instead, I ask three questions about each candidate connection.

1. Does this connection remove a manual step that happens daily, or one that happens quarterly? Daily manual steps compound. A connection that saves fifteen minutes a day is worth building before one that saves three hours once a quarter, even though the quarterly task looks more dramatic on paper.
2. What happens if this connection is wrong, not just missing? A broken integration that simply doesn't run is an inconvenience. A broken integration that runs and silently pushes wrong data — a stale price, an outdated inventory count, an old customer address — is a liability. Rank connections by the cost of being silently wrong, not just the cost of being absent.
3. Who inherits this connection when the person who built it leaves? If the answer is "nobody knows," that's a sign the integration needs documentation and an owner before it needs another feature.

Running candidate integrations through those three questions tends to produce a very different priority order than "build whatever the loudest department is asking for," and it's a more honest starting point for a roadmap.

The Middleware Question: Build, Buy, or Wait

A question I get constantly right now: should a company build custom middleware, buy an iPaaS subscription, or just wait for their existing AI vendors to ship native connectors?

My honest answer depends less on budget than on how many systems are actually involved and how central they are to revenue. If a company has two or three core systems and the connections between them are stable, an iPaaS tool is usually the right call — it's fast to stand up and doesn't require dedicated engineering headcount to maintain. If a company has eight or more systems with genuinely different data models, custom middleware earns its cost because it gives you a single source of truth for how data moves, instead of eight separate point-to-point relationships that each need their own maintenance.

Waiting for native connectors is a reasonable strategy only if the connections you need aren't urgent and you're comfortable with the manual process in the meantime — because native connector coverage, even with an open standard like MCP behind it, is still uneven across less common business tools. It's a good bet for well-known platforms and a bad bet for anything niche or homegrown.

None of these choices are permanent. I tell clients to think of their integration architecture the way they'd think of office space: right-sized for where the business is now, with a clear sense of when it'll need to change, not built for a scale that hasn't arrived yet.

What Good Integration Looks Like in Practice

A well-integrated system doesn't look impressive from the outside. That's actually the point. Data moves between systems without anyone thinking about it, errors surface as alerts instead of angry customer calls, and adding a new tool is a scoped project with a known cost instead of an open-ended risk. The teams that get this right tend to share a few habits:

• They document every integration point in plain language, not just in code comments.
• They assign an owner to each connection, not just to the initial build.
• They revisit their integration map on a set schedule instead of only when something breaks.

If any of this sounds like it's describing a gap in your own operation rather than a solved problem, that's worth naming honestly before adding another AI tool to the stack. An AI readiness assessment is where I'd start that conversation, because integration planning only works once you know what you're actually integrating and why.

FAQ

What's the difference between system integration and automation? Automation is a task running without a person triggering it each time. System integration is the underlying connection that makes the data available for that task to run on. You can automate a broken integration and just get wrong answers faster.

Do small businesses need custom middleware, or is an iPaaS tool enough? For most small businesses connecting three or four core systems, an iPaaS platform like Zapier, Make, or n8n is enough and far cheaper than custom development. Custom middleware becomes worth the cost once you're managing eight or more systems with genuinely different data structures, or once uptime and data accuracy carry real financial risk.

What is the Model Context Protocol and does it replace traditional integration work? MCP is an open standard Anthropic released in November 2024 that gives AI models a common way to connect to external tools and data sources. It reduces the amount of custom connector code needed for supported systems, but it doesn't remove the need to decide what should be connected, govern the access, or maintain the connection over time.

How do we know if our integration setup is a compliance risk? If your AI system reads from or writes to more than one business system and nobody can produce a current map of those connections along with who has access to each one, you have a gap. ISO/IEC 42001:2023 clause 6.1.2 and the NIST AI RMF's GOVERN 6.1 both treat this kind of undocumented dependency as a risk category in its own right, not a minor technical detail.

What's the first sign that an integration has quietly become a manual process again? Watch for an employee who's become the unofficial "translator" between two systems — someone who re-keys, reformats, or double-checks data because the automated connection either doesn't exist or isn't trusted. That's usually a sign the integration was never finished, not that it isn't needed.

Last updated: 2026-08-25