Physical AI: What It Actually Is, and What It Costs to Deploy

Physical AI is the part of artificial intelligence that has to be right in front of something. Not right on a benchmark, not right on average across a validation set, but right about this doorway, this vehicle, this obstacle, at this moment, with the actuators already moving.

The term has had a busy two years. NVIDIA built a product line and a developer conference narrative around it. Robotics investors adopted it as a category. It is now vague enough to be worth defining precisely, because the engineering underneath it is not vague at all.

A working definition

A physical AI system perceives the world through its own sensors, decides what to do, and acts on the world through its own actuators, with that loop closing on the machine itself. Three properties follow, and they are what separate it from an AI product that happens to have a camera:

• The loop is closed on the platform. The output of the decision changes the next input. A recommendation engine is wrong and the user scrolls on; a physical system is wrong and it has already moved.
• Latency is a safety property, not a UX metric. A 400ms round trip to a cloud endpoint is a good API. It is also four meters of travel for a vehicle at 22 mph.
• There is a power budget, and it is small. Every watt spent on perception is a watt not spent on propulsion, and on most platforms it is the same battery.

Everything hard about the field falls out of those three.

Case study: NASA lets a model plan a drive on Mars

In December 2025, NASA's Perseverance rover completed the first drives on another planet planned by artificial intelligence. Engineers at JPL used vision-language models to generate waypoints, a task normally done by human rover planners, and the rover drove a total of 456 meters across two days without human control.

The detail worth studying is not the model. It is the harness around it. Before any command went to Mars, the team ran it through JPL's digital twin of the rover and verified more than 500,000 telemetry variables against the flight software. The model proposed; a deterministic simulation of the actual vehicle disposed.

That is the shape of every credible physical AI deployment we have seen. The learned component is bounded by something that can be checked. Nobody who has to answer for a vehicle ships a policy network with authority over actuators and no verification layer beneath it.

Case study: DARPA RACER, and what off-road really costs

DARPA's Robotic Autonomy in Complex Environments with Resiliency program ran from 2021 until its conclusion, and it is the most honest public dataset on what unstructured terrain does to autonomy. The program's goal was combat-scale vehicles moving autonomously through terrain with no lanes, no markings, and no map worth trusting.

Early experiments ran roughly two-mile courses at just under 20 mph. By the later phases the program had scaled the same algorithms onto RACER Heavy Platform vehicles: 12-ton, 20-foot tracked machines. The interesting result was not top speed. It was that the difficulty of the problem is set by the environment's structure, not by the vehicle: the same stack that behaves on a road needs fundamentally more perception, and more margin, the moment the road ends.

This is the case a federal buyer should have in mind. Highway autonomy and off-road autonomy are not the same problem at different difficulty settings. They are different problems.

Case study: the boring, enormous one

Amazon has deployed more than a million robots since 2012. Its Sparrow arm handles over 200 million distinct products by shape, size and weight; Proteus, its first fully autonomous mobile robot, moves carts around people in open floor space rather than in caged zones.

We include this because it is the counterweight to the humanoid demo reel. The largest working deployment of physical AI on earth is a logistics operation, and it got there by narrowing the problem until the environment was partly engineered in its favor: known floor, known lighting, known catalog, hard safety interlocks. That is a legitimate strategy and usually the right one. Constrain the world before you ask the machine to generalize across it.

The constraint nobody escapes

NVIDIA's Jetson Thor, the current reference compute module for robotics, delivers up to 2,070 FP4 teraflops inside a 130-watt envelope. That is an extraordinary amount of compute, and it is also a space heater on anything that flies or runs on a battery for a shift.

The number to hold onto is the envelope, not the teraflops. Ask what your platform can actually give perception, continuously, and the answer is usually single digits of watts: a small UAS, an unattended ground sensor, a wearable, a cubesat. That is the gap between what physical AI demos look like and what fields.

It is also why we work on neuromorphic silicon. Conventional processors separate memory from compute and run on a clock, burning energy on every cycle whether or not anything happened. Event-driven processors spend power only when the world changes. In our own lab, a hybrid deployment pairing a BrainChip Akida with an NVIDIA Jetson held the same accuracy at 9 watts that the Jetson alone needed 120 watts to reach. The full method and measurements are in our benchmark write-up.

At the research end, the same physics scales up: Intel's Hala Point packs 1,152 Loihi 2 processors and 1.15 billion neurons into six rack units drawing a maximum of 2,600 watts. Nobody is putting that on a drone. It is evidence that event-driven architectures hold their efficiency advantage at scale, which is the precondition for trusting them at the small end.

How to scope a first physical AI project

The pattern that works, in order:

1. Write down the power budget first, in watts, continuous, for perception alone. Every later decision is downstream of this number and teams routinely discover it after choosing hardware.
2. Name the failure you cannot accept and design the deterministic check that catches it. If there is no such check, you have a demo, not a system.
3. Constrain the environment as far as the mission allows. Generalization is expensive and you should buy it only where you must.
4. Pick one workload for event-driven hardware, typically the always-on sensing tier, and leave the rest on conventional compute. Porting everything at once is how neuromorphic pilots fail.
5. Measure on the platform, not in a rack. Thermal throttling, power delivery and sensor timing are all different once it is bolted down.

Where this is going

The honest read on the field: the perception and control research is moving faster than the verification and assurance work that has to sit under it. Learned policies are getting very good. The tooling for proving to an accreditor that one is safe is not keeping pace.

For anyone buying, that means the differentiator over the next few years is not whose model is best. It is who can show measurements, on real hardware, inside the power and latency envelope you actually have, with a verification story an authorizing official will sign. That is the work we do.