Oxaide
Back to blog
Deployment & Security

When On-Premise Deployment Matters for Critical Infrastructure AI

A practical note on when on-premise or air-gapped deployment makes sense for teams handling sensitive telemetry and operational technology networks.

February 5, 2026
5 min read
Oxaide Team
When On-Premise Deployment Matters for Critical Infrastructure AI

The Cloud Assumption That Doesn't Hold at the Grid Edge

The default architecture for AI-powered monitoring in 2026 is cloud-first: sensors push data to AWS/Azure/GCP, models run inference in the cloud, and results stream back to a dashboard. For enterprise SaaS applications, this works. For critical energy infrastructure, it introduces three unacceptable risks.

Risk 1: Latency Kills

Grid-scale BESS systems can transition from normal operation to thermal runaway in under 30 seconds. If your anomaly detection pipeline requires a round-trip to a cloud region, even one in Singapore, you are adding network latency and queueing time before the system can respond.

For a 100MWh facility with 50,000 cells sampled at 1Hz, that's 50,000 data points per second. At peak utilisation, cloud inference queues can add seconds of delay. In a thermal cascade scenario, seconds matter.

The solution: Run inference at the edge. Our Horizon engine deploys as a compiled Rust binary on commodity x86 hardware (or Apple Silicon for cost-effective high-performance). Processing happens locally with deterministic sub-millisecond latency. No network dependency.

Risk 2: Data Sovereignty Is a Legal Requirement

Singapore's IM8 framework requires government-linked entities and critical infrastructure operators to maintain data residency within national borders. The upcoming IEC 62443 requirements for industrial control system security add further constraints on data egress from OT (Operational Technology) networks.

For BESS operators connected to the national grid, telemetry data is classified as critical infrastructure data. Sending it to a cloud provider, even one with a Singapore availability zone, means:

  • The data transits shared network infrastructure
  • It's processed on multi-tenant compute nodes
  • Encryption at rest doesn't prevent the cloud provider from accessing it for operational purposes
  • Regulatory auditors may challenge the data residency claim

The solution: Air-gapped deployment. Our engine runs entirely on the operator's OT network. Zero egress by design. The compiled binary and model weights are delivered on encrypted physical media. Updates are deployed via the same secure channel used for PLC firmware updates.

Risk 3: Model Training on Your Data

The fine print matters. When you use a cloud AI service to process your operational data, check the terms of service carefully:

  • Does the provider retain rights to use your data for model improvement?
  • Are inference results aggregated for benchmarking?
  • Can your competitors benefit from patterns learned from your operational data?

With Oxaide Horizon, your data never touches our infrastructure. The engine is a self-contained binary that runs exclusively on your hardware. We provide the forensic audit (Verify) as the initial diagnostic, then deploy the permanent safety layer (Horizon) as an on-premise license. Once deployed, the system operates independently.

Architecture: How Air-Gapped AI Actually Works

The common objection is: "If the system is air-gapped, how do you update the models?"

Here's our approach:

1. Physics-Informed Models Don't Need Frequent Retraining

Unlike statistical ML models that drift with data distribution changes, physics-informed models encode fundamental laws such as thermodynamics, electrochemistry, and electrical engineering principles. The dQ/dV method does not need to be reinvented every time the battery ages. It is designed to detect the aging itself.

The model weights are set during the initial calibration phase using the operator's own baseline data. Subsequent "updates" are calibration adjustments, not full retraining cycles.

2. Secure Update Channel

When calibration updates are needed, usually annually or after significant asset changes:

  1. The operator exports encrypted telemetry summaries (not raw data) to portable media
  2. Calibration analysis is performed in a controlled environment using the exported summaries
  3. Updated calibration parameters are delivered on encrypted media
  4. The operator loads the update via the same secure process used for PLC firmware

This mirrors the update methodology used for safety-critical systems in aviation and nuclear industries.

3. Edge Compute Requirements

The Horizon engine is designed for modest hardware:

  • Minimum: 4-core x86_64, 8GB RAM, 100GB SSD
  • Recommended: 8-core x86_64 or Apple M-series, 16GB RAM, 500GB SSD
  • No GPU required: The engine uses deterministic algorithms, not deep learning inference

Total hardware cost for an air-gapped deployment: approximately S$3,000-5,000. For a facility managing S$50-100M in BESS assets, this is negligible.

The GeBIZ Alignment

Singapore government procurement through GeBIZ increasingly requires vendors to demonstrate data sovereignty capabilities. The IMDA Agentic AI Framework (January 2026) explicitly calls for governance controls on AI systems processing government data.

Oxaide is a gazetted Singapore Government Supplier. Our air-gapped deployment model is designed from the ground up for IM8 compliance, PDPA requirements, and the emerging IEC 62443 standards for industrial cybersecurity.

Conclusion

For grid-critical infrastructure, the question is not whether to deploy AI monitoring. It is whether the monitoring architecture respects the safety and sovereignty requirements of the assets it protects.

Cloud-first AI works for customer support chatbots and business analytics. It doesn't work when milliseconds matter, when data sovereignty is legally mandated, and when the consequences of a detection failure are measured in megawatts and millions of dollars.

Sovereign AI isn't a marketing term. It's an engineering requirement.


If you are evaluating the broader query and governance layer around this architecture, read Oxaide Sovereign: Multi-Database Natural Language Query with RBAC and Audit Logs.

If you want the clean product split between the forensic baseline, the live monitoring layer, and the governed query layer, read Verify vs Horizon vs Sovereign: Which Oxaide Product Fits the Job?.


Ready to explore air-gapped deployment for your critical assets? Schedule a technical briefing and we can talk through the fit with you.

V

Independent forensic review

Oxaide Verify

Scoped forensic review for BESS assets

Review focus

Establish the asset baseline clearly

We review telemetry, operating history, and the physical signals standard reporting tends to miss.

Root cause, not just symptoms
Yield and safety blind spots surfaced
Clear report for operators and investors
Independent scopeRoot-cause analysisOperator-ready summary

Brief the asset, share available telemetry, and we’ll scope the review from there.

Operating posture

Scope first

Defined review scope

Boundary, telemetry window, and mandate question are pinned down before conclusions move.

Encrypted handling

Protected review workflow

Review traffic and operating data are handled with encrypted transfer and controlled access.

Customer boundary

Customer-controlled deployment

Managed, private, and isolated deployment paths are available when the environment requires them.

Direct accountability

Principal sign-off

Technical accountability stays close to the method rather than disappearing into a generic workflow.