Humanoid Robot Functional Safety (ISO) Explained in 2026

Introduction: the hard part is not the backflip

In 2026, the humanoid-robot conversation is finally moving from stage demos to factory-floor deployments.

That shift changes what matters.

A demo robot can be “impressive.”
A production robot must be safe, predictable, diagnosable, and insurable.

One small line in recent deployment coverage says a lot: Agility Robotics has been working toward ISO functional safety certification for Digit so it can operate cooperatively alongside people without physical barriers.

That is the real unlock.

This post breaks down what “functional safety” actually means in robotics, which standards show up in real projects, and what a serious safety program looks like when you’re shipping a humanoid into an environment full of humans, forklifts, and chaos.

Source note: Example deployment context referenced from: https://www.humai.blog/physical-ai-is-here-how-robots-wearables-and-drones-are-leaving-the-lab-in-2026/

1) What “functional safety” means (in one sentence)

Functional safety is the discipline of ensuring a system responds safely to inputs and failures, such that the residual risk is acceptable.

In robotics, that includes things like:

If the perception stack fails, the robot must not keep moving as if nothing happened.
If a joint sensor drifts, the robot must detect it and transition to a safe state.
If software updates change behavior, you must prove they don’t break safety assumptions.

Functional safety is not “the robot is usually careful.” It is engineered, testable safety behavior under faults.

2) Why humanoids make safety harder than classic industrial robots

Traditional industrial robots are typically safe because they are separated:

cages
light curtains
interlocked doors
hard boundaries

Humanoids are explicitly being sold on the opposite promise:

same space as humans
flexible tasks
changing layouts
shared tools and aisles

That creates a nasty safety equation:

A) More degrees of freedom → more ways to fail

A humanoid has many actuators, often with complex whole-body balancing behavior. Fault modes multiply.

B) Contact is not an exception, it is a feature

If your robot is moving totes, opening doors, or working near people, contact can happen. You need safe contact strategies and conservative limits.

C) ML adds uncertainty

Learning-based perception and policies create two problems:

Non-determinism (especially under domain shift)
Hard-to-validate logic (it’s not an if-statement you can reason about line by line)

Safety programs do not ban ML by default, but they constrain it and build layers around it.

3) The standards you keep hearing about (and what they’re for)

There isn’t a single “humanoid safety standard.” In practice you’ll see a stack of standards, each covering a slice.

Here are the names that come up constantly:

ISO 10218 (industrial robot safety)

Historically central to industrial robots and robot systems.
Useful because it anchors many baseline concepts: protective stops, safety-rated monitored stop, speed/position limiting, etc.

ISO/TS 15066 (collaborative robots)

Often referenced for collaborative operation guidance.
Important conceptually because it focuses on human-robot contact and limits.

ISO 13849 and IEC 62061 (safety-related control systems)

These are about the reliability of the safety functions implemented by the control system.

ISO 13849 is widely used in machinery safety.
IEC 62061 is the machinery sector implementation tied to IEC 61508 concepts.

They help answer: “If we claim this safety function prevents a hazard, how do we prove it meets a target integrity level?”

IEC 61508 (functional safety, foundational)

This is a foundational functional safety standard used across industries.

In robotics-adjacent work, it often appears indirectly (via sector standards) but the mental model matters:

define hazards
define safety functions
allocate targets (SIL-like requirements)
verify and validate systematically

ISO 12100 (risk assessment)

This is the “start here” standard for machinery risk assessment.

Even if you never quote it publicly, the process it represents is what auditors and safety engineers expect:

hazard identification
risk estimation
risk reduction measures
iteration until acceptable residual risk

Important: Standards applicability depends on your exact use case and region. The point here is not legal advice; it’s how real robot teams structure safety work.

4) Safety is not one feature. It’s a safety case.

If you want a single takeaway:

Certification is usually the byproduct of a safety case.

A safety case is a structured argument, backed by evidence, that the system is acceptably safe for a defined scope.

A serious humanoid safety case typically includes:

Operational Design Domain (ODD)
- Where will it operate?
- What surfaces, lighting, aisle widths, payload ranges?
- How fast can it move?
Hazard analysis
- pinch points
- falls (robot falls are a hazard)
- dropped payloads
- unexpected contact
- battery/thermal events
- EMI, sensor failure, compute lockup
Safety functions + requirements Examples:
- protective stop on e-stop
- speed and separation monitoring
- force/torque limits
- safe torque off
- safe joint limit monitoring
- emergency controlled stop vs immediate power cut (tradeoffs)
Architecture with separation You almost always see a split:
- “Performance” compute (perception, planning, ML)
- “Safety” compute (safety PLC or safety controller, independent monitoring)
The safety side monitors the performance side and can force a safe state.
Verification and validation evidence
- test plans
- fault injection
- traceability matrices (requirements → tests)
- field data with incident reporting
Change management
- safety impact analysis for every software update
- rollback strategies
- controlled deployment rings

This is why “we’ll just update the policy” is a scary sentence in robotics.

5) The three safety layers that actually work in practice

Most successful robot safety strategies look like layered defenses:

Layer 1: Design-time risk reduction

eliminate hazards by design (rounded edges, fewer pinch points)
reduce energy (limit speed, limit payload, compliant actuation)
mechanical safeties (covers, guards)

Layer 2: Runtime safety functions (independent monitoring)

safety-rated stops
speed limiting
separation monitoring (if sensors support it)
watchdogs for compute and comms
sanity checks on joint state

Layer 3: Operational controls

training for operators
signage
defined interaction rules
maintenance schedules
incident response procedures

Humanoids that succeed commercially will usually be the ones that are boring at Layer 2 (reliable safety behavior), even if their AI is exciting.

6) How ML fits into safety without pretending it’s certified “intelligence”

A useful, realistic framing is:

Use ML for capability (perception, grasp selection, semantic understanding)
Use deterministic systems for constraints (hard limits, safe envelopes)

Examples of “ML inside constraints” patterns:

The policy can choose a motion, but a safety controller enforces max speed/torque.
The perception stack can propose obstacles, but a safety monitor assumes “unknown = hazardous.”
If confidence drops below a threshold, the robot slows or stops.

In other words: ML makes the robot useful; safety makes it shippable.

7) What “ISO certification” signals to buyers (and why RaaS teams care)

When a robotics company says it’s pursuing ISO functional safety certification, it usually signals:

they expect to deploy at scale (not one-off pilots)
they’re building for regulated procurement and insurance requirements
they have internal discipline: traceability, testing, change control
they want to reduce friction with factory EHS teams and integrators

For Robot-as-a-Service (RaaS), safety is not just a moral requirement. It is a business requirement:

lower site onboarding time
fewer facility modifications
fewer incidents and downtime
easier expansion from 7 robots to 70

8) A quick checklist if you’re evaluating a humanoid for a real site

If you’re a buyer, partner, or engineer doing diligence, here are sharp questions that cut through hype:

What is the defined ODD? (and what is out of scope)
What are the safety functions and how are they implemented?
Is there independent safety monitoring hardware?
How do software updates get validated for safety impact?
What happens under sensor failure, comms loss, or compute overload?
Do you have incident reporting and post-mortem processes?
What standards are you designing against, and what evidence exists?

If the answers are vague, the deployment risk is high.

Conclusion: the “ChatGPT moment” won’t ship without safety engineering

The most important story in physical AI is not that robots are getting smarter.

It is that robots are becoming deployable.

Humanoid robots next to humans will only scale if teams treat functional safety as a first-class engineering product: standards, safety functions, layered architecture, disciplined validation, and clear operational scope.

If 2025 was about “can it do the task?”, 2026 is about “can it do the task safely, every day, in a messy world?”

Humanoid Robot Functional Safety in 2026: What ISO Certification Really Means