What is physical AI? A working definition

Physical AI is artificial intelligence that perceives the physical world, decides what to do, and acts on that decision through a machine body. The body can be a robot arm, a wheeled mobile robot, a humanoid, a drone or a car. What makes it physical AI is that the output is motion — and motion has consequences that cannot be reviewed before they happen.

The term is recent as an industry label; researchers have studied the same thing for decades under the name embodied AI.

How physical AI differs from generative AI

A language model and a robot model can share most of their architecture. What they do with it is different.

	Generative AI	Physical AI
Output	Text, images, code	Motor commands
Who checks the output	Usually a person, before it is used	Nobody — it executes immediately
Cost of an error	A wrong answer	Damage, downtime or injury
Training data	The internet	Must be collected or simulated
Timing	Seconds are acceptable	Control loops run many times per second
Runs on	A data centre	Mostly on the machine itself

The second and third rows are why this handbook spends as much time on safety and regulation as on models.

The physical AI stack

It is tempting to think of a robot as “a model with a body”. In practice a working system has at least five layers, and most failures in the field come from the boundaries between them.

1. Sensing. Cameras, depth sensors, joint encoders, force-torque sensors and inertial units turn the world into numbers.
2. The model, or policy. The learned part: it maps what the robot observes, and often a language instruction, to what it should do next. Vision-language-action models are the current leading approach.
3. Low-level control. Classical controllers turn the model’s intended motion into motor currents, hundreds or thousands of times per second.
4. Hardware. Actuators, hands, structure, compute and batteries set hard limits on what any model can achieve.
5. The safety layer. Independent, verified functions — protective stops, speed and force limits, safeguarded zones — that hold no matter what the model outputs.

Around the stack sits everything that makes it a product: fleet management, remote assistance, maintenance and integration with the site’s existing systems.

Why now

Three things changed in a few years.

Foundation models reached robotics. Pretrained vision-language models gave robots a usable understanding of objects, scenes and instructions without learning them from robot data alone.

Data began to pool. Efforts such as Open X-Embodiment combined more than a million robot trajectories, from 22 types of robot, into a shared dataset, which made training one model across different bodies practical.

Simulation became good enough to train in. GPU-accelerated simulators let a policy practise for the equivalent of years in hours, at least for skills such as walking where simulation transfers well to reality.

What is still hard

Data is scarce. There is no internet of robot actions. Every hour of demonstration data has to be collected by teleoperation, generated in simulation, or inferred from video of people.

The world has a long tail. A robot that succeeds 95% of the time is an impressive demo and an unusable product. Closing the gap from “usually works” to “works for a whole shift without help” is where most deployment effort goes.

Learned behaviour is hard to certify. Machine safety has traditionally relied on predictable, analysable behaviour. A neural network policy offers neither, which is why safety functions are kept outside it and why a rigorous risk assessment matters more, not less.

Hardware is expensive and breaks. Unlike software, every additional unit costs money to build, ship and repair.

Where to go next

If you are new to the field, read on in this order: how robot models work, how a risk assessment is done, and which standards apply to which kind of robot. The glossary defines every term used along the way.