Physical AI and the ChatGPT moment

There has been a lot of buzz about physical AI recently. Given that it involves robots and intelligence, a perfect recipe for verification problems, I couldn’t let it slide. I’ve been reading up on the changes and the technology, and as I do that I thought I’d share some of my thoughts, lessons and reflections here. This is going to be a series of posts in no particular order.

At first when I heard physical AI, it was a bit confusing, with all the other jargon out there. What we now call physical AI, or at least a variant of it, has gone by several names. There was cybernetics, then cyber-physical systems, which is the term I used through my PhD and most of my work since, and embodied AI from cognitive science and robotics. Physical AI is the newest label, and Jensen Huang pushed it into the mainstream at CES 2025. This is not to say that there is nothing new in physical AI. It adds the dimension of learning from data to perform tasks.

I recently read about BMW’s experiment with Figure’s humanoid robots at its Spartanburg plant. This was quite interesting, as Figure aims to have robots that are completely autonomous. That is, once the goal is given to them, they figure out how to perform the tasks and don’t really need much intervention. They are generalists, think of something like L5 in autonomous driving. The closest I’ve seen to mapping this is a graph by Montauk Capital that plots reasoning autonomy, how much a robot can figure out on its own, against charge autonomy, how long it can keep working without a dock. The corner where a robot scores high on both is nearly empty. And, I think, the followin write up refers mainly to the right most boxes and not so much to the ones on the left. Maybe the spectrum and how they differ is for another post.

At Spartanburg, the robots loaded sheet-metal parts onto welding fixtures, ran 10-hour shifts on weekdays and logged about 1,250 hours of runtime. The project ran for eleven months, but that counts from when Figure first brought up the robot. They reached the plant around month six and an active assembly line only around month ten, and BMW calls the whole thing a pilot.

Still, it is the most concrete public deployment of humanoids I have found, and it is what the field is hoping for, robots on a real line generating real data. Figure says every hour on the line and every intervention logged shaped how it built Figure 03. That data went back to Figure though. Figure also set three targets, cycle time, placement accuracy and interventions per shift, and reported results for none of them. The number of interventions is the one that would tell us how the robot handles the rare cases, and it is the one we don’t get to see.

Physical AI is having its time right now, and much of the field sees data as the main bottleneck. In his interview with Sergey Levine, Dwarkesh Patel asks, “If data is a big bottleneck, why can’t you just increase the size of your office 100x?” The plan is to collect as much data as possible to get a flywheel started, and hope for a ChatGPT-like moment. People mean different things by that. For some it is a jump in what robots can do, and by that measure Jensen Huang already called it here at CES 2026. My understanding of it is closer to what happened when ChatGPT came out. The model was already good at launch, and the moment was millions of people using it within a couple of months. For robots that kind of use is also what would get the flywheel going, since every robot in use collects data. Levine doesn’t fully agree with the question. In his answer, more data alone isn’t enough, you also need to know what to scale to get which capability. So the question is when robotics gets its moment, and what it looks like when it comes.

Robots have to generate their own data

Robots need data to train on to become general. Language models had the internet’s text sitting there before the models arrived. Unfortunately, robots have no such pile; they need to generate it.

The Hugging Face robot learning tutorial explains part of how every trajectory belongs to one robot in one set of conditions. Expert demonstrations are expensive, and two experts will do the same task two different ways. Mix data from different bodies and you can get negative transfer, where the mix can be worse than the parts. Dwarkesh Patel makes a related point in the Levine interview:

Famously, LLMs have all these emergent capabilities that were never engineered in, because somewhere in internet text is the data to train and to be able to give it the knowledge to do a certain kind of thing. With robots, it seems like you are collecting all the data manually. So there won’t be this mysterious new capability that is somewhere in the dataset that you haven’t purposefully collected.

One answer to the shortage is to pool data. Open X-Embodiment pooled 60 datasets from 22 robot types, over a million trajectories. A model trained on the pool did better than the specialist models on the robots that had little data of their own, but on the large datasets it did worse, and only a much bigger model improved on them. That pool came from research labs, not from robots in production, and the models were tested on the same kinds of tasks the data came from. So I am a bit skeptical when applying it to general tasks.

A second answer comes from the web. Levine says web data already helps robots generalize, though “I don’t think that by itself is a silver bullet.” His own model at Physical Intelligence is, in his words, “a vision-language model that has been adapted for motor control”, so the robot starts from what that model learnt from images and text on the web. He adds “I don’t think it solves everything, but it does help a lot”, and hopes that a model which learns by controlling a robot will get better at absorbing data sources that have been tricky to use so far. Web data can tell a robot what a cup is and where it usually sits. It says much less about how hard to grip the cup or what happens when it slips, and that part the robot still has to collect itself.

A third answer is simulation. Baillie Gifford see simulators running millions of virtual trials as a fix for the shortage of training data. Still, a bigger pool doesn’t mean the rare cases are in it, and as Bosch puts it, the tail “is where all the value and all the liability sit.”

During my PhD we were trying to learn discrete models from existing data from factory floors. A fundamental limitation there is that you only get to collect what exists and never get what is wrong that leads to errors. In reinforcement learning, since the agent tries things and sees what fails, it overcomes part of the issue. But on real hardware you can’t let it explore the unsafe actions, so it relies on simulation, and simulations are never complete. That’s something for another post.

The data that exists is locked in

Robot data does exist, and a lot of it, actually. Bosch counts about 4.66 million installed industrial robots that have been “executing, logging and correcting for years,” with almost none of that captured in a form that could train anything.

During my PhD we did a small version of getting that data out (2018, 2019). An ABB robot knows exactly what it is doing, but getting the data out is hard without writing extra code into or around the robot. We subscribed to the signal changes of the program point through the vendor’s SDK, without touching the robot program, and turned them into live Gantt charts of the robot operations at an automotive company. The data was good for monitoring and building process models. However, it was far from being useful to train a policy on.

The hard part was getting it out. The data exists, but it sits inside each vendor’s walled garden. It isn’t public, and every vendor has a reason to keep it that way. I assume ABB will try to build its own models on what its robots log, KUKA its own, and Fanuc and Yaskawa theirs. Or the product companies themselves can start creating their own models. Text, on the other hand, was easily available on the internet, so anyone with enough compute could train on roughly the same pile (even if that meant breaking copyright laws), and general models came out of it. Robot data is proprietary from the start, and proprietary data would give rise to proprietary models, each trained on one vendor’s machines and sold inside that vendor’s products. That is perfectly fine. The issue then is how we go from siloed data to general intelligence.

I recently read about the EU Data Act, which might change part of this. Since September 2025 it gives users of connected products, industrial machinery included, a right to the data their machines generate and to share it with third parties, and products put on the EU market from September 2026 have to be designed for that access. How it gets implemented, and what it actually means for the data on the factory floor would be interesting to look into.

So when?

My expectation isn’t a ChatGPT moment but a much slower adoption. We can’t generate the data from day one. It is going to take time, and we will start with limited, structured spaces, manufacturing systems and warehouses, where deployments are much more feasible, and then go more general, towards homes and more unstructured environments. Autonomous driving took a similar path. Driver assistance was the first stepping stone, and driverless cars came later, in small geofenced areas. At the start most of the demonstrations only took place on highways. Even Levine, who is far more optimistic than I am, expects the scope of what robots are trusted with to grow step by step. In subsequent posts I plan to go deeper into this to understand the emergence of outcome that is general and usable in the short term.

Structured spaces have structure and are more fixed. The rules are well known or at least teachable, the tasks are limited and to some extent fixed, and simulating a limited space is much easier than simulating everything in the world in one simulator. Bosch says much the same: “Generality is a claim about a distribution and the only way to close a distribution is to bound it.” But fixed tasks are also what industrial robots already do, with hand-made code and definitions for each one. What you want from learning is something more general and adaptable, being able to give a goal and let the robot figure things out. That way you can change robots more easily, one robot can do multiple tasks, and there is less downtime between them. The environment can be structured but it still has variability that learning can handle.

A few things would change my mind about generalist robots coming faster. If deployments like BMW’s start logging hours fast, and failure rates in the long tail fall with them. If transfer holds at long horizons and on new tasks, outside the lab benchmarks where Open X-Embodiment tested it, more of the stack can be learned. The same goes if learned policies become cheap to verify. Right now Bosch points to an analysis of 1,228 vision-language-action papers, where policies that succeed about 95 percent of the time on the LIBERO benchmark drop below 30 percent when the scene is changed only slightly. And if deployed machines start producing usable data as a byproduct, the flywheel turns without anyone doing special collection. Even then, I believe what we will see is learned models handling specific functions inside a robot, with more deterministic, explicit control around them for the rest.

Now, I might be wrong. The ChatGPT moment might be very close, right around the corner, and that would be exciting. Already, LLMs have become so great that they can generate control code to control robots extremely well.

Sources