Edge Data Centres: The Missing Layer for Real-Time AI

Gartner predicted that 75% of data would be generated outside traditional clouds in 2025. That one stat explains why “edge” keeps showing up in AI roadmaps—even for businesses that don’t think of themselves as infrastructure-heavy.

If you’re building AI-driven customer engagement, real-time fraud checks, in-store personalisation, or ops automation in Singapore, you’re not only choosing models and tools. You’re also choosing where inference runs, how fast data moves, and which networks you trust when traffic spikes or links degrade.

Edge data centres are expanding fast (the global edge market is forecast to reach US$317B by 2026), but the uncomfortable truth is this: edge capacity is growing faster than edge architecture is maturing. The result is a gap between what AI teams want (low latency, predictable performance, clean compliance) and what the regional ecosystem can consistently deliver.

Why edge infrastructure now affects everyday AI projects

Answer first: Edge data centres matter to Singapore businesses because they reduce latency and keep sensitive data closer to where it’s produced, which is exactly what many real-time AI use cases require.

A lot of “AI business tools” work fine with a cloud-only approach: summarising emails, generating ad copy, internal chatbots. But the moment you need real-time signals—video analytics, IoT telemetry, clickstream personalisation, call-centre assist, dynamic pricing—latency stops being a technical detail and starts becoming a product constraint.

Here’s the practical version:

• If your AI needs a response in <100ms, geography and routing matter.
• If you’re serving users across APAC, cross-border latency and network paths can swing wildly.
• If you’re handling regulated data, data residency and auditability become design requirements, not legal afterthoughts.

In the iTNews Asia interview, Lightstorm’s CTO Lalit S. Chowdhary describes a region where edge demand is surging, but the foundations—connectivity fabric, interoperability, distributed security governance, and standardisation—aren’t uniform yet. That mismatch is what trips up deployments at scale.

The three edge barriers that slow AI adoption in Singapore

Answer first: The biggest blockers are (1) inconsistent connectivity and peering, (2) operational complexity across many providers, and (3) multi-jurisdiction compliance and security governance.

1) Connectivity isn’t just “bandwidth”—it’s peering and path control

Singapore is well-connected, but your users, branches, and data sources often aren’t all in one place. When AI workloads depend on multiple hops across networks, problems show up as:

• Last-mile peering gaps (you can have great upstream capacity but poor local interconnect choices)
• Cross-border latency inefficiencies (traffic taking the “wrong” path due to commercial routing)
• Insufficient interconnect density (fewer viable paths means less redundancy and less predictability)

For AI, unpredictability is poison. A model that responds in 60ms on Tuesday and 220ms on Friday isn’t “a bit slower”—it changes user behaviour, conversion rates, and customer trust.

A useful mental model:

• Cloud is great for training and non-urgent inference.
• Edge is for deadline-driven inference.
• Networks decide whether your edge plan actually behaves like edge.

2) “Ecosystem readiness” is where most edge plans break

Chowdhary’s strongest point is also the least talked about: ecosystem readiness. Not the building, not the racks—the messy middle layer across operators, platforms, APIs, orchestration, and commercial terms.

“Ecosystem readiness involves aligning operational processes, APIs, security models, orchestration platforms and commercial frameworks across multiple players.”

If you’ve ever tried to roll out the same AI workflow across multiple sites (HQ, stores, depots, partner locations), you’ve seen this.

What low readiness looks like in an AI rollout:

• You can deploy to one location, but replicating it across 10 sites means 10 different networking patterns.
• Observability is fragmented: logs in one tool, network metrics in another, security events somewhere else.
• Changes require tickets with multiple vendors, turning “real-time” into “next-week”.

My stance: Most AI teams underestimate ops. Not because they’re careless, but because the demo works. Production is where the integration debt shows up.

3) Compliance and security governance don’t scale automatically at the edge

Edge pushes compute closer to data sources. That’s good for latency and sometimes good for privacy—but it also multiplies governance points.

In APAC, compliance gets harder because data can cross borders unintentionally via routing, failover, or vendor-managed network overlays. Chowdhary notes that multi-country routing complicates data residency and compliance, and that strict enterprise SLAs are hard to enforce when control is abstracted.

For Singapore businesses operating regionally, edge architecture needs to answer:

• Where does inference happen (Singapore-only, or regional)?
• Where are logs stored? Where are prompts stored? Where are embeddings stored?
• What happens during failover—does traffic fail into another jurisdiction?
• Can you prove performance and path diversity to meet internal risk standards?

Network as a Service (NaaS): helpful, but don’t treat it as “magic”

Answer first: NaaS can speed up provisioning and expansion, but many current offerings trade away visibility and strict SLA control—two things real-time AI needs.

NaaS is attractive because it promises faster setup, flexible capacity, and simplified operations. For fast-moving AI programs, that’s a real benefit.

But Chowdhary highlights limitations that matter specifically for AI workloads:

• Shared infrastructure + abstracted control layers can reduce visibility into routing and performance.
• SLA enforcement around latency and path diversity may be weaker than what mission-critical inference requires.
• Legacy integration friction means your “as-a-service” network still needs custom work.
• Inconsistent APIs across providers can stop you from standardising deployments.

A practical rule for Singapore teams:

• Use NaaS for non-critical connectivity, rapid pilots, and burst scenarios.
• Be stricter for customer-facing real-time AI (checkout, fraud, call-centre assist, industrial safety). For those, demand measurable latency targets and clear observability.

What an “edge-native” AI architecture looks like (and what to do while we wait)

Answer first: A mature edge-native architecture combines distributed execution with centralised orchestration, consistent security governance, and interoperable networking across vendors.

The industry is heading there, but it’s not fully there yet—especially across a fragmented APAC ecosystem. So the smart move isn’t “wait”; it’s to architect your AI so it can operate across imperfect edge conditions.

Build for distributed execution, keep central intent

You want inference close to users and devices, but you don’t want 50 mini-platforms you can’t govern.

Good patterns for Singapore businesses:

1. Centralised policy + decentralised compute

   • One place to manage identity, secrets, and policy.
   • Local inference nodes for latency.

2. Standard deployment packaging

   • Containers for inference services.
   • Repeatable infrastructure templates.

3. Unified observability

   • End-to-end tracing from app → model server → network path.
   • Alerting based on user experience (p95 latency), not only CPU.

Treat neutrality and interoperability as business requirements

Chowdhary makes a strong point: carrier and cloud neutrality isn’t just regulatory. It’s resilience.

For AI delivery, neutrality means:

• You can shift workloads across clouds (or between cloud and edge) without rewriting everything.
• You can maintain multi-path redundancy, not just “one primary link”.
• You reduce the risk of a single provider’s outage or commercial policy change becoming your outage.

This matters in Singapore because many businesses run multi-cloud by necessity—procurement, risk, data domains, and regional expansion tend to push you there.

A decision checklist for Singapore teams planning real-time AI

Answer first: If your AI use case has tight latency, high availability, or compliance requirements, decide edge placement and network strategy before you finalise tools and vendors.

Use this checklist in your next AI planning session.

1) Classify the AI workload by latency budget

• Relaxed (seconds): most internal copilots, batch insights, reporting
• Interactive (<300ms): web personalisation, agent assist, search
• Deadline-driven (<100ms): fraud scoring at payment time, safety monitoring, robotics

If you’re in the last two categories, edge and network architecture are first-order decisions.

2) Define your “failure mode” up front

Write it down:

• If the edge node fails, do you fail over to cloud (slower but available)?
• If connectivity degrades, do you degrade the experience (smaller model, cached answers)?
• If a region is unreachable, do you block requests to maintain residency?

3) Demand measurable observability from vendors

Ask for:

• p95/p99 latency reporting per site
• path diversity options (not only bandwidth)
• clear SLAs and escalation paths
• API support for provisioning and policy

If you can’t measure it, you can’t run it.

4) Plan compliance like an architecture constraint

Don’t leave this to legal review at the end. For regional deployments, explicitly map:

• jurisdictions involved
• where data is processed and stored
• audit logging location
• encryption and key management boundaries

Where this is heading in 2026: programmable, AI-assisted networks

Answer first: The next phase of edge maturity will come from programmability and automation—API-driven networks, predictive monitoring, and automated remediation.

Chowdhary points to a future where AI and automation make edge operations less manual: self-serve provisioning, predictive performance monitoring, automated remediation, intent-based optimisation. That’s exactly what real-time AI needs: an infrastructure layer that behaves predictably without constant human babysitting.

But right now, growth in edge data centres doesn’t automatically deliver that maturity. Architectural consistency is the bottleneck.

For Singapore businesses, the opportunity is still big: edge can make customer experiences faster and smarter, and it can keep sensitive data closer to home. The way to win is to plan for an ecosystem that’s improving—but not uniform yet.

If you’re rolling out AI business tools in Singapore for real-time analytics or customer engagement, I’d start with one question: Which parts of your AI must be real-time, and which parts just need to be right? Your edge strategy becomes much clearer after that.