Back to blogDeutsche Version
AI Automation

Where Should Industrial AI Run? A Failure-Domain Approach to Edge, Plant and Cloud

Choose device edge, plant edge or cloud by failure domain, data gravity and recovery objectives—not by slogans. A practical partition-tolerant architecture for industrial AI.

5 min readUpdated
Industrial operations room with an amber-isolated local cable cabinet, cyan control linework and a human operator.

BLUF: put industrial AI where it can fail safely, not where a vendor diagram happens to place it. A device or line edge is justified when a local decision must remain available through a plant-network or WAN partition. A plant edge is usually the operational default for shared site context and local recovery. A central platform is appropriate for fleet learning, heavy training and cross-site governance—but it must degrade cleanly when a site is disconnected.

Start with the failure domain, then test locality

“Edge versus cloud” is not a binary architecture choice. It is a set of independently failing domains: device, line, plant network, identity service, WAN, regional cloud service and central data platform. For each AI function, name the consequence of losing each domain, the maximum tolerated outage (RTO), the permitted data loss (RPO), and whether the function can influence a physical control path.

NIST SP 800-82 Rev. 3 treats OT as distinct because it interacts with the physical environment and must meet performance, reliability and safety requirements. That is why an advisory quality classifier and a command-capable optimisation service cannot share the same placement rule. The earlier OT safety and security boundary explains why observation, recommendation and control need separate authority boundaries.

Reference architecture: partition-tolerant by design

Diagram: sensors and PLCs → device/line collector → signed local artifact cache → plant edge data contract and inference service → store-and-forward queue → central platform registry, fleet analytics and training. A red interlock separates inference recommendations from the safety PLC/control path. During a WAN partition, the plant continues with the last approved local artifact and bounded local data retention; cloud-only enrichment is marked unavailable rather than silently substituted.

The device or line edge owns signal acquisition, protocol adaptation and fast local filtering. The plant edge owns site-local context: asset identity, historian access, approved model artifacts, authentication proxies, observability and a durable outbound queue. The central platform owns fleet-scale training, model evaluation, artifact signing, cross-site analytics and promotion policy. Keep production inference artifacts immutable and verify signatures before activation; this complements semantic data contracts from OPC UA to AAS because locality does not repair missing units, timestamps or asset semantics.

Placement decision matrix

WorkloadDefault placementDeciding evidenceMain trade-offRecovery pattern
Machine-vision reject hint with bounded local responseDevice/line edgeControl-path proximity, milliseconds-level local availability need, defined safe fallbackConstrained compute and difficult fleet operationsSigned fallback artifact; revert to deterministic rule or stop state
Site energy or maintenance recommendationPlant edgeShared site context, operation during WAN loss, local data sensitivityPlant infrastructure and patching responsibilityLocal queue; replay upstream after reconciliation
Cross-plant forecasting, training and evaluationCentral platformData gravity is manageable; minutes/hours recovery is acceptableWAN and regional-service dependencyVersioned snapshots and delayed batch processing
Remote expert copilot using live plant contextHybridLocal read gateway plus central reasoning, explicit disconnected modeMore integration surfacesRead-only local mode or clear unavailable state

A practical placement test

1. Enumerate functions, not products: acquisition, feature extraction, inference, recommendation, action approval, training, artifact distribution and audit. 2. For each function, write the RTO and RPO with the process owner—not an assumed latency target. 3. Simulate loss of WAN, plant edge, identity provider and artifact registry. 4. Identify data gravity: raw video or high-frequency signals may be filtered locally, while compact signed events can travel centrally. 5. Define a disconnected-mode contract: what continues, what is buffered, what expires, and what must stop. 6. Run recovery as an exercise, including artifact signature verification and duplicate-safe queue replay.

Store-and-forward is a data contract, not a retry loop

A robust queue item carries an event ID, asset and schema version, source timestamp and clock-quality marker, sequence number, payload digest, retention class and delivery state. Consumers must be idempotent: a reconnect can redeliver events. Do not allow a cloud acknowledgement to be interpreted as physical-action approval. Separate telemetry replication from command authority, and reconcile gaps visibly after reconnection.

Failure modes to engineer before rollout

WAN partition causes a hidden cloud dependency: local inference starts but entitlement or feature lookup is remote. Mitigation: test a complete isolated-mode dependency graph; cache only approved inputs and fail closed for unavailable authority.

A stale model artifact continues after a safety-relevant change. Mitigation: give every artifact an expiry and compatibility policy; a plant may keep an approved last-known-good version only within an explicit operating envelope.

Queue replay corrupts fleet analytics through duplicates or out-of-order events. Mitigation: use immutable event IDs, ordering metadata, idempotent consumers and reconciliation reports.

Central updates overwrite a local plant configuration. Mitigation: signed promotion bundles, site-scoped compatibility checks and a rollback drill—apply the same discipline described in the LLM release-bundle pattern.

What this does not solve

Failure-domain placement does not make a model accurate, validate a safety function or eliminate cybersecurity exposure. Edge hardware still needs patching, physical protection, monitoring and capacity planning. A local deployment can increase operational burden; a cloud deployment can be entirely reasonable when the process tolerates disconnection and the data path is controlled. Any change that can affect safety functions, regulated records or worker decisions needs the relevant safety, security, privacy and legal review; this article is engineering guidance, not legal advice.

A useful first engagement

Start with one plant workflow and a 90-minute failure-domain workshop. Produce a placement matrix, a disconnected-mode contract, a signed-artifact flow and one partition recovery drill. The output is not “edge” or “cloud”; it is a system boundary that operations can test and own.

Sources

NIST, SP 800-82 Rev. 3: Guide to Operational Technology Security; 5G-ACIA, Industrial 5G Edge Computing: Use Cases, Architecture and Deployment; OPC Foundation, OPC UA for AI and Companion Specifications; CISA et al., Principles for the Secure Integration of AI in OT.

#enterprise-ai#ai-governance#industrial-ai

Building AI into your operations?

I help teams design and ship compliant AI automation — production agents with n8n and LangGraph, RAG systems, and the evals to keep them reliable.

A

Written by

Ade Christanto

AI Automation Specialist and former network engineer focused on practical AI implementation for German B2B and Mittelstand companies.