From Edge to Cloud—and Back to the Field: How Physical AI Is Shaping the Next Generation of AIoT Devices
At 10:17 a.m., a production-line camera detects that a workpiece has shifted out of position. At the same time, vibration readings from the equipment begin to deviate from normal.
The robotic arm cannot wait several seconds for a cloud analysis before deciding whether to slow down. Yet if an engineer wants to understand why the same issue has already occurred three times that day, the system must compare maintenance manuals, historical work orders, and equipment records to identify the most likely cause.
The same environment therefore requires two different forms of intelligence: real-time perception and control within milliseconds or seconds, and deeper understanding based on extensive knowledge and data from multiple systems.
This is the foundation of Physical AI and cloud–edge collaboration. AI no longer exists only on a screen or inside a chat interface. Through cameras, microphones, radar, sensors, and controllers, it can interpret the physical world and translate its conclusions into actions that equipment can execute safely.
Physical AI: Moving AI from Information to Real-World Response
Many conventional AIoT devices primarily collect data and send it to the cloud for analysis. Physical AI takes this further by enabling devices to perceive, understand, act, and learn from feedback.
Cameras identify people, objects, and movement. Microphones receive spoken requests, while temperature, vibration, location, mmWave radar, and other sensors continuously reflect conditions in the field. AI must interpret these signals, determine what is happening, and decide whether the situation calls for a prompt, an alert, an equipment adjustment, or human confirmation.
Physical AI, however, does not mean placing every workload on the device or allowing equipment to make every decision autonomously. The cloud is well suited to large-scale model training, cross-system data integration, and complex reasoning. The edge preserves responsiveness, data privacy, deterministic operation during network outages, and local control.
A mature architecture does not choose between edge and cloud. It assigns each task to the environment best equipped to handle it.
Edge AI Performance Is About More Than TOPS
The first technical foundation of Physical AI is heterogeneous computing close to the point of operation.
The CPU offers broad flexibility for system control, application logic, and operations that an accelerator may not support. The GPU is effective for graphics, imaging, and highly parallel workloads. The NPU or APU provides dedicated acceleration for neural-network inference, delivering greater efficiency within a constrained power envelope. In a real product, these processors typically work together rather than relying on a single compute engine.
An AI performance figure measured in TOPS cannot, by itself, determine whether a device can run a particular model. Model size, quantization method, supported operators, memory capacity and bandwidth, context length, thermal design, and the available power budget all affect the actual user experience.
This is especially important for language models. Small language models (SLMs) use fewer parameters and computational resources than large language models, making them better suited to real-time, offline, and resource-constrained environments. Even so, an SLM must still be selected and optimized for the target hardware, available memory, and intended task. Not every edge device is suitable for an SLM, and a larger model does not automatically produce a better product experience.
Platform selection should therefore begin with the actual workload. Lightweight image recognition, gesture detection, and event classification may favor platforms optimized for cost and power efficiency. Products requiring on-device GenAI, vision-language models, multi-camera analytics, or longer semantic context need more capable NPUs and larger memory configurations.
Platforms such as MediaTek Genio 420, Genio 520, and Genio 720 address different levels of edge AI and GenAI requirements with scalable CPU, NPU, memory, and multimedia capabilities. InnoComm's SOG52 and SOG72 integrate the corresponding platforms into SoMs, giving development teams a modular foundation that combines processing, memory, storage, I/O, and operating-system support.
Model Refinement in the Cloud or on a Host System
The phrase "from edge to cloud" can create the impression that every inference request must be sent to the cloud. In a Physical AI architecture, however, the cloud or a host PC also plays another important role: model development and optimization.
Development teams typically train and validate a model in the cloud or on a workstation before converting it from a mainstream framework into a format supported by the target platform. Techniques such as quantization, pruning, and mixed precision can then reduce model size, memory requirements, and computational demand. A hardware-specific toolchain can further compile the model into a deployment package optimized for the target NPU.
This process involves more than simply making the model smaller. Teams must verify accuracy before and after conversion, determine which operations can be accelerated by the NPU and which must run on the CPU or GPU, and confirm that latency, memory usage, temperature, and power consumption meet the requirements of the actual device.
A typical Edge AI deployment workflow includes model conversion, compilation, performance profiling, and accuracy evaluation. Depending on application requirements, developers may choose between flexible framework-based execution and hardware-precompiled deployment to reduce overhead and achieve more predictable latency.
For product teams, the names of the individual tools matter less than establishing a repeatable workflow. Every model update should be convertible, testable, deployable, and recoverable—rather than working in the lab but producing performance or compatibility issues on production hardware.
One Architecture, Two Distinct Loops
A complete cloud–edge Physical AI architecture contains two loops that operate on very different time scales and serve different purposes.
Model lifecycle: Data and models → Cloud or host training, quantization, and compilation → Edge deployment, validation, and updates
Runtime control loop: Cameras and sensors → Edge inference → Safety-rule validation → Device or actuator response → New field feedback
The model lifecycle may evolve over days or weeks. The field execution loop may need to complete within milliseconds or seconds. Separating the two avoids a common misconception: Physical AI does not require all raw data to travel continuously between the device and the cloud, and critical control actions should not depend on network availability.
When an event requires enterprise knowledge, records from multiple devices, or more complex semantic understanding, the edge can upload only the necessary event summary—for example, an error code, a short window of sensor changes, an inference result, and the user's question. A cloud-based LLM can then combine this information with maintenance manuals, historical work orders, or enterprise data to produce a more informed recommendation. Once returned to the field, the result must still be checked against equipment status, user permissions, and established control rules before it becomes a prompt, task, or physical operation.
Back to the Field: From Sensor Streams to Safe Action
Physical AI creates value when data is converted into action at the point of operation.
Cameras, audio devices, and sensors generate continuous streams of data. An edge system must perform preprocessing, inference, and event evaluation within a limited compute and power budget. Time-critical workloads can use models optimized in advance for the target hardware to reduce execution overhead and improve latency predictability. Applications that require frequent model changes or portability across platforms may retain a more flexible execution approach.
Regardless of the deployment strategy, an AI output should not automatically become a control command. A clearly defined safety layer must sit between the model and the equipment, validating device status, operating boundaries, user permissions, and current conditions. AI may identify a potentially misaligned workpiece, but speed limits, restricted zones, emergency-stop functions, and human-approval requirements should remain protected by deterministic, verifiable control mechanisms.
With this structure, a device can maintain essential perception, alerts, and basic control even when the network is unavailable. Once connectivity returns, it can synchronize event records or request more comprehensive cloud analysis.
Security Cannot Be Added at the End
When AI begins to influence physical equipment, security must extend from model deployment and data processing all the way to control execution.
Product design should address secure boot, software and model signing, encryption for data at rest and in transit, identity and permission management, and recovery mechanisms for failed system updates. Where supported by the platform and operating system, protected execution environments and memory isolation can further reduce the risk of unauthorized access to input data, model files, and inference results.
Teams must also define how a device should degrade safely when inference confidence is low, a sensor fails, connectivity is lost, or model versions become inconsistent. Reliable Physical AI does not assume that a model will always be correct. It ensures that the system still knows how to remain safe when the model is uncertain or another component fails.
How Physical AI Moves from the Factory to Retail and Care
In industrial and logistics environments, cameras can identify workpiece position, stacking conditions, and approaching personnel, while vibration and temperature sensors provide information about equipment health. Edge AI evaluates these conditions locally and can slow, alert, or pause equipment when necessary. The cloud can then combine maintenance knowledge with historical data to help engineers understand the cause of an anomaly and determine the next diagnostic step.
In smart retail and service terminals, a device can perform wake-word detection, speech recognition, image analysis, or domain-specific SLM inference locally to preserve responsiveness and privacy. When a request requires extensive product knowledge, inventory across multiple stores, or a more complex recommendation, a cloud model and enterprise systems can provide additional context. Payments, membership data, and inventory changes should still be handled by established systems under appropriate access controls.
In healthcare, care facilities, and smart buildings, edge devices can process emergency calls, positioning data, mmWave radar, and environmental events in real time without continuously uploading raw video. When an event requires care records, staff schedules, or analysis across multiple locations, the device can send a focused summary to the cloud to help personnel understand the situation more quickly—not to replace professional judgment.
These applications may look very different, but their underlying logic is the same: give the field enough intelligence to perceive and respond locally, use cloud knowledge when it adds value, and turn the final result into an action that is controlled, traceable, and appropriate to the situation.
From Silicon and SoMs to Production-Ready Physical AI Products
A model running successfully on a development board is still a long way from becoming a finished product.
Product teams must integrate cameras, audio, displays, sensors, and wireless connectivity while addressing power, thermal design, mechanics, operating systems, drivers, and long-term software updates. They must also ensure that AI workloads perform consistently on production hardware. When model selection, hardware selection, and system design proceed independently, teams often discover too late that memory is insufficient, interfaces are incompatible, power consumption is too high, or software versions do not align.
InnoComm SoM & Connectivity Module provides a modular hardware and BSP foundation supported by expertise in Embedded Android and Linux, edge AI, cameras and audio, wireless connectivity, and system integration. InnoComm helps customers progress from platform selection, model assessment, and proof of concept to complete product design, validation, and mass production.
InnoComm's role is not to manufacture the robot itself. It is to help customers build the computing, software, and connectivity foundation inside the device—the technology that enables Physical AI to operate reliably across different product formats and real-world environments.
Turning Cloud Intelligence into Value in the Field
The value of Physical AI does not come from giving every device the largest possible model or complete autonomy. It comes from executing the right workload in the right place.
The cloud or host environment provides model training, optimization, and access to broader knowledge. The edge preserves responsiveness through heterogeneous computing, local inference, and safety rules. The device turns those decisions into prompts, services, and actions that users can experience in the real world.
When these two loops are designed effectively, AIoT devices can continue operating when offline, continue improving when connected, and maintain the control and safety required to function in an unpredictable physical world.
Learn more or discuss your project requirements — contact InnoComm today.