News analysis · Published
ISO 13482 Final Draft: Prepare a Service Robot Safety Case
By the ELYMENT AI editorial team · Free to read
ISO 13482 has reached Final Draft International Standard status for its second edition, moving the proposed service-robot safety update into the approval phase. It is not yet the final published standard. The draft covers service robots in personal and professional or commercial settings, including physical human contact, while excluding industrial and medical applications. Operators should use the moment to build a service-robot safety case: define scope, map hazards, test safeguards, specify human intervention and preserve evidence for every deployed site.

What changed in ISO 13482
As of 28 September 2026, ISO lists ISO/FDIS 13482, Robotics — Safety requirements for service robots, as Edition 2 at stage 50.20. That means the Final Draft International Standard is in its approval phase. ISO says it will replace ISO 13482:2014, but the current page still labels the new edition under development.
The stated scope covers service robots used in personal and professional or commercial applications. It considers hazards, hazardous situations and physical human contact, and includes information on functional safety. ISO explicitly says the draft is not intended for robots used in industrial or medical applications. Those boundaries matter: a mobile concierge, cleaning robot or commercial assistant may sit in scope, while an industrial robot cell is addressed through the separate ISO 10218 series.
A model capability is not a safety function
Modern service robots increasingly combine learned perception, language interfaces, planning and adaptive control. Those components may improve usability, but they also make behaviour sensitive to unfamiliar environments, distribution shift and opaque failure modes. An IROS 2026 workshop on verifying AI-enabled autonomous systems, published on 27 September, identifies exactly this tension: traditional verification must now meet foundation models, vision-language systems and learning-based components.
The practical response is architectural separation. A language model can propose a task, but independent safety mechanisms should enforce speed, force, clearance, restricted zones, emergency stopping and recovery. A confidence score from a perception or planning model is useful evidence; it is not proof that a physical action is safe.
Build a site-specific service robot safety case
A procurement certificate alone cannot describe every doorway, floor surface, crowd pattern, network dependency or human interaction. Before a pilot becomes routine operation, assemble a living safety case that connects each claim to a control and test result.
- Fix the scope: record the robot, software and model versions, tools, payloads, site, users and tasks covered by approval.
- Map credible hazards: include collision, crushing, trapping, unexpected motion, dropped loads, unsafe contact, sensor loss, cyber compromise and bad instructions.
- Separate safety from intelligence: identify which safeguards remain effective if a model, network connection or cloud service fails.
- Define runtime states: specify when the robot may proceed, slow, pause, request help, enter a safe state or require a physical reset.
- Test the real environment: use representative lighting, surfaces, obstacles, bystanders and failure conditions, then retain results and near-miss records.
- Control change: require revalidation after changes to hardware, models, prompts, maps, payloads, permissions or the operating site.
What business leaders should do now
Do not market compliance with the second edition before it is published and applicable to the product. Instead, ask suppliers for a gap assessment against the Final Draft, the standards they currently claim, the safety-related control architecture and the evidence supporting each operating limit. Contract for incident notification, patch support, change records and revalidation obligations.
NIST’s AI Risk Management Framework playbook recommends documenting risk tolerance, monitoring deployed systems, capturing near misses and decommissioning systems that exceed tolerance. Apply that discipline to physical AI. Pair ELYMENT AI’s task-envelope method with its human-approval workflow and physical-AI permission model to keep capability, authority and safety evidence distinct. The goal is not a thicker file. It is a robot that knows when it must stop, and an organisation that can prove why.
Sources
- ISO, ISO/FDIS 13482: Robotics — Safety requirements for service robots (Current status checked 28 September 2026) - Official scope, Final Draft status, approval stage and relationship to ISO 13482:2014.
- ISO, ISO 10218-1:2025 and ISO 10218-2:2025 (2025) - Official ISO overview of the separate safety standards for industrial robots and industrial robot applications.
- Leahy et al., AI and the verification of autonomous systems (27 September 2026) - Peer-reviewed IROS 2026 workshop overview of verification challenges created by foundation models and learning-based autonomy.
- NIST AI RMF Playbook, Manage (Current guidance checked 28 September 2026) - Government guidance on risk tolerances, post-deployment monitoring, near misses, override and decommissioning.
Continue learning
Frequently asked questions
Is the second edition of ISO 13482 final?
No. As of 28 September 2026, ISO lists ISO/FDIS 13482 as a Final Draft International Standard in the approval phase and still under development.
Which robots does ISO 13482 cover?
Its stated scope covers service robots used in personal and professional or commercial applications. It excludes industrial and medical robot applications.
What should a service robot safety case contain?
It should define the approved task and site, map hazards, identify independent safeguards, specify runtime stop and handoff states, record tests and control every material change.