Integration Infrastructure With Zero External Dependencies — And Why It's Now a Board-Level Requirement

By Aaron Gammon · Founder, Inferrex · June 2026

I sold data protection, backup, and recovery tooling into regulated enterprises for years before building Inferrex — energy, utilities, financial services, the kind of organisations where "where does the data live" is never a casual question. The thing I kept noticing was that the integration layer, the plumbing moving data between every system, was almost always the part nobody asked the hard sovereignty questions about. Everyone scrutinised the database and the storage. Almost no one scrutinised the pipes.

This piece argues that's changed, and that it's changed at board level rather than at IT level. Where I describe how Inferrex runs, I keep to what it does, not how it's built; the methodology stays proprietary. Live figures are at inferrex.com/claims.

For most of the history of enterprise software, the board's relationship to integration was simple: it didn't have one. Integration was infrastructure in the literal sense — the stuff in the walls. As long as the systems talked to each other, the question of how never reached the people signing off on risk.

That's ending, and the cause is a question that now gets asked in board papers and procurement reviews where it never used to appear: "what does this depend on that we don't control?"

It's a supply-chain question, and it arrived from several directions at once — geopolitics making cross-border data dependencies a strategic liability, regulators getting specific about residency and operational resilience, and a dawning awareness that "it's in the cloud" describes a dependency, not a location. Once a board internalises that a critical data pathway routes through infrastructure, models, and control planes owned by someone else, in a jurisdiction they don't choose, the integration layer stops being plumbing and becomes a risk on the register.

The uncomfortable part, when you actually trace it, is how many external dependencies a modern integration platform carries that nobody put on the diagram.

The control plane. Most "deploy anywhere" integration tools still phone home — licensing checks, configuration, orchestration, telemetry routed back to the vendor's cloud. The runtime might sit in your environment; the brain that runs it doesn't. Cut the link and the thing degrades or stops.

The AI calls. This is the one that's newest and least understood. The moment a platform's "AI" is a wrapper around a call to an external model provider, every piece of data that touches that feature leaves your environment — and you've taken on a dependency on a third party's model, availability, pricing, and terms. For a regulated buyer, an integration layer that ships data out to an external model on every ambiguous field isn't an AI feature. It's an egress problem wearing an AI badge.

Data egress generally. Even setting AI aside, plenty of platforms move, cache, or process your data through their own infrastructure as a matter of course. "We're just passing it through" is still your data on someone else's machine in someone else's jurisdiction.

None of these are visible on the architecture slide. All of them are answers to the board's question — and the answer is "more than you think."

If "runs in your environment" can still mean three different external dependencies, the phrase needs teeth. Here's the bar that actually matters.

It runs on your hardware. Not a runtime agent reporting to a cloud control plane — the whole thing, brain included, on infrastructure you control. Down to modest hardware if that's what the deployment calls for.

It runs on its own models. The AI that classifies fields and infers schemas is bundled, running locally, not a call to an external provider. This is the dependency most platforms can't shed, because their intelligence was never theirs — it was rented from a model API. If your integration layer's comprehension stops working the moment it can't reach the internet, it was never really yours. (I make the strategic case for owning the model layer separately; here the point is narrower: you cannot air-gap a dependency you don't own.)

It makes no external calls — and that's enforced, not promised. Zero egress at both the network and application layer, under a signed offline licence, in the sovereign and air-gapped configurations. Not "we don't intend to send your data anywhere." Can't. The difference between a policy and an enforced control is the difference a regulator cares about.

That's the standard. Anything short of all three leaves a wire running out of your environment to somewhere you don't govern.

The instinct, faced with this, is to assume sovereignty means a stripped-down, special, second-class version of the product — the "secure" edition that does less. That trade-off is exactly what shouldn't be necessary, and designing it in is a choice, not a law of nature.

The right shape is one platform that runs across a spectrum, same codebase throughout: Cloud (multi-tenant, managed) → Enterprise (dedicated, in your VPC, your keys) → Sovereign (self-hosted on your own Kubernetes, bundled models and connector library, offline licence) → Air-gapped (zero internet, zero telemetry, signed offline licence). What changes across that spectrum is what leaves the environment — at the air-gapped end, nothing does. What doesn't change is the capability. The air-gapped deployment isn't the platform with its arms cut off; it's the same platform, comprehension and self-healing intact, running with no line to the outside world. I make that counter-intuitive case in full in a companion piece.

That single-codebase-across-the-spectrum property is the thing that makes sovereignty a deployment choice rather than a different purchase — and it's only possible because the intelligence is owned and local rather than rented and remote.

For a large and growing set of buyers, none of this is a nice-to-have you'd pay extra for. It's the thing without which they cannot buy at all.

A defence-adjacent organisation cannot route its data through an external model provider. A central bank running a sovereign deployment cannot have a control plane phoning home across a border. A government department handling citizen data under a residency mandate cannot use a platform whose "AI" ships fields to a third party. A financial institution under operational-resilience rules has to be able to demonstrate that a critical data pathway keeps functioning with no external dependency. For all of them, the marketplace-app, cloud-first, call-an-external-model architecture isn't a weaker option — it's a disqualifying one.

This is the repositioning underneath the whole category, and it's worth stating plainly: integration middleware, for these buyers, has stopped being application software and become something closer to critical infrastructure — judged by the standards you'd apply to infrastructure, bought the way you buy infrastructure. I trace that shift, and what it does to how this software has to be built and procured, in a separate piece.

So here's the whole argument compressed.

The integration layer was plumbing, and plumbing didn't reach the board. Then boards started asking what their critical pathways depend on that they don't control — and the integration layer turned out to depend on a great deal: external control planes, rented models, quiet egress. That makes the choice of integration infrastructure a sovereignty decision, not an IT one. And a sovereignty decision has a clear test: does it run on your hardware, on its own models, with no external calls — enforced, not promised? Most of the category can't answer yes to all three, because their intelligence was never theirs to bring inside the wall.

I built Inferrex to run across that whole spectrum from the start, because I'd spent too long watching the integration layer be the unexamined dependency in otherwise careful organisations. The systems got scrutinised. The data store got scrutinised. The pipes carrying everything between them got a shrug.

Boards have stopped shrugging. That's the right instinct, and the organisations acting on it early are the ones who'll find, when the regulation or the geopolitics tightens further, that they already control the thing everyone else is suddenly scrambling to bring back inside the wall.