Standfirst: A robot may complete every simulated task yet still fail on its real hardware. Executives need separate evidence for physical performance, safeguarding and release; insurers make their own risk decisions.
Executive takeaways
- Treat a simulation result as evidence about the conditions actually tested, not as release authorisation.
- Preserve the software-to-hardware configuration and assess physical task performance separately from safety-related protective functions.
- Use independent examination where it adds decision value; insurers remain free to assess other evidence and determine terms.
A successful simulation does not answer the release question
A simulation result can justify selecting a robot for controlled hardware evaluation; it cannot, by itself, authorise operational release. Before release, management needs physical task evidence on the proposed configuration, qualified evaluation of relevant protective functions, and an accountable decision on site conditions and residual risk. An insurer may separately assess the exposure. A simulated placement score cannot establish whether a protective stop—a safety-related stopping response demanded by a protective device—will work as specified.
This concerns underwriting AI-related risk—insuring losses from AI-enabled machines—not an insurer using AI in underwriting.
NVIDIA identifies why simulated and physical performance differ
NVIDIA’s Isaac Lab documentation describes a simulation-to-reality (sim-to-real) gap arising from approximations in physical dynamics and differences in sensors, actuation, task setup and software interfaces [1]. It highlights friction and contact, camera calibration and lighting, control delay, units, joint ordering, action scaling, control frequency and preprocessing. This is platform-developer guidance, not independent validation of any particular robot.
An interface error deserves attention even when simulation physics is strong: NVIDIA notes that domain randomisation—training a policy across plausible variations—cannot correct an incorrectly implemented interface. It describes comparing a simple scripted policy’s observations and actions in simulation and on hardware as a diagnostic technique [1]. These are engineering diagnostics, not safety evaluations.
An independent peer-reviewed survey of the robotics reality gap likewise describes persistent discrepancies between simulated and physical conditions, surveys transfer methods and distinguishes metrics for the gap from those for actual transfer [5]. This corroborates the existence of the engineering challenge, not a finding about any specific deployment.
NVIDIA also recommends comparing the same learned policy against the same task-level metric across simulated and physical trials. Similar results do not prove transfer when both performances are poor. Only controlled evaluation of the target hardware can establish how that specific policy performed there [1].
Preserve the configuration behind every claim
A statement such as “tested in Isaac Lab” cannot reconstruct an experiment. ODA3 Institute proposes preserving simulator and software versions, code revision, environment assets, learned policy (the system choosing robot actions) and checkpoint, sensor and action interfaces, randomisation ranges, trial definitions, failures, metrics and result-generation method. These are proposed evidence elements, not universally mandated records. NIST’s voluntary AI Risk Management Framework similarly calls for documenting limitations of generalisation beyond development conditions [6]; it does not certify robotics safety or prescribe insurer requirements.
For the physical target, record the machine, sensors, tooling, firmware, control stack, communication paths and operating restrictions. Compare this record with the simulation and state which differences were examined, remain untested or require new evaluation following a material change.
A competent examiner may check configuration provenance or evaluate an observed result against defined criteria. Such findings remain bounded; provenance does not establish physical safety.
From configuration records to examinable evidence
For each material simulation-to-deployment assertion, ODA3 Institute proposes identifying the exact claim, evaluation configuration, applicable acceptance criterion, observed result, failure record, known exclusion and decision owner. A statement that a policy transferred successfully should identify what task-level outcome was observed on the target hardware, under which conditions, and against which criterion.
The evidence record should distinguish:
• Simulation performance: the task, environment, trial population, metrics, failures and evaluated policy version.
• Configuration equivalence and differences: the relationship between simulated assumptions and actual hardware, sensors, firmware, interfaces, control timing and site conditions.
• Physical task performance: controlled observations, failure modes and the limits of the conditions tested.
• Protective-function evidence: separate requirements, qualified evaluation and results for applicable safety-related functions.
• Release authority: the responsible decision-maker, accepted residual restrictions, unresolved evidence and conditions triggering reassessment.
Acceptance criteria should be defined before relying on the evaluation outcome wherever practicable. Changes to relevant hardware, learned policies, interfaces, software or operating conditions should trigger an impact assessment; the necessary extent of retesting depends on that assessment.
This is a proposed evidence model, not a claim that every element is universally required by law, ISO 10218, NVIDIA or an insurer.
Underwriting involves two different evidence questions
Insurer → organisation. An insurer assessing a material physical AI exposure could request configuration comparisons, physical transfer observations, qualified safeguard evidence and unresolved operational limits. These are ODA3 Institute analytical proposals, not verified mandates of any insurer. Actual questions depend on the insurer, product, market and policy.
Organisation → insurer. Management can substantiate a narrow assertion using simulation records, physical results, changes and exclusions rather than merely stating that a model passed. An insurer may weigh operating history, site surveys and losses more heavily than simulation. No insurer reliance or pricing effect is established.
| Executive or underwriting question | Evidence to examine | What it may show | What remains uncertain |
|---|---|---|---|
| What succeeded in simulation? | Fixed model, environment, task, trial failures and metrics | Performance in tested simulated conditions | Physical performance |
| Does the policy transfer? | Target hardware, interface checks and controlled physical observations | Results for the tested configuration | Changed or excluded conditions |
| Were modelled variations relevant? | Parameter sources, ranges, site comparison | Covered assumptions | Unmeasured dependencies |
| Do safeguards meet requirements? | Hazard assessment and qualified physical evaluation | Examined protective-function performance | Other demands and degradation |
| Is the operating state authorised? | Safety, security and release records | Basis for the responsible authority’s decision | Residual risk and later changes |
| What can an insurer rely upon? | Bounded evidence, exclusions and disclosures | What has been substantiated | Acceptance, pricing and coverage |
ODA3 Institute analysis; not an adopted underwriting standard, certification or functional-safety case.
When a simulated placement meets an untested light curtain
Illustrative scenario — entirely synthetic; no system examined.
A fictional robot places containers on a fixture. Its simulated trials cover defined object positions and friction ranges. Those trials support a statement about simulated placement, not the operation of an installed protective function.
The physical installation introduces a camera, gripper, communications path and protective light curtain—a sensor-based safeguarding device that detects entry into a protected area. Differences in sensing or timing could affect placement. A qualified safety evaluation would examine the applicable protective-function requirements, including the relevant detection arrangement, safety-related control response and stopping behaviour, against the installed configuration and assessed hazards. The evidence should distinguish the light curtain’s detection function, the machine’s response to a protective demand and the conditions under which that response was evaluated. A successful simulated placement does not establish any of these results. This illustration does not prescribe a safety-validation procedure.
Suppose a controlled physical trial reveals inconsistent placement under lighting absent from the simulated test set. The organisation could restrict that operating condition pending investigation and further qualified evaluation. This fictional observation does not establish injury, financial loss, legal liability or insurance coverage.
Safety and legal obligations depend on the actual system
ISO 10218-1:2025 addresses safety requirements for industrial robots, while ISO 10218-2:2025 addresses industrial robot applications and robot cells [2][3]. Their scopes are not interchangeable. The published scope descriptions identify exclusions involving, among others, medical and healthcare robots, specified service and consumer applications, and mobility-related hazards when robots are integrated with mobile platforms or driverless industrial trucks.
The exclusion of particular hazards does not necessarily exclude every other aspect of a robot or installation from the relevant standard. Applicability must be evaluated against the intended use, robot configuration, integration context, hazards and applicable regulatory requirements. Public scope descriptions alone neither establish compliance nor substitute for assessment against the full applicable requirements.
In the European Union, Regulation (EU) 2026/1744 amended the AI Act’s high-risk classification and application framework. Under the amended Article 113, Chapter III, Sections 1–3, subject to the stated exception, apply from 2 December 2027 to high-risk systems classified under Article 6(2) and Annex III, and from 2 August 2028 to high-risk systems classified under Article 6(1) and Annex I [4].
The amendment also moved Regulation (EU) 2023/1230 on machinery from Section A to Section B of Annex I of the AI Act. This changes the relationship between the AI Act’s horizontal high-risk requirements and the sectoral machinery regime. The amended framework provides for AI-related essential health and safety requirements to be incorporated into machinery legislation through delegated acts, with the relevant acts intended to apply by 2 August 2028.
These dates must not be interpreted as authorising deployment, postponing every existing product-safety obligation, or establishing that all AI-enabled robots are high-risk AI systems. Classification depends on the system’s intended purpose, applicable product legislation, safety function, conformity-assessment context and any relevant transitional provisions. A site-specific legal assessment remains necessary.
Regulation (EU) 2026/1744 entered into force on 27 July 2026. Outside the EU, the cited EU application dates do not automatically apply. In all jurisdictions, evidence of learned-policy performance should remain distinguishable from evidence supporting applicable product-safety and deployment obligations.
The release decision: what to do next
For the next deployment review: (1) request the exact simulation-to-hardware configuration comparison; (2) ask the qualified safety lead for the protective-function evidence separately; (3) record who can authorise controlled evaluation, constrained operation or release, and which unresolved conditions prevent the next stage. These are decision questions, not an alternative to the applicable safety case.
A technical deviation might cause an operational interruption or property damage, but deviation does not itself establish a loss. Loss does not establish legal liability, and liability does not establish policy coverage. Those questions require different facts, legal analysis and contractual interpretation.
A release decision should identify its permitted operational state, the evidence accepted for that state, any restrictions that remain in force and the authority responsible for approving changes. Controlled evaluation, restricted operation and unrestricted operational release should not be treated as equivalent decisions. Unresolved safety-related evidence must be escalated to the competent safety authority rather than resolved solely through management acceptance of business risk.
| Action | Accountable owner | Evidence and reconsideration condition |
|---|---|---|
| Preserve simulation and target configuration | Engineering lead / Chief Risk Officer | Traceable versions, metrics and exclusions; re-evaluate after material change |
| Separate task and protective-function evidence | Robotics safety lead / deployment authority | Qualified system-specific evaluation; use competent existing evidence where sufficient |
| Consider bounded independent examination | Audit or Risk Committee | Defined claim, competence, conflicts, observation scope and reliance; commission only where proportionate to the decision |
| Make evidence-based insurer disclosures | Head of insurance / General Counsel | Tested scope, physical observations and known limits; adapt to actual requests and wording |
| Record the release decision | Accountable operational authority | Site restrictions, residual risks and sign-offs; reopen if evidence or conditions materially change |
Management owns controls and release. Examiners report only within agreed scope, with conflicts and reliance recorded. Insurers decide acceptance and pricing; coverage depends on wording, facts and law.
Notably Absent
No simulation was executed, robot tested, protective function measured, site inspected or release decision examined for this article. Developer guidance and research surveys do not certify any deployment.
No insurer-side underwriting manual, quotation, endorsement, paid claim or observed pricing effect specifically linking simulation-transfer evidence to underwriting decisions was examined as primary evidence here. Accordingly, the proposed evidence exchange is analysis, not demonstrated insurer practice. This does not establish that such practices do not exist.
No litigation outcome, actuarial causal relationship, system-specific EU AI Act classification, complete machinery-law applicability assessment or cost-benefit analysis of independent examination is established. Published standards were reviewed for scope only.
Conclusion
Simulation earns consideration for controlled hardware testing, not permission for site release. It can help select a candidate for controlled hardware evaluation when the tested configuration, metrics and exclusions are preserved. Operational release additionally requires relevant physical observations, qualified protective-function assessment and an accountable decision tied to the exact proposed configuration. Such evidence may also inform an insurer, but insurer reliance remains unproven in this analysis.
References
[1] NVIDIA. “Simulation to Reality.” Getting Started With Isaac Lab, version 2026-10.0; publication date not stated. https://docs.nvidia.com/learning/physical-ai/getting-started-with-isaac-lab/2026-10.0/robot-learning-fundamentals/08-simulation-to-reality.html (accessed 28 October 2026).
[2] International Organization for Standardization. “ISO 10218-1:2025 — Robotics — Safety requirements — Part 1: Industrial robots.” Published February 2025. https://www.iso.org/standard/73933.html (accessed 28 October 2026).
[3] International Organization for Standardization. “ISO 10218-2:2025 — Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells.” Published February 2025. https://www.iso.org/standard/73934.html (accessed 28 October 2026).
[4] European Parliament and Council. “Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230.” Official Journal of the European Union, 24 July 2026. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202601744 (accessed 28 October 2026).
[5] The Reality Gap in Robotics: Challenges, Solutions, and Best Practices. Annual Review of Control, Robotics, and Autonomous Systems, volume 9, pp. 403–432 (2026); first published online 2 December 2025. https://doi.org/10.1146/annurev-control-031924-100130 (accessed 28 October 2026).
[6] National Institute of Standards and Technology. AI Risk Management Framework, Core, MEASURE 2.5 (voluntary guidance). https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ (accessed 28 October 2026).
© 2026 ODA3 Pvt Ltd.
Methodology note
Document-based technical/legal-scope synthesis and explicitly synthetic robot/light-curtain scenario; separate simulation performance, hardware observations, protective-function evaluation and accountable release; insurer evidence questions are proposals, not established practice.
Notably Absent
No simulation or robot testing, protective-function measurement, site inspection, release decision, insurer underwriting manual/quote/claim/pricing effect, system-specific EU classification, litigation or actuarial causal finding.
