Robotics Startups and the Safety Standard Problem
When a robotics startup ships its first commercial unit into a hospital, a warehouse, or a hotel corridor, it does not get to choose which safety standards apply. It inherits all of them — and none of them fit cleanly.
ISO 10218 governs industrial robots. ISO/TS 15066 addresses collaborative robots operating near humans. ISO 13482 covers personal care robots. Each was written for a specific class of system in a specific deployment context. None of them was written for a mobile manipulator navigating a dynamic environment, responding to natural language instructions, and making real-time decisions using a learned model. That system — increasingly the target product for advanced robotics startups — exists in a gap between every applicable standard.
This is not a minor inconvenience. It shapes hiring decisions, product architecture, funding rounds, and customer procurement cycles. It determines which markets a startup can enter in year two versus year five. Understanding how engineers are actually navigating this problem is more useful than waiting for a single authoritative framework that may not arrive for years.
What the Existing Standards Actually Cover
ISO 10218-1 and 10218-2 define safety requirements for industrial robot manipulators and their integration into work cells. They assume a fixed installation, defined work envelopes, physical guarding, and human exclusion during operation. The core safety model is separation: keep people out, and the robot can operate freely within its rated parameters.
ISO/TS 15066, published as a technical specification rather than a full standard, extends collaborative operation to scenarios where robots and humans share space. It introduced four collaboration modes — safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting — and provided the first quantitative limits on contact forces and pressures. The biomechanical injury threshold data in Annex A remains the foundational reference for cobot designers.
ISO 13482 addresses “personal care robots” in three categories: physical assistant robots, mobile servant robots, and person carrier robots. It was developed with domestic and healthcare applications in mind. Unlike 10218, it explicitly anticipates human contact and addresses the problem of naive users — people who did not train on the system and may not understand its behavior.
Each standard addresses real hazards in its original context. The problem is that advanced robotics startups are building systems that combine characteristics from all three: they manipulate objects (10218 territory), they operate in close proximity to untrained humans (15066 territory), and they operate in unstructured environments serving non-expert users (13482 territory). The overlap is not just partial — it is total.
What the Patchwork Leaves Out
Three capability classes drive the gap between current standards and current products.
Mobile manipulation. A robot that moves through space and then reaches into that space to interact with objects is qualitatively different from a fixed arm or a mobile platform that only carries. The hazard analysis must account for the full kinematic envelope of the arm at every point in the robot’s path, through every configuration the mobile base might assume. Existing standards handle this poorly. ISO 10218’s work cell model does not translate to an environment where the work cell is moving. ISO 13482’s treatment of mobile platforms does not address high-payload manipulators mounted on them.
AI-driven behavior. When a robot’s actions are determined by a learned policy rather than a deterministic program, the traditional safety verification model breaks down. You cannot enumerate the input space. You cannot formally verify that the system will never enter a hazardous state. ISO 10218 assumes validated software with defined behavior. ISO/TS 15066’s speed and separation monitoring assumes a speed controller with predictable outputs. Neither standard provides guidance on validating ML components, handling distribution shift, or defining acceptable degradation modes for learned systems.
Novel deployment environments. A warehouse is not a hospital corridor is not a hotel lobby. Existing standards were validated against specific environments. The hazard classes differ. The human population differs — workers, patients, guests. The regulatory context differs. Applying a standard written for manufacturing automation to a robot operating among elderly residents of an assisted living facility requires interpretive leaps that create certification risk on both sides.
How Startups Are Actually Responding
Engineering teams at advanced robotics startups are not waiting for a unified standard. They are making architectural decisions today that satisfy multiple frameworks simultaneously, accepting capability constraints in exchange for certification clarity.
The most common strategy is conservative parameterization across the union of applicable limits. If ISO/TS 15066 specifies a maximum contact force of 65N for a particular body region and an internal design target suggests 80N would be mechanically achievable, the team ships at 65N. If ISO 13482 specifies a maximum approach speed for mobile platforms and ISO 10218’s equivalent guidance suggests a lower threshold, the product ships at the lower value. This sounds straightforward, but applied across a full safety case — forces, speeds, torques, stopping distances, contact areas — it adds up to a product that operates at significantly reduced capability compared to its hardware limits.
A second strategy is architectural decomposition: separating the AI reasoning layer from the safety-critical execution layer and applying different validation standards to each. The learned policy generates high-level actions. A deterministic safety monitor, independently verified to IEC 61508 or ISO 13849, evaluates those actions against a set of formal constraints before execution. If the action violates a constraint, the monitor overrides it. This approach preserves the ability to use learned systems while keeping the safety-critical path within reach of existing verification methods. It also maps reasonably well onto the functional safety frameworks customers and notified bodies already understand.
A third strategy, used by teams targeting medical or regulated environments, is explicit over-compliance documentation. Rather than claiming conformance to the most applicable standard and hoping the rest is covered, they document which requirements from each applicable standard they have addressed, how they have addressed them, and where they have gone beyond requirements. This creates a traceable safety case that can withstand scrutiny from procurement engineers at hospital systems or from Underwriters Laboratories assessors who have not yet developed product-specific guidance for mobile manipulators.
What Standard Bodies Are Working On
The gap is not invisible to the bodies that write standards. ISO Technical Committee 184, Subcommittee 2 — which owns the 10218 series — completed a revision of ISO 10218-1 in 2021 that introduced new language around collaborative operation and began addressing mobile platforms, but stopped short of the AI behavior problem. A working group within TC 184/SC 2 is developing guidance on functional safety requirements for AI and autonomous systems in industrial robotics, with a publication target in the 2027–2028 timeframe.
IEC Technical Committee 62A, which handles safety of medical electrical equipment, is working on amendments to IEC 62443 (industrial automation cybersecurity) and developing new guidance on AI in medical devices that intersects with robotic surgical and rehabilitation systems. The intersection with ISO 13482 for healthcare robotics remains institutionally unresolved.
At the international level, ISO/IEC JTC 1/SC 42 — the joint subcommittee on artificial intelligence — has published ISO/IEC 42001 on AI management systems and is developing framework documents on AI risk that are intended to be sector-neutral. Whether robotics-specific applications will reference SC 42 outputs directly or develop parallel guidance through TC 184 is an open question that several national body delegations are actively debating.
Engineers at robotics startups who have participated in these working groups describe the timeline with consistent frustration. Consensus processes at this level routinely take five to seven years from problem identification to published standard. A startup founded today will likely exit or reach Series C before the applicable standards fully catch up to its product.
What a Purpose-Built Standard Would Need to Cover
Robotics engineers and safety practitioners working at the frontier of this problem have a reasonably consistent view of what adequate guidance would require.
A hazard taxonomy that includes behavioral hazards. Current standards focus on physical hazards — contact forces, pinch points, tip-over loads. A standard for AI-driven robots needs a structured way to classify hazards that arise from behavioral failures: the robot does the wrong thing at the wrong time in a way that was not anticipated in design. This requires methods for characterizing the operating domain, identifying out-of-distribution conditions, and specifying acceptable behavior degradation.
Validation methods for learned components. This does not require solving the general AI alignment problem. It requires, at minimum, standardized approaches for: defining the operational design domain (borrowing from automotive autonomy work), specifying minimum performance thresholds in domain, specifying fallback behavior at domain boundaries, and documenting training data provenance and known limitations. ISO/PAS 21448 (SOTIF — Safety of the Intended Functionality), developed for automotive autonomy, provides a useful structural template even if its specific requirements do not transfer directly.
Environment-class-specific annexes. Rather than a single universal standard, a modular architecture with normative annexes for specific deployment environments — industrial, healthcare, public-access commercial, domestic — would let teams apply requirements appropriate to their actual context without having to interpret requirements written for a different one.
Explicit treatment of the human-robot interaction interface. How does a robot communicate its intent? How does a user override its behavior? What information must be available to a naive user versus a trained operator? ISO 13482 gestures at this but does not provide actionable requirements. A purpose-built standard needs to treat HRI as a safety-critical system component with its own requirements and verification methods.
The Traceability Imperative
One practical implication of operating under an incomplete standard landscape: the teams that will be best positioned when next-generation standards arrive are the ones building rigorous traceability now.
A startup that can demonstrate a complete chain from hazard identification through risk assessment, design decision, verification method, and test result — for every applicable requirement across every applicable standard — has built something valuable independent of which standard eventually governs their product. Notified bodies assessing novel products in the absence of clear standards invariably ask for exactly this kind of documentation. Procurement engineers at regulated-industry customers ask for it too.
The practical challenge is that maintaining this traceability manually, across multiple evolving standards and a fast-moving product, is expensive. Teams using modern requirements management tools that support graph-based traceability — linking requirements to hazards, design artifacts to requirements, and test evidence to design artifacts — carry substantially lower documentation overhead than teams working in spreadsheets or static documents. Flow Engineering, designed specifically for hardware and systems teams, implements this kind of connected traceability natively, which matters in environments where the applicable standard set is itself a moving target.
Honest Assessment
The safety standard gap for advanced robotics is real, not manufactured. The existing frameworks cover real hazards in their original contexts well. They do not cover the class of systems now entering the market.
Startups navigating this environment are making pragmatic, defensible choices: conservative parameterization, architectural decomposition, over-compliance documentation. These choices work. They come with capability costs and timeline costs, and they require engineering discipline that some teams underestimate.
The standard bodies working on next-generation guidance are doing real work, but the timelines are long and the institutional coordination problems are genuine. A unified, purpose-built robotics safety standard that addresses mobile manipulation, AI behavior, and diverse deployment environments is not coming in the next two years.
Teams that accept this reality and build their safety cases accordingly — documenting assumptions, maintaining traceability, and designing for defensible conservatism — are the ones that will survive regulatory scrutiny when it arrives. The patchwork is the environment. Building well inside it is the job.