Robot safety was easier when there was a cage.

As robots move into shared spaces and become harder to describe, the boundary safety engineering has to reason about is moving too.

Carina Käser Founder, ply August 2026 5 min read

Pen-and-ink drawing of an industrial arm behind a cage and a person sharing open space with a mobile robot. — For decades, the cage made the safety boundary visible. Now robots are moving beyond it.

For most of industrial robotics history, we had a remarkably effective safety strategy: keep the robot and the human apart.

Put the robot behind a fence. Define its workspace. Make its behavior predictable. If something goes wrong, stop it.

Now we're building robots specifically to remove that separation.

A warehouse robot shares an aisle with a worker. A delivery robot has to understand someone stepping into its path. A humanoid is supposed to operate in a space designed for us, not for machines.

There is no cage anymore.

And at the same time, the machine inside that shared space is becoming harder to describe.

Pen-and-ink drawing of a robot arm reaching toward a cup along one planned path and many possible learned trajectories. — A learned system does not produce certainty. It produces an answer under particular conditions.

A camera doesn't simply “see a person.” A perception model produces a detection with some confidence, based on what it has learned, through a particular sensor, under particular conditions.

Fog the lens. Change the lighting. Update the model. Tune a threshold.

The robot may still work.

But is it still the robot we tested?

I think this is where an interesting shift in safety engineering starts.

A lot of traditional machine safety is built around defining the system and its boundaries, identifying what can go wrong, engineering safeguards, and demonstrating that they work.

None of that becomes less important with AI.

If anything, it becomes more important.

Pen-and-ink drawing comparing a stopped industrial arm with a dynamically balancing humanoid robot. — The machine, its behavior and its operating conditions increasingly have to be understood together.

But the boundary we're trying to reason about is moving.

The relevant question starts to become less:

Was this robot validated?

and more:

What has this particular robot been validated to do, under which conditions?

It sounds like a small distinction. It isn't.

A modern robot isn't just a mechanism executing fixed logic. It may perceive the world through learned models whose outputs are probabilistic. It may be connected and remotely updated, which means a cybersecurity failure can become a physical one. And for a humanoid or legged robot, even “stop” is no longer necessarily a safe state — staying upright is itself something the machine has to continuously control.

So the safety of the machine increasingly depends on a combination of things:

the physical system, the software running today, the models and sensors it relies on, the environment around it, and the assumptions under which all of those were tested.

Change one of them and the robot doesn't suddenly become unsafe. But the evidence we were relying on may no longer tell us what we think it does.

A perception model is updated. A sensor starts performing differently in dust. A security patch changes timing. A humanoid gets a new controller. The same robot moves from a clean lab into a busy warehouse.

The machine still works.

But what exactly have we established about the machine that exists now?

Today, answering that often means going back through requirements, tests, safety analyses and engineering decisions to reconstruct which assumptions still hold and which evidence still applies.

That was manageable when machines changed slowly and operated inside tightly controlled boundaries.

I'm not convinced it scales to machines that learn, update, connect and operate alongside us.

Pen-and-ink drawing of a certification seal beside a continuously maintained evidence record. — Safety evidence has to be maintained as the machine changes, not reconstructed after the fact.

Safety can't remain something we assemble around the machine at the end.

It has to become much more closely connected to the machine itself — its software, hardware, environment, tests and the engineering decisions behind them.

Not because existing safety engineering is obsolete.

Because the robots it has to keep safe are changing.

That's the problem we're working on at Ply.