Sit through any enterprise AI evaluation in 2026 and you will hear the same sentence in the third meeting: "the model never sees your data". Sometimes it's true. Often it isn't — and even when it is, the LLM provider's control plane sees enough metadata, query strings, and access patterns to make the security team uncomfortable. For most industries, that discomfort is manageable. For some, it ends the conversation.
This is the conversation no one in the data-platform category wants to have honestly. So let's have it.
What "runs in your network" actually means
There are three layers of network isolation, and the vendors blur them on purpose:
- VPC isolation. Your compute runs inside an account you control. The hyperscaler can still see the traffic patterns at the routing layer; the vendor can still issue control-plane API calls into your subscription.
- Private connectivity. Your traffic to the vendor never touches the public internet. The vendor still receives every request you make.
- Air-gapped. Your environment has no route to the vendor at all. License validation, model updates, telemetry, support — everything must work without an outbound connection. This is rarer than the brochures suggest.
The first two are what "self-hosted" means for Snowflake, Databricks, and Microsoft Fabric. The third is what it means for a defence contractor, a central bank, a national health record, or a sovereign cloud customer in the Gulf.
If you sell into the third category, you cannot ship a product that phones home to validate a license or fetch a model update. You also cannot ship a product whose AI features go quiet the moment the customer's perimeter firewall blocks an outbound cloud LLM endpoint.
The customers who actually need this
Across the engagements we've run in Singapore, Riyadh, Abu Dhabi, Sydney, and Bengaluru, the customers asking for true air-gap deployments cluster into five patterns:
- Defence and national security. No outbound traffic, period. The model lives on hardware that physically cannot reach the internet.
- Central banks and Tier 1 financial institutions. The model can be reachable from inside the bank network, but not the other way around. Vendor SaaS that needs to push updates inbound is rejected at the architecture review.
- Sovereign-cloud requirements. A growing list of governments (Singapore IM8, Saudi NDMO, UAE TDRA, India's MeitY guidelines) want data and the operational workloads on top of it to remain on shore and under domestic operator control.
- Critical national infrastructure. Power, water, transport, telecom. The OT side of the house has stricter perimeter rules than the IT side, and AI is increasingly relevant on the OT side.
- Patient and citizen data at scale. Healthcare ministries, large hospital networks, social-security administrations — HIPAA equivalents in the region forbid sending records, even with consent, to a cloud LLM.
These are not edge cases. They are some of the largest enterprise budgets in our region.
What the existing data-cloud agents actually require
It's worth being precise here, because the marketing copy is uniformly evasive.
Snowflake Cortex runs the model inside Snowflake compute. Customer data does stay in Snowflake. But Cortex itself is a managed service of Snowflake the company — the SQL workload, the function call, the prompt, and the response transit through Snowflake's plane. If the customer's account is suspended, or the region is unavailable, Cortex stops working. There is no air-gapped Snowflake.
Databricks Genie uses Databricks Model Serving. Customer data stays in their workspace. Again, the model serving layer is run by Databricks the company. Standard Databricks Workspace requires a reachable control plane in cloud.databricks.com for cluster orchestration. Some larger customers get the "Customer-Managed VPC" or "PrivateLink" setup, but these still require the Databricks control plane to be reachable from the workspace; they do not make the workspace air-gap-capable.
Microsoft Fabric Copilot uses a Microsoft-operated cloud LLM service inside Azure. Your data is processed within an Azure tenant, but the model serving layer is operated by Microsoft. Same shape.
None of these are bad architectures. They are the right answer for the majority of customers. They are simply the wrong answer for the five patterns above.
What true self-hosted actually requires
If you want the same natural-language data agent experience without any of that, the product has to make seven specific design choices:
- Bundle the model. Ship the LLM weights as part of the install image. No model download on first run.
- Run on commodity hardware. No requirement for proprietary GPUs from a vendor that won't sell to your region.
- License-validation must be offline. Cryptographically signed license file, validated against an embedded public key, with no phone-home call.
- Don't brick on license expiry. Enterprise legal teams will not sign anything that can refuse to operate on a date in the future.
- Telemetry off by default. Not "off after opt-out". Off, with an explicit opt-in for customers who want to help.
- Upgrade by file transfer. The customer must be able to upgrade the product by SCP-ing a signed tarball into the network, not by reaching a CDN.
- Document every outbound connection. An explicit list in the architecture docs. A second list of customer-data-source connections (Postgres, S3, log volumes) the product is allowed to initiate inside the network.
Most "self-hosted AI" products fail one or more of these checks. The shortcut is usually number 3 — the license key actually does need to reach the vendor's license server — or number 1 — the model is pulled from a hosted model registry on first run.
How we built it at Wekams Lens
This is why our own data agent platform, Wekams Lens, is built the way it is. The Community Edition image bundles an open-weight LLM (Qwen 2.5). License validation for Pro and Enterprise is an offline-signed JWT validated against an embedded public key. Telemetry is off; the product never phones home. We have customers running it inside networks that cannot reach our own GitHub.
And it does the same thing the cloud-native agents do — takes a natural-language question, generates SQL across the customer's data sources, executes safely, and answers in plain English. Just without the dependency on our infrastructure.
This isn't a debate about whether one architecture is better. It's a debate about which customers each architecture can serve. The cloud-native data agents will continue to serve the majority of enterprises beautifully. The self-hosted ones will continue to be the only option for the tail that the majority misses — and that tail contains the largest budgets in regulated sectors.
What to ask in your next evaluation
Three concrete questions to bring to the next AI-platform shortlist meeting:
- "Can I unplug the network cable and still ask the model a question?" If the answer is "no, but you wouldn't want to," then the product is cloud-native. That is fine; just know what you're buying.
- "What happens to the product on the day the vendor's region is down?" If the answer is "it stops", and your continuity policy says "AI must remain available", you have a mismatch.
- "Show me the list of outbound connections the product makes." A vendor that can't produce this list inside ten minutes is not built for the regulated-industry conversation.
Run those three questions through your shortlist. The list usually gets shorter.