Collaborative removes the cage, not the hazard
A cobot is safe only when its speed-and-separation monitoring or power-and-force limits are validated for the specific task, payload, and tooling in front of it, not because the machine is sold under the label collaborative.
Collaborative is a mode, not a machine
The most useful thing an EHS director can know about collaborative robots is that collaborative describes how a robot is operated, not a category of inherently safe hardware. The governing standards make this explicit. ISO 10218 and the supporting technical specification ISO/TS 15066 (now folded into ISO 10218-2:2025, and adopted in the United States through the ANSI/A3 R15.06 series) set out four collaborative operating methods: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting. A robot is only collaborative while it is genuinely running in one of those modes, within limits validated for the actual job.
This matters because a common failure of reasoning is category thinking: the robot was purchased as a cobot, therefore it is safe to work beside, therefore the guarding comes down. None of those therefores hold. The same arm that is safe carrying a rounded plastic part at low speed becomes a hazard the moment it holds a sharp deburred casting, moves faster to hit a cycle time, or reaches toward a pinch point against a fixture. The label did not change. The physics did.
Where safety actually lives
Take the two most common shared-space methods. Speed and separation monitoring keeps a protective distance between person and robot and slows or stops the robot as that distance closes. Its safety depends on sensing that actually covers the approach paths, and on stopping distances calculated for the real speed and payload. Power and force limiting takes a different route: it caps how hard the robot can contact a person. ISO/TS 15066 provides the basis for that cap in the form of biomechanical limits, body-region-specific thresholds for permissible contact force and pressure, and it distinguishes transient (brief) contact from quasi-static (clamping) contact, which is the more dangerous case because the person cannot pull away.
Two things follow that marketing rarely foregrounds. First, those limits are defined per body region and per contact type, so under the limit is not a single number the robot satisfies once. It depends on where on the body contact could occur and whether the person could be pinned. Second, and this is the point that undoes category thinking entirely: the limits apply to the whole application, not the bare arm. The end-effector, the workpiece, the speed, and the cell layout are all part of the contact. A gripper holding a sharp edge concentrates force into a small area, and pressure, force over area, is what breaks skin. The robot can be nominally within force limits while the part in its hand is not.
The task is the unit of safety, not the robot
This is why the standards center on a documented risk assessment of the application before a fenceless cell runs. The assessment maps every point on the robot’s path where contact with a person is possible, and it includes the tool and the part, not just the manipulator. It estimates the risk at those points and confirms that the chosen collaborative method, with whatever additional measures are needed, brings it to an acceptable level. Change the payload, the tooling, the speed, or the layout, and you have a different application that has not yet been assessed.
The forward-looking read is genuinely optimistic: validated speed-and-separation and power-and-force limiting are letting humans and machines share space productively in ways that were unthinkable a decade ago. The caution is narrow and specific. The safety case is task-specific and perishable. It is created by validation for this job and destroyed by any uncontrolled change to it.
Before you invest
Before any guarding comes down, ask: for this exact task, at this speed, with this tool and this part, does a current, documented risk assessment show that the collaborative method holds contact within the ISO/TS 15066 biomechanical limits for every body region a person could reach? If the justification is that it is a collaborative robot rather than a validation of this application, you are relying on a purchasing category to do the work of an engineering assessment. And ask the second half: what change control catches the day someone swaps the gripper or raises the speed and quietly voids the assessment?
Cobots are a real advance, and the standards to deploy them well already exist. But collaborative is a claim about a validated task, not a promise stamped on the hardware. Remove the cage only after the specific application has earned it.