Analysis

AI alignment and Physical AI safety are different problems

2 min readMati Melchior
AI alignment and Physical AI safety are different problems

Two problems get conflated in almost every AI safety discussion. They shouldn't be.

Alignment asks: does the AI want what we want? Does its objective function match human intent? If you tell it to "minimize harm," does it interpret harm the way you do? Alignment is about the fidelity between what the human intended and what the system optimizes for. The entire field of RLHF, constitutional AI, and reward modeling exists to close this gap.

Physical safety asks a different question: what can the AI actually do in the physical world — and what hard limits prevent damage regardless of intent? This is the domain of functional safety engineering: hardware interlocks, force limiters, safety-rated speed bounds, and independent monitoring channels that operate below the software layer.

These are not the same problem. And treating them as interchangeable creates blind spots.

Consider two scenarios. In the first, an AI controlling a robotic arm is misaligned — it optimizes for the wrong objective. But the arm has hardware-enforced torque limits, speed caps, and an independent hardware safety layer that cuts power if force exceeds a threshold. The AI does the wrong thing, but the damage is bounded. The outcome is survivable.

In the second scenario, the AI is perfectly aligned — it understands exactly what the human wants. But a software bug corrupts its control signal. Or a cosmic ray flips a bit in memory. Or an adversary injects a malicious command through a network connection. Without hardware-enforced bounds, the aligned AI has no physical limit on what it can do in the moment of failure. The outcome is unpredictable.

The distinction matters because the two problems require different expertise. Alignment researchers work on objective functions, reward models, interpretability, and value learning. Physical safety engineers work on redundancy architectures, diagnostic coverage, fail-safe states, and hardware fault tolerance. Both disciplines are essential. Neither one subsumes the other.

The AI safety conversation today is dominated by alignment. The physical safety conversation barely exists in the AI community. In traditional industries — aviation, nuclear, rail — this conversation has been happening for decades under the framework of IEC 61508 and its derivatives. Physical AI needs both conversations, running in parallel, with engineers who understand that solving alignment does not automatically solve the problem of a robot arm that can crush a human hand.

Share

Physical AI Safety Dispatch

Monthly analysis. No spam. One exclusive insight per issue.

One issue per month. Unsubscribe in one click from any email. Privacy policy.

Regulation

What five weeks of counting found

104 days separate 8 October 2026 from 20 January 2027, when Regulation (EU) 2023/1230 will apply as a cut-off with no transition period. Thirty-nine notified bodies held a current notification on 13 September 2026, against one hundred and forty-four under the Directive it replaces. No harmonised standard has yet been cited under the Regulation, the application guide is expected in the fourth quarter of 2026, no readiness figure has been published, and none of the seven certification bodies checked publishes how long the work takes. The deadline is measured to the day. Almost nothing behind it is.

Read →

Regulation

You have 127 days. Nobody publishes how long this takes.

127 days separate 15 September 2026 from 20 January 2027, when Regulation (EU) 2023/1230 will apply. Seven certification bodies were checked for a published duration benchmark and not one publishes it, so what follows is what is documented instead: the first assessor notified on 8 September 2024, roughly twenty-eight months before the Regulation applies, no harmonised standard yet cited under the Regulation, and seven trade associations on record that machinery was the only sector left out of the Omnibus IV transition period.

Read →

We use cookies

This site uses essential cookies to function and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Learn more.