Physical AI: Decide at the Edge, Train in the Cloud, Earn Autonomy in Stages

On November 12, 2026, IIoT World published a summary of a panel at the Industrial AI Summit 2026 on how to deploy, govern and secure so-called physical AI. The speakers were Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) and Tauseef Ahmed (Grayhawk Consulting Group). One caveat is in order: the article is sponsored by InfluxData and discloses the use of AI tools for the summary. It should therefore be read as panel opinion, possibly shaped by vendor interests, not as independent research.

Where to run AI

The proposed rule is simple and a useful starting point for engineering and IT leaders:

• Edge: safety-critical decisions, quality defect detection and anything that requires sub-second responses.
• Cloud: pattern recognition across multiple plants, model training on aggregated failure data, multi-site energy analytics.
• Hybrid: agentic workflows in which the anomaly is detected at the edge, then maintenance history, manuals and spare-parts inventory in the cloud are used to prepare work orders and parts requests; the action returns to the edge for execution.

Physical AI that acts locally and learns globally.

The Siemens Energy example

The case cited uses AWS IoT SiteWise Edge for condition monitoring and energy optimization in every factory. The signature of a bearing failure triggers an action within milliseconds, without going through the cloud. According to the article, 200 ms of delay can separate a safe shutdown from an accident, a quality defect or a line stoppage. The edge layer ingests 10 protocol types, including Modbus, OPC UA and legacy Siemens S7, while predictive maintenance models are trained in the cloud on failure data collected from multiple plants.

Cost and resilience

Keeping raw telemetry on site for 5 days to a month and sending only the relevant subsets to the cloud would reduce storage cost to roughly one tenth of full ingestion; however, the figure comes without a source and should be verified in your own context. The resilience principle is more solid: edge devices must keep making decisions even when the network goes down.

Guardrails and staged autonomy

Before any autonomous action, the panel lists four checks:

• the data is current and reliable;
• operating conditions fall within the model's training range;
• the scope of authorized actions is clearly defined;
• there is a path for handling exceptions.

For data quality, the panel suggests a unified namespace and a tag ontology, useful for catching naming drift, clock skew and schema changes (for example, an integer becoming a float). Back-testing new sensors against the existing ontology adds another control. The risk is silent schema drift, which degrades models without anyone noticing.

Autonomy should be granted in four stages: observation; recommendation with human approval; pattern-based decisions with proven, reversible outcomes; and full autonomy only after consistent performance across all earlier stages. Each stage requires explainability, escalation to a person above a risk threshold, and domain boundaries, so that a model trained for one plant is not applied to another.

Security and hardware limits

Physical AI, such as a robot interacting with both a WMS and an MES, crosses boundaries that ISA 95 meant to keep separate. A poisoned edge model or a prompt attack could travel up through agentic workflows to work orders and maintenance planning in the cloud, across multiple sites. For this reason the panel calls for merging IT and OT security disciplines and protecting data at rest, in transit and at the point of use.

On the hardware side, edge memory limits model size, and factory heat causes thermal throttling that would add roughly 30 ms to inference in summer. Here too, the article does not give a basis for the figure.

What to do with it

The advice is to start with well-bounded projects, with scope, success criteria and authorized actions defined, then reuse the architecture, governance and security controls at other sites. For engineering and IT leaders, the practical message is to design data quality controls and OT network segmentation in from the start, treating the panel's figures as hypotheses to validate, not as benchmarks.