In our previous Physical AI Month post, Alexander Sashkov argued that Physical AI is a system-engineering effort, and that getting the architecture right means mapping the right work to the right hardware block. This post is about the vocabulary for that mapping.
Edge AI, embedded AI, and Physical AI are often used as if they were 3 sizes of the same thing. They're answers to 3 different questions: where does inference run, how tightly is the model bound to the hardware, and does the system act on the world. A single machine can answer yes to all 3. To help visualize this, the rest of this post follows one robot.
Take an autonomous mobile robot that moves pallets around a warehouse shared with people. It runs 3 control loops at very different speeds.
Runs on a microcontroller at roughly 1 kHz. It reads the wheel encoders and the IMU, drives the motors, and stops the robot when a bumper or the safety lidar says so. Its timing is deterministic by design.
Runs on a system-on-chip with a neural accelerator at 20 to 30 frames per second. It finds people, forklifts, and obstacles in camera and lidar data, and keeps track of where the robot is.
Decides which pallet to fetch next and which aisle to take. It runs every few seconds, on a server in the building or in the cloud, and coordinates the fleet.
One robot, 3 loops: each term above covers a different span of this same system. Our example assumes the planning loop runs in the cloud. If the planner runs on an on-site server instead, edge AI covers all 3 loops as well. That overlap is why it’s crucial to know how the terms answer different questions about the same machine.
The robot as a whole closes the loop of sensing, deciding, acting, and checking the result, and the terms we’ll explore below describe the different spans of that loop. The end of this post will highlight what each costs and where teams tend to get it wrong.
Edge AI makes one claim about a system: the model runs close to where the data is produced, on the device or on a gateway or industrial PC beside it, instead of in a remote data center. In our robot, the perception loop is edge AI, and the camera frames never leave the machine.
Latency is the usual argument. A round trip to the cloud over warehouse Wi-Fi can reach 300 milliseconds, and a robot moving at 2 meters per second covers 60 centimeters in that time. It's rarely the strongest argument, though. A fleet of 40 robots with 3 cameras each can't stream video through a plant network sized for barcode scanners. Warehouses have Wi-Fi dead zones that nobody marks on the site plan, and the robot has to keep behaving when the network drops. Cameras on a shop floor see people, and that footage is easier to keep on-site than to move. Cloud inference is also a recurring bill that grows with the fleet; inference on the robot is a capital cost, paid at purchase plus electricity.
The price is engineering, because the hardware sits in the field with a thermal and power envelope, and rolling a new model out to 40 robots is a staged fleet update with a rollback plan. What the term does not tell you is how constrained that hardware is. An industrial PC with a discrete GPU and a microcontroller with 512 KB of flash are both edge. That gap is what the next term covers.
The boundary between edge AI and embedded AI isn't standardized, and engineers differ on where it falls, some call a Linux SoC with a GPU "embedded" too. This post uses the term for a model that ships as a component of the product's firmware, on hardware whose compute, memory, and power budget were fixed when the board was designed.
In our robot, the slip detector, a small network that watches motor current and IMU data at 1 kHz and flags a wheel sliding on a wet patch or a load that has shifted, is embedded AI. It gets a few hundred kilobytes of flash, runs int8 weights (the model's math compressed down to a smaller number format), and has a few hundred microseconds per inference, because the loop won't wait for it.
The defining moment is the BOM freeze, the point where the bill of materials and the chip gets locked in. The day the microcontroller is chosen, the model's ceiling is set. There's no bigger instance to migrate to; the upgrade path is a pin-compatible part with more memory in the best case, and a board respin if not.
This is why the model and the hardware have to be designed together. The machine learning team needs the memory and cycle budget before training starts, and the hardware team needs to know how much model the product requires before picking the part. Memory budget is usually the number teams argue about first, but the cycle budget is the one that breaks the schedule, since it only shows up once the model runs alongside everything else on the chip. Getting this order wrong costs months, and it's usually discovered at integration.
The toolchain is tied to the chip, as getting a model to run well on a microcontroller means quantization, operator support checks, and a runtime such as TensorFlow Lite for Microcontrollers on top of CMSIS-NN kernels, or the silicon vendor's SDK. The same model on a different chip is a separate porting job. Updating the model works differently too, depending on the chip.
On the perception SoC, a new model is a container pull. On the motor controller, a new slip detector goes through the full firmware release process: an over-the-air update, a rollback plan, and re-validation of everything that shares the chip with it, safety logic included. Which is one of the reasons safety functions on a real robot often get their own dedicated controller. This causes issues such as odometry drift, and its fix ships at firmware speed, not app-update speed.
When a perception workload outgrows its compute module, there's usually an upgrade path that leaves the rest of the robot alone. When the slip detector outgrows the motor controller, the upgrade is a new part or a new board, and a new safety validation either way.
Physical AI is the term for the whole robot. It’s a system that perceives, decides, and acts in the real world in a closed loop, and adapts when the world differs from what it expected. The previous post covered the definition, the sim-to-real gap, compounding errors, and why safety is a system property, so this section focuses more on how it relates to the other two questions.
It's easy to assume "Physical AI" means the AI has to live on the robot itself. It doesn't. Physical AI says nothing about where inference runs, the planning loop can live in the cloud and the robot is still Physical AI. What actually decides where each piece of intelligence runs is speed. The fastest loop a decision takes part in sets a hard ceiling on where it can live; the bandwidth, connectivity, and cost arguments from the edge section choose within that ceiling. Route planning can tolerate a few seconds of delay, so it can run anywhere with a network connection. Obstacle avoidance needs a response within tens of milliseconds, so it has to stay on the robot. The safety stop, once the scanner or bumper trips, needs single-digit milliseconds, so it stays on a dedicated, predictable local controller. One robot, 3 different placements, and all 3 terms from this post apply to it at once.
Once a robot is physically strong enough to hurt someone, this stops being just an engineering choice and becomes a legal one. A robot moving a 500 kg load near people has to meet formal safety standards covering the control system (ISO 13849 and IEC 61508) and driverless industrial vehicles specifically (ISO 3691-4). Formally certifying an AI model itself under these standards is possible in theory, and the standards bodies are actively working out how (ISO/IEC TR 5469 offers early guidance, and a full requirements document, ISO/IEC TS 22440-1, is still being drafted), but for most industrial projects today, that's not a certification path worth betting a schedule on.
The workaround most teams use is straightforward. Let the AI model guide normal, everyday operation, but keep a separate, simpler safety system in place that can shut things down instantly without relying on the AI model at all. This is sometimes called “deterministic logic above the model”, meaning the safety function runs on traditional, predictable logic rather than a learned model, so it doesn't need the same certification the AI would. That split has to get decided before the first schematic is drawn, since it determines which chip handles which job.
The gap between the words and the work shows up in 3 recognizable ways:
Projects usually run into at least 2 of these at once. Each one is a term being misread. The first team heard "edge" and pictured a smaller cloud. The second heard "embedded" after the hardware was already fixed. The third heard "Physical AI" and pictured robotics plus a model.
We work across all 3 layers, from hardware design and embedded firmware to on-device model optimization and the IoT and edge systems that connect the fleet. The advantage of doing this under one roof is due to the BOM freeze. The decisions above have to be made by one team, at one table, before the parts are ordered. If your project has more than one of these loops in it, let’s connect.