From AI SaaS to Critical National Infrastructure: The Repositioning Underway

By Aaron Gammon · Founder, Inferrex · June 2026

I spent eighteen years selling software into government and large regulated organisations, and I've written separately, at length, about what I think is wrong with how the British state handles its own data — that's The State Cannot See Itself, and I won't repeat it here. This is the companion argument, pointed forward: not "here's the problem," but "here's the category shift happening underneath it, and what it means for how this kind of software gets built and bought."

It's a thesis piece — argument first, sourced where it leans on a fact. Where it touches what Inferrex does, I keep to outcomes, not methods. Live figures at inferrex.com/claims.

There's a line that certain pieces of software cross, usually without anyone announcing it, after which they stop being applications and become infrastructure. The test isn't how big the vendor is or how much the licence costs. It's this: if it stopped working, would the organisation simply be inconvenienced, or would it be unable to function?

An app, by definition, is swappable. You can rip it out, replace it with a competitor, live without it for a fortnight while you migrate. Infrastructure isn't like that. You don't "swap out" the thing every other system depends on without the whole edifice wobbling. The electricity grid is infrastructure. The payment rails are infrastructure. The moment a piece of software becomes the layer through which an organisation's systems understand each other, it has joined that category — and it should be judged by the standards you apply to a power station, not the ones you apply to a productivity app.

The integration layer crosses this line earlier than almost anything else, because it's load-bearing for everything else. Every system that matters routes data through it. When it's healthy, nobody thinks about it. When it fails, everything connected to it fails with it. That is the textbook definition of infrastructure — and yet it's still routinely bought, built, and governed as though it were an app.

What's changed recently isn't the software. It's the question being asked about it.

Boards and procurement functions in serious organisations have started asking, of every critical pathway: what does this depend on that we don't control? It's a supply-chain question, and it's arrived from geopolitics, from regulators getting specific about operational resilience, and from a slow realisation that "it runs in the cloud" names a dependency rather than a location.

For an integration layer, the honest answer to that question is usually alarming, because modern middleware carries dependencies nobody drew on the diagram — a control plane that phones home to the vendor's cloud, and, increasingly, an "AI" feature that is really a call out to an external model provider, shipping your data across a boundary every time it fires. I trace those hidden dependencies in detail in the sovereign-infrastructure piece. The point here is what it does to the category: the instant a board recognises that a load-bearing data pathway depends on infrastructure, models, and jurisdictions it doesn't control, the integration layer stops being a line item and becomes a strategic risk. And strategic risks get governed like infrastructure.

For a decade, "it's in the cloud" was a reassurance. It meant modern, scalable, someone-else's-problem. For a growing set of buyers it now means the opposite: a dependency on someone else's infrastructure, in someone else's jurisdiction, governed by someone else's terms, that you cannot fully audit and cannot guarantee will keep functioning if the relationship or the geopolitics sours.

This isn't cloud-scepticism for its own sake. For most software, the cloud is exactly right. But infrastructure has a different requirement: it has to keep working under conditions where the convenient assumptions don't hold. A power station that only runs when the supply chain is friendly isn't infrastructure; it's a liability with good uptime. When the integration layer becomes infrastructure, "it's in the cloud" changes from a feature into the exact thing the resilience reviewer is worried about — and "trust us, we won't lose your data" stops being good enough, because infrastructure is judged on what it cannot do, not what it promises not to.

Once you accept that the integration layer has become infrastructure for these buyers, the requirements stop looking like premium features and start looking like baseline conditions of being infrastructure at all.

It has to run where the owner needs it to run — including on their own hardware, fully under their control, not as an agent reporting back to a vendor's cloud. It has to be owned, not rented, all the way down — including the intelligence, because infrastructure that depends on an external model API is infrastructure with a wire running out of the country. It has to make no external calls when it mustn't, enforced rather than promised, because the standard for infrastructure is a control you can prove, not an intention you can read in a policy. And it has to persist — outlast the procurement cycle, the vendor's funding round, the political reshuffle. I've argued elsewhere that government's deepest problem is that its core is unstable while its leadership is the only constant — leadership should be additive, building on a stable core, not digging up the foundation every four years. Infrastructure-grade software has to be the stable core. If it's the thing that gets re-platformed every cycle, it was never infrastructure; it was just an app that mattered too much.

Inferrex was built to meet these conditions deliberately: it runs Cloud, in a VPC, on the customer's own Kubernetes, or fully air-gapped, on its own models, with zero egress enforced at the sovereign end — one platform across the whole spectrum rather than a crippled "secure edition." That design only makes sense if you believe the integration layer is becoming infrastructure. I do, which is why I built it that way from the start.

Here's the part vendors find uncomfortable, because it changes how the sale works.

You don't buy infrastructure the way you buy a SaaS seat. A SaaS purchase is a quick evaluation, a card, a per-user line that scales with headcount, and an easy exit if it disappoints — the whole model assumes swappability. Infrastructure is the opposite on every axis: it's a deliberate, scrutinised decision, because the cost of getting it wrong is systemic; it's bought on resilience, sovereignty, and control as much as on features; and it's priced on capacity and criticality, not on logos and seats, because what you're buying is a dependable layer, not a tool a team logs into.

This is why the seat-based, connector-metered pricing models of the iPaaS era sit so awkwardly with infrastructure buyers. Charging per connector and per user is an application pricing model, and infrastructure buyers instinctively distrust it — they're not buying a number of seats, they're buying a layer they intend to depend on, and they want to pay for capacity and criticality, not be metered on their own growth. The procurement motion for infrastructure is slower, deeper, and more adversarial, and that's appropriate: you should interrogate the thing you're about to depend on harder than the thing you could swap out next quarter.

So here is the shift, named directly.

A class of software — integration middleware chief among it — is crossing from application to infrastructure, because it has become the load-bearing layer through which everything else understands everything else. The trigger was the question boards now ask of every critical pathway: what does this depend on that we don't control? For the integration layer, the honest answer exposed dependencies — external control planes, rented models, quiet egress — that are tolerable in an app and disqualifying in infrastructure. Which means the category is repositioning whether its vendors like it or not: from "AI SaaS vendor you evaluate and swap" to "critical infrastructure you scrutinise and depend on." Most vendors are still selling, pricing, and architecting for the old category. The buyers have already moved to the new one.

I find this shift clarifying rather than threatening, because Inferrex was built for the category it's becoming rather than the one it's leaving. But the repositioning is bigger than any one company. It's a statement about a class of software growing up — accepting that when enough depends on you, "move fast and we'll patch it" stops being a virtue and "you can depend on this, and here's why you can prove it" becomes the whole job.

The organisations that internalise this early — that start treating their integration layer as infrastructure to be owned and proven rather than an app to be rented and swapped — are the ones who won't be scrambling to bring it back inside the wall when the next tightening of regulation or geopolitics makes the old answer untenable. The line has already moved. The only question is whether you've noticed.