Air-gapped OSS/BSS: the whole stack inside your perimeter, AI included

A security architect at a Tier-1 carrier once ended a vendor evaluation with a single question: “When the fibre to the internet is cut, does the product still work?”

The answer took four minutes and contained the phrase “graceful degradation.” The evaluation ended there.

That question is not pedantry. It is the only test that reliably separates a genuinely disconnected deployment from a hosted product with an on-premises collector in front of it. And as OSS and BSS platforms become AI-native, more operators are asking it — because the answer now determines where their subscriber base, their network topology and their commercial terms actually live.

You are not choosing between AI and sovereignty

For twenty years operators ran OSS and BSS in their own data centres because that is where those systems were born. Fault management, inventory, mediation, provisioning — all of it on-premises, all of it disconnected, and nobody wrote about it because there was no alternative.

Then operations tooling grew a model, and a new assumption arrived with it: that the intelligence has to live somewhere else. That assumption is worth examining, because it is an artefact of how most platforms were built, not a property of the technology. A model is a component. It needs GPUs, a serving runtime, a set of weights and something to retrieve from. All four of those can sit in your data centre.

What makes the assumption sticky is that an AI-native platform is hungry. Every alarm you correlate, every topology you traverse, every change request you score, every customer complaint you summarise becomes a prompt. If prompts leave the building, the volume and sensitivity of what has crossed the boundary is an order of magnitude beyond what a traditional integration ever exposed — and a prompt sent to a commercial endpoint is a disclosure event, whatever the data processing agreement says about retention.

So the question is not whether operators should accept that exposure in exchange for automation. It is whether the platform was built so the question never arises.

What air-gapped has to mean for OSS/BSS

The term has been stretched. Some platforms describe a single-tenant cloud tenancy as air-gapped. Others describe an on-premises install as air-gapped while inference still travels to a hosted model API outside the perimeter. Both fail the fibre-cut test.

We hold the term to five properties. All five, or the claim does not hold.

1. 1

   No outbound dependency. Every module — assurance, resource management, plan-to-build, CRM, orders, subscribers, supply chain — operates indefinitely with zero egress. Not “degrades gracefully.” Operates.

2. 2

   Inference runs on operator hardware or inside the perimeter. The serving stack sits on GPUs you own, in a facility you control. No prompt crosses the boundary — not for correlation, not for RCA narrative, not for MOP authoring, not for a NOC Copilot query typed at 2 a.m.

3. 3

   The weights are inside too. Inference locality is not enough if the model itself is a remote artifact fetched at start-up. Weights ship inside the signed offline package, or you bring your own locally hosted models and the platform binds to those.

4. 4

   The grounding corpus is inside. The property most often missed. An AI-native OSS platform is only as good as what it retrieves from — 3GPP specification text, OEM procedure documentation, your MOP library, historical incidents, topology. If retrieval reaches a hosted index, the platform is not disconnected, and the retrieval queries themselves leak operational intent.

5. 5

   Updates arrive as inspectable offline artifacts. Signed packages, validated by your security team, staged in non-production, promoted through your own change management. Never a background pull.

Seen in production

Two deployments, both anonymised at the operator’s request.

Sovereign AI: the models, the inference and the corpus are yours

Air-gapped is a network property — nothing leaves. Sovereign is the stronger claim: the intelligence itself belongs to the operator.

• Inference on operator GPUs. Both production deployments above ran LLM inference on the operator’s own hardware. This is the shipped configuration, not a bespoke engagement.
• Bring your own validated reasoning models. Operators with an existing local inference stack bind the platform to the models they already host, rather than duplicating a GPU investment.
• Model choice stays open. Models are swappable as better ones ship. No operator is pinned to a model generation, and no capability depends on a third-party model API continuing to exist.
• Local grounding with citations. Retrieval runs against 3GPP specification text, OEM documentation, your MOP library, incident history and topology — all held inside the perimeter. Every model-assisted recommendation carries citations back to the source it retrieved.
• No training on operator data. Operational history tunes your deployment through your local corpus and your own model retraining. It does not become anyone else’s product capability.
• ML stays deterministic where it should be. Risk scoring and blast-radius simulation are ML, not LLM. Prediction paths are reproducible and auditable — which matters when a change board has to defend a decision after the fact.

For a sovereign-cloud or national-infrastructure review, this is usually the paragraph that decides it. The answer to “where does the AI run, and who controls it” is: your data centre, and you.

Degrees of on-premises

“On-prem” covers a wide range, and the differences only surface under security review. Four configurations, in order of how much of the intelligence sits inside the boundary.

The two production deployments described above sit in the sovereign on-prem column: platform, weights, inference and corpus all inside, with a controlled egress point retained for update delivery. Air-gapped removes that last path and replaces it with a signed offline artifact workflow. The architecture is the same; what changes is the update mechanism and the security review that precedes it.

What the model asks of you, honestly

Four things worth planning for. None of them is a reason to send your data elsewhere; all of them are easier to absorb when they are on the table before signature rather than after.

Eight questions to test any air-gapped claim

Including ours. If a vendor cannot answer all eight without qualification, the claim is weaker than the brochure.

1. 1

   When the internet link is cut, which features stop working? “None” is the only passing answer. Any list is the real product boundary.

2. 2

   Where do the model weights physically live, and who can read them? If they are fetched at start-up from a vendor endpoint, the deployment is not disconnected.

3. 3

   What does retrieval query? A hosted vector index defeats the perimeter as effectively as a hosted model, and is easier to overlook.

4. 4

   Does telemetry, licensing, usage metering or crash reporting phone home? Metering is the most common leak. Ask about it specifically, by name.

5. 5

   How are updates delivered, signed and verified, and who holds the signing key? You should be able to inspect a package before it enters non-production.

6. 6

   Which components hold subscriber personal data, and can that subset be isolated further? An OSS-only perimeter that leaves BSS outside solves half the problem and should be described that way.

7. 7

   Can we evaluate on our own production data without exporting it? If the proof of concept needs an extract to leave the building, the production claim is untested.

8. 8

   Show us the audit trail for one AI-assisted decision, end to end. Citations, retrieved sources, confidence, policy gate, approver, execution record, rollback path. If it cannot be reconstructed, it cannot be defended to a regulator.

The perimeter is an architecture decision, not a deployment option

Air-gapping is not something a platform is configured into late. Either every module was built to run without an outbound path, or some of them were not — and the ones that were not surface during the security review, usually in week nine, usually in front of the CISO.

NetSingularity was built for operators who could not export their data in the first place. The production deployments described above did not begin with a sovereignty requirement bolted onto a cloud product. They began with an operator saying that no prompt, no alarm and no subscriber record would leave the building, and the platform being architected to that.

Frequently asked questions about air-gapped OSS/BSS

Deployment outcomes cited in this article are drawn from NetSingularity production engagements. Operators are anonymised at their request. Figures are as measured in the respective deployments and are not a forecast for any other network.