Chmltech

Home / Insights / Chmltech Online Journal

Chmltech Online JournalVolume 105, Issue 3Research article

Safety, Reliability and Economics of Deploying Physical AI

Quak Foo LeeChief Technology Officer, Chmltech Ltd.Division of Artificial Intelligence and Machine Learning · Vancouver, BC, Canada

Published November 9, 202616 min read

Abstract

Learned robot policies are now capable enough to be considered for industrial use, but capability does not establish that a system is safe, dependable or economic. This paper addresses those three questions for organizations deciding whether to deploy physical AI. It reviews the physical hazards of robots and the failure modes particular to learned components, including distribution shift, objective misspecification and the weaknesses of human supervision. It summarizes functional safety standards, the ISO 10218 robot safety standards and guidance on collaborative operation, and the European Union's Machinery Regulation and Artificial Intelligence Act as amended in 2026. A comparison of required safety integrity with observed task failure rates shows that a learned policy cannot be the component on which safety depends. The paper then describes the architecture that follows from this: a learned performance channel enclosed by a conventional safety-rated layer, with safety filters and separation monitoring. Reliability is treated quantitatively, covering the compounding of step failures, the number of failure-free trials needed to demonstrate a failure rate, and availability and intervention in service. A cost model relates net benefit to operating hours, availability and intervention, and a worked example shows a payback of 2.5 years becoming a loss at lower reliability or utilization. The paper concludes with a deployment framework that is conservative about safety and empirical about value.

Keywords: physical AI; robot safety; functional safety; ISO 10218; reliability; human–robot collaboration; automation economics; EU Machinery Regulation

1. Introduction

Industrial robots have a long safety record built on a simple principle: the robot's motion is programmed and predictable, and people are separated from it by guards and interlocks. More than 4.6 million industrial robots were in operation worldwide in 2024 [1], most of them under that principle. Physical AI changes both of its premises. A learned policy is not programmed line by line, and its behavior on an input unlike its training data cannot be fully predicted. At the same time, the applications that motivate learning, such as mobile inspection, the handling of varied objects and work alongside people, take the machine out of the guarded cell.

The capabilities of these systems have advanced quickly, but capability and dependability are different properties. The authors of a leading open vision-language-action model report success rates typically below 90% on the tasks they tested [2], whereas safety functions on machinery are specified in terms of dangerous failures per hour that are many orders of magnitude lower. An organization deciding whether to deploy physical AI must therefore answer three questions that a demonstration does not answer. Is it safe, and can that be shown to the standard that regulation requires? Is it reliable enough to be useful? And does it pay?

This paper addresses those questions in order. Section 2 reviews hazards and the failure modes particular to learned systems. Section 3 summarizes the standards and regulations that apply. Section 4 describes the safety architecture by which a learned component can be used without being relied upon for safety. Section 5 treats reliability: how it compounds, how much testing is needed to demonstrate it, and how it is measured in operation. Section 6 develops a cost model with a worked example, and Section 7 sets out a deployment framework.

2. Hazards and Failure Modes

2.1 Physical hazards

The physical hazards of a robot are those of any powered machine: impact, crushing, shearing and entanglement, together with hazards from the tool or the payload. Haddadin and co-authors measured robot–human impacts experimentally and showed that injury severity depends strongly on whether the body part is free to recoil or is clamped against a fixed surface, and that severity indices borrowed from automotive crash testing transfer poorly to robots [3]. Clamping and contact with sharp tooling are therefore the cases that dominate risk assessment for close human–robot work. Surveys of human–robot collaboration in industry treat safety as the precondition for the other benefits of collaboration and review the sensing and control methods used to obtain it [4]. A mobile robot adds collision with people and vehicles in shared routes, and, in process plants, the possibility of striking equipment or becoming an ignition source.

2.2 Failure modes of learned components

Learned components fail in ways that conventional software does not. Amodei and co-authors identified five classes of problem: negative side effects, where the system achieves its objective by a route that damages something the objective did not mention; reward hacking, where it exploits a flaw in the objective; limited oversight, where correct behavior is too costly to check often; unsafe exploration; and lack of robustness to distributional shift [5]. The last is the most important in deployment. A policy trained on one set of objects, lighting conditions and layouts may act confidently and wrongly when these change, and nothing inside the policy signals that it has left familiar territory. Sinha and co-authors argue that the problem must be handled at system level, by detecting such inputs at run time and switching to a fallback, because no training procedure removes it [6].

2.3 The system view

Leveson's systems approach treats safety as a control problem: accidents arise not only from component failures but from unsafe interactions among components that each work as designed, and from inadequate enforcement of safety constraints [7]. The view suits physical AI, where the learned policy, the supervising person, the safety controller and the surrounding plant interact. Human supervision in particular cannot be assumed to be a reliable barrier. Bainbridge observed that automating a task leaves the operator to monitor for rare events and to take over in the most difficult situations, which are the tasks for which a person who is out of the loop is least prepared [8]. Parasuraman and co-authors proposed that the type and level of automation be chosen deliberately for each function, with human performance consequences as a primary criterion [9]. Table 1 lists the principal failure modes with their mitigations.

Table 1. Failure modes of physical AI systems and corresponding mitigations.
Failure modeExampleMitigation
Distribution shiftNew packaging or lighting causes a wrong grasp or pathRun-time monitoring, defined operating domain, fallback behavior [6]
Objective misspecificationRobot meets its cycle-time target by moving unsafely fastHard limits outside the learned policy; review of reward and demonstrations [5]
Compounding errorSmall deviations accumulate over a long taskShorter task segments, recovery behaviors, checkpoints (Section 5.1)
Perception failurePerson or obstacle not detectedIndependent safety-rated sensing for protective functions [10]
Unsafe interactionComponents each behave as designed but the combination is hazardousSystem-level hazard analysis [7]
Supervisor out of the loopOperator misses a rare event or takes over poorlyDesign of the human role; alarms and handover [8, 9]
Model updateRetrained model behaves differently in an untested caseChange control and revalidation (Section 7)

3. Standards and Regulation

3.1 Functional safety

Functional safety standards specify how reliable a safety function must be and how that reliability is to be achieved and shown. IEC 61508 defines safety integrity levels (SIL) for electrical, electronic and programmable systems; for a function operating continuously, SIL 2 corresponds to an average frequency of dangerous failure between 10−7 and 10−6 per hour [11]. ISO 13849-1 applies the same idea to machinery through performance levels (PL), and PL d covers the same band [10]. Protective functions on industrial robots, such as protective stops and speed and position limits, are typically required to reach this level. A dangerous failure rate below 10−6 per hour means less than one such failure in about 114 years of continuous operation. Both standards obtain this integrity through architecture, diagnostics and a systematic development process, and both presume that the behavior of the safety function can be specified and verified.

3.2 Robot standards

ISO 10218 is the principal safety standard for industrial robots. Part 1 addresses the robot as supplied by its manufacturer and Part 2 addresses robot applications and cells as built by the integrator; revised editions of both parts were published in 2025 [12, 13]. ISO/TS 15066 gives guidance for collaborative operation, in which people and robots share a workspace. It describes four methods: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting, the last with limits on contact force and pressure for different regions of the body [14]. None of these documents prohibits learned control. They require that the safety functions meet their specified integrity whatever the rest of the control system does.

3.3 Regulation

In the European Union, Regulation (EU) 2023/1230 on machinery replaces the Machinery Directive and applies from 20 January 2027. It addresses software and autonomous machinery explicitly, and it places safety components with self-evolving behavior that use machine learning among the products requiring conformity assessment by a third party [15]. The Artificial Intelligence Act establishes a risk-based framework in which an AI system that is a safety component of a product covered by harmonized legislation, including machinery, is classed as high-risk [16]. Because both instruments could apply to the same machine, an amending regulation adopted in July 2026 reorganized their relationship [17]. According to one analysis, the main technical requirements for high-risk AI in machinery are to be incorporated into the machinery framework by a delegated act due by August 2028, and the practical effect will depend on the content of that act [18]. Requirements in this area are therefore still settling, and manufacturers and users should confirm the current position for their jurisdiction.

Outside binding regulation, the AI Risk Management Framework of the U.S. National Institute of Standards and Technology organizes the management of AI risk under four functions, govern, map, measure and manage, and is widely used as a voluntary reference [19].

3.4 The verification gap

The difficulty is now apparent. A safety function must be shown to fail dangerously less often than once in a million hours. A learned policy that completes 99.9% of its tasks correctly, at 60 tasks per hour, fails about once in 17 hours. Not every task failure is dangerous, but the comparison shows that a learned policy cannot at present be the component on which safety depends: its failure rate is too high by several orders of magnitude, and its behavior cannot be specified completely enough to verify. The practical consequence is architectural.

4. Safety Architecture for Learned Components

4.1 Separation of performance and safety

The established answer is to separate the system into a performance channel and a safety channel. Sha described the pattern for control software as using simplicity to control complexity: a complex, high-performance controller is allowed to operate only while a simple, verifiable monitor confirms that the system remains within a region from which a simple, verified controller can always recover it [20]. Applied to physical AI, the learned policy proposes actions; a safety-rated layer, built and certified by conventional means, limits speed, force and workspace, monitors separation from people, and commands a protective stop when a limit is approached. The learned policy can then be changed or retrained without reopening the safety case, provided the safety layer and its assumptions are unchanged. Figure 1 shows the arrangement.

Block diagram. Cameras and joint sensors feed a learned policy labeled performance channel, which sends a proposed action into a safety-rated layer. Inside that layer a safety filter limiting speed, force, workspace and separation passes a safe action to the drives and actuators, and safety-rated sensing such as scanners, light curtains and emergency stop feeds the filter and can command a protective stop directly. Below the policy, a run-time monitor for unfamiliar input and low confidence exchanges signals with the policy and asks a supervisor for help. Safety-rated layer conventional, verified, PL d Safety filter speed · force workspace · separation Eqs. (1)–(2) Safety-rated sensing scanners light curtains · e-stop Cameras joint sensors Learned policy (performance channel) proposed action Drives and actuators safe action protective stop Run-time monitor unfamiliar input, low confidence Supervisor (asked for help) Improves task success and availability; not part of the safety function
Figure 1. Safety architecture for a learned component. The learned policy proposes actions in a performance channel; a conventional safety-rated layer filters them and can command a protective stop from its own sensing. A run-time monitor that detects unfamiliar inputs or low confidence improves task success but is not part of the safety function. Drawn by the author, after [14, 20, 21].

4.2 Safety filters

A safety filter makes the separation precise. Let the safe set be the states x for which a function h(x) is non-negative. A control barrier function condition requires every applied action u to satisfy

dh(x, u)/dt ≥ −α(h(x))(1)

where α is an increasing function with α(0) = 0. The condition allows h to decrease only as fast as the remaining margin permits, so that a state inside the safe set stays inside it. The filter passes the action proposed by the policy if it satisfies Eq. (1) and otherwise replaces it with the closest action that does, found by solving a small optimization problem at each step [21]. Reviews of safe learning in robotics place such filters among the methods that give formal assurances, while noting that the assurances depend on the accuracy of the dynamic model used to evaluate the condition [22].

4.3 Separation monitoring

For work near people, speed and separation monitoring applies the same logic to distance. The robot must stop before a person can reach it, so the protective separation distance is

Sp = vh(Tr + Ts) + vrTr + Ss + C + Z(2)

where vh and vr are the speeds of the person and the robot toward each other, Tr is the reaction time of the sensing and control system, Ts and Ss are the robot's stopping time and stopping distance, C is an allowance for intrusion before detection and Z covers position uncertainty [14]. As an illustration, with vh = 1.6 m s−1, vr = 1.0 m s−1, Tr = 0.1 s, Ts = 0.3 s, Ss = 0.15 m and C + Z = 0.20 m, the required distance is 0.64 + 0.10 + 0.15 + 0.20 = 1.09 m. The equation shows what a learned policy can and cannot influence: it may choose the path and the speed, but the distance at which the robot must slow or stop is fixed by measured stopping performance and by safety-rated sensing.

4.4 Knowing when to ask

A complementary measure is to have the learned component recognize its own uncertainty. Ren and co-authors used conformal prediction to calibrate a language-model planner so that the robot requests human help when its confidence is insufficient, with a statistical assurance on the task success rate and with fewer requests than simpler rules [23]. Run-time monitors that detect inputs unlike the training data serve the same purpose for perception and control [6]. These measures reduce task failures and unnecessary stops. They improve performance and availability, but because they are themselves learned or statistical, they supplement the safety layer and do not replace it.

5. Reliability

5.1 Compounding over steps

A task that consists of n steps, each of which succeeds independently with probability p, is completed with probability

Ptask = pn(3)

At p = 0.99, a 10-step task succeeds 90% of the time and a 50-step task only 61% of the time; at p = 0.999 the 50-step task succeeds 95% of the time. Long tasks therefore demand per-step reliability far above what short demonstrations reveal. The remedies are to shorten the chain, by dividing work into segments with checks between them, and to add recovery behaviors so that a failed step is retried instead of ending the task. Figure 2 plots Eq. (3) for three values of p.

Line chart of task success probability against number of steps from 1 to 100. With per-step success of 0.999 the curve falls slowly to about 0.90 at 100 steps and is marked 0.95 at 50 steps. With 0.99 it is marked 0.90 at 10 steps and 0.61 at 50 steps and falls to 0.37 at 100 steps. With 0.95 it falls below 0.1 by 50 steps. 0 20 40 60 80 100 N u m b e r   o f   s t e p s   i n   t h e   t a s k ,   n 0.0 0.2 0.4 0.6 0.8 1.0 P r o b a b i l i t y   t h e   t a s k   s u c c e e d s ,   P t a s k 0.90 0.61 0.95 Success probability per step p   =   0 . 9 9 9 p   =   0 . 9 9 p   =   0 . 9 5
Figure 2. Probability that a task of n independent steps succeeds, Eq. (3), for three per-step success probabilities. The marked points are the values quoted in the text. Author's calculation from Eq. (3).

5.2 How much testing demonstrates reliability

If N independent trials are run without a failure, the number needed to claim with confidence C that the true failure probability is no greater than p0 is

N ≥ ln(1 − C) / ln(1 − p0) ≈ 3 / p0 for C = 0.95(4)

The approximation is the rule of three: after N failure-free trials, the upper 95% confidence bound on the failure probability is about 3/N [24]. To support a claim of no more than one failure in 1,000 cycles, about 3,000 consecutive failure-free cycles are needed; for one in 100,000, about 300,000. Kalra and Paddock applied the same reasoning to automated vehicles and found that 275 million failure-free miles would be required to show, with 95% confidence, a fatality rate no higher than that of human drivers [25]. Koopman and Wagner concluded that testing alone is not a feasible way to assure systems based on machine learning, and that it must be combined with architectural measures such as a simple monitor that bounds the behavior of the complex function [26]. For physical AI the implication is the same. Task reliability at the level of one failure in a thousand can be demonstrated by testing; safety integrity cannot, and has to come from the architecture of Section 4.

5.3 Reliability in operation

In service, the relevant measures are availability and the rate of human intervention. Steady-state availability is

A = MTBF / (MTBF + MTTR)(5)

where MTBF is the mean time between failures that stop the system and MTTR is the mean time to restore it. Availability is one of the three factors of overall equipment effectiveness, with performance rate and quality rate, by which production equipment is commonly assessed [27]. For a learned system, many stoppages are not breakdowns but requests for help: a dropped part, an unrecognized object, a blocked path. Each is cleared by a person, locally or remotely. The fraction of a person's time consumed per hour of robot operation, here called the intervention fraction f, is the quantity that most directly links reliability to economics, and it should be measured during any trial.

6. Economics

6.1 Cost structure

The investment in a physical AI system comprises the machine, its integration into the site, the safety system and its validation, and commissioning and training. Integration and safety together can be comparable to the cost of the robot itself. Annual costs comprise maintenance and spare parts, software licenses or subscriptions, energy, and the labor of supervision and intervention. A further recurring cost is particular to learned systems: data collection, retraining and revalidation whenever products, layouts or tasks change.

6.2 A simple model

For a system that substitutes for labor at an hourly cost cL, the annual net benefit is

B = H A cL (1 − f) − M(6)

where H is the scheduled operating time per year, A the availability of Eq. (5), f the intervention fraction and M the annual cost of maintenance and software. The simple payback time is the investment I divided by B, and the net present value over a life of n years at discount rate i is [28]

NPV = −I + B [1 − (1 + i)−n] / i(7)

Equation (6) omits benefits that are real but site-specific, such as avoided injuries, improved quality, and the value of inspection data, and it should be extended with them where they can be estimated. Its purpose here is to show the structure: the benefit is proportional to operating hours and to availability, and it is eroded directly by intervention.

6.3 Worked example

Table 2 applies the model to a hypothetical mobile manipulation cell that tends machines in place of one operator per shift. All inputs are illustrative. In the base case, on two shifts with 90% availability and an intervention fraction of 0.10, the annual net benefit is 99,600 USD, the payback time is 2.5 years, and the NPV over seven years at 10% is about 235,000 USD. If availability falls to 70% and the intervention fraction rises to 0.30, values that are plausible for an immature system, the benefit falls to 48,400 USD, the payback lengthens to 5.2 years and the NPV becomes negative. On a single shift, even with the base-case reliability, the benefit is 34,800 USD and the NPV is about −81,000 USD.

Table 2. Worked example: hypothetical mobile manipulation cell (illustrative inputs; USD).
QuantityBase caseLow reliabilitySingle shift
Investment I250,000250,000250,000
Scheduled hours H (h per year)4,0004,0002,000
Availability A0.900.700.90
Intervention fraction f0.100.300.10
Labor cost cL (per hour)404040
Maintenance and software M (per year)30,00030,00030,000
Annual net benefit B, Eq. (6)99,60048,40034,800
Simple payback (years)2.55.27.2
NPV, 7 years at 10%, Eq. (7)234,900−14,400−80,600

Author's calculation. Scheduled hours assume 250 days per year and 8 hours per shift.

Two conclusions follow. Utilization dominates: the same machine that repays its cost in two and a half years on two shifts does not repay it at all on one. And reliability is an economic variable as much as a technical one, since availability and intervention together moved the result from clearly positive to negative. A vendor's quoted cycle time says little about either. Figure 3 shows the dependence of NPV on the intervention fraction for different shift patterns.

Line chart of net present value in thousand US dollars against intervention fraction from 0 to 0.5. Four straight lines slope downward: three shifts at 0.90 availability is highest and stays positive; two shifts at 0.90 availability crosses zero near 0.43; two shifts at 0.70 availability crosses zero near 0.27; one shift at 0.90 availability is negative throughout. Marked points: base case plus 235, low reliability minus 14, single shift minus 81. 0.0 0.1 0.2 0.3 0.4 0.5 I n t e r v e n t i o n   f r a c t i o n     ( p e r s o n - h o u r s   p e r   r o b o t - h o u r ) f −200 −100 0 100 200 300 400 500 600 NPV, 7 years at 10% (thousand USD) Base case +235 Low reliability: −14 Single shift: −81 Three shifts, A = 0.90 Two shifts, A = 0.90 Two shifts, A = 0.70 One shift, A = 0.90
Figure 3. Net present value of the hypothetical cell of Table 2 against intervention fraction, from Eqs. (6) and (7), for one, two and three shifts at 90% availability and for two shifts at 70% availability. The marked points are the three cases of Table 2. Author's calculation from Eqs. (6) and (7) with the inputs of Table 2.

6.4 Evidence at the level of the economy

Studies of conventional industrial robots give context. Graetz and Michaels, using data for 17 countries from 1993 to 2007, estimated that increased robot use raised annual labor productivity growth by about 0.36 percentage points [29]. Acemoglu and Restrepo, studying local labor markets in the United States, estimated that one additional robot per thousand workers reduced the employment-to-population ratio by 0.2 percentage points and wages by 0.42% [30]. These results concern programmed robots in earlier decades and need not carry over to learned systems, but they indicate that productivity gains are measurable and that effects on employment are a legitimate concern in planning a deployment.

7. A Deployment Framework

The preceding sections suggest the following sequence for an organization introducing a physical AI system.

  1. Define the operating domain: the objects, areas, lighting, speeds and presence of people for which the system is intended, and what it must do outside that domain.
  2. Carry out a system-level hazard analysis that includes the learned policy, the safety layer, the supervising person and the surrounding process [7].
  3. Assign every safety function to a conventional, safety-rated layer with a specified performance level, and confirm that no protective function depends on the learned policy [10, 13].
  4. Set quantitative reliability targets for the task, and derive the number of failure-free trials needed to demonstrate them from Eq. (4).
  5. Run the system in a supervised trial, record availability and the intervention fraction, and evaluate Eq. (6) with measured values before committing to scale.
  6. Design the human role explicitly, including training, alarm presentation and handover, so that supervision is a workable task [8].
  7. Place model updates under change control. A retrained model is a modification: repeat the reliability tests, and confirm that the assumptions of the safety layer still hold.
  8. Monitor in service for distribution shift and for trends in intervention rate, and define the conditions under which the system reverts to manual operation [6].

The framework is deliberately conservative about safety and empirical about value. It treats the learned component as a source of performance that may be improved continually, inside a safety envelope that changes rarely and only with full verification.

8. Conclusion

Physical AI can be deployed safely with present technology, but not by trusting the learned policy. Safety functions on machinery are specified at dangerous failure rates below one in a million hours and must be verifiable; learned policies fail far more often and cannot be verified to that level, nor can testing alone demonstrate such rates. The workable architecture keeps the learned policy in a performance role and assigns protection to a conventional safety-rated layer of limits, monitoring and protective stops. Regulation in the European Union is moving to address machine learning in machinery explicitly, and its details were still being settled in 2026. Reliability is the link between the technical and the economic questions. It compounds over the steps of a task, it can be demonstrated statistically only to modest levels, and through availability and the intervention fraction it determines whether an installation pays. The worked example showed a payback of two and a half years turning into a loss with lower reliability or lower utilization. Organizations should therefore define the operating domain, separate safety from performance, measure availability and intervention in a supervised trial, and decide on the basis of those measurements.

References

  1. International Federation of Robotics. (2025, September 25). Global robot demand in factories doubles over 10 years: World Robotics 2025 report – Industrial robots [Press release]. IFR, Frankfurt. ifr.org/ifr-press-releases/news/global-robot-demand-in-factories-doubles-over-10
  2. Kim, M. J., Pertsch, K., Karamcheti, S., Xiao, T., Balakrishna, A., Nair, S., Rafailov, R., Foster, E., Lam, G., Sanketi, P., et al. (2024). OpenVLA: An open-source vision-language-action model. arXiv preprint arXiv:2406.09246. arxiv.org/abs/2406.09246
  3. Haddadin, S., Albu-Schäffer, A., & Hirzinger, G. (2009). Requirements for safe robots: Measurements, analysis and new insights. The International Journal of Robotics Research, 28(11–12), 1507–1527. 10.1177/0278364909343970
  4. Villani, V., Pini, F., Leali, F., & Secchi, C. (2018). Survey on human–robot collaboration in industrial settings: Safety, intuitive interfaces and applications. Mechatronics, 55, 248–266. 10.1016/j.mechatronics.2018.02.009
  5. Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., & Mané, D. (2016). Concrete problems in AI safety. arXiv preprint arXiv:1606.06565. arxiv.org/abs/1606.06565
  6. Sinha, R., Sharma, A., Banerjee, S., Lew, T., Luo, R., Richards, S. M., Sun, Y., Schmerling, E., & Pavone, M. (2022). A system-level view on out-of-distribution data in robotics. arXiv preprint arXiv:2212.14020. arxiv.org/abs/2212.14020
  7. Leveson, N. G. (2012). Engineering a Safer World: Systems Thinking Applied to Safety. The MIT Press. 10.7551/mitpress/8179.001.0001
  8. Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. 10.1016/0005-1098(83)90046-8
  9. Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics – Part A: Systems and Humans, 30(3), 286–297. 10.1109/3468.844354
  10. International Organization for Standardization. (2023). ISO 13849-1:2023 Safety of machinery – Safety-related parts of control systems – Part 1: General principles for design (4th ed.). ISO, Geneva. www.iso.org/standard/73481.html
  11. International Electrotechnical Commission. (2010). IEC 61508-1:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements (2nd ed.). IEC, Geneva. webstore.iec.ch/en/publication/5515
  12. International Organization for Standardization. (2025). ISO 10218-1:2025 Robotics – Safety requirements – Part 1: Industrial robots (3rd ed.). ISO, Geneva. www.iso.org/standard/73933.html
  13. International Organization for Standardization. (2025). ISO 10218-2:2025 Robotics – Safety requirements – Part 2: Industrial robot applications and robot cells (2nd ed.). ISO, Geneva. www.iso.org/standard/73934.html
  14. International Organization for Standardization. (2016). ISO/TS 15066:2016 Robots and robotic devices – Collaborative robots. ISO, Geneva. www.iso.org/standard/62996.html
  15. European Parliament and Council. (2023). Regulation (EU) 2023/1230 of 14 June 2023 on machinery. Official Journal of the European Union, L 165, 1–102. eur-lex.europa.eu/eli/reg/2023/1230/oj
  16. European Parliament and Council. (2024). Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689. eur-lex.europa.eu/eli/reg/2024/1689/oj
  17. European Parliament and Council. (2026). Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI). Official Journal of the European Union. eur-lex.europa.eu/eli/reg/2026/1744/oj
  18. Pendaries, M. (2026, August 6). Machinery Regulation 2023/1230: What the Digital Omnibus on AI changes. Eurogip, Paris. eurogip.fr/en/machinery-regulation-2023-1230-what-the-digital-omnibus-on-ai-chan
  19. Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology, Gaithersburg, MD. 10.6028/NIST.AI.100-1
  20. Sha, L. (2001). Using simplicity to control complexity. IEEE Software, 18(4), 20–28. 10.1109/MS.2001.936213
  21. Ames, A. D., Xu, X., Grizzle, J. W., & Tabuada, P. (2017). Control barrier function based quadratic programs for safety critical systems. IEEE Transactions on Automatic Control, 62(8), 3861–3876. 10.1109/TAC.2016.2638961
  22. Brunke, L., Greeff, M., Hall, A. W., Yuan, Z., Zhou, S., Panerati, J., & Schoellig, A. P. (2022). Safe learning in robotics: From learning-based control to safe reinforcement learning. Annual Review of Control, Robotics, and Autonomous Systems, 5, 411–444. 10.1146/annurev-control-042920-020211
  23. Ren, A. Z., Dixit, A., Bodrova, A., Singh, S., Tu, S., Brown, N., Xu, P., Takayama, L., Xia, F., Varley, J., et al. (2023). Robots that ask for help: Uncertainty alignment for large language model planners. arXiv preprint arXiv:2307.01928. arxiv.org/abs/2307.01928
  24. Hanley, J. A., & Lippman-Hand, A. (1983). If nothing goes wrong, is everything all right? Interpreting zero numerators. JAMA, 249(13), 1743–1745. 10.1001/jama.1983.03330370053031
  25. Kalra, N., & Paddock, S. M. (2016). Driving to safety: How many miles of driving would it take to demonstrate autonomous vehicle reliability? Transportation Research Part A: Policy and Practice, 94, 182–193. 10.1016/j.tra.2016.09.010
  26. Koopman, P., & Wagner, M. (2016). Challenges in autonomous vehicle testing and validation. SAE International Journal of Transportation Safety, 4(1), 15–24. 10.4271/2016-01-0128
  27. Muchiri, P., & Pintelon, L. (2008). Performance measurement using overall equipment effectiveness (OEE): Literature review and practical application discussion. International Journal of Production Research, 46(13), 3517–3535. 10.1080/00207540601142645
  28. Towler, G., & Sinnott, R. (2022). Chemical Engineering Design: Principles, Practice and Economics of Plant and Process Design (3rd ed.). Butterworth-Heinemann/Elsevier. 10.1016/C2019-0-02025-0
  29. Graetz, G., & Michaels, G. (2018). Robots at work. The Review of Economics and Statistics, 100(5), 753–768. 10.1162/rest_a_00754
  30. Acemoglu, D., & Restrepo, P. (2020). Robots and jobs: Evidence from US labor markets. Journal of Political Economy, 128(6), 2188–2244. 10.1086/705716

How to cite this article

Lee, Q. F. (2026). Safety, Reliability and Economics of Deploying Physical AI. Chmltech Online Journal, 105(3). https://www.chmltech.com/post/safety-reliability-and-economics-of-deploying-physical-ai

Chmltech Online Journal

More from the journal

All journal articles

Chmltech Online Journal · Vol. 105, Issue 3

Download the PDF

Safety, Reliability and Economics of Deploying Physical AI

We use your details to record this request and may follow up about it. See our privacy notice.

Ready to find your next improvement?

Book a strategy call. We will talk through your goals, pain points and where AI, systems or process work can make the biggest difference.

Book a Strategy Call

Or email info [at] chmltech [dot] com