Deployment Reality · 03 of 06

Why Safety Is Not Just a Software Problem

A robot is a physical machine. Safety lives in the hardware, the workspace, the people, the standards, the maintenance — and only then the software.

12 min read

When people hear the word safety in robotics, they often imagine AI deciding to be careful.

That is part of the picture. It is a small part. A robot is a physical machine that moves weight through space. Safety lives in the hardware, the workspace, the people around it, the standards it is built to, and the maintenance schedule — long before it lives in the model.

What stops this machine if everything else fails?

Safety is a system, not a feature

OSHA describes an industrial robot system as the robot, the end-effector, the control system, the power sources, the sensors, and the communication interfaces. Every one of those parts can hurt someone, and every one has to be considered.

  1. 01The body

    Mass, momentum, joints, edges, pinch points, falling distance.

  2. 02The end-effector

    Hands, grippers, tools — the part that touches the world.

  3. 03The workspace

    Floor surface, lighting, fencing, signage, escape paths.

  4. 04The stop system

    Emergency stops, soft stops, fall recovery, power isolation.

  5. 05The people

    Trained operators, bystanders, visitors, maintenance staff.

  6. 06The software

    Perception, planning, behaviour, fault handling — sits on top of all of the above.

What the standards already say

There is a body of work behind machinery safety, and most of it predates AI by decades. ISO 12100 sets out general principles for machinery risk assessment and risk reduction. ISO 10218 covers industrial robots — manufacturers and system integrators — and the 2025 update adds clearer functional-safety, collaborative-application, end-of-arm-tooling, manual load/unload, and cybersecurity requirements.

The point

AI does not get to skip risk assessment. It is one input to risk assessment.

Why humanoids make this harder

An industrial arm usually lives inside a cage or a defined cell. A humanoid is designed to move through human spaces. It may walk, carry, reach, kneel, climb stairs, and work near people without a fence.

…is hard.
  1. It falls

    A humanoid loses balance in a way an arm cannot. Falling is a hazard for the robot and anyone nearby.

  2. It carries

    Anything in the hands becomes part of the safety picture — including the kinetic energy of a dropped object.

  3. It moves between zones

    Risk assessment cannot assume one cell — the robot crosses lighting, surfaces, and people.

  4. It is general-looking

    People assume more from a humanoid than from a yellow arm. Expectations are themselves a hazard.

Where software does help — and where it does not

Better perception and behaviour models can lower risk: detecting people, slowing in tight spaces, recovering from confusion. Safety platforms like NVIDIA Halos for Robotics are bringing functional-safety thinking to the compute stack itself.

None of this removes the physical hazards. A safer model running on a heavy machine is still a heavy machine. Software complements physical safety; it does not substitute for it.

If the answer to “what stops it” is only software, it is not a safe system yet.

What people often misunderstand

  1. Mistake 01

    “Collaborative means safe.”

    Collaborative robots are designed to share space with people — they still cause injuries when misapplied.

  2. Mistake 02

    “If the AI is good, the robot is safe.”

    Most accidents involve hardware, layout, training, or maintenance.

  3. Mistake 03

    “Safety is the vendor's job.”

    Standards explicitly hold integrators and operators responsible for the deployed system.

  4. Mistake 04

    “The standards will catch up later.”

    They are catching up now — and missing them creates liability today, not someday.

The simple test for any safety claim

Who is responsible for stopping this machine if a person walks into the wrong place at the wrong time?

The basic rule

If the answer names a person, a standard, and a hardware system — not just a model — the safety story is real.

Robot safety is not a personality trait of the AI. It is a property of the whole system.
What does safety actually look like?
Hardware that can stop. A workspace designed for failure. People trained to recover. Standards held to. And software that does its part on top of all of that — not instead of it.
What to remember
  • A robot system includes the body, end-effector, controls, power, sensors, and people.
  • ISO 12100 and ISO 10218 already define how to assess and reduce machinery risk.
  • Humanoid form factors widen the safety problem because they share human spaces.
  • Software can lower risk but cannot remove physical hazards.
  • Responsibility is shared between vendor, integrator, operator — and named.
Key terms
Functional safety
Engineering that ensures a system behaves safely even when parts fail.
End-effector
The tool, gripper, or hand at the working end of a robot.
Collaborative robot
A robot designed to share space with people, with built-in force and speed limits.
ISO 12100
International standard for machinery risk assessment and risk reduction.
ISO 10218
International standard for industrial robot safety; updated in 2025.
Risk assessment
A structured review of how a system could harm someone, and what reduces that harm.
Sources and evidence notes
Evidence

What this essay leans on

ClaimEvidenceStrengthNote
A robot system is more than the robot.OSHA Technical Manual — robotics overview.StrongLong-standing regulator framing.
Machinery risk reduction is a defined discipline.ISO 12100:2010 — Safety of machinery.StrongReference standard.
Industrial robot safety expectations were updated in 2025.ISO 10218-1/-2:2025 update covering functional safety, collaborative apps, EOAT, manual operation, cybersecurity.StrongRecent revision.
Compute and software safety stacks are emerging.NVIDIA Halos for Robotics safety platform.MediumVendor-led, complements physical safety.