Physical AI: How Intelligent Machines Act, and What Makes Them Safe

AI is moving beyond generating answers to controlling physical machines. The opportunity is significant, but a familiar engineering distinction becomes critical: a system that can perform a task is not necessarily ready to perform it safely in the real world.

Cover image supplied by the TechiesJournal editor for this article (AI-generated). It is a concept view of the four steps from perception to physical action, not a photograph and not a depiction of any real system. The step labels in the image are part of the illustration.

In technology, we often distinguish between a system that works and one that is ready for production.

An application may pass its functional tests but behave differently when it encounters incomplete information, unexpected demand or a failed dependency. Production readiness asks a harder question: what happens when conditions are no longer ideal?

Physical AI brings that question into the world of movement. An intelligent machine may recognize an object, plan a route or adjust a robotic arm. But if the decision is wrong, or correct but impossible to execute safely, the result may be immediate and irreversible.

I find the progress in physical AI compelling. More flexible machines could take on difficult industrial tasks and work in places where conditions cannot be programmed in advance. What interests me just as much, however, is the engineering around the intelligence.

Showing that a robot can do something is different from showing that it can do it safely in its intended environment.

When automation meets an unexpected situation

In March 2018, an experimental self-driving vehicle operated by Uber struck and killed a pedestrian in Tempe, Arizona.

The investigation by the US National Transportation Safety Board (NTSB) found that the automated driving system detected the pedestrian about 5.6 seconds before impact. It continued to track her, but did not accurately classify her as a pedestrian or predict her path. By the time the system determined a collision was imminent, the situation had exceeded the response specifications of its braking system.

The vehicle’s design also precluded automatic emergency braking for collision mitigation while the developmental system was in control. It relied on the human safety operator, who was looking away from the road and intervened too late.

The NTSB identified the distracted operator’s failure to monitor the driving environment as the probable cause. It also cited Uber’s inadequate risk assessment, ineffective operator oversight and insufficient measures to address complacency among contributing factors. NTSB investigation.

It is tempting to reduce such an incident to a single failure: the AI did not understand what it saw. But that misses the more useful engineering lesson.

Detection, prediction, braking design, supervision and organizational risk management all mattered. A safety system is only as effective as the way these responsibilities work together.

The case does not describe every modern autonomous machine. It does show why the entire operating system, not only the AI model, must be part of a safety assessment.

Explore the evidence: The companion incident timeline presents the NTSB’s documented sequence and findings. It is not a simulated reconstruction of the collision.

An intelligent plan still needs a safe way to act

For decades, industrial robots have performed predefined tasks, often inside restricted workspaces. Physical AI expands the kinds of situations machines may respond to.

Consider a warehouse robot handling packages that arrive in different positions. Its sensors gather information. An AI-enabled controller may identify an object and propose how to grasp or move it. Motors and other control systems then translate the plan into motion.

The plan might make sense while the physical action does not. A worker may move into the path. A package may be heavier than expected. A camera may lose a clear view at exactly the wrong moment.

This is why the distinction between proposing an action and allowing that action to reach the machine matters.

A protective controller might limit speed, prevent movement into a restricted zone or command a defined fallback when necessary information is missing. Industrial machines already use safeguards such as interlocks, protective stops and speed restrictions. Researchers are now examining how more adaptive safety controls can operate alongside learned AI models.

For example, the 2025 SHIELD research explored safety constraints for humanoid locomotion, including experiments on a Unitree G1 robot. The 2026 paper Verifiable Foundation Models for Robot Safety examined how a more limited and verifiable safety component can constrain a capable learned controller. Both are useful research directions. Neither demonstrates that all movements of all humanoid robots are safe. SHIELD · Verifiable Foundation Models for Robot Safety.

A separate component also does not become an independent safeguard merely because a diagram labels it that way. If the planner and the safety check rely on the same faulty sensor, both may reach the wrong conclusion. If a robot cannot stop quickly enough, a correct software warning may arrive too late to prevent contact.

When I look at this architecture, I want to know what the protective system can actually enforce, how it behaves when other components fail and whether those claims have been tested on the machine itself.

Explore the mechanism: The safety-control experience compares a normal movement, an unexpected obstruction and loss of sensor information. It is a conceptual teaching example, not a physics simulator or a safety certification.

The real test begins outside the simulation

Simulation is valuable because a robot can encounter difficult situations virtually before anyone is placed at risk. Researchers can vary objects, obstacles and operating conditions and repeat experiments many times.

But a simulated robot does not experience every detail of a real one. Friction changes. Loads shift. Sensors become noisy or obstructed. Mechanical wear and delays affect how a machine responds.

A model may identify a person correctly while the complete robot still lacks the distance or braking capability to stop safely.

This gap between experimental performance and practical deployment is one reason the US National Institute of Standards and Technology (NIST) is developing ways to measure and test AI-enabled robotics for manufacturing. NIST explicitly identifies a gap between embodied AI research and what manufacturers and integrators can confidently apply. NIST Physical AI project.

Established safety engineering remains relevant. ISO 10218-1:2025 addresses industrial robot safety. ISO 10218-2:2025 addresses industrial robot applications and cells. That distinction is practical: even a robot with built-in safeguards can become hazardous when integrated with unsuitable tools, loads or workspace arrangements. These standards are not a universal certification for every vehicle, drone, service robot or medical device. ISO Part 1 · ISO Part 2.

I would rather see a narrow, honest statement (this machine was tested for these tasks, under these conditions, with these limits) than a broad promise that a system is simply “safe.”

India’s physical AI development: A useful direction, with evidence still needed

India’s recent activity provides an interesting example of the broader shift toward separating intelligent action from safety enforcement.

In October 2026, Inner Sky Labs introduced a modular platform with models for perception, action and safety. Its published architecture describes visual, audio and tactile perception models. Models intended to plan or anticipate physical actions. And a safety family called Kavach that the company says can evaluate actions before execution. Inner Sky Labs.

The separation is worth examining because it addresses a real architectural question: should the system choosing a movement also be the only system judging whether that movement is permitted?

But we must separate what a company describes from what independent testing has established. Inner Sky Labs reports a 1.00 prompt-safety and 0.91 response-safety score for Kavach v2. These are company-published benchmark claims about AI instruction and response safety. They are not measurements of a robot’s collision avoidance, stopping distance or contact force. The company describes broader multimodal capabilities for v3 and physical embodiment for v4. The public material reviewed here does not independently establish comprehensive physical safety certification for those claims.

Accessible text alternative for this figure

Four stacked bands joined by arrows. Perception, with Drishti for vision, Shruti for audio and Sparsh for touch. Action and world modeling, with Kriya, Karma and Prana. Safety, with Kavach, which the company says evaluates actions before execution. Robot actuators at the bottom.

Below the bands, two columns. Company-reported: Kavach v2 prompt and response safety scores from a text benchmark, with the evaluator not named. Not established from the cited materials: independent validation of physical safety on a robot, such as collision avoidance, stopping or contact force.

That is not a reason to dismiss the work. It is a reason to ask the next question: how does the proposed safeguard perform on actual hardware when a person enters the workspace, the load changes or a sensor fails?

India’s activity extends beyond one company. IIT Roorkee and Avathon announced plans for a Physical AI laboratory focused on industrial research in 2026. It is an investment in capability and collaboration, not, by itself, evidence of a certified deployed system. Government of India announcement.

I would evaluate Indian, American, European and Chinese developments by the same standard: demonstrated capabilities, clear limitations and evidence from the intended operating environment.

What I would ask before trusting the machine

The question is not whether intelligent machines should be developed. There are good reasons to pursue robots that can adapt to changing conditions, perform hazardous work and reduce repetitive physical effort.

The question is what evidence justifies their deployment.

Before trusting a physical AI system in a workplace or around the public, I would want three things to be clear.

What is it allowed to do? The machine needs defined operating conditions and enforceable limits on its behavior. The limits may involve workspace, speed, force, permitted tasks or proximity to people.

What happens when something goes wrong? A safe response must be tested, not assumed. Stopping immediately is not always the right response, for example, abruptly removing power from a machine holding a suspended load can introduce another hazard.

What evidence supports the claim? I would expect testing on the real machine, with representative tasks, measured outcomes, stated limitations and appropriate independent assessment.

Accountability matters too. The model developer, robot manufacturer, system integrator and operating organization may control different parts of the system. Their responsibilities cannot be collapsed into a vague claim that “the AI” was in charge.

Nor can a human operator always be treated as a reliable last-second safety mechanism. In March 2026, the NTSB reported findings from two fatal crashes involving Ford BlueCruise, a partial driving-automation system that requires an attentive driver. The investigations identified overreliance and driver-monitoring limitations, among other issues. BlueCruise is not a fully driverless system, but the findings reinforce the importance of designing realistic human oversight. NTSB BlueCruise findings.

Physical AI will continue to improve. More capable models, better sensors and new control methods can all contribute. But confidence should grow with evidence, not with increasingly polished demonstrations.

In enterprise technology, working software is only the beginning of a production-readiness discussion. With physical AI, that distinction becomes even more important because a mistake may already have consequences before anyone can reverse it.

Intelligence expands what a machine can attempt. Engineering and evidence determine what it should be trusted to do.

Sources and further reading

Editorial source cutoff: 15 October 2026. Each source was opened and checked on 15 October 2026. The company descriptions and benchmark claims are reported as the company publishes them and were not independently verified.

1. NTSB: Uber developmental automated-driving collision investigation. Investigation of the March 2018 collision in Tempe, Arizona.
2. NTSB: Ford BlueCruise partial-automation investigations, March 31, 2026. Press release on two fatal crashes involving a partial driving-automation system.
3. NIST: Physical AI and Data Generation for Robotics. NIST project page.
4. SHIELD: Safety on Humanoids via CBFs in Expectation on Learned Dynamics. Research paper.
5. Verifiable Foundation Models for Robot Safety. Research preprint.
6. ICML 2026: Position: Modular Safety Guardrails Are Necessary for Foundation-Model-Enabled Robots in the Real World. Position paper.
7. ISO 10218-1:2025. Robotics, safety requirements, Part 1: industrial robots.
8. ISO 10218-2:2025. Robotics, safety requirements, Part 2: industrial robot applications and robot cells.
9. Inner Sky Labs: Modular Physical AI Platform. Company descriptions and benchmark claims.
10. Government of India: IIT Roorkee and Avathon Physical AI Lab. Press Information Bureau announcement of plans for a laboratory.