Robot Safety Standards for Working Near People

The short answer

Choose robot safety standards by application and hazard—not by whether the machine looks like a cobot, AMR, service robot, or humanoid. The robot body is only one part of a safety case. The end effector, payload, task, speed, workspace, people who can enter it, control system, integration, maintenance process, and local law can all change which requirements apply.

For many industrial deployments, the central 2025 references are the two parts of ISO 10218: Part 1 addresses industrial robots, while Part 2 addresses industrial robot applications and robot cells (ISO 10218-1, ISO 10218-2). Driverless industrial trucks—including machines commonly called AGVs or autonomous mobile robots—have a separate application standard in ISO 3691-4:2023 (ISO). ISO 13482:2014 addresses personal care robots, while a broader service-robot revision is in final-draft development as of July 14, 2026 (published edition, revision).

These documents do not replace a risk assessment. ISO 12100 supplies the general machinery framework for identifying hazards, estimating and evaluating risk, and reducing risk through design, protective measures, and information for use (ISO). Safety-related control functions may then be designed using standards such as ISO 13849-1:2023, but selecting a performance level is not the same as validating the whole application (ISO).

This guide is an orientation map, not a certification decision or legal opinion. Standards adoption, regulatory effect, and conformity procedures vary by jurisdiction.

U.S. equipment authorization is a separate layer. The FCC’s July 2026 Covered List action addresses supply-chain and cybersecurity risk for a defined category of foreign-produced mobile robots. It does not replace machinery risk assessment or functional-safety evidence. Our FCC foreign-robot restrictions guide explains the device definition, existing-model boundary, Conditional Approval path, and software-update waiver.

The scope map

Robot application	Primary starting point	What the source covers	Boundary to keep visible
Industrial robot as a machine	ISO 10218-1:2025	Safety requirements for industrial robots	The robot alone is not the completed application or cell
Integrated industrial robot application or cell	ISO 10218-2:2025	Integration, commissioning, operation, maintenance, and decommissioning of industrial robot applications and cells	End effectors, workpieces, adjacent machinery, access, and tasks change the risk
Collaborative industrial robot application	ISO 10218:2025, with ISO/TS 15066 as an important reference	Human–robot collaboration and collaborative workspace considerations	“Collaborative robot” is not a stand-alone safety classification for the complete application
Driverless industrial truck / industrial AMR	ISO 3691-4:2023	Safety requirements and verification for driverless industrial trucks and their systems	Public-zone robots and non-truck mobile robots can fall outside this scope
Personal care robot	ISO 13482:2014	Inherently safe design, protective measures, and information for use for personal care robots	The 2014 scope has exclusions; a wider service-robot revision is still under development
Other service robot	Application-specific analysis plus the developing ISO 13482 revision	The final draft is titled “Safety requirements for service robots”	A draft is not a published replacement; requirements can change before publication
Any machinery system	ISO 12100:2010	General risk-assessment and risk-reduction principles	It is a foundation, not a robot-specific integration checklist
Safety-related control system	ISO 13849-1:2023	Design and integration principles for safety-related parts of control systems	Control reliability does not remove mechanical, ergonomic, operational, or cybersecurity hazards

A single system can require more than one row. A mobile manipulator in a factory may combine vehicle hazards, arm hazards, end-effector hazards, interaction with fixed machinery, and a collaborative operating mode. The correct question is not “Which one standard certifies this robot?” but “Which hazards and lifecycle activities does each applicable standard cover, and where are the gaps?”

What changed in ISO 10218:2025

ISO published the third edition of ISO 10218-1 in February 2025. Its official scope describes industrial robots as partly completed machinery and explicitly excludes several categories, including service robots accessible to the public, consumer products, medical applications, prosthetics, and other application classes (ISO). Those exclusions are not declarations that excluded robots are safe or unregulated. They mean this particular document is not the complete application standard for them.

The paired ISO 10218-2:2025 focuses on industrial robot applications and robot cells. That distinction is critical:

• Part 1 is centered on the robot manufacturer’s product.
• Part 2 is centered on the integrator’s completed application.
• The operator still needs site-specific procedures, training, inspection, maintenance, and change control.

ISO’s published 2025 text also explains that most requirements from ISO/TS 15066:2016 were incorporated into the ISO 10218 series because human–robot collaboration relates to the application, not the robot alone (ISO 10218-1, ISO 10218-2).

That change corrects a persistent market misconception: buying a product described as a “collaborative robot” does not make every tool, workpiece, speed, and task safe for unguarded human access.

Collaboration is an operating mode, not a sticker

A collaborative application permits a person and robot system to share a collaborative workspace under defined conditions. Its safety depends on the entire interaction.

Consider a low-force arm carrying a sharp sheet-metal part. The robot’s joints may limit force, yet the payload can create cutting, crushing, or trapping hazards. A soft gripper can still pick up a hot, heavy, fragile, or contaminated object. A safe arm can become part of an unsafe cell when mounted on a mobile base, positioned near a fixed structure, or programmed with a path that creates a pinch point.

A collaboration review should therefore include at least:

1. Task and intended use: what the system is designed to do, who can approach it, and under what conditions.
2. Foreseeable misuse: shortcuts, unexpected entry, payload changes, bypassed sensors, and recovery behavior.
3. Contact geometry: blunt or sharp surfaces, trapping points, tools, fixtures, workpieces, and nearby structures.
4. Motion envelope: speed, acceleration, payload, reach, mobile-base movement, and possible combined momentum.
5. Safety functions: monitored stop, speed or separation controls, force or power limits, emergency stop, and fault response as applicable.
6. Validation: evidence that each claimed safety function achieves its required behavior in the integrated system.
7. Lifecycle access: teaching, cleaning, jam clearing, tool change, maintenance, and decommissioning—not only normal automatic operation.

ISO/TS 15066 remains useful context for collaborative industrial robot systems and work environments, but a team should document the exact editions it applies. Silently combining a 2016 technical specification, a 2011 robot standard, and selected 2025 concepts can create an incoherent safety file.

Industrial AMRs: ISO 3691-4 has a specific lane

ISO 3691-4:2023 covers driverless industrial trucks and their systems. ISO’s scope notes that examples can be known as automated guided vehicles, autonomous mobile robots, bots, or automated guided carts (ISO). The label “AMR” alone is not enough; the machine still needs to meet the document’s definition and intended-use boundaries.

The standard’s published scope also distinguishes trucks intended for public zones. This matters when a warehouse vehicle moves into a hospital corridor, retail floor, airport, sidewalk, or home. A system designed for a controlled industrial site should not inherit a public-space safety claim merely because the navigation software is similar.

For a mobile manipulator, teams should examine both sides of the machine:

• vehicle stopping, stability, speed, route interaction, localization failure, and charging;
• arm reach, payload, grasp failure, dropped objects, pinching, and interaction with people or fixed equipment;
• combined hazards when the base and arm move together;
• safe behavior when perception, communications, maps, or task planning become uncertain.

A base that stops safely does not prove the arm is safe, and a validated arm stop does not prove the moving platform has adequate clearance.

Service robots and the ISO 13482 transition

The current published ISO 13482:2014 addresses personal care robots. ISO describes requirements and guidance for inherently safe design, protective measures, and information for use, especially for human–robot physical contact (ISO). ISO/TR 23482-2:2019 provides application guidance intended to help designers use ISO 13482 (ISO).

As of July 14, 2026, ISO lists a final draft titled ISO/FDIS 13482, Robotics — Safety requirements for service robots. ISO says it is under development and will replace the 2014 edition (ISO). That is a strong signal that the framework is broadening, but it is not permission to cite a draft as an already published requirement.

For a home humanoid, hospitality robot, mobile assistant, or public-facing service robot, record three separate facts:

• which published standard and edition the design currently uses;
• whether the developing revision is being monitored or contractually anticipated;
• which national rules, product requirements, accessibility duties, privacy obligations, or sector regulations also apply.

The closer a robot operates to children, older people, patients, untrained members of the public, or people who cannot easily move away, the less reasonable it is to borrow assumptions from a controlled industrial cell.

Where humanoids fit

“Humanoid” is a form factor, not a standards scope. Two visually similar robots can belong to different safety frameworks because one performs a bounded industrial task inside a controlled plant and the other performs chores in private homes.

Use this sequence:

1. Classify the application. Industrial production, industrial transport, logistics, personal care, public service, research, medical use, entertainment, or another category.
2. Define the operating environment. Restricted factory zone, shared aisle, customer facility, public space, home, lab, or construction site.
3. Map the complete system. Legs or wheels, arms, hands, tools, payloads, batteries, chargers, external controllers, fleet software, and connected machinery.
4. Identify exposed people. Trained operators, integrators, maintenance workers, visitors, customers, or household members.
5. Determine the applicable standards and laws. Use current editions adopted in the target jurisdiction and document exclusions.
6. Validate each bounded task and mode. Walking safely does not validate manipulation; a safe demo does not validate overnight operation.

A general-purpose marketing claim should never expand the safety case. Safety validation becomes more specific as the task, payload, and environment become concrete.

AI changes behavior, not the need for a safety case

Physical-AI systems can use learned perception, vision-language-action models, reinforcement learning, online adaptation, or large planners. These components may make behavior harder to predict, but they do not make risk assessment optional.

Separate three layers:

• Task intelligence: decides what action to attempt.
• Motion and control: translates the action into trajectories, forces, and actuator commands.
• Safety-related controls: enforce validated limits and move the system to a safe state when required.

A confidence score from a vision model is not automatically a safety function. A foundation model’s instruction-following benchmark does not establish diagnostic coverage, fault tolerance, stopping performance, or a required performance level. If a safety claim depends on learned behavior, the evidence should address the target environment, foreseeable distribution shifts, failure detection, fallback behavior, software updates, and validation after change.

At minimum, change control should answer:

• Does a new model or policy alter reachable space, speed, force, task selection, or recovery?
• Can an over-the-air update bypass a previously validated constraint?
• What regression tests cover safety-relevant scenarios and faults?
• Which model, configuration, dataset, and firmware version was validated?
• Who can approve deployment, roll back a release, and examine incident logs?

Treating a model update as “software only” is unsafe when that software changes physical behavior.

Risk assessment: the durable core

ISO 12100’s general approach is more durable than any product label: define limits, identify hazards, estimate and evaluate risk, then reduce risk. A practical hierarchy is:

1. Inherently safe design: remove the hazard or reduce energy, reach, sharpness, mass, speed, trapping geometry, or instability through design.
2. Safeguards and complementary protective measures: guards, protective devices, safety-related controls, monitored zones, stops, and other engineered protections.
3. Information for use: warnings, instructions, training, procedures, and personal protective equipment for residual risks.

Warnings should not substitute for a feasible design control. Likewise, a demonstration that the robot stopped once is not validation of stopping performance across payload, speed, floor condition, approach direction, sensor occlusion, and fault states.

The assessment should cover the full lifecycle:

• transport and installation;
• commissioning and teaching;
• automatic operation;
• human–robot collaboration;
• cleaning and sanitation;
• tool, payload, and battery changes;
• fault recovery and jam clearing;
• inspection and preventive maintenance;
• software and model updates;
• decommissioning and disposal.

Many serious exposures occur during non-routine work, when normal safeguards are altered or people enter a space to diagnose a problem.

What a credible safety evidence package contains

A buyer should not accept “ISO compliant” without scope, edition, and evidence. Ask for:

Evidence	Why it matters
Intended-use and reasonably foreseeable misuse statement	Defines what was actually assessed
Applicable standards list with edition years	Prevents vague or mixed-edition claims
Responsibility matrix	Separates robot-maker, integrator, end-effector supplier, operator, and site duties
Hazard analysis and risk-reduction record	Connects hazards to controls and residual risks
Safety requirement specification	Defines what each safety function must do
Architecture and component evidence	Shows how safety-related controls are implemented
Verification and validation reports	Tests the integrated system, not only individual components
Stopping and separation evidence	Supports workspace and access assumptions
Payload, tool, speed, surface, and environment limits	Keeps the claim bounded to tested conditions
Installation, operation, maintenance, and recovery instructions	Covers lifecycle work and residual risk
Training and competence requirements	Identifies who may teach, recover, modify, or maintain the system
Software/model version and update controls	Preserves validity when behavior changes
Incident, intervention, protective-stop, and fault logs	Reveals real operating conditions after commissioning
Declaration or certification documents, where applicable	Shows the claimed conformity route and its scope

Independent certification can be valuable, but it is not a substitute for reading the certificate’s scope, exclusions, configuration, and expiry or surveillance conditions.

Standards are not automatically law

ISO states that International Standards, technical specifications, publicly available specifications, international workshop agreements, and technical reports are voluntary and do not themselves include contractual, legal, or statutory requirements (ISO). A standard can still become commercially or legally significant when adopted into regulation, referenced by a regulator, incorporated into a contract, or used in a conformity-assessment scheme.

In the United States, OSHA’s robotics overview says there are currently no OSHA standards specific to the robotics industry, while directing readers to general requirements, consensus standards, and hazard-recognition resources (OSHA). OSHA’s technical manual discusses industrial robot system safety and references US consensus standards (OSHA). That does not mean robots are outside workplace-safety law; it means “the robot meets ISO 10218” and “the workplace satisfies every legal duty” are different claims.

For any purchase or deployment, identify:

• the country and sector;
• the manufacturer, importer, integrator, employer, and operator roles;
• applicable machinery, workplace, electrical, radio, battery, medical, consumer, accessibility, and data rules;
• the national or regional adoption of relevant standards;
• required declarations, technical files, inspections, or third-party assessment.

Do not copy a compliance statement from one market into another.

A practical review workflow

Before selecting a robot

1. Write the task and environment without naming a vendor.
2. Identify all people who may approach the system, including during faults and maintenance.
3. List payloads, tools, energy sources, surfaces, environmental conditions, and connected equipment.
4. Map likely standards by application and jurisdiction.
5. Put evidence requirements and change-control duties into the request for proposal.

Before site acceptance

1. Confirm the delivered configuration matches the assessed configuration.
2. Review the integration risk assessment and residual risks.
3. Witness safety-function validation under representative worst-case conditions.
4. Test access, stopping, restart prevention, fault recovery, and emergency procedures.
5. Confirm training, inspection, maintenance, backup, logging, and software-update processes.
6. Record open findings and prevent production use until acceptance criteria are met.

After deployment

1. Monitor protective stops, interventions, collisions, near misses, bypasses, and recovery work.
2. Reassess after task, payload, tool, layout, speed, staffing, model, firmware, or fleet-software changes.
3. Investigate repeated “nuisance” stops instead of weakening protections to improve throughput.
4. Audit whether real use still matches intended use.
5. Preserve the versions and evidence behind every safety-relevant change.

Red flags in robot safety claims

Be cautious when a supplier or buyer says:

• “The robot is collaborative, so no risk assessment is needed.”
• “It is force-limited, so every end effector is safe.”
• “The AI avoids people, so a safety-rated protective function is unnecessary.”
• “The base and arm are certified separately, so the mobile manipulator is certified.”
• “It meets ISO standards,” without listing documents, editions, configuration, or assessed scope.
• “The demo ran without an incident,” without trials, faults, interventions, or validation criteria.
• “The new model is only a software update,” when physical behavior changes.
• “The same approval applies worldwide.”

Each statement collapses a system-level question into a component or marketing label.

Bottom line

The safest way to navigate robot standards is to resist category shortcuts.

• Start with ISO 12100 for risk assessment and risk reduction.
• Use ISO 10218-1 and -2:2025 for industrial robots and integrated industrial applications.
• Treat collaboration as an application property, with current ISO 10218 requirements and ISO/TS 15066 context—not as an unguarded-use guarantee.
• Use ISO 3691-4:2023 for driverless industrial trucks that fall within its scope.
• Use the published ISO 13482:2014 framework for personal care robots while clearly tracking—but not prematurely claiming—the developing service-robot revision.
• Apply safety-related control standards such as ISO 13849-1 where the risk assessment requires them.
• Confirm the legal and conformity route in every target jurisdiction.

For emerging humanoids and physical-AI systems, the essential discipline is the same: bound the task, identify the hazards, engineer and validate the controls, disclose the residual risk, and reassess every change that can alter physical behavior.

Related Physical AI Guide resources

See What Is Physical AI? for the full perception-to-action stack, Humanoid Robots in 2026 for evidence-based commercial status, Embodied AI for the closed-loop system, and the glossary for autonomy, collaborative robots, pilots, teleoperation, and whole-body control. Our editorial policy explains how we distinguish primary evidence, uncertainty, and time-sensitive claims.

Frequently asked questions

Which safety standard applies to a humanoid robot?

There is no single answer based on body shape. The intended application and operating environment matter. An industrial humanoid integrated into a manufacturing application can fall within the ISO 10218 framework; a service robot accessible to the public may point toward ISO 13482 or its forthcoming revision; and a mobile material-handling function can also bring ISO 3691-4 or other application standards into scope. A competent risk assessment must determine the applicable requirements for the complete system and jurisdiction.

Does a collaborative robot make an application safe without guarding?

No. Collaboration describes an application in which people and robots can share a collaborative workspace under defined conditions. ISO 10218-2 treats collaboration at the application level. The robot, end effector, workpiece, speed, force, layout, foreseeable contact, and safety functions must be assessed together; a robot marketed as collaborative is not a complete safety case.

Is ISO/TS 15066 still relevant after ISO 10218:2025?

Yes as a reference, but the relationship changed. ISO states that most ISO/TS 15066 requirements were incorporated into the 2025 ISO 10218 series because collaboration concerns the application rather than the robot alone. Teams should use the current standards set adopted for their market and avoid mixing editions silently.

Does compliance with an ISO standard automatically satisfy the law?

No. ISO states that its standards and other deliverables are voluntary and do not themselves contain contractual, legal, or statutory requirements. Laws, regulations, adopted national standards, contracts, and conformity-assessment routes vary by market. Obtain qualified advice for the target jurisdiction.

What evidence should a robot supplier provide to a buyer?

Ask for the intended-use statement, risk assessment scope, applicable standards and editions, safety-function architecture and validation evidence, residual-risk documentation, installation constraints, operating and maintenance instructions, change-control process, incident and stop logs, and limits on payloads, tools, speeds, environments, and human access.