Cloud, Edge or Controller? A Decision Architecture for Industrial AI

A factory does not need an anti-cloud architecture. It needs explicit decision boundaries. The cloud is strong at fleet-wide learning, heavy computation, cross-site analytics and coordinated lifecycle management. A controller is strong at deterministic, tightly bounded control. Edge compute can mediate between the two. Problems begin when a team treats those planes as interchangeable.

Source status — reviewed 2 August 2026. This article is an architecture decision method, not an account of a client deployment. Its constraints are grounded in NIST OT-security guidance, the OPC UA architecture and published edge-platform behaviour. Any timing, availability or safety threshold must come from the product's intended use and applicable sector requirements.

Begin with consequence, not latency folklore

Real time is too vague to place a function. Ask four sharper questions:

1. What physical or operational consequence follows if the result is late, wrong or absent?
2. What is the maximum end-to-end time from observation to action, including queues and recovery?
3. What must continue during a network partition, cloud outage or credential failure?
4. Which component is authorised to command an actuator or change a safety-relevant state?

NIST SP 800-82 Rev. 3 defines operational technology as programmable systems that interact with the physical environment and stresses its distinctive performance, reliability and safety requirements. That is the architectural starting point: a delayed dashboard and a delayed protective action do not have the same failure semantics.

The four-plane architecture

Plane 1 — deterministic control and protection

This plane contains interlocks, protective functions and control loops whose timing and failure response must remain bounded. It normally runs in a PLC, safety controller, drive or dedicated real-time component. A learned model may provide an observation or recommendation, but the safety boundary should be explicit and independently enforceable where the risk analysis requires it.

Design rule: loss of the edge application or cloud must not create an undefined actuator state.

Evidence: timing analysis, hazard/risk analysis, state machine, fail-safe/fail-operational behaviour as required, interface contract and fault-injection results.

Plane 2 — local inference and operational application

This plane contains perception, anomaly detection, retrieval, operator assistance, short-horizon optimisation and orchestration that must remain useful locally. It can run on an industrial PC, gateway or accelerator near the process. It should have a declared behaviour for stale inputs, low confidence, resource exhaustion and loss of upstream connectivity.

Design rule: local operation is bounded; the edge does not silently acquire authority that belongs to a deterministic controller or a human role.

Evidence: target-device evaluation, sustained operating-envelope test, offline-mode test, local queue/storage limits, human-oversight design and recovery path.

Plane 3 — fleet, data and learning services

This is where the cloud is often the right tool: fleet inventory, aggregated telemetry, long-horizon analytics, training, model registry, policy distribution, cohort rollouts and cross-site evidence. The cloud can coordinate a fleet without being placed in every time-critical loop.

Design rule: the fleet plane distributes signed intent and collects evidence; it does not become an undeclared single point of physical control.

Evidence: identity and authorisation model, data contracts, store-and-forward behaviour, update signing and rollout policy, regional/data boundary, observability and cloud-disaster recovery.

Plane 4 — the evidence and governance spine

Evidence crosses all three execution planes. It binds requirement, version, decision, operator action, incident and change. Without it, local and cloud teams can each report healthy components while the end-to-end product is failing.

Design rule: every operational decision that matters can be traced to system identity, input context, software/model version and the policy that authorised it—within the retention and privacy boundary.

Evidence: versioned system inventory, decision/event schema, audit and retention policy, acceptance records, incident linkage and change-control owner.

A placement matrix

Default is a prompt for analysis, not a standard. Place each function from its consequence and operating boundary.

Interoperability is part of the product boundary

OPC UA defines a platform-independent architecture spanning embedded devices through IT/cloud systems. Its client-server and PubSub patterns solve different exchange problems. OPC UA Part 14 explicitly covers distribution of data and events within device networks and to IT/analytics cloud systems.

That does not mean use OPC UA everywhere It means the information model, ownership of commands, delivery semantics, time stamps, units, quality flags and compatibility rules are architecture decisions. A protocol connection without those semantics merely transports ambiguity faster.

For every northbound and southbound interface, specify:

• authoritative source and consumer;
• schema/version and units;
• event time versus processing time;
• ordering, duplication and idempotency behaviour;
• stale/missing-data response;
• command acknowledgement and authority;
• security zone and identity;
• what is buffered, for how long and what happens when storage is exhausted.

Design the disconnected state as a first-class mode

Connectivity is a state, not a boolean assumption. A product should distinguish healthy online operation, intermittent operation, deliberate offline operation, degraded local operation and recovery/reconciliation.

Published platforms illustrate the mechanics. Microsoft's Azure IoT Edge offline documentation describes local authentication, module communication and store-and-forward while disconnected, while also noting that message retention depends on configured time-to-live and available disk. The general lesson is portable: works offline is incomplete until storage, expiry, restart, reconciliation and operator visibility are specified and tested.

A disconnected-state test should cover:

1. loss during an in-flight decision;
2. device and application restart while offline;
3. local credential/cache validity;
4. storage reaching warning and hard limits;
5. commands or policy changes waiting upstream;
6. reconnection with duplicate, delayed or conflicting state;
7. a cloud dashboard that cannot observe the current device state.

Five architecture traps

1. The API call is treated as the decision boundary

Network, queue, model and application latency are measured separately, while the product requirement applies end to end. Instrument the complete observation-to-action path and its tail behaviour.

2. The edge is treated as a small cloud server

An edge device has a physical power/thermal envelope, hardware variants, local state and costly field recovery. Containerising a service does not remove those constraints.

3. Safety and AI confidence are conflated

A confidence score is not a safety case. Define the deterministic guard, human authority and safe/degraded states separately from model uncertainty.

4. Northbound telemetry becomes an accidental control plane

A dashboard command or optimisation output reaches actuators without an explicit authority and state-machine design. Separate recommendation, bounded setpoint and direct command in the interface contract.

5. Fleet management arrives after the pilot

The prototype proves one device. The product needs identity, inventory, compatibility, signed updates, cohort rollout, rollback, observability, data retention and field service. Those choices shape the architecture before hardware freezes.

The product decision record

For every material function, record:

• intended outcome and user/operator;
• consequence of late, wrong and absent output;
• execution plane and authority;
• latency/availability/offline requirement;
• input/output contract and stale-state behaviour;
• safety/cybersecurity/privacy boundary;
• degraded and recovery states;
• evaluation and operational evidence;
• lifecycle owner and cost driver.

Then review the set as a system. An individually reasonable placement can still create an incoherent end-to-end product—for example, a local inference path whose required policy can only be fetched online, or a cloud rollout whose rollback image does not fit the device.

Cloud and edge are a product allocation problem

The strongest industrial architecture is rarely all edge or all cloud It is a deliberate allocation: deterministic protection where timing and physical consequence demand it; local intelligence where proximity, data volume and continuity demand it; fleet services where aggregation and lifecycle coordination create leverage; and an evidence spine that keeps every plane accountable.

That allocation must be owned as a product decision, not left as an emergent result of whichever team built the first demo. The Physical AI Product System places it alongside customer value, economics, safety, operations and ecosystem decisions so architecture can advance only with the product around it.