Policies trained in simulation routinely fail on hardware. The reasons are specific and addressable — but only if you understand the full pipeline: physics simulation, domain randomization, synthetic data generation, sim-to-real transfer, virtual commissioning, and on-robot edge inference. This guide explains each stage, covers the leading platforms (NVIDIA Isaac Sim, Gazebo, MuJoCo), walks through VLA policy architectures, and maps the ISO 10218 / ISO TS 15066 / IEC 61508 safety requirements that govern AI control in production robot cells.
Last reviewed: May 2026
Sim-to-real transfer is the process of training a robot control policy — a function mapping sensor observations to actuator commands — entirely or primarily in simulation, then deploying it on physical hardware. The central challenge is that no simulator perfectly replicates real-world physics, perception, and actuator dynamics. Closing the resulting performance gap requires a systematic pipeline: high-fidelity physics simulation, domain randomization, synthetic data generation, hardware-in-loop validation, and careful edge inference deployment. Done correctly, it eliminates the need for large-scale real-world data collection; done incorrectly, the robot fails on its first interaction with the physical world.
A robot policy trained entirely in simulation and deployed directly on hardware fails — often immediately, sometimes catastrophically. This is not a surprise; it is an expected consequence of the fundamental mismatch between simulation and reality. Understanding exactly where and why policies fail is the prerequisite for designing a pipeline that produces policies that actually transfer.
The gap has two dimensions. The first is physical: simulators approximate contact dynamics, friction, actuator behaviour, and sensor characteristics. These approximations are unavoidable — even the highest-fidelity physics engines make simplifying assumptions that differ from reality by amounts that matter to a control policy. The second dimension is perceptual: simulated cameras render idealized lighting, texture, and geometry. Real cameras encounter motion blur, structured noise, specular reflections, and environmental variations that the policy has never seen during training.
The practical consequence is action distribution shift: the policy has learned a mapping from simulated observations to actions, and when real observations (which differ from simulated ones in the ways described above) are presented, the policy produces actions appropriate for the simulation observation it expected to see, not the real one it actually received. This manifests as erratic motion, grasping failures, and in the worst case, unsafe uncontrolled motion.
Domain randomization is the primary mitigation: by training across a wide distribution of simulated conditions (varied friction, varied lighting, varied object poses), the policy learns representations that generalize beyond any single simulation configuration. The real world becomes just another sample from this distribution — one the policy has not seen, but whose characteristics fall within the range it has been trained to handle. This works to the extent that the real world is within the randomization envelope. Ensuring that it is requires careful system identification.
Simulators render idealized textures, lighting, and object geometry. Hardware cameras encounter motion blur, specular highlights, dust, and perspective distortions that the policy has never seen. Even small perceptual deltas cause catastrophic action distribution shift.
Contact dynamics — friction, compliance, backlash, cable tension — are notoriously difficult to model accurately. Policies trained on rigid-body sim assumptions fail immediately when grasping deformable objects or operating on non-flat factory floors.
Real servo controllers have latency, current limits, thermal saturation, and backlash. Simulations typically assume instantaneous, perfect actuation. A policy that exploits precise timing in sim will fight the hardware.
IMUs drift, force/torque sensors have temperature dependence, depth cameras have structured noise. Policies not trained on realistic sensor noise distributions fail when deployed on real hardware.
Simulation cannot anticipate every real-world configuration: slightly misplaced parts, damaged packaging, humidity effects on gripper friction. Coverage of the full long-tail of real-world conditions is the fundamental challenge.
In simulation, ground-truth state is always available. On hardware, state must be inferred from noisy sensors. Policies that depend on precise pose estimates break when the estimation pipeline introduces uncertainty.
A production sim-to-real deployment is not a single algorithm — it is a pipeline of six distinct stages, each with its own tooling, decision points, and failure modes. The stages are sequential: the quality of each stage sets the ceiling for the next.
The following describes each stage as Hyperion implements it in industrial robotics projects. Platform references are neutral — the pipeline works with any of the major simulation environments described in Section 3.
Build a high-fidelity physics model of the robot, its end-effector, the workspace, and all objects of interest. Rigid-body and articulated-body dynamics, contact models (Coulomb friction, soft contact), and kinematic constraints are specified here. The quality of the physics model sets the ceiling for downstream transfer.
Key Decisions
Tooling
Intentionally vary physical and visual parameters across training episodes to force the policy to learn representations that generalize. Randomization acts as a regularizer: a policy that succeeds under a wide distribution of sim conditions is more likely to handle the specific (unknown) conditions of the real deployment.
Key Decisions
Tooling
Generate large-scale training datasets from simulation: RGB-D images with perfect ground-truth labels, 6-DoF pose annotations, segmentation masks, and trajectory demonstrations. Synthetic data bridges the annotation bottleneck that limits supervised learning from real-world data.
Key Decisions
Tooling
Apply transfer techniques to close the residual gap after domain randomization. System identification matches simulation parameters to real hardware measurements. Adaptation layers (RAPID, RMA, or similar) condition the policy on a learned context vector that encodes real-world environment properties from short interaction windows.
Key Decisions
Tooling
Before deploying on physical hardware, run the trained policy in a digital twin of the production cell — including PLC logic, conveyor timing, and inter-robot coordination. Virtual commissioning catches integration failures (timing conflicts, workspace collisions, unexpected state machine transitions) without risking hardware damage.
Key Decisions
Tooling
Deploy the trained policy to the robot's onboard compute for real-time inference. Latency, memory footprint, and power envelope are the key constraints. Policies are typically quantized to INT8 or FP16 and compiled with TensorRT or ONNX Runtime for the target hardware (NVIDIA Jetson, Orin, or AMD Kria SOM).
Key Decisions
Tooling
The three dominant simulation platforms for industrial robotics each occupy a distinct niche. The choice is driven by task type, target hardware, team expertise, and licensing constraints — not by vendor preference. All three are capable of producing deployable policies when the pipeline is correctly configured.
Disclosure: Hyperion has no commercial partnership, reseller agreement, or certification from NVIDIA, Open Robotics, Google DeepMind, or any simulation platform vendor. Platform descriptions are based on public documentation and Hyperion's implementation experience.
Isaac Sim is NVIDIA's robotics simulation environment built on the Omniverse USD platform. Isaac Lab (formerly Isaac Gym successor) provides the reinforcement learning training infrastructure. GPU-parallelized simulation enables running thousands of parallel environments simultaneously — critical for the sample efficiency demands of modern RL policies. Isaac Lab integrates domain randomization APIs, robot asset importers (URDF, MJCF), and a standard reinforcement learning training loop.
Industrial Fit
Highest photorealism via path-traced rendering; tightest integration with NVIDIA Jetson and AGX Orin edge inference hardware. Best choice when visual realism is a primary sim-to-real concern or when deploying on NVIDIA edge compute.
Limitations
Requires NVIDIA GPU for simulation (no AMD or CPU-only path). License terms require review for production deployments.
Gazebo is the de facto open-source simulator for ROS 2 development. Gazebo Harmonic (2023+) is the current stable release under Open Robotics, with a plugin architecture that supports multiple physics backends (DART, Bullet, ODE). Native ROS 2 integration via gz_ros2_control and ros_gz_bridge makes it the natural choice for teams building on ROS 2. The open-source license and active community make it cost-effective for proof-of-concept and development-phase sim work.
Industrial Fit
Best for ROS 2-native development pipelines. Strong community support for AMR (Autonomous Mobile Robot) navigation, manipulation, and sensor simulation. Free and modifiable for industrial use.
Limitations
Physics fidelity and rendering quality below Isaac Sim. Parallel training requires custom infrastructure (no built-in GPU-parallel RL support).
MuJoCo (Multi-Joint dynamics with Contact) is a physics engine purpose-built for robotics and biomechanics simulation. Its contact dynamics model is widely considered the most accurate available for contact-rich manipulation tasks. Acquired by Google DeepMind in 2021 and released free for all users, MuJoCo is the physics backend of choice for manipulation research (most academic manipulation benchmarks use MuJoCo). The MJCF model format is expressive and well-documented.
Industrial Fit
Best physics accuracy for manipulation tasks — grasping, assembly, screwing, deformable object handling. Essential when contact-rich task success depends on accurate dynamics simulation.
Limitations
No GPU-parallel simulation natively (MJX, the JAX port, adds limited GPU support). Rendering quality lower than Isaac Sim for visual-policy training.
Not sure which simulation platform fits your task, or where your current pipeline is leaking performance? Hyperion runs a focused discovery sprint — 2 weeks — that maps your robot cell, identifies the specific sim-to-real failure modes you are likely to encounter, and produces a pipeline architecture for your specific task and hardware.
The latest generation of robot policies extends beyond task-specific RL or imitation learning by grounding control in large pre-trained vision-language models. These VLA (Vision-Language-Action) policies provide semantic generalization — the ability to follow natural-language instructions and handle novel object categories — that conventional task-specific policies cannot. The tradeoff is compute and inference latency. The following describes the four dominant policy architectures used in industrial-adjacent sim-to-real work.
Diffusion Policy models robot action sequences as a denoising diffusion process over action space. It learns a score function that, given a noisy action proposal and the current observation, predicts the score gradient toward the demonstrated action distribution. In practice: highly multimodal — can represent multiple valid action modes for the same observation. Strong generalization to novel object positions. Computationally heavier at inference time than MLP-based approaches.
Best Applicability
Manipulation tasks with multimodal action distributions: pick-and-place with variable object poses, assembly with path flexibility.
ACT uses a transformer encoder-decoder architecture trained via imitation learning (CVAE-style) to predict chunks of future actions rather than single-step actions. Action chunking reduces compounding errors and improves temporal coherence. ACT has been demonstrated on bimanual manipulation tasks (ALOHA hardware) and has strong real-world transfer from teleoperation demonstrations.
Best Applicability
Bimanual assembly, folding, and tasks requiring coordinated two-arm motion. Works well with 50–200 human teleoperation demonstrations.
Approaches in the RT-2 lineage fine-tune large vision-language models (VLMs) to directly output robot actions as tokenized sequences. The VLM backbone provides rich semantic understanding of scene content, enabling zero-shot generalization to novel object categories described in natural language. OpenVLA (open-source, 7B parameter) makes this class of model accessible without proprietary infrastructure.
Best Applicability
Tasks requiring semantic understanding: 'pick the red component from the bin', 'place the object on the labeled tray'. Handles novel object categories at inference time.
Model-free RL with GPU-parallel simulation remains the dominant approach for locomotion and contact-rich tasks where the reward function can be engineered. PPO (Proximal Policy Optimization) and SAC (Soft Actor-Critic) trained in Isaac Lab or Brax with domain randomization produce policies that transfer to hardware via the residual dynamics gap. The AnyBotics ANYmal and Boston Dynamics Atlas locomotion policies are canonical examples.
Best Applicability
Locomotion (legged robots, AGV obstacle avoidance), contact-rich tasks (nut/bolt insertion, valve turning) where reward shaping is feasible.
AI-trained robot policies do not exist outside the safety regulatory framework. They are control programs, and safety standards that govern robot systems apply to them in full. The critical architectural principle — which Hyperion implements on every deployment — is that the AI policy runs in the non-safety channel. Safety enforcement is always implemented independently in the robot controller's certified safety layer.
Safety architecture principle: The AI inference stack is not the safety system. Speed limiting, force limiting, collision avoidance, and safety-rated monitored stops are implemented in the robot controller's certified safety PLC — independent of, and hierarchically above, the AI inference path. The AI system operates within the safety envelope; it does not define it.
Robots and Robotic Devices — Safety Requirements for Industrial Robots
ISO 10218-1 covers robot manufacturers; ISO 10218-2 covers robot system integrators. Together they define the safety requirements for industrial robot design, installation, and guarding. AI-controlled robots must satisfy the same mechanical and guarding requirements as conventionally programmed robots. ISO 10218-2 is the integration standard most relevant to physical AI deployments.
AI Implication
A sim-to-real trained policy is a control system. Its outputs (joint velocities, forces) must be bounded by safety-rated monitored stops and speed/force limiting — functions that must be implemented in the robot controller's safety PLC, not in the AI inference stack.
Robots and Robotic Devices — Collaborative Robots
ISO TS 15066 specifies requirements for collaborative robot systems operating in direct human-robot contact scenarios. It defines four collaborative operation modes: safety-rated monitored stop, hand guiding, speed and separation monitoring (SSM), and power and force limiting (PFL). For AI-driven cobots, SSM and PFL are the most relevant modes.
AI Implication
AI policies must respect the dynamic safety zones calculated by the SSM system. The policy outputs must be rate-limited and clamped before reaching the servo layer. The AI inference system is not the safety system — it operates within the safety envelope defined by the cobot controller.
Functional Safety of E/E/PE Safety-Related Systems
IEC 61508 is the foundational functional safety standard for electrical, electronic, and programmable electronic systems. It defines Safety Integrity Levels (SIL 1–4) and the systematic process for developing and validating safety-related software. Its sector derivatives (IEC 62061 for machinery, ISO 26262 for automotive) directly govern industrial robot safety systems.
AI Implication
AI inference components that participate in safety functions (e.g., collision avoidance, force limiting) must be assessed for functional safety. In practice, the approach is to keep the AI inference path in the non-safety channel and implement safety functions independently in a certified safety PLC or robot controller safety layer. The architecture separates AI autonomy from safety enforcement.
EU Machinery Regulation — Replacing Machinery Directive 2006/42/EC
The new EU Machinery Regulation (fully applicable 2027) explicitly addresses autonomous machinery and collaborative robots. It requires risk assessments for autonomous decision-making functions and introduces requirements for machinery that can adapt its behaviour. AI-controlled industrial robots fall squarely within its scope.
AI Implication
AI-driven industrial robots placed on the EU market after 2027 must undergo conformity assessment under the Machinery Regulation. Design documentation, risk assessment, and post-market monitoring requirements apply to the AI control system, not just the mechanical structure.
The following is a factual account of Hyperion's background as it relates to sim-to-real robotics deployments. These are verified facts, not marketing claims.
Hyperion has built Auralink — an edge-deployed agent platform with 400+ microservices and approximately 20 AI agents. Auralink includes a ROS 2 bridge for physical infrastructure control and a distributed-agent arbitration layer, the architectural pattern described in the arXiv preprint 2603.08736. The system architecture that enables multi-agent arbitration over distributed edge nodes — planning, sensing, and actuation — directly transfers to industrial robotics deployments. This is not hypothetical; it is a production codebase (approximately 1.7M lines of code).
A preprint published on arXiv (2603.08736) covers autonomous edge-deployed AI agents for physical infrastructure — addressing the distributed coordination, state estimation, and real-time control challenges that characterise sim-to-real deployment. Note: this is a preprint, not a peer-reviewed publication. Its relevance here is architectural: the agent coordination and edge inference patterns it describes are directly applicable to industrial robot cell deployments.
Hyperion has built 10 production AI ventures. The architectural depth required to build and maintain this portfolio — spanning edge inference, multi-agent coordination, ROS 2 bridging, and sovereign AI deployment — is the same depth required for sim-to-real robotics work. This is not general-purpose AI consulting; it is systems engineering.
Founder Mohammed Cherifi spent 17+ years in automotive and embedded systems engineering, including work at Renault-Nissan-Mitsubishi Alliance, Cisco, and ABB. This background means Hyperion understands the operational constraints of production environments — safety certification requirements, real-time control architectures, and the gap between laboratory demonstrations and shop-floor deployments — from direct experience.
Hyperion does not manufacture robots, does not supply certified safety PLCs, and is not a hardware integrator. The engagement model is AI architecture, sim-to-real pipeline design, policy training methodology, and edge inference deployment — working alongside the robot OEM and the systems integrator, not replacing them. This scope boundary matters: the right engagement with Hyperion is the one where your OEM handles the iron and Hyperion handles the intelligence layer.
A production sim-to-real deployment is a systems engineering project. The following are the decision points that every robotics team will need to address during integration.
Policy inference for manipulation typically runs at 10–50 Hz. NVIDIA Jetson AGX Orin (275 TOPS INT8) handles real-time inference for transformer-based policies up to ~200M parameters at 30 Hz. Larger policies (VLA-scale, 7B+) require a GPU compute node in the cell rather than per-robot edge hardware. AMD Kria K26 SOM is an alternative for cost-sensitive deployments at smaller model sizes.
The policy node in ROS 2 subscribes to observation topics (camera streams, joint states, force/torque) and publishes action topics (joint velocity commands or Cartesian pose targets). The ros2_control framework connects to the robot controller via hardware interface plugins. A separate safety watchdog node monitors inference latency and triggers a safety-rated stop if the policy node misses its deadline.
Each deployed policy version must be versioned alongside its training configuration, domain randomization parameters, and evaluation metrics. A rollback procedure must be defined and tested before production deployment. In practice: maintain at least two policy versions on the edge compute, with a hardware switch or ROS 2 parameter toggle to revert to the previous version.
Real-world conditions drift from the training distribution over time: gripper wear changes friction, object appearance changes with production lot, lighting changes seasonally. A runtime monitor that tracks policy uncertainty (ensemble disagreement or MC dropout variance) and triggers human review when confidence drops below a threshold is essential for production-grade autonomy.
The AI policy runs in the non-safety channel. Safety functions (speed limiting, force limiting, collision avoidance via safety scanner) run in the robot controller's certified safety PLC, independent of the AI inference stack. This architecture allows the AI layer to fail-safe without relying on the AI system itself to detect its own failures. The safety PLC must be rated to the appropriate SIL under IEC 62061.
Every policy failure on hardware — grasping miss, unexpected contact, recovery trigger — should be logged with the full observation window (camera frames, joint states, sensor readings) and the action taken. This failure dataset drives the next round of domain randomization expansion and fine-tuning. Without systematic failure logging, the policy cannot improve after deployment.
The sim-to-real gap is the performance degradation a robot policy experiences when transferred from a simulation environment to physical hardware. It arises because no simulator perfectly captures real-world physics (contact dynamics, actuator behaviour, sensor noise) or appearance (lighting, texture, depth-camera noise). Domain randomization reduces the gap by training across a wide distribution of sim conditions, but some residual gap always remains and must be closed by system identification, hardware adaptation, or fine-tuning on real data.
This depends strongly on task complexity, domain randomization quality, and the transfer method used. Well-designed sim-to-real pipelines with aggressive domain randomization can achieve near-zero-shot transfer for manipulation tasks with structured workspaces (assembly with fixed object locations). For tasks with high perceptual variability (bin-picking of randomly oriented objects), 100–500 real-world demonstrations for fine-tuning is typical. Residual policy approaches (where the sim policy is supplemented by a small real-data-trained residual) can work with as few as 20–50 real trajectories.
Isaac Sim is not required. MuJoCo (free, high physics fidelity) and Gazebo Harmonic (open-source, native ROS 2 support) are both production-grade alternatives. The platform choice should be driven by the task type (contact-rich manipulation favours MuJoCo physics; ROS 2 integration favours Gazebo; visual-policy training favours Isaac Sim's rendering quality) and the target inference hardware (NVIDIA edge compute integrates more cleanly with the Isaac ecosystem). Hyperion does not prefer one platform and does not have a commercial relationship with any simulator vendor.
Safety standards apply to the robot system, not specifically to how the robot is programmed. An AI-trained policy is a control program: its outputs (joint velocities, Cartesian commands) must be bounded by the same safety-rated functions required for any robot program — safety-rated monitored stops, speed and force limiting. The critical architectural principle is that AI inference runs in the non-safety channel, and safety enforcement is implemented independently in the robot controller's certified safety PLC. The AI system cannot be the safety system.
A VLA policy is a robot control policy built on a pre-trained vision-language model (VLM) backbone, fine-tuned to output robot actions directly. The VLM provides rich semantic understanding of the scene, enabling zero-shot generalization to novel objects described in natural language. VLA policies are appropriate when the task requires semantic scene understanding — 'pick the fastener from the labeled bin' — and when a large pre-trained model can be fine-tuned on robot demonstrations. They are less appropriate for pure locomotion or high-frequency contact-rich tasks where smaller, faster policies suffice.
Simulation-based training produces the robot policy. Virtual commissioning validates that the trained policy works correctly within the full production cell — including PLC logic, conveyor timing, inter-robot coordination, and safety interlock sequences — before any physical hardware is deployed. Virtual commissioning catches integration failures that training simulation does not model: a policy that works correctly in isolation may fail when the upstream conveyor delivers parts at irregular intervals, or when a neighbouring robot's motion creates unexpected workspace conflicts.
No. Hyperion's scope is AI architecture: sim-to-real pipeline design, policy training methodology, edge inference deployment, and ROS 2 integration. Hardware selection, mechanical integration, CE marking, and safety PLC certification are performed by the robot OEM and the certified systems integrator. Hyperion works alongside those partners; it does not replace them. This scope boundary is important: bringing in an AI consulting firm for hardware supply or safety certification is a scope mismatch.
A focused project — one task, one robot model, one workspace — typically takes 12–20 weeks from scoping to first production trials. This breaks down as: 2–4 weeks for simulation environment setup and system identification; 4–6 weeks for policy training with domain randomization; 2–4 weeks for sim-to-real transfer and hardware trials; 2–4 weeks for virtual commissioning and production integration. Complex multi-task, multi-robot deployments with novel object categories and safety certification requirements can extend to 6–12 months.
Tobin, J. et al. (2017). "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World."
Context: IEEE/RSJ IROS 2017. Seminal paper introducing domain randomization as a sim-to-real transfer technique for robotic grasping using synthetic training data.
Kumar, A. et al. (2021). "RMA: Rapid Motor Adaptation for Legged Robots."
Context: Robotics: Science and Systems (RSS) 2021. Introduces the teacher-student adaptation framework that enables zero-shot sim-to-real transfer for quadruped locomotion by learning an adaptation module from privileged simulation context.
Chi, C. et al. (2023). "Diffusion Policy: Visuomotor Policy Learning via Action Diffusion."
Context: Robotics: Science and Systems (RSS) 2023. Introduces diffusion-based action generation for robot manipulation; demonstrates strong real-world transfer from simulation demonstrations.
Zhao, T. et al. (2023). "Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware."
Context: IEEE/RSJ IROS 2023 (ACT paper). Introduces Action Chunking with Transformers for bimanual manipulation; demonstrates transfer from 50–200 teleoperation demonstrations to real hardware.
Open Robotics / OSRF (2024). "Gazebo Harmonic Documentation."
Context: Official documentation for Gazebo Harmonic physics simulation, ROS 2 integration via gz_ros2_control, and sensor plugin API.
NVIDIA Corporation (2024). "Isaac Lab: GPU-Accelerated Robot Learning."
Context: Official documentation for NVIDIA Isaac Lab (formerly Isaac Gym successor): parallel environment training, domain randomization API, robot asset import pipeline.
DeepMind / Google (2024). "MuJoCo Physics Engine Documentation."
Context: Official MuJoCo documentation covering contact dynamics models, MJCF format, and the MJX JAX port for GPU-parallel simulation.
ISO (2011). "ISO 10218-1/2: Safety Requirements for Industrial Robots."
Context: International standard specifying safety requirements for industrial robot design (Part 1: robot manufacturer) and system integration (Part 2: integrator). Revision in progress as of 2024.
ISO (2016). "ISO/TS 15066: Collaborative Robots."
Context: Technical specification for collaborative robot systems: four operating modes, biomechanical pain threshold limits for power and force limiting, and speed and separation monitoring requirements.
IEC (2010). "IEC 61508: Functional Safety of E/E/PE Safety-Related Systems."
Context: Foundational functional safety standard; defines SIL 1–4 levels and systematic safety lifecycle requirements. Parent standard to IEC 62061 (machinery) and ISO 26262 (automotive).
Hyperion Consulting (2026). "arXiv preprint 2603.08736: Autonomous Edge-Deployed AI Agents for Physical Infrastructure."
Context: Hyperion founder's preprint (not peer-reviewed) covering distributed-agent arbitration and ROS 2 bridge architecture for edge-deployed AI systems. The architectural patterns are directly applicable to industrial robot cell deployments.
Whether you are designing your first sim-to-real pipeline for a manipulation cell or diagnosing why a trained policy is underperforming on hardware, the architecture decisions made early shape everything that follows. Hyperion brings 17+ years of embedded systems and manufacturing engineering experience alongside a production track record in edge-deployed AI agent systems. Start with a conversation.
Founder & AI Strategy Lead
Mohammed Cherifi is the founder of Hyperion Consulting, with 17+ years in automotive and embedded systems engineering. He specialises in physical AI deployment — bringing operational experience from Renault-Nissan-Mitsubishi Alliance, Cisco, and ABB to industrial robotics and edge inference architecture.
End-to-end sim-to-real pipeline design and edge inference deployment services
The 6-layer Physical AI Stack for robotics, edge AI, and industrial automation
Sovereign AI for manufacturing: Mistral on-premise and air-gapped deployment
Compliance requirements for high-risk AI systems in industrial environments