# Physical AI

> Source: https://aiwiki.ai/wiki/physical_ai
> Updated: 2026-07-31
> Fact-checked: 2026-07-31
> Categories: Artificial Intelligence, Embodied AI, Robotics
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Physical AI." aiwiki.ai, 31 Jul 2026. https://aiwiki.ai/wiki/physical_ai
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**Physical AI** is a contested umbrella term for [artificial intelligence](https://aiwiki.ai/wiki/artificial_intelligence) systems whose decisions are coupled to sensing and action in the physical world. In its broadest current use, it includes AI-enabled [robots](https://aiwiki.ai/wiki/robot), automated vehicles, and other machines that perceive their surroundings, select actions, and alter a physical process. It is not a standardized branch of AI, a particular model architecture, or a legal product class. A 2026 Nature Machine Intelligence editorial described physical AI, embodied intelligence, world models, ecological approaches, and robotics as overlapping frameworks that approach the shared problem of intelligent physical action from different directions.[1]

The phrase also has more than one research lineage. A 2020 Nature Machine Intelligence article used **physical artificial intelligence** for a multidisciplinary program to synthesize nature-like robotic systems.[2] A related but narrower concept, **physical intelligence**, locates some adaptive behavior in an agent's materials, morphology, mechanics, and body rather than only in its software.[3] [NVIDIA](https://aiwiki.ai/wiki/nvidia) later made **physical AI** a prominent industry label, presenting it at CES 2025 as a progression from perception AI and [generative AI](https://aiwiki.ai/wiki/generative_ai) to systems that perceive, reason, plan, and act.[4] NVIDIA's glossary applies the label to autonomous systems including robots, self-driving vehicles, cameras, and smart spaces.[5] That vendor taxonomy is influential, but it is not a scientific consensus and NVIDIA did not coin the phrase.

This article uses a practical working definition: a physical AI system combines computation with a physical plant and a feedback loop, and at least some decisions in that loop are produced or materially informed by AI methods. The definition covers both learned end-to-end policies and hybrid systems that combine learned perception or planning with conventional estimation, optimization, and control. It excludes a language or image model merely describing a physical scene, a simulator with no claimed connection to a physical system, and ordinary fixed automation that does not use AI. Borderline cases should be described by their actual functions rather than included only because a developer uses the label.

Claims about physical AI require unusually careful evidence. A successful laboratory trial, a selected video, a simulation score, and a production deployment answer different questions. They do not establish the same degree of reliability, generality, autonomy, or safety. Product announcements and company benchmarks can document what a developer reported, but independent evaluation or customer evidence is needed before treating those reports as established system performance.

## Meaning and history

Physical AI is best understood as a family of usages rather than a field with one founding event. Earlier work in behavior-based robotics already challenged the separation of intelligence from perception and action. Rodney Brooks's 1991 paper `Intelligence without representation` argued for building complete systems that interact with the real world through perception and action, while rejecting a mandatory centralized world representation.[6] Brooks did not use the modern industry label, but the work is an important intellectual precursor to current arguments about embodied, closed-loop intelligence.

Later publications put more weight on the body itself. Miriyev and Kovac described physical artificial intelligence as the theory and practice of synthesizing nature-like intelligent robotic systems, with expertise spanning materials, mechanical design, fabrication, sensing, actuation, control, and AI.[2] Sitti's physical-intelligence perspective separated computational intelligence from capabilities encoded in an agent's body, such as mechanical response, material behavior, and morphology.[3] These meanings do not reduce physical AI to placing a large neural network inside a conventional robot.

The broad commercial usage became conspicuous during the foundation-model period. At CES 2025, [Jensen Huang](https://aiwiki.ai/wiki/jensen_huang) used physical AI for machines that could perceive, reason, plan, and act, and tied the category to NVIDIA's simulation, model, and compute products.[4] NVIDIA's own later glossary broadened the category further to cover robots, autonomous vehicles, and camera-equipped spaces.[5] This framing helped standardize industry language, but it also bundled together systems with very different bodies, autonomy levels, safety regimes, and evidence bases.

| Date | Usage | What the source establishes | What it does not establish |
|---|---|---|---|
| 1991 | Behavior-based robotics | Brooks made direct perception-action coupling central to an influential robot architecture.[6] | The paper did not introduce the term physical AI. |
| 2020 | Physical artificial intelligence | Miriyev and Kovac presented a multidisciplinary program for synthesizing nature-like intelligent robotic systems.[2] | It did not define today's entire commercial category. |
| 2021 | Physical intelligence | Sitti emphasized intelligence encoded in bodies, materials, and mechanics alongside computation.[3] | Physical intelligence is not simply another name for every AI-controlled machine. |
| 2025 | NVIDIA's physical AI taxonomy | NVIDIA publicly grouped robots, autonomous vehicles, and related platforms under a perceive-reason-plan-act framing.[4][5] | A company taxonomy is not a standards-body definition or proof that all included products share one architecture. |
| 2026 | Converging research frameworks | A Nature Machine Intelligence editorial treated physical AI as one of several overlapping approaches to intelligent physical action.[1] | Convergence on a research problem does not erase differences among the approaches. |

Three meanings therefore recur:

1. **A broad systems label** for AI-enabled machines that act in the physical world.
2. **A robotics research program** that co-designs body, sensing, actuation, control, and learning.
3. **A vendor ecosystem category** that groups models, simulation, compute, robots, vehicles, and smart spaces.

The first is useful for this overview. The second identifies a specific interdisciplinary research tradition. The third describes how companies organize products and markets. An accurate account states which meaning is intended instead of moving silently among them.

## Boundaries with related fields

Physical AI overlaps with [embodied AI](https://aiwiki.ai/wiki/embodied_ai), robotics, cyber-physical systems, learned world models, simulation, digital twins, and automated driving. The overlaps are real, but the terms answer different questions.

Embodied AI asks how an agent's body, sensory experience, actions, and environment shape intelligent behavior. Its research tasks include navigation and manipulation and are often developed or evaluated in simulators before any physical deployment. A review of embodied vision-language planning, for example, organizes tasks, algorithms, metrics, simulators, and datasets around agents using vision and language to interact with environments.[7] Physical AI in the working sense used here requires a claimed connection to physical sensing or action. An embodied agent that exists only in a game or simulation can be valid embodied-AI research without yet being a deployed physical AI system.

A cyber-physical system is broader in a different direction. The NIST framework defines such systems as interacting digital, analog, physical, and human components engineered through integrated physics and logic.[8] A power grid controller, industrial process, or medical monitoring network can be a cyber-physical system without machine learning. Conversely, a learned robot policy can be discussed as physical AI without the article needing to classify the entire facility around it.

A [digital twin](https://aiwiki.ai/wiki/digital_twin) is a digital representation tied to a particular real counterpart or process and used for purposes such as diagnosis, prediction, optimization, or control. NIST's Digital Twin Core report emphasizes connection, synchronization, interoperability, and lifecycle uses.[9] A digital twin can support a physical AI deployment, but it is not itself an autonomous agent. A generic simulated warehouse, a generated video, and a synchronized model of a specific warehouse are not interchangeable.

| Term | Primary focus | Relationship to physical AI | Important non-equivalence |
|---|---|---|---|
| Embodied AI | Intelligence shaped by an agent's body, action, and environment | Supplies theories, tasks, datasets, and learning methods | May study agents entirely in simulation |
| Robotics | Design, construction, sensing, planning, control, and operation of robots | Provides the machines and engineering discipline for many physical AI systems | Robots can be fixed-programmed or conventionally controlled without AI |
| Cyber-physical systems | Integrated digital, analog, physical, and human components | Provides system-engineering concepts for connected physical deployments | AI and autonomy are not required |
| World model | Internal representation or predictive model used by an agent | May support state estimation, prediction, or planning | It is a component, not the robot or deployed system |
| Physics simulator | Computational environment for design, training, or tests | Can generate experience and controlled evaluation | Its output is not automatically valid in reality |
| Digital twin | Connected representation of a particular physical counterpart | Can support monitoring, planning, validation, and operations | A generic simulator or generated world is not necessarily a twin |
| Automated vehicle | Vehicle and driving-automation feature within an operational context | A major application class in some industry definitions | It has domain-specific levels, regulation, and validation requirements |

ISO 8373:2021 is a published robotics vocabulary, but its public metadata does not establish physical AI as a standardized robot type.[10] For road vehicles, SAE J3016 instead defines six levels of driving automation based on how a feature performs the dynamic driving task and on the role of the user.[11] The levels describe driving-automation features, not a generic amount of AI in a vehicle. Calling an [autonomous vehicle](https://aiwiki.ai/wiki/autonomous_vehicle) physical AI therefore adds an umbrella label but does not replace the feature's operational design domain, automation level, or safety case.

## How physical AI systems close the loop

No single architecture is mandatory. A useful abstraction is a feedback loop connecting a physical plant and environment to sensing, state estimation, decision-making, control, and actuation. Human operators, fleet services, and safety functions often surround this loop. Surveys of [foundation models](https://aiwiki.ai/wiki/foundation_models) in robotics likewise place learned models at different points in an autonomy stack, including perception, decision-making, and control, while identifying data scarcity, uncertainty, safety guarantees, and real-time execution as open problems.[12]

| Layer | Typical functions | Questions that determine evidence quality |
|---|---|---|
| Physical plant and embodiment | Structure, joints, wheels or legs, grippers, motors, brakes, power, passive mechanics | What forces, speeds, payloads, reach, compliance, and failure modes are physically possible? |
| Sensing | Cameras, depth sensors, radar, [LiDAR](https://aiwiki.ai/wiki/lidar), inertial sensors, encoders, force-torque sensors, tactile sensors | Which quantities are measured, at what rate and calibration, and what happens when a sensor degrades? |
| State estimation and perception | Localization, object and person detection, tracking, pose estimation, contact estimation, semantic scene interpretation | What environments and distribution shifts were tested, and how are uncertainty and missing observations handled? |
| Task and motion decision | Goal interpretation, task decomposition, path and grasp planning, policy inference, prediction | Which decisions are learned, optimized, rule-based, or human-approved? |
| Control and actuation | Trajectory following, impedance or force control, balance, steering, braking, motor commands | What are the control rate, latency budget, stability assumptions, and fallback behavior? |
| Safety and supervision | Limits, guarding, collision monitoring, independent stop channels, anomaly detection, access control | Which functions are safety-rated, independent, tested, and certified for the actual application? |
| Operations | Work-cell integration, fleet scheduling, maintenance, logging, teleoperation, updates, incident response | How much human intervention is needed and how are changes validated after deployment? |

### Embodiment and sensing

The body is not a neutral container. Its geometry, degrees of freedom, transmission, compliance, end effectors, wheels or feet, and passive mechanical behavior constrain what can be sensed and controlled. A high-level planner cannot compensate for a gripper that cannot reach, support, or detect the required contact. In the physical-intelligence tradition, some useful behavior can be shifted into compliant structures or materials, reducing what the controller must compute.[3]

Sensors provide partial and noisy observations. Cameras can support [computer vision](https://aiwiki.ai/wiki/computer_vision), but illumination, occlusion, motion blur, and viewpoint changes can alter their input. Proprioceptive sensors report joint and body state; force and tactile sensing expose contact that vision alone may miss. Practical systems fuse modalities because no sensor is universally reliable. The fusion method, calibration procedure, sampling rate, and fault response are part of the system claim.

### Estimation and decisions

Raw observations are normally converted into estimates of robot state, objects, people, obstacles, free space, and task progress. Some systems maintain explicit maps or object states. Others learn compact latent representations. Decisions can then be produced by a task planner, a motion planner, a learned policy, model-predictive control, rules, or a hierarchy combining them.

The boundary between planning and control is important. Language-conditioned planning may run slowly and choose a subtask such as `place the cup in the rack`, while a faster controller tracks joint targets and reacts to contact. An end-to-end policy may map observations and instructions directly to action chunks, but the deployed machine can still include conventional low-level controllers and separate safety functions. Describing a model as the robot's `brain` obscures these interfaces and should not substitute for an architecture description.

### Time, compute, and operations

Physical action imposes timing constraints. Perception, inference, communication, and control each consume part of the latency budget. A delayed but semantically correct command can be unsafe or useless when a person, vehicle, or object has moved. Some inference can run through [edge computing](https://aiwiki.ai/wiki/edge_computing) on the machine, while training, fleet optimization, or non-critical planning can use remote compute. Network loss and cloud latency must be treated as failure conditions if a function depends on them.

Operations also affect apparent autonomy. A system may require initial mapping, scripted work-cell logic, frequent resets, remote assistance, human confirmation, or maintenance between runs. None of those practices invalidates a useful deployment. They do mean that model capability, robot autonomy, and operational performance should be reported separately.

## Learning methods and foundation models

[Robot learning](https://aiwiki.ai/wiki/robot_learning) supplies several ways to acquire policies or components:

- **Supervised and self-supervised learning** can train perception, state representations, predictive models, and success detectors from labeled or unlabeled observations.
- **[Imitation learning](https://aiwiki.ai/wiki/imitation_learning)** learns behavior from demonstrations, teleoperation, or recorded trajectories. It can reproduce demonstrated actions but may fail when its own mistakes move the system outside the demonstration distribution.
- **[Reinforcement learning](https://aiwiki.ai/wiki/reinforcement_learning)** optimizes behavior from rewards through interaction in simulation, on hardware, or in a mixture of both. Reward design, exploration safety, and transfer to real conditions remain central constraints.
- **Model-based methods** learn or use dynamics to predict action consequences before selecting a control.
- **Hybrid systems** combine learned perception or policies with kinematics, optimization, rules, and feedback control. Hybridization is common because different layers have different data, timing, interpretability, and assurance requirements.

### Vision-language-action models

A [vision-language-action model](https://aiwiki.ai/wiki/vision_language_action_model), or VLA, conditions robot actions on visual observations and language. The label covers multiple architectures and action representations. It does not imply one model size, one control rate, or one level of generality.

RT-2 introduced an influential approach in which a vision-language model was co-trained on robot data and represented actions as tokens, allowing web-scale semantic knowledge to influence robot control within its evaluation setting.[13] The Open X-Embodiment collaboration later assembled data from 22 robot embodiments and reported positive transfer from policies trained on the mixture.[14] Positive transfer across the tested robots is not the same as a universal controller: embodiments can differ in cameras, coordinate frames, action dimensions, dynamics, grippers, and workspaces.

[OpenVLA](https://aiwiki.ai/wiki/openvla) provides a peer-reviewed open example. The authors described a 7-billion-parameter model trained on 970,000 real-robot demonstrations and evaluated it on 29 tasks across multiple embodiments.[15] Those figures establish the model and protocol reported in the paper. Its success-rate comparisons should not be combined with results from other test suites as though all tasks and trial definitions were identical.

| System | Public evidence at the cutoff | Architecture or scope reported by the source | Evidence boundary |
|---|---|---|---|
| RT-2 | Peer-reviewed CoRL paper | Co-trained vision-language-action model with robot actions expressed as tokens[13] | Results apply to the paper's robots, tasks, data, and baselines |
| Open X-Embodiment and RT-X | Peer-reviewed ICRA paper and public dataset project | Data from 22 embodiments and experiments on transfer across robots[14] | Dataset aggregation does not remove embodiment and protocol differences |
| OpenVLA | Peer-reviewed CoRL paper, code, and checkpoints | Open 7B VLA trained on 970,000 demonstrations[15] | Reported rankings are protocol-specific, not a universal model league table |
| [pi0](https://aiwiki.ai/wiki/pi0) | Developer-authored preprint and model release | Pretrained vision-language backbone with a flow-matching action model, evaluated across several robot platforms and manipulation tasks[16] | Preprint results are not independent deployment evidence |
| Gemini Robotics | Google DeepMind technical report and developer publication | Gemini 2.0-based VLA plus a separate embodied-reasoning model, demonstrated on multiple robot forms[17] | Benchmark claims and demonstrations are developer-reported |
| Helix | Figure AI developer publication | Two-rate architecture coupling a slower vision-language component to a 200 Hz visuomotor policy for a humanoid upper body[18] | No peer-reviewed or independent reproduction was provided in the cited announcement |

[Google DeepMind](https://aiwiki.ai/wiki/google_deepmind) introduced Gemini Robotics in March 2025 and described it as a VLA built on Gemini 2.0 with physical actions as an output modality. The company also introduced Gemini Robotics-ER for spatial reasoning and connection to existing controllers.[17] [Figure AI](https://aiwiki.ai/wiki/figure_ai) described Helix as a two-rate model, with a vision-language component operating at 7 to 9 Hz and a visuomotor component outputting actions at 200 Hz.[18] These are useful architecture disclosures. Statements such as `more than doubles performance`, `first`, `generalist`, or `commercial-ready` remain the developers' claims unless the test, comparison set, and deployment evidence independently support them.

A **generalist policy** covers more tasks, objects, instructions, or settings than a task-specific baseline. A **robot foundation model** is a model intended for adaptation across tasks or platforms. A **general-purpose robot** is a much stronger system-level claim involving hardware, software, safety, operations, and performance across diverse applications. The three phrases should not be treated as synonyms.

## World models, simulation, and digital twins

A [world model](https://aiwiki.ai/wiki/world_model) is an internal model used to represent or predict relevant aspects of an agent and its environment. Ha and Schmidhuber's 2018 `World Models` learned compressed spatial and temporal representations of reinforcement-learning environments and trained a policy inside the learned model before transferring it back to the original environment.[19] In robotics, however, the same phrase can refer to an explicit scene database, a dynamics model, a map, or a learned generative predictor. A 2023 review found no single concise definition consistently used across robotics domains and documented both classical state representations and learned internal simulators.[20]

Three tools are often conflated:

| Tool | Relationship to reality | Typical role | Main validation question |
|---|---|---|---|
| Learned world model | Learned from observations or trajectories and may represent only task-relevant state or dynamics | Prediction, planning, representation learning, policy training | Does it predict the consequences that matter under the deployment distribution? |
| Physics simulator | Implements chosen geometric, dynamic, sensor, and rendering models | Design, data generation, policy training, repeatable tests | Which physical effects, sensors, contacts, delays, and disturbances are modeled accurately enough? |
| Digital twin | Represents a particular physical asset or process and is connected or synchronized with it | Monitoring, diagnosis, optimization, what-if analysis, lifecycle support | Is the twin current, calibrated, interoperable, and credible for its intended decision? |

Simulation can reduce the cost and risk of collecting some data, repeat rare conditions, and run controlled comparisons. It cannot by itself prove performance on hardware. Friction, compliance, deformable objects, wear, sensor artifacts, actuator delays, people, and operational variation can all create a **simulation-to-reality gap**.

Domain randomization addresses one part of that gap by varying simulated appearance or parameters so that the real world is less likely to be outside the training distribution. Tobin and colleagues demonstrated the approach for object localization and grasping using randomized simulated images.[21] Later research has expanded the idea to dynamics, sensors, latency, geometry, and disturbances. It remains a robustness technique, not a guarantee that unmodeled conditions are covered.

Cross-domain policy-transfer research distinguishes appearance and viewpoint gaps in observations, dynamics gaps, and morphology or embodiment gaps. A 2024 IJCAI survey formalized domains in terms of environment, embodiment, and transition dynamics, and also treated the task-relevant reward as domain-dependent. The survey also emphasized why target-domain data are hard to obtain: real data collection is costly and safety constraints limit experimentation.[22] Synthetic data should therefore be documented by generation method, simulator assumptions, sampling distribution, connection to real data, and the real-world tests used to validate transfer. Photorealism alone does not establish physical fidelity.

## Evaluation and reproducibility

There is no single score for physical AI. Evaluation must match the application, failure consequences, and claimed scope. At minimum, reports should define:

- the exact robot, sensors, controller, model version, prompts or instructions, and compute;
- the task, initial-state distribution, object and environment variation, and number of trials;
- full success, partial success, time, throughput, intervention, reset, and recovery criteria;
- held-out objects, layouts, instructions, users, disturbances, and other distribution shifts;
- latency, energy or battery use, network dependence, and resource limits;
- contacts, near misses, safety stops, damage, and other relevant physical events;
- human assistance, teleoperation, scripted logic, excluded trials, and software changes.

Simulation is useful for repeatability, but its predictive validity must be measured. SIMPLER compared simulation and real-world evaluations, reporting more than 1,500 paired trials across two embodiments and eight task families after addressing visual and control disparities. The authors found strong correlation for their tested policies and setups.[23] The result supports SIMPLER as a carefully constructed proxy in that domain. It does not imply that any simulator, task, or policy will have the same relationship to reality.

Real-world evaluation has the opposite problem: it is expensive, slow, and difficult to standardize across laboratories. RoboArena used double-blind pairwise comparisons over more than 600 real-robot episodes, seven policies, and seven academic institutions to aggregate a distributed ranking.[24] Its design illustrates both the value of diverse real settings and the challenge of comparing policies when tasks and environments differ.

A demonstration video is a record of selected behavior, not a success-rate estimate. A benchmark result is evidence about its protocol, not all possible work. A customer deployment can demonstrate operational integration while still being narrow. Strong evidence combines controlled tests, real-world trials, failure reporting, exact denominators, reproducible artifacts where feasible, and post-deployment monitoring.

## Applications and deployment evidence

The broad label is applied to manufacturing, logistics, transport, agriculture, inspection, service robotics, assistive systems, and smart infrastructure. These domains have different constraints. A factory cell may prioritize repeatability, cycle time, guarding, and integration with existing equipment. A warehouse mobile robot may prioritize fleet coordination and human traffic. A field robot faces weather, terrain, and communications. A vehicle must handle a defined driving task and operational design domain. An assistive robot adds close human contact, accessibility, privacy, and individualized risk.

Public evidence should be classified by maturity:

| Evidence level | What it can establish | What it cannot establish by itself |
|---|---|---|
| Laboratory demonstration | A disclosed system performed selected trials under stated conditions | Stable performance across deployments or an unknown success rate |
| Benchmark | Comparative performance under a defined protocol | Performance on different hardware, tasks, environments, or metrics |
| Pilot | Integration and operation in a bounded real workflow | Economic scalability or broad general-purpose autonomy |
| Production deployment | Repeated use in an operating process, if scope and denominators are disclosed | Transfer to unrelated tasks or environments |
| Forecast or announced plan | A company's intention or an analyst's scenario | A demonstrated capability, shipment, price, or deployment |

Three public examples show why scope matters:

- [Amazon](https://aiwiki.ai/wiki/amazon) reported in June 2025 that it had deployed its one-millionth robot across its operations and introduced a fleet-coordination foundation model called DeepFleet.[25] The milestone is a company-reported example of large-scale, task-specific warehouse robotics. It is not evidence that one general-purpose policy controls a million interchangeable robots.
- [Agility Robotics](https://aiwiki.ai/wiki/agility_robotics) and GXO announced a multi-year deployment of Digit robots at a logistics facility after a pilot. The described workflow moves totes from other mobile robots to conveyors and is managed through Agility's fleet platform.[26] That is meaningful commercial evidence for a bounded workflow, not proof of unrestricted warehouse competence.
- BMW reported in June 2026 that Figure 02 had supported production of more than 30,000 BMW X3 vehicles over ten months by inserting sheet-metal parts for welding.[27] This is customer-authored evidence of a specific production task. The vehicle count is not a robot count, a task-success denominator, an autonomy rate, or an independent measure of economic return.

These examples range from established task-specific automation to newer humanoid deployments, but none justifies a universal timeline for household or general-purpose robots. Funding rounds, company valuations, market-size forecasts, planned unit shipments, and announced consumer dates measure finance or intention, not technical capability. They should not be combined into a physical AI progress score.

Automated driving also needs application-specific language. SAE levels assign responsibility for the dynamic driving task to the user or the driving-automation feature under defined conditions.[11] A perception model, a simulation platform, or a `physical AI` brand does not establish a vehicle's automation level or safe operating domain.

## Safety, standards, and regulation

Physical systems can cause injury, property damage, environmental harm, and interruption of critical operations. Learned components add familiar AI risks such as distribution shift, opaque failure modes, data quality problems, adversarial inputs, and update drift to conventional hazards from motion, force, stored energy, sharp or hot tools, electrical systems, payloads, and human access.

A 2025 IJCAI survey of physical-risk control for foundation-model-enabled robotics organized controls across pre-deployment, pre-incident, and post-incident phases and identified important gaps in pre-incident mitigation, physical human interaction, and risks intrinsic to foundation models.[28] That lifecycle view is more defensible than assigning safety to a single model. A practical layered approach includes:

1. **Hazard analysis and intended-use limits** before model or hardware selection.
2. **Inherently safer mechanics and work design**, including limits on reachable energy, force, speed, sharp tools, payloads, and access.
3. **Validated low-level control and protective functions** such as guarding, separation monitoring, emergency stops, braking, and independent limits.
4. **Model-level controls** including constrained action spaces, uncertainty handling, out-of-distribution detection, and refusal or escalation for unsupported requests.
5. **Operational controls** such as authorization, trained supervision, inspection, maintenance, teleoperation rules, and safe recovery.
6. **Lifecycle assurance** through configuration control, logging, incident investigation, regression tests, and revalidation after changes.

Standards are application-specific rather than organized around the marketing label:

| Source | Scope relevant to physical AI | Boundary |
|---|---|---|
| ISO 10218-1:2025 | Safety requirements for industrial robots as partly completed machinery[29] | Robot applications and cells are addressed separately |
| ISO 10218-2:2025 | Integration, commissioning, operation, maintenance, and decommissioning of industrial robot applications and cells[30] | Does not make every AI-enabled machine an industrial robot |
| ISO 13482:2014 | Specified personal-care robot types, including mobile servant, physical assistant, and person-carrier robots[31] | Excludes industrial robots, medical devices, military applications, flying robots, and other listed classes |
| ISO/IEC TR 5469:2024 | AI inside a safety-related function, non-AI safety functions protecting AI-controlled equipment, and AI used in safety-function development[32] | A technical report is not a product certificate or universal physical-AI safety standard |
| NIST AI RMF 1.0 | Voluntary, non-sector-specific framework for governing, mapping, measuring, and managing AI risk[33] | Does not replace sector regulation or machine-safety engineering |

Regulatory treatment likewise depends on the product and intended use. Under Article 6(1) of the EU AI Act, the regulated-product route classifies an AI system as high-risk when two cumulative conditions apply: it is a safety component of, or itself is, a product covered by listed Union legislation, and the product or AI system requires third-party conformity assessment under that legislation.[34] Other AI Act routes and sector laws can also apply. The phrase `physical AI` alone neither creates nor removes a legal classification.

Semantic reasoning should not be confused with a safety-rated function. Google DeepMind's own robotics safety page says its VLA models can be composed with lower-level safety mechanisms and describes its human-distance response as ongoing research rather than a guaranteed safety-rated system.[35] That limitation is broadly instructive: model behavior can contribute to risk reduction, but certified protective functions, system integration, and operational controls need their own evidence.

## Research limitations

Physical AI research has advanced on language-conditioned manipulation, representation learning, cross-robot datasets, simulation, and real-world evaluation. Several persistent limitations keep those results from automatically becoming general deployment:

- **Physical data are scarce and heterogeneous.** Robot trajectories are expensive to collect, and datasets mix different sensors, action spaces, embodiments, operators, tasks, and success criteria.[12][14][22]
- **Distribution shift changes both perception and action.** New objects, lighting, clutter, surfaces, people, wear, calibration, or dynamics can move a system beyond its training and validation conditions.
- **Contact and deformable objects are difficult.** Small errors in friction, compliance, geometry, or force estimation can change the outcome of grasping, insertion, cloth handling, cables, food, and tool use.
- **Long tasks compound errors.** A policy that is strong on short actions may still fail to detect mistakes, recover, preserve state, or complete a multi-stage workflow.
- **Cross-embodiment transfer is incomplete.** Shared semantic knowledge does not remove differences in kinematics, dynamics, reach, sensors, grippers, or control interfaces.[14][22]
- **Evaluation is fragmented.** Results often use different tasks, trial counts, reset rules, assistance, and hardware, making headline percentages non-comparable.[23][24]
- **Real-time and energy constraints matter.** A model useful in offline analysis may be too slow, power-hungry, or network-dependent for a mobile or safety-relevant control loop.[12]
- **Assurance must survive updates.** Model, prompt, sensor, firmware, tool, and environment changes can invalidate earlier tests, so deployment requires configuration control and regression evidence.[28][33]
- **Terminology can outrun evidence.** `Physical AI`, `generalist`, `world foundation model`, and `robot foundation model` can describe research directions or product positioning without establishing generality, physical accuracy, safety, or commercial performance.

Progress is therefore better measured through bounded, reproducible claims: which machine performed which task, under which conditions, how often, with what assistance and failures, and under what safety controls. That evidence can support useful systems without presuming a single architecture or forecasting when general physical intelligence will arrive.

## References

1. Nature Machine Intelligence. "From embodied intelligence to physical AI." April 24, 2026. https://doi.org/10.1038/s42256-026-01239-3
2. Miriyev, Aslan, and Mirko Kovac. "Skills for physical artificial intelligence." Nature Machine Intelligence 2, 658-660. November 10, 2020. https://doi.org/10.1038/s42256-020-00258-y
3. Sitti, Metin. "Physical intelligence as a new paradigm." Extreme Mechanics Letters 46, 101340. July 2021. https://doi.org/10.1016/j.eml.2021.101340
4. NVIDIA. "CES 2025: AI Advancing at 'Incredible Pace,' NVIDIA CEO Says." January 6, 2025. https://blogs.nvidia.com/blog/ces-2025-jensen-huang/
5. NVIDIA. "What is Physical AI?" NVIDIA Glossary. https://www.nvidia.com/en-gb/glossary/generative-physical-ai/
6. Brooks, Rodney A. "Intelligence without representation." Artificial Intelligence 47, 139-159. 1991. https://people.csail.mit.edu/brooks/papers/representation.pdf
7. Francis, Jonathan, Nariaki Kitamura, Felix Labelle, Xiaopeng Lu, Ingrid Navarro, and Jean Oh. "Core Challenges in Embodied Vision-Language Planning." Proceedings of IJCAI 2023, 6878-6883. https://doi.org/10.24963/ijcai.2023/775
8. Griffor, Edward R., Christopher Greer, David A. Wollman, and Martin J. Burns. "Framework for Cyber-Physical Systems: Volume 1, Overview." NIST SP 1500-201. June 2017. https://doi.org/10.6028/NIST.SP.1500-201
9. Lin, Shi-Wan, Kym Watson, Guodong Shao, Ljiljana Stojanovic, and Bassam Zarkout. "Digital Twin Core Conceptual Models and Services." November 3, 2023. https://www.nist.gov/publications/digital-twin-core-conceptual-models-and-services
10. International Organization for Standardization. "ISO 8373:2021 Robotics - Vocabulary." November 2021. https://www.iso.org/standard/75539.html
11. SAE International. "J3016_202104: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles." April 30, 2021. https://doi.org/10.4271/J3016_202104
12. Firoozi, Roya, et al. "Foundation models in robotics: Applications, challenges, and the future." The International Journal of Robotics Research 44(5), 701-739. 2025. https://doi.org/10.1177/02783649241281508
13. Zitkovich, Brianna, et al. "RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control." Proceedings of the 7th Conference on Robot Learning, PMLR 229, 2165-2183. 2023. https://proceedings.mlr.press/v229/zitkovich23a.html
14. Open X-Embodiment Collaboration. "Open X-Embodiment: Robotic Learning Datasets and RT-X Models." IEEE International Conference on Robotics and Automation. 2024. https://robotics-transformer-x.github.io/
15. Kim, Moo Jin, et al. "OpenVLA: An Open-Source Vision-Language-Action Model." Proceedings of the 8th Conference on Robot Learning, PMLR 270, 2679-2713. 2025. https://proceedings.mlr.press/v270/kim25c.html
16. Black, Kevin, et al. "pi0: A Vision-Language-Action Flow Model for General Robot Control." arXiv:2410.24164. October 31, 2024. https://arxiv.org/abs/2410.24164
17. Parada, Carolina. "Gemini Robotics brings AI into the physical world." Google DeepMind. March 12, 2025. https://deepmind.google/blog/gemini-robotics-brings-ai-into-the-physical-world/
18. Figure AI. "Helix: A Vision-Language-Action Model for Generalist Humanoid Control." February 20, 2025. https://www.figure.ai/news/helix
19. Ha, David, and Jurgen Schmidhuber. "World Models." arXiv:1803.10122. March 27, 2018. https://arxiv.org/abs/1803.10122
20. Sakagami, Ryo, Florian S. Lay, Andreas Domel, Martin J. Schuster, Alin Albu-Schaffer, Freek Stulp. "Robotic world models - conceptualization, review, and engineering best practices." Frontiers in Robotics and AI 10. November 2, 2023. https://doi.org/10.3389/frobt.2023.1253049
21. Tobin, Josh, Rachel Fong, Alex Ray, Jonas Schneider, Wojciech Zaremba, and Pieter Abbeel. "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World." IEEE/RSJ International Conference on Intelligent Robots and Systems. 2017. https://doi.org/10.1109/IROS.2017.8202133
22. Niu, Haoyi, Jianming Hu, Guyue Zhou, and Xianyuan Zhan. "A Comprehensive Survey of Cross-Domain Policy Transfer for Embodied Agents." Proceedings of IJCAI 2024, 8197-8206. https://doi.org/10.24963/ijcai.2024/906
23. Li, Xuanlin, et al. "Evaluating Real-World Robot Manipulation Policies in Simulation." Proceedings of the 8th Conference on Robot Learning, PMLR 270, 3705-3728. 2025. https://proceedings.mlr.press/v270/li25c.html
24. Atreya, Pranav, et al. "RoboArena: Distributed Real-World Evaluation of Generalist Robot Policies." Proceedings of the 9th Conference on Robot Learning, PMLR 305, 336-364. 2025. https://proceedings.mlr.press/v305/atreya25a.html
25. Dresser, Scott. "Amazon launches a new AI foundation model to power its robotic fleet and deploys its 1 millionth robot." Amazon. June 30, 2025. https://www.aboutamazon.com/news/operations/amazon-million-robots-ai-foundation-model
26. Agility Robotics. "GXO Signs Industry-First Multi-Year Agreement with Agility Robotics." June 27, 2024. https://www.agilityrobotics.com/content/gxo-signs-industry-first-multi-year-agreement-with-agility-robotics
27. BMW Group. "BMW Group advances the use of Physical AI in production with Figure 03 project in Spartanburg." June 25, 2026. https://www.press.bmwgroup.com/canada/article/detail/T0458794EN/bmw-group-advances-the-use-of-physical-ai-in-production-with-figure-03-project-in-spartanburg?language=en
28. Kojima, Takeshi, et al. "A Comprehensive Survey on Physical Risk Control in the Era of Foundation Model-enabled Robotics." Proceedings of IJCAI 2025, 10517-10527. https://doi.org/10.24963/ijcai.2025/1168
29. International Organization for Standardization. "ISO 10218-1:2025 Robotics - Safety requirements - Part 1: Industrial robots." February 2025. https://www.iso.org/standard/73933.html
30. International Organization for Standardization. "ISO 10218-2:2025 Robotics - Safety requirements - Part 2: Industrial robot applications and robot cells." February 2025. https://www.iso.org/standard/73934.html
31. International Organization for Standardization. "ISO 13482:2014 Robots and robotic devices - Safety requirements for personal care robots." February 2014. https://www.iso.org/standard/53820.html
32. International Organization for Standardization and International Electrotechnical Commission. "ISO/IEC TR 5469:2024 Artificial intelligence - Functional safety and AI systems." January 2024. https://www.iso.org/standard/81283.html
33. Tabassi, Elham. "Artificial Intelligence Risk Management Framework (AI RMF 1.0)." NIST AI 100-1. January 26, 2023. https://doi.org/10.6028/NIST.AI.100-1
34. European Commission AI Act Service Desk. "High-risk AI in regulated products." https://ai-act-service-desk.ec.europa.eu/en/high-risk-ai-regulated-products
35. Google DeepMind. "Responsibly advancing AI and robotics." https://deepmind.google/models/gemini-robotics/responsibly-advancing-ai-and-robotics/