Physical AI: What to Run at the Edge, What in the Cloud, and Within What Limits

On 12 November 2026, IIoT World published a summary of a panel from the Industrial AI Summit 2026 on how to deploy, govern and secure so-called "physical AI". A caveat up front: the article is sponsored by InfluxData and, by its own statement, was summarized with the help of AI tools. The speakers were Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) and Tauseef Ahmed (Grayhawk Consulting Group). It should be read as panel opinion, not independent research.

Where to run AI: the placement rule

The panel boils the idea down to a formula: physical AI that "acts locally and learns globally". The proposed split is as follows.

• Edge: safety-related decisions, quality defect detection, and anything that needs a sub-second response.
• Cloud: pattern recognition across multiple plants, model training on aggregated failure data, and multi-site energy analysis.
• Hybrid layer: agentic workflows that detect an anomaly at the edge, use maintenance logs, manuals and spare-parts inventory in the cloud to generate work orders and parts requests, and send the action back to the edge for execution.

The Siemens Energy example

The case cited is Siemens Energy: condition monitoring and energy optimization run locally in each factory using AWS IoT SiteWise Edge, which connects 10 protocol types, including Modbus, OPC UA and the aging Siemens S7. Failure data from multiple plants is then aggregated in the cloud to train predictive maintenance models. The article argues that a 200 ms delay can make the difference between a safe shutdown and an incident, citing a bearing fault signature handled in milliseconds.

Cost and resilience

Keeping raw telemetry locally for 5 days to a month and sending only the relevant subsets to the cloud can cut storage cost to roughly a tenth of full ingestion. Edge devices, moreover, must keep working when the network goes down.

Data trust and limits on 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;
• a defined path exists for exceptions.

A unified namespace with a tag ontology should catch naming drift, clock skew and schema changes before they reach the models; one example is an integer that becomes a float. Back-testing against historical patterns is a second control, because silent schema drift degrades models without anyone noticing. Data must be protected at rest, in transit and at the point of consumption. Each level of autonomy requires explainability and escalation paths to a human, and a model should not be reused across plants with different equipment or processes.

Security risks

A robot that interacts with both a WMS and an MES crosses boundaries that the ISA-95 model meant to keep separate. Model poisoning or prompt attacks at the edge could propagate upward through agentic workflows, all the way to work orders and maintenance scheduling across multiple sites. The panel calls for merging IT and OT security. Then there are physical limits: edge hardware has memory and thermal constraints, and inference time would rise by about 30 ms in summer due to thermal throttling.

Takeaways

The advice is to start with tightly scoped projects, with clear scope, success criteria and authorized actions, and only then replicate architecture, governance and security controls across sites. For those working on PLC, SCADA and historian integration, three ideas are immediately useful: a placement rule based on latency and criticality, a data reliability checklist built on a unified namespace, and the recognition that schema drift and thermal limits are engineering problems, not just data science ones. Since this is sponsored content, it is worth verifying the figures against your own plant data.