Physical AI in Manufacturing: What It Is, What It Is Not and Why It Starts with Data

Physical AI is AI that perceives, reasons and acts on the real world. In a factory it starts by capturing the data of the equipment that already exists properly. This guide formalises that loop, places each plant decision in its time horizon, describes what the data must satisfy at every rung and orders the path into a five-level ladder with observable criteria. Level 4, the one with robots and autonomous policies, is explained at the end as the state of the art of the sector, with the sources in the text itself.

What physical AI is and what it is not

Physical AI is AI that perceives, reasons and acts on the real world. In a factory it starts by capturing the data of the equipment that already exists properly. The NVIDIA glossary definition (consulted in September 2026) points the same way: systems that perceive, understand, reason and perform or orchestrate complex actions in the physical world. What this guide changes is where it puts the starting point: not on the robot, but on the data of the machine you already have.

The three verbs are easier to understand with equipment every plant already owns. A PLC reads temperatures, pressures, limit switches and part counters every few milliseconds: that is already perception, and the problem is that it stays inside the device. When a line stops, someone crosses the controller warning with the shift, the product being run and the machine history to decide whether it is a micro-stop or a breakdown that will last: that crossing, manual today, is reasoning. And lowering a compressor setpoint when demand drops, or opening a maintenance order when vibration goes out of range, is acting. Perceive, reason and act are not technologies, they are capabilities: a plant can have them manually, partially or automated.

It also helps to pin down where machine learning enters, because saying that a system uses AI without saying where says nothing. It can enter perception, when a model interprets an image or a vibration series that a fixed threshold could not read. It can enter the model of the process dynamics, when the response of a machine to an input is identified. It can enter the decision policy, which is where the autonomous policies of level 4 live. And, far less often, it can enter the objective itself, learning the cost function. The rule that orders the rest of the article is simple: the closer to the actuator the system learns, the more demanding the verification required. A defect classifier is validated against a labelled set and is cheap; a policy that moves an axis is validated on unseen cases and needs an independent safety envelope.

What physical AI is not

The term is used today to sell almost anything. The fastest way to draw the line is to ask about the three capabilities and about a fourth one almost nobody demands: whether the system measures the effect of its own action.

Four boundaries follow from the table. Generative AI produces content from a request and stays on the screen; it can be part of a physical AI system as a reasoning or interface layer, but on its own it closes no loop. The digital twin is a representation fed with real data, extremely valuable for reasoning and for testing before touching the plant, but a twin with no loop back is a mirror. Classic automation, the PID and the interlock logic, is a particular and very well solved case of the loop: it perceives one variable, applies a fixed law and acts, with no declared economic objective and no memory. And programmed robotics runs a taught path: it does not reason about what it perceives, which is why it works beautifully as long as the part arrives where expected.

A fifth confusion remains, the most frequent one in 2026: a conversational assistant with read access to the SCADA. Asking for the state of a machine in natural language is convenient and has value, but it is still a read-only interface. There is physical AI only when the system can close the loop with a bounded, traceable, supervised action whose effect is measured.

The perceive, reason, act loop

A plant is a dynamic system, and describing it with the notation of control theory saves a lot of arguments. There is a state, what you would need to know about the system at an instant in order to predict its future: temperatures, positions, wear, work in progress. It is almost never directly observable. There are actions, what the control system can modify: setpoints, starts, speeds, work orders. There are disturbances, what changes the state and is not controlled: raw material, environment, the electrical grid, people. And there are observations, what the sensors return, which is noisy, partial and delayed.

With that notation the loop breaks down into four chained stages. They are four different engineering problems and it pays not to mix them, because they fail for different reasons and are fixed by different teams.

Acquisition and signal conditioning

This turns a physical phenomenon into a number that means something. The sensor translates pressure, temperature, current or light into an electrical signal, with its accuracy, its drift, its bandwidth and its mounting: a well-chosen but badly mounted sensor produces bad data that looks good. Then comes conditioning, and here one rule admits no exception: the anti-aliasing filter goes before sampling. If the signal has content above half the sampling frequency, that content does not disappear, it folds onto the useful band and shows up as a false component that no later processing can separate.

The Nyquist criterion sets the theoretical minimum at twice the maximum frequency of interest, but industrial practice works at five to ten times the frequency of the phenomenon to be reconstructed, because the goal is not only to avoid aliasing but to see the shape of the signal. Quantisation adds its own noise floor: the nominal bits of the converter are not the useful bits. And the stage industry underestimates most is the last one: timestamp and context. A number with no instant and no asset identity is not data, it is a figure.

State estimation

Going from observations to state is an inference problem, not a data transport problem, and it starts with a prior question: observability. With the sensors installed, can the state you want to know be reconstructed? If it is not observable, no algorithm recovers it. Adding a model does not replace adding a sensor when what is missing is information.

Methods range from classical filtering, when a model exists and noise is reasonably characterised, to nonlinear observers and learned models when the physical model is unavailable or intractable. In plant language, estimating state means going from digital input 7 being at zero while the counter does not advance, to line 3 having spent forty seconds in a micro-stop for lack of material upstream. That jump is exactly what separates level 1 from level 2 of the ladder.

Decision: the policy

A policy is a function from the estimated state to an action, subject to constraints and aimed at an objective. The usual forms, from least to most machinery, are the fixed feedback law (PID, cascade control), rules and decision trees written by experts, receding-horizon optimisation with a model, and a policy learned by imitation or by reinforcement. What defines a policy is not the technique but the existence of a declared objective and declared constraints. A system that issues recommendations with no written objective does not have a policy, it has opinions.

Actuation

The action is executed on real actuators, with saturation, deadband, hysteresis, wear and delay. Three requirements are almost always forgotten. The first is confirmation: writing a setpoint is not acting; acting is writing and then verifying in the measured signal that the equipment accepted and executed it. The second is authority: every action has an owner, someone who approves it, someone who can revert it and a set of interlocks under which it is never executed. The third is the record: which data triggered it, with which version of the rule or model, who supervised, what was written and what the equipment answered.

What changes compared with a PID and with an expert system

A PID is a degenerate particular case of the loop, which is why it works so well where it works. Its perception is the error on a single measured variable, with no state estimation. Its reasoning is a fixed linear law with three parameters tuned at commissioning, with no explicit model of the process and no constraints. Its action is one output on one actuator. Its horizon is implicit and very short: it reacts to the error already produced, it does not anticipate. And its adaptation is nil apart from manual retuning. None of that is a defect, it is its design, and it remains the right tool for the regulatory loop. Physical AI does not replace the PID: it sits above it and sets its setpoints.

Against an expert system the difference is another one. In an expert system the knowledge is written by a person once, and the classic bottleneck is exactly that: someone has to state every rule. It is also deterministic and categorical, whereas state estimation is probabilistic and returns a distribution. And there is a difference that matters on the plant floor: an expert system does not know that it does not know. Faced with a case not contemplated, it either fires no rule or fires the wrong one; an estimator with uncertainty can declare low confidence and hand over control. What the expert system does better is being auditable, explainable and reproducible, which is why safety layers and interlocks are still rules and must remain rules even when the policy is learned.

From all of the above comes the criterion used in the rest of this article: the loop is only closed if the effect of the action is measured. If the effect is not measured there is no closed loop: there is a recommender. That sentence is what separates level 2 from level 3 across the whole rubric.

Decision horizons and where the compute lives

A plant does not take one kind of decision, it takes four, and they span nine or ten orders of magnitude in time. The rule that orders them has two parts: the compute lives at the highest level that meets the latency and that still lets the level below degrade safely if the level above disappears.

In the regulatory loop, from microseconds to milliseconds, converter switching, motor current and torque, axis interpolation and safety interlocks are decided. The drive, the CNC and the controller resolve them, with no human intervention. The 5G-ACIA and ZVEI white paper (November 2019) places the usual cycle times of periodic industrial communication between 10 ms and 0.5 ms. The dominant constraint is not bandwidth but determinism: jitter matters more than the mean. That compute lives inside the controller, in the cabinet, and never on the far side of a non-deterministic network.

In supervision, from 100 milliseconds to seconds, live alarms, anomaly detection, sequence start and stop, in-line quality inspection and downtime classification. The constraint is different: it has to keep working with no link outside the plant. That is why it lives at the edge, on a gateway or an industrial PC, with a mandatory local buffer. Shift optimisation, from minutes to hours, resequences, adjusts a recipe, moves energy consumption or decides to stop for maintenance; it needs to cross production, energy, quality and maintenance, so it lives on the platform and tolerates a round trip over the network. And planning, from days to months, decides capacity, maintenance plans, energy contracting and investment; it needs long comparable history, and it is where model training lives, which must never sit on the critical path of a fast decision.

The boundary most often violated in practice is the first one: trying to close a millisecond loop through a platform. It does not fail because of bandwidth, it fails because of delay variance. And there is a second, less visible condition, the clock. The same 5G-ACIA and ZVEI white paper (November 2019) notes that the working clock domain, where robots and motion control sit, requires synchronisation of 1 microsecond or better, trending towards 100 nanoseconds. The standard that solves it is IEEE 1588-2019, the precision clock synchronisation protocol approved by the IEEE Standards Association on 7 November 2019, and the deterministic network profile for industrial automation, IEC/IEEE 60802, was published on 29 June 2026 according to the IEEE 802.1 TSN Task Group. In other words: the time infrastructure a fast loop needs is already a published standard, not a draft.

Why it starts with data: the substrate each level demands

Every rung of the ladder demands a different data substrate, and the requirements are cumulative: level 3 needs everything level 2 needs plus its own. Stating them separately avoids the sterile conversation about how much data is enough, which never has an answer, and replaces it with six questions that do: at what frequency, with what clock accuracy, with what context, with what completeness, for how long and under what governance.

At level 1 there is no global frequency, it is set per variable. Discrete machine states are captured on change of state with a resolution of one second or better, because an eight-second micro-stop vanishes completely if polled every thirty, and with it vanishes the largest availability loss of many lines. Counters go by event or by edge, never by difference of slow polls. Slow process variables sit comfortably at one second. Electrical power for energy management asks for one second to see the starting signature and the peaks: the fifteen-minute billing aggregate serves the invoice and explains nothing. And vibration for diagnosis, when the band of interest reaches tens of kilohertz, is neither transmitted continuously nor needs to be: the spectrum is computed at the edge and what goes up is the indicator with its window.

The timestamp is set at source, as close to the sensor as possible, and never at ingestion time. Tens of milliseconds of accuracy are enough for OEE, energy and shift analysis; to causally order events across different pieces of equipment, that is, to answer what tripped first when the failure cascade lasts less than a second, a millisecond or better is required. With no common clock, the history lets you count but not explain. The minimum context travelling with each value is equally concrete: stable asset identity (not the register address), quantity and unit, scale and range, data quality and the version of the signal definition. And completeness is measured per channel and per period, never globally, because an aggregated 99% hides an entire channel that was down.

At level 2 a context appears that is not technical but operational, and it is the one that sinks most projects: order and batch, product or recipe, shift and shift calendar, planned time, nominal speed of the product being run, good parts, rejects, rework and downtime reason taken from a closed catalogue. With no nominal speed per product there is no performance, and with no performance there is no OEE. At level 3 the requirement changes nature again: low latency is no longer enough, what is needed is bounded and measured latency, every action declares the maximum age the data justifying it may have, and an immutable record of the decision with its subsequent effect exists. And at level 4 completeness stops being a percentage of samples and becomes coverage of the distribution: ten thousand repetitions of the normal case do not cover the rare case that decides whether the system is deployable.

That is why in a factory physical AI starts with data, and it is not a commercial argument: capture is the only part of the loop that, when missing, invalidates the other two. Three recent sources quantify the starting point of Spanish industry. Metalindustria (22 May 2026), reporting on the third Barometer of industrial digitalisation and automation in Spain presented at Advanced Factories 2026, puts at 3.3% the factories describing themselves as fully digitalised. INE, in the final data of its survey on ICT use in companies for the first quarter of 2025 (published 22 October 2025), puts companies with 10 or more employees using artificial intelligence at 21.1%, and Fundación Cotec (same date) notes that industry stops at 17.5%. For comparison, Eurostat (11 December 2025) reports 20.0% across the EU, with Denmark at 42.0% and Finland at 37.8%.

The picture of prior automation points the same way. According to World Robotics 2025 from the International Federation of Robotics (September 2025), Spain installed 5,086 industrial robots in 2024, up 1%, and overtook France as the third largest European market behind Germany (26,982) and Italy (8,783). Average world robot density in manufacturing was 177 robots per 10,000 employees, with Europe at 148. In the IFR release of 8 April 2026, South Korea leads with 1,220 and Germany reaches 449. A robotised installed base is not the same as a connected plant, but it gives the scale of the starting point: there is plenty of machinery able to generate data and few plants able to use it.

There is also an economic argument that makes waiting until the end unnecessary. Connecting the existing equipment and turning its signals into real-time indicators produces value on its own: downtime that becomes visible, consumption that gets corrected, quality that can be traced. It is the base of the only result Captia publishes: over 30% energy savings in energy-intensive companies. Each level you climb pays for itself and leaves the plant ready for the next.

The Physical AI Ladder, level by level

The Physical AI Ladder is the framework we use to order that path. Five levels defined by what the plant can do with its data, not by the technology it buys. Each has criteria that are observable during a plant visit, a signal that confirms you are there and a concrete next step.

The ladder is used in two ways. As a diagnosis: you go down the signal column and the first level whose signal is not met is the real level of the plant, even if it has a brilliant pilot two rungs higher. And as a plan: the next-step column says what must be solved before investing in the following rung. The scoring rule is deliberately strict: a level counts as reached when its own criteria and those of every level below are met. Nothing is skipped. A plant can have lines at different levels; in that case it is placed by the line that holds the rest back, not by the best one.

Level 0: Isolated

The data exists, but it lives inside each machine. It is read on the panel screen or written on a report. There is no comparable history across equipment and no common clock, and the plant runs on the experience of its people, which is valuable but cannot be scaled or audited. The observable criteria are uncomfortably concrete: ask for the number of stops on a line last Tuesday without opening the machine interface and watch what happens; find the notebook or the spreadsheet holding the shift report and the person who keeps it; check in the same meeting whether two people give two different production figures for the same shift; and attend a shift handover to see how counters are read and transcribed.

The signal that you are here: to know what a line produced yesterday you ask the shift or look for a paper report. The next step is the inventory of equipment, available signals, protocols spoken and owner of each piece of data. It is not a software project, it is field work.

Level 1: Connected

The equipment speaks a common language and the data reaches one place with time and context. It is solved with industrial protocols, an edge layer that survives network outages and a normalised data model. Five criteria can be verified during a visit: a signal list exists with asset, unit and frequency, maintained by someone with a name and with a date of last change; data from two different machines can be plotted on the same chart on the same time axis, which is checked by running the query live; clocks are synchronised and the deviation can be measured by looking at the same event from two systems; data availability is measured per channel, with a panel of gaps rather than the claim that there are none; and capture survives a link outage and then backfills, which is demonstrated by showing a recent gap already filled, with its date.

The signal: any plant signal can be checked from the browser with its history, without exporting anything. In the Captia platform this level is covered by Captia Connect. If you want the concept without the product, the reference is the guide on what an industrial data platform is and the pieces on unified namespace, industrial historian and edge buffering.

Level 2: Aware

The plant knows what is happening. OEE, energy, downtime and quality are calculated in real time per line and compared across shifts and days. The observable criteria centre on whether the number can be defended: OEE is calculated from captured data and not from manual entry, and a single written definition exists with the declared origin of every term; stops carry a reason and the share of time marked unclassified is known and low, which is checked by looking at the reason breakdown of the last month; the line operator and management look at the same number, verified by comparing the line screen and the monthly report on the spot; energy can be allocated to a line or a product and not only to the invoice; and someone took a concrete decision with that data in the last few weeks, with a date and an owner.

The signal: the morning meeting runs on the screen and not on spreadsheets, and the discussions are about causes and not about figures. This is where the analysis and alert modules of Captia.ai work. The definition of OEE that holds all of this together is developed in the OEE guide.

Level 3: Acting

The system decides and executes under supervision. Rules that open a maintenance order, workflows that escalate an incident, energy setpoints that follow demand, sequences that get reordered. The criteria are the most demanding of the first three levels: at least one action exists that the system proposes or executes and that is recorded with its measured result; there is an identified supervisor and a reversion path that has actually been used, with its record; what the system does when data is missing or stale is defined and has been tested; the effect is measured against a declared reference, before and after or against a control line; and rule or model changes go through versioning and approval, with history and approver.

The signal: an alert produces an action without anyone copying it by hand into another system, and a record exists of the effect it had. It is the closed loop with workflows, Energy and Service inside the platform. Two capabilities of this level rest on pieces of their own: predictive maintenance and AI visual inspection, which stop being analytics and become a loop as soon as they trigger a recorded action.

Level 4: Physical

Perceive, reason and act autonomously on the real world. It is the state of the art of the sector and it is described here in the third person: robots that modify their plan from what they perceive instead of running a fixed path, policies quantitatively evaluated on cases that were not in the training set, safety envelopes independent of the learned model, reproducible failure episodes and a drift metric with a threshold that triggers review. Those five criteria are what would have to be demonstrable, and they are useful for reading any public demonstration critically. They are only reachable once levels 1 to 3 are solved: without connected data there is no reliable perception, without indicators there is no ground truth to evaluate against, and without a supervised loop there are no action and effect pairs.

How you climb: what fails at each transition

Projects do not fail at the rung they stand on, they fail in the transition. And the symptom always looks the same while the cause does not. Stating the technical root cause of each transition is what makes it possible to solve them in order.

From 0 to 1: the scope is chosen badly

The most expensive failure is connecting what is easy and leaving out what matters: the equipment that already spoke a convenient protocol gets integrated and the old machine causing half the downtime is left out. The root cause is that scope was chosen by protocol availability and not by asset relevance, and the result is a complete history of what does not fail. The other four failures of this transition are technical and well known: thousands of signals arrive with names that replicate the controller addressing, because the PLC structure was copied instead of modelling the asset; the timestamp is set by the gateway on arrival, so any network retention destroys causal order exactly during failures, which is when the network behaves worst; periodic polling is used where change of state capture was needed, and micro-stops disappear; and management traffic is put on the control network, which shows up as intermittent stops with no apparent cause and burns confidence in the whole project. The order of resolution is: asset relevance first, semantic model second, clock and change of state capture third, network segmentation as a precondition to all of it. The full engineering of this transition is in the piece on connecting the PLCs you already have.

From 1 to 2: there is data and there is no question

Dashboards get deployed that nobody opens three weeks later, because instrumentation came first and the indicator was defined afterwards, so the panels answer whatever was easy to plot. Then come the definition problems: two OEEs in the same company because of different definitions of planned time, of nominal speed and of what counts as a reject; a catalogue nominal speed instead of the real one for the product being run, so performance stops correlating with anything; downtime reasons that are mostly other, because the catalogue is badly sized and classification is asked of someone who gains nothing from classifying well; and local time mixed into the aggregates, which twice a year produces shifts of 23 and 25 hours and breaks year-on-year comparisons without anyone noticing. The order of resolution inverts the instinct: first the question and the written definition, then the panel. The layers of context, the asset model and the traps of real-time OEE are developed in the piece on the plant that knows what is happening.

From 2 to 3: the loop is closed without measuring the effect

This is the failure that defines the transition: no baseline and no comparison were defined, so nobody can say whether anything improved and the argument is settled by whoever has the most seniority. Four others sit alongside it: variable latency on the action path, because the loop goes through a platform with queues and retries, and the symptom is blamed on the algorithm when it belongs to the transport; actuation with no safe default behaviour, because the maximum age of the data was never declared; alarm fatigue, because the threshold was tuned to miss no case and the cost of a false positive is not zero, it is the attention of the operator; and a clash of responsibilities, because writing a setpoint touches maintenance, production and safety, and with no owner for the action the project stays in pilot indefinitely. The order: owner of the action and reversion path before anything else, then the baseline, then the latency bound, and only then a wider catalogue of actions. The full treatment of this transition is in the piece on how an industrial loop is closed under supervision.

From 2 to 4: the jump that gets attempted and does not work

This is the most expensive failure mode. A robot, autonomous vision or an acting agent gets bought and mounted on a plant sitting at level 2. The demonstration works and the deployment does not: under controlled conditions, with the demo part and the demo lighting, the system performs; in production, with variability of material, light and product, it degrades. The root cause is that the policy was validated on a distribution that is not the one of the plant, and it cannot be corrected, because correcting requires the record of observation, action and result triples, which is exactly what level 3 produces and what does not exist here. Then nobody detects the degradation, because measuring the effect of the action is a level 3 capability and without it there is no drift metric; the twin or the simulator is built with no plant data, so its parameters do not match the real machine; and when the system meets a case it cannot solve there is nobody to hand control back to, because supervision was designed as a screen and not as an architecture.

Put briefly: level 4 is not a product installed on top of level 2, it is what can be attempted once levels 1, 2 and 3 exist, because each of them produces something level 4 consumes. To place your plant with criteria, the physical AI readiness index walks through these criteria one by one, and the digital maturity test gives a first approximation in ten questions.

The state of the art and why level 4 cannot be skipped to

Level 4 is explained here as the state of the art of the sector, in the third person and with the sources in the text. It deserves depth for two reasons: because that is where the money and the noise are, and because understanding how it works inside is what makes it clear why it needs the three levels below.

Predictive model versus world model

Levels 2 and 3 use predictive models: functions from a feature vector to a bounded output, such as the probability of a bearing failing within seven days or the class of a defect in an image. They do not represent the dynamics of the process, they contain no actions and therefore they cannot answer what would happen if something else were done. A world model does learn the dynamics: given a latent state and an action, what the next state is and what observation to expect, with its uncertainty. The paper of the NVIDIA Cosmos platform (arXiv 2501.03575, 7 January 2025) defines it as a general-purpose world model that can be fine-tuned into customised world models. NVIDIA presented Cosmos at CES on 6 January 2025 and published Cosmos 3 on 31 May 2026 according to its newsroom, with the weights of the Super and Nano variants under an open licence.

The technical consequence is the one that matters to a factory: a world model needs action data, not just observation data. A history containing process variables but not recording interventions is purely observational data: it allows learning what usually happens, not what happens if I intervene. This is why level 3 is a prerequisite for level 4 and not a decorative rung. The long treatment of this question, with the comparison between families of models and their known limits, is in the piece on world models and physical AI.

Vision-language-action policies

The term was set by RT-2 from Google DeepMind (arXiv 2307.15818, 28 July 2023), which proposes expressing actions as text tokens and incorporating them directly into the training set. Since then the dominant architecture separates two speeds. NVIDIA describes Isaac GR00T N1 (arXiv 2503.14734, 18 March 2025) with a vision and language system that reasons and a diffusion transformer that generates actions, trained on a heterogeneous mixture of real robot trajectories, human video and synthetic data. Figure describes Helix (20 February 2025) with the same separation and gives the numbers: the reactive policy runs at 200 Hz, that is five milliseconds per cycle, and semantic reasoning at 7-9 Hz. Google DeepMind published Gemini Robotics 1.5 on 25 September 2025 separating action from embodied reasoning, and Gemini Robotics 2 on 30 July 2026, with whole-body control, a variant that runs on the device itself and adaptation to a new morphology with, according to the company, a few hours and fewer than two hundred examples.

Four limits matter in a factory. Inference frequency bounds the achievable control bandwidth, so a policy of this kind sits on top of the millisecond loop and does not replace it. The output is probabilistic, so underneath it a deterministic safety envelope that does not depend on the model is required. Out-of-distribution behaviour is hard to bound formally, and that collides head on with the certification requirements of a cell shared with people. And above all, a policy of this kind does not solve the problem of knowing which state the plant is in: it consumes perception and turns it into movement within a bounded task.

The simulation to plant gap is a distribution problem

The popular explanation says simulation fails because it is not realistic enough. The correct formulation is a different one. The review of the reality gap in robotics (arXiv 2510.20808, 23 October 2025, also published in the Annual Review of Control, Robotics, and Autonomous Systems of 2026) attributes it to the abstractions and approximations every simulator inevitably introduces. A policy trained in simulation optimises under the state distribution the simulator induces, and on deployment it meets a different one. The aggravating factor belongs to control: the policy determines which states it visits, so a small error takes it to poorly represented states where it makes a larger error, which takes it further still.

The sources of the shift are several and only one is visual: badly identified dynamic parameters such as friction, inertias, backlash, elasticity, delays and actuator saturation; sensor noise, resolution and latency, which in simulation tend to be ideal; contact and deformation; and yes, appearance too. The canonical technique for crossing it is domain randomisation, defined by Tobin and others (arXiv 1703.06907, 20 March 2017) as training models on simulated images that transfer to real images by randomising the rendering. The other two are identifying the system with real data to centre the parameter family and fine-tuning with real episodes. All three require measured plant data, and here level 1 reappears: a badly characterised delay is learned as a dynamic that does not exist.

Where level 4 data comes from

The answer of the sector has three legs. The first is teleoperation: Open X-Embodiment (arXiv 2310.08864, 13 October 2023) aggregated data from 22 different robots collected by 21 institutions, demonstrating 527 skills, and models trained on that set show transfer across morphologies. The second is the heterogeneous mixture GR00T N1 already described: real trajectories, human video and synthetic data generated with world models. The third is co-training on heterogeneous tasks, which Physical Intelligence uses in pi-0.5 (arXiv 2504.16054, 22 April 2025) to achieve open-world generalisation. None of the three looks like a plant history, and that is precisely the point: plant history serves perception, the identification of dynamics within the operating range actually visited and the definition of the normal operating envelope, but on its own it is not enough to learn a policy, because it contains neither the alternative actions nor their results.

What is actually deployed

Demonstrations deserve to be read with the same rigour as an indicator. Siemens announced on 16 April 2026, in an official press release, a trial with the HMND 01 Alpha robot from Humanoid at its electronics factory in Erlangen, on the NVIDIA physical AI stack: tote destacking in internal logistics, with 60 tote moves per hour, more than eight hours of uptime and an autonomous pick-and-place success rate above 90%. It is a proof of concept and the release says so. BMW announced on 27 February 2026, in its press room, the first European humanoid pilot at its Leipzig plant with the AEON robot from Hexagon, with a real pilot phase from the summer of 2026, and on 25 June 2026 the use of Figure 03 in Spartanburg for component sequencing in logistics, without labelling it as full production. Figure, for its part, published on 19 November 2025 that its 02 robot completed a ten-month deployment at Spartanburg with more than 1,250 hours and more than 90,000 parts: those are vendor figures, not audited by third parties.

The financial contrast helps to calibrate. The Robot Report published on 7 September 2026 that Agility Robotics reported 1.8 million dollars of revenue and 140 million of operating loss in 2025, in the context of its public listing through a merger announced on 24 June 2026 at a pre-money valuation of 2.5 billion. It is the only humanoid maker with public accounts, and it shows the distance between valuation and revenue in the sector. Meanwhile conventional industrial robotics keeps growing at its own pace: the IFR (September 2025) counts 542,000 installations in 2024 and an operational stock of 4,664,000 units, and forecasts 575,000 installations in 2025 and passing 700,000 by 2028. In Spain, the humanoid robotics and physical AI ecosystem grouped into the ÁNIMA association, driven by AFM Cluster and AER Automation, according to Automática e Instrumentación (4 September 2026).

Read together, that is what orders the ladder. What is deployed in full production is classic automation and programmed robotics. What is in pilot is bounded internal logistics tasks, in plants that have had their data solved for years. And what is sold as imminent is a capability requiring reliable perception, ground truth and action and effect pairs, that is, levels 1, 2 and 3. The full account of that wave, with the funding rounds, the verifiable deployments and what each source does and does not say, is in the report on the physical AI wave in industry.

What an industrial data platform does

Levels 1 to 3 are the ones an industrial data platform covers, and it is worth saying precisely what each layer does. The order holds with any tool; the names are those of the Captia platform.

1. Level 1, capture: Captia Connect. An edge layer next to the equipment that reads Modbus, OPC UA, MQTT and the other plant protocols, sets the timestamp at source, normalises the data with its unit, its asset and its quality, stores it locally if the network drops and sends it securely when it returns. Without touching the PLC logic or the safety interlocks. The comparison between the two protocol families is in OPC UA versus MQTT, and the work of giving meaning to the data in industrial data contextualisation.
2. Level 2, awareness: Captia.ai. On the consolidated history, OEE, energy, downtime and quality are calculated per line, with multi-user web screens and alerts by role. The analysis modules, anomaly detection, predictive maintenance and forecasting, work on that same history; without it there is no model to train and no ground truth to evaluate it against. The operating interface is explained in web SCADA.
3. Level 3, closed loop: rules, workflows, Energy and Service. Rules and workflows that turn an alert into an action, energy setpoints that follow demand and maintenance orders born from the data. With a closed catalogue of actions, a declared maximum age for the data justifying them, human approval for the higher-impact ones, a tested reversion path and a record of the measured effect.

What a platform like that does not do matters just as much: it does not replace control, it does not touch the interlocks and it does not close millisecond loops. It sits above the regulatory loop, sets its setpoints and returns constraints to it, and lets each decision horizon keep working when the one above disappears.

European regulatory framework

The timeline of the European artificial intelligence regulation is published by the European Commission on its AI Act service desk, consulted in September 2026: it entered into force on 1 August 2024, the prohibitions and general provisions apply from 2 February 2025, the general-purpose and governance rules from 2 August 2025 and general application from 2 August 2026. The deadlines affecting industry come later because of the Digital Omnibus package: the rules for high-risk systems under Annex III apply on 2 December 2027, and those for AI embedded in regulated products under Annex I, which covers machinery, on 2 August 2028. In parallel, Regulation (EU) 2023/1230 on machinery, adopted on 14 June 2023 and applicable from 20 January 2027 according to the EU-OSHA record, replaces Directive 2006/42/EC. Prudent planning uses that 2027 date for AI embedded in machinery, because the sector proposals for postponement are today limited to cybersecurity.

Alongside the horizontal framework sit the technical standards a level 3 project already touches. ISO published in February 2025 the new ISO 10218-1:2025, safety requirements for the robot manufacturer, and ISO 10218-2:2025, for the cell integrator; according to The Robot Report (18 February 2025), the revision integrates the collaborative application requirements that previously lived in the technical specification ISO/TS 15066. In cybersecurity, the ISA/IEC 62443 series defines the requirements for industrial automation and control systems in four groups, from terminology to component requirements, and its part IEC 62443-2-1:2024, of August 2024, sets the security programme of the asset owner with a maturity model. For robotics interoperability, the companion specification OPC 40010-1 in its version 1.02, released by the OPC Foundation on 8 September 2025, models manipulators, axes, motors and controllers for asset management and vertical integration with MES and cloud. The practical reading for a plant is that the foundations of data, clock and traceability that levels 1 to 3 demand are the same ones these standards will ask to see documented.

Common mistakes when starting

Projects that stall at the pilot stage usually share one of these eight mistakes. None of them is technological: all of them are about order.

• Starting at level 4. Buying a collaborative robot or an AI camera for a plant that still writes downtime on paper. The pilot works in the demo and dies in production because there is no data to integrate it with and no process to make use of it.
• Replacing instead of connecting. Swapping PLCs and machines that work to get "AI-ready" equipment. The existing equipment already perceives and already acts; what is missing is getting the data out, and that is done with the protocols it already speaks.
• Mistaking a dashboard for awareness. A screen with indicators nobody updates or that do not share a clock with the other systems is level 0 with a better look. Level 2 requires real-time data that is comparable across lines and shifts.
• Choosing scope by protocol and not by asset. What was easy gets connected and the machine causing half the downtime is left out. The result is an impeccable history of what does not fail.
• Setting the timestamp at ingestion. The gateway stamps the data on arrival, so any network retention shifts the events and destroys causal order exactly when there is a failure, which is when the network behaves worst.
• Closing the loop with no limits and no measurement. Letting a system change setpoints or create orders without a catalogue of authorised actions, without a maximum data age, without approval for the impactful ones and without measuring the effect. Autonomy is earned with a track record, not granted on day one.
• Not naming a data owner. Without someone responsible for each signal being correct, having context and being maintained, the history degrades and any model built on it reasons over noise. The most common reason a three-year history turns out to be useless is not technical: someone renamed or rescaled a tag and it was never recorded.
• Measuring the project by the technology and not by what the plant can do. "We have AI" is not a result. "Line 2 opens its own maintenance orders and breakdown downtime went down against the baseline of the previous quarter" is. The ladder is designed to measure that.

Frequently asked questions about physical AI

If you want to know which level of the ladder your plant is at and what the next step is, tell us what equipment you have and we will tell you which data can be captured now and what it would take to close the loop. The full architecture we work on is described in the industrial data platform, and the short definition of the term in the glossary entry for physical AI.