Skip to content

Physical AI

Last reviewed: August 2026 | This document covers a fast-moving area and is subject to quarterly review.

Physical AI refers to the shift from AI confined to digital data (like text and images) toward AI that connects to the physical world of sensors, robots, vehicles, and equipment — perceiving, deciding, and physically acting. Unlike digital AI such as chatbots or document processing, Physical AI is fundamentally different in that failures of latency, safety, and real-time behavior can pose direct risks to people or equipment.

Physical AI is not a single product but a pipeline of interlocking layers. Data flows in from the physical world, passes through training and simulation, and flows back out as physical action.

flowchart LR
    S[Sensors · cameras · IoT] --> E[Edge inference]
    E -->|telemetry| C[Cloud training · model mgmt]
    C -->|synthetic data| SIM[Simulation · digital twin]
    SIM -->|policies · models| C
    C -->|deploy| E
    E --> A[Actuators · robots · vehicles]
    A -.feedback.-> S

Data from the physical world is voluminous and real-time, making it impractical to send everything to the cloud. The default is to infer at the edge first and send only the necessary data to the cloud.

Item AWS Azure Google Cloud OCI
Edge runtime IoT Greengrass Azure IoT Operations / IoT Edge Google Distributed Cloud (Edge) Roving Edge Infrastructure
Edge ML inference Greengrass ML components (deploy SageMaker AI models) IoT Edge modules + Azure AI services Edge TPU / Coral Self-managed compute on RED
Industrial data ingestion IoT SiteWise (OPC UA) IoT Operations (OPC UA) — (partner / self-managed) — (self-managed)

Training robots and vehicles solely in the real world is costly, risky, and slow. This is why sim-to-real approaches have taken hold: generate and train on large volumes of scenarios in a digital twin and simulation that virtually replicate the physical environment, then transfer to reality.

Item AWS Azure Google Cloud OCI Cross-vendor
Digital twin IoT TwinMaker Azure Digital Twins — (self-managed with Spanner Graph, BigQuery, etc.) NVIDIA Omniverse
Robotics / physics simulation — (RoboMaker discontinued; self-managed) — (partner / self-managed) — (partner / self-managed) NVIDIA Isaac Sim / Isaac Lab

Just as LLMs generalized language, robot foundation models are emerging to generalize a robot’s perception, planning, and motion. A representative approach is VLA (Vision-Language-Action), which takes natural-language instructions and connects vision, language, and action.

Item Status
Leading stack NVIDIA Isaac GR00T — an open foundation model for robots (VLA), with Omniverse/Cosmos-based simulation and synthetic data, and Jetson Thor for on-device inference
The three major clouds Native general-purpose robot foundation models are still limited — they generally run the NVIDIA stack on GPU infrastructure or offer it via partnerships
National policy Japan adopted robotics foundation model development as a national project under GENIAC (see Japan’s AI Landscape)

Safety Layer — Autonomous Driving and Robotics

Section titled “Safety Layer — Autonomous Driving and Robotics”

AI that moves in the physical world is directly tied to human life and equipment, making functional safety certification central. In this area, NVIDIA provides the Halos safety system.

  • Autonomous vehicles (AVs): the DRIVE platform (AGX, Hyperion) with the Halos safety system (end-to-end from cloud to car, aligned with ISO 26262), using Omniverse/Cosmos for simulation.
  • Robotics: in June 2026, NVIDIA announced Halos for Robotics (IGX Thor, Holoscan Sensor Bridge, Halos OS, AI Systems Inspection Lab), extending its AV safety foundation to industrial robots, humanoids, and AMRs.

Multicloud and Edge Architecture Considerations

Section titled “Multicloud and Edge Architecture Considerations”
  • Data gravity and latency — Sensor data is voluminous and latency-sensitive, so a design that splits edge inference and cloud training is the default. Decide first what to process at the edge and what to send up.
  • Simulator portability — If your digital twin and simulation are tied to one cloud’s dedicated service, migration is hard. Prioritizing a stack that runs anywhere with GPUs (like NVIDIA Omniverse/Isaac) reduces lock-in.
  • On-device vs. cloud training split — It is common to place training and synthetic-data generation on cloud GPUs and real-time inference on-device (e.g., Jetson-class hardware).
  • Safety and regulation — Autonomous driving and industrial robots are subject to separate functional-safety certifications and regulations. Factor certification requirements into the architecture early.
  • Check product lifecycle — This area has many retired (EOL) products (e.g., Azure Percept, AWS RoboMaker). Always confirm each service’s current support status before designing.
  • Sending all data to the cloud — A design that ignores latency, bandwidth, and cost fails at real-time control. Edge inference splitting comes first.
  • Using EOL products in new designs — Do not adopt discontinued services like RoboMaker or Percept based only on old material.
  • Locking into a single vendor’s simulator — Tying your training pipeline to one cloud’s dedicated simulation makes migration and comparison difficult.
  • Bolting on safety later — For AVs and robots, safety must be designed from the start (“built-in,” not “bolt-on”).
  • Have you separated inference to run at the edge from data to send to the cloud?
  • Is your digital twin / simulation stack portable to other clouds (lock-in check)?
  • Are the IoT / robotics services you plan to use under current support (EOL check)?
  • For AVs or industrial robots, have you factored functional-safety certification requirements into the design?
  • Is the split between on-device inference and cloud training clearly defined?