The economics usually favour the cloud. Managed inference is cheap, elastic, and somebody else runs it. We still deploy most industrial workloads at the edge, and the reasoning holds even when the cloud option is effectively free.
Reason one: latency the process actually cares about
A safety interlock or a reject-gate decision has a budget measured in tens of milliseconds. A round trip to a regional cloud region, on plant connectivity, will not meet it reliably — and "usually meets it" is not a specification a safety function can be written against.
Reason two: data residency is a procurement gate
For public infrastructure operators, defence-adjacent manufacturing, and a growing share of European industry, an architecture that requires data to leave the site is not a technical concern but a disqualification. Edge deployment is what keeps the vendor in the evaluation.
Reason three: the one nobody mentions
Plant connectivity is worse than anyone admits in the design review. Not down — intermittent. A link that drops for ninety seconds several times a shift will not show up in an uptime report and will comprehensively break a system that assumed a persistent connection.
Edge deployment turns that from an outage into a buffering problem. Inference continues locally, results queue, and the link syncs when it returns. Nothing is lost and nobody is paged. A cloud-dependent architecture handles the same event as a series of gaps in the record, which then have to be explained during an audit.
What we actually run where
- Edge: vision inference, anomaly detection on high-rate signals, anything with a control or safety consequence.
- Core, inside the customer network: aggregation, cross-asset context, reporting, model training.
- Outside: nothing, unless the customer explicitly chooses a cloud deployment.
Written from deployment experience across multiple sites. Patterns are described without identifying any customer — we are under confidentiality with the operators involved.
Talk to an engineer about this