Governing AI That Can Move, Touch, and Harm: A Compliance Playbook for Physical AI

For a decade, "AI risk" meant something happening inside a screen: a biased model, a hallucinated answer, a leaked prompt. That framing is now incomplete. AI is acquiring a body — industrial robots and cobots, autonomous mobile robots on the warehouse floor, delivery drones, self-driving shuttles, surgical robots, and edge-AI controllers wired straight into machinery. When an AI system can move, touch, and exert force, a bad decision is no longer a wrong answer. It's a physical event.

That shift changes what "compliance" has to mean. Software-AI governance asks what did the model decide and can we audit it. Physical-AI governance has to also ask was the machine safe, did the e-stop work, who was standing next to it, and can we prove all of that to a regulator, an insurer, and a procurement team.

The regulation is already here

This is not a speculative, five-years-out problem. A wave of standards and law landed between 2023 and 2026, and the headline deadline is close:

• EU Machinery Regulation 2023/1230 is directly applicable on 20 January 2027. For the first time, it explicitly treats machine-learning-based, self-evolving safety components as high-risk — pulling AI-driven machinery into formal conformity assessment, a Technical File, and a Declaration of Conformity.
• ISO 10218-1/-2:2025 (industrial robots) and ISO/TS 15066 (collaborative robots, power-and-force limiting) were refreshed. ISO 3691-4 and ANSI/RIA R15.08 cover autonomous mobile robots; UL 3300 covers service and consumer robots.
• For anything that drives, ISO 26262 (functional safety), ISO 21448 (safety of the intended function), UL 4600 (autonomous products), and UNECE R155/R156 (vehicle cybersecurity and software-update management) apply.
• The EU AI Act classifies safety components of machinery, vehicles, and medical devices as high-risk, layering on risk management, event logging, human oversight, and serious-incident reporting.
• And because these machines are networked, IEC 62443 (OT/ICS security) and the EU Cyber Resilience Act (SBOMs, vulnerability handling) now sit on top of the safety stack.

The forcing functions aren't only legal. Insurers won't bind a fleet without evidence of safety controls. Enterprise buyers won't sign until you can show your posture. And the moment there's a physical-harm incident, liability turns on whether you can produce a defensible record of what the system was designed and permitted to do.

Why this is mostly an evidence problem

Here's the honest part. You cannot "scan" a cobot's emergency stop the way you scan a web app for a missing security header. Most physical-AI compliance is attestation and documentation: a risk assessment under ISO 12100, a functional-safety rating (Performance Level, SIL, or ASIL), a validation report, a tested kill-switch, a defined operational design domain, an incident procedure, proof of insurance. The hard problem isn't running a clever scanner — it's having one trustworthy place where every embodied system, every safety control, and every piece of evidence lives, stays current, and can be assembled into a safety case on demand.

There are two seams that genuinely go beyond paperwork, and they're the ones worth investing in:

1. Runtime governance of the agent driving the machine. The AI "brain" has an operational design domain, a degraded-mode behavior, a geofence, and a model that can drift. When a robot exits its ODD, does it fall to a minimal-risk condition? When firmware updates over the air, is that change gated and logged, or does the machine silently change behavior? Where a fleet exposes an API, mission starts, faults, e-stops, and geofence breaches can be captured as tamper-evident telemetry — a black box that satisfies both AI Act logging and UL 4600 record-keeping.
2. Cyber-physical security of the controllers. Robots and OT gear speak ROS, MQTT, Modbus, and OPC-UA — often with default credentials, no TLS, and flat network segmentation. That surface is scannable, and it maps cleanly to IEC 62443.

How KollGuard approaches it

KollGuard already governs the software AI agents teams deploy: an inventory, a per-agent autonomy policy, a master kill-switch, and a hash-chained, tamper-evident audit log. Physical AI is the same spine, extended to systems with actuators.

• A framework and control catalog for the standards above, so every obligation resolves to concrete, trackable controls.
• A robot and fleet register where each system is an asset — category, autonomy level, human proximity, harm class, safety-integrity rating, and its attestation status — producing a live conformity-coverage percentage.
• Runtime governance for embodied agents: the autonomy policy, kill-switch attestation, ODD, and hash-chained audit chain extended from software agents to physical ones. Telemetry where a fleet API exists; structured attestation where it doesn't.
• A cyber-physical scan of network-exposed robot and OT controllers, reusing the same DAST-lite engine and SSRF egress guard that already power web and cloud scans, mapped to IEC 62443.
• A KGAI safety questionnaire that drafts risk-assessment answers for human approval, each answer tied to a specific control.
• And a safety case and Declaration-of-Conformity export — a Goal-Argument-Evidence package bound to the live control matrix and a slice of the tamper-evident audit log, ready for a notified body, insurer, or buyer.

One boundary worth stating plainly: KollGuard is a compliance management system, not a safety certifier, and it never actuates a robot. It attests, tracks, and logs the physical-safety controls you operate — turning a scatter of PDFs and spreadsheets into an evidence-of-record you can defend.

Start before the deadline, not after

If you build or operate embodied AI, the practical first move is boring and valuable: inventory every physical system, map each to the standards that actually apply, and find the gaps while you still have runway to close them. The teams that treat January 2027 as a build-the-record deadline — rather than a scramble — will be the ones who can sell into the EU, satisfy their insurers, and answer the only question that matters after an incident: can you prove the machine was governed?

Physical AI Compliance & Security is on the KollGuard roadmap. If you're navigating the EU Machinery Regulation, the AI Act, or IEC 62443 for embodied systems, we'd like to hear how you're approaching it.