Learned Robot Policies: Acceptance and the Safety Case

A basic technical shift is underway in industrial practice with driverless transport systems and autonomous mobile robots. Where classical driverless transport vehicles rest on deterministic state machines and fixed routes, systems are increasingly arriving whose movement decisions come out of learned models. To describe that shift precisely, the terminology has to be fixed first. The term Physical AI is primarily shaped by technology vendors. NVIDIA describes Physical AI as the ability of autonomous systems such as cameras, robots and self-driving vehicles to perceive, understand and reason about their environment and to perform or orchestrate complex actions in the physical world. For autonomous vehicles, NVIDIA explicitly names vision-language-action models (VLA) that make decisions on the basis of sensor data.

For operators, asset managers and maintenance leads, that produces a fundamental change in acceptance. With a deterministic autonomous mobile robot (AMR), the behaviour can be enumerated in full and tested systematically: every planned route, every branch, every behaviour at a fire door and every stopping profile can be walked through line by line in a test protocol and ticked off. Once all defined routes and stopping points have been completed successfully, the installation counts as accepted.

With a learned policy, that enumerable state space no longer exists. A neural network maps a continuous probability space. The operator is not accepting a linear if-then program but a statistical distribution of behaviour. The same obstacle can produce slightly different avoidance radii or acceleration values depending on the angle of the light, the approach speed or the pixel distribution in the camera sensor. Anyone carrying responsibility for such a fleet needs a changed approach to specification and acceptance testing, as also applies to Physical AI for outdoor AMRs in brownfield settings.

• Deterministic AMR: system behaviour follows explicit logic with finite, fully testable paths and defined stopping conditions.
• Learned policy: system behaviour rests on high-dimensional statistical weights; what is tested is a distribution of response patterns under changing environmental conditions.
• Operational consequence: classical checklist acceptance no longer works, because completeness is mathematically unreachable.

Once test cases can no longer be enumerated in full, the acceptance procedure has to move from a point-by-point functional check to statistical scenario coverage. Operators cannot demand that every conceivable environmental state be physically simulated in advance. What they can demand instead is that the vendor demonstrate and contractually warrant a representative sample of operationalised scenarios.

The precondition for any acceptance protocol is a written operating envelope. That document sets out the physical, visual and operational limits inside which the learned policy is permitted to make valid decisions. It covers precise lux values for illumination, permissible floor gradients, friction coefficients, temperature ranges, and minimum contrast for route markings and obstacles. If the deployed environment departs from those parameters in service, no defect claim attaches to the learned function; instead the system has to transition in a controlled way into a safe state.

Equally decisive is the out-of-scope catalogue: an explicit contractual statement of what the system is expressly not expected to handle. Without that negative list, every operational anomaly turns into a drawn-out dispute between operator and integrator. The catalogue clearly excludes edge cases such as reflective puddles, hanging sheeting or transparent barriers, and defines the fallback response required of the vehicle.

In classical mechanical engineering, the control software of an installation stays largely unchanged after acceptance, apart from rare, qualified PLC patches. With AI-based robots, manufacturers frequently advertise continuous over-the-air updates (OTA) meant to improve the vehicle steadily in service. For the fleet operator, however, a model update is not a convenient software patch but a fundamental change in the behaviour of a running machine.

A new neural network fine-tuned on additional data may raise the detection rate for particular pallet types while at the same time producing unanticipated behaviour at junctions that were previously uncritical. Operator contracts therefore have to establish that no update may be loaded straight onto the production floor without prior operational validation. That validation requires a staged test chain:

1. Staging validation: evaluation of the new model against the operator's historical sensor data to check for regressions.
2. Shadow mode: the new model runs in parallel on individual robots and computes paths, while the existing, accepted policy drives the actuators.
3. Canary deployment: release of the update to a single vehicle in a separated area of the building across several consecutive shifts.
4. Fleet-wide rollout: progressive distribution to the rest of the fleet over a structured interface such as the multi-tenant connector.

An automated and mandatory rollback path has to be agreed contractually as well. If a new model on the floor produces a defined threshold breach in creep-speed events, false stops or travel times, the vehicle has to be able to fall back to the previous, released model state without delay and without a service technician intervening on site.

The central principle for operating robots with learned components is this: a learned policy is not a safety function. The safety-related control functions have to be built deterministically at all times and sit entirely outside the learned model. That principle follows from the scope of the technical report CEN ISO/TR 22100-5:2022 (identical to ISO/TR 22100-5:2021) on the relationship between machinery safety and machine learning.

The scope of that technical report contains two fundamental exclusions every operator should know. First, the document is expressly not applicable to machinery with machine-learning applications designed to act beyond specified limits and thereby capable of producing unpredictable effects. Second, the document does not address safety systems with artificial intelligence, such as safety-related sensors and other safety-related parts of control systems.

For operational practice that means the learned layer acts purely as a planning and optimisation unit. It computes trajectories, optimises turning radii and recognises load carriers. Below that layer sits a certified safety controller with safety-rated laser scanners and emergency stop circuits (with sector-specific transport standards such as ISO 3691-4 setting the deterministic protective-field requirements). If the learned policy requests a faulty movement, the deterministic safety level cuts the actuators hard. At the interface to the higher-level control system, a standardised fleet architecture such as VDA 5050 in the mixed fleet keeps travel commands and safety states cleanly separated.

Modern robots generate gigabytes of sensor data every shift, including high-resolution 2D camera images, 3D point clouds from LiDAR sensors and spatial building plans. With learned models, manufacturers regularly ask for that data to flow back into their cloud systems so models can be trained further. For facility and maintenance leads, that creates a substantial risk to operational security and data sovereignty.

The procurement contract has to state precisely which data may leave the site. Raw video streams and detailed 3D maps carry operationally relevant information about building layouts, production sequences and cycle times. Contracts should establish that data transfers stay limited to aggregated telemetry values, or that full local pre-processing (edge processing) takes place. It also has to be settled whether the manufacturer may use operational data to train generic models that could subsequently be available to competitors.

The scenario of vendor insolvency, takeover or model discontinuation deserves particular attention. If a manufacturer ceases trading or stops maintaining a model, the fleet must not come to a standstill. Thorough supplier due diligence therefore has to include contractual safeguards: operators need a permanent, irrevocable right to use the last released model version (model freeze), together with an assurance that the robots can keep working locally and self-sufficiently without an active cloud connection. How fleets are run economically after several years of service is set out in the guide to year three and end of life.

• Limit data outflow: no unencrypted raw image data or point clouds transferred to external clouds without written operator release.
• Usage rights on model discontinuation: deposit of the weight matrices and inference runtime environments in a software escrow to secure continued operation.
• Local self-sufficiency: full functionality of the overall system in offline mode when external server infrastructure fails.

In the robotics market, almost every form of sensor-based automation is currently marketed as AI-powered. For operators it is essential to take vendor marketing apart technically. In many cases the components fitted are not autonomous learned action policies at all, but classical industrial machine vision with nothing more than a standard classifier integrated for object recognition.

The difference matters. A system built on classical machine vision with an upstream classifier merely recognises an object (a pallet at a particular confidence, say) and hands the coordinates to a fully deterministic motion planner. A genuine learned policy, such as a VLA model, instead drives the robot's motors and joints directly on the basis of visual input. The first case remains testable in the classical way; the second requires the statistical scenario acceptance described above. Rolling either kind across a mixed fleet is a separate problem, covered under multi-robot coordination and day-to-day robot fleet management.

The situation is sharpened by the normative gap in the standards landscape. The technical report ISO/IEC TR 5469:2024 ("Artificial intelligence — Functional safety and AI systems") describes properties, risk factors, methods and processes for using AI in safety-related functions, but as a Technical Report it is purely informative and carries no normative force. No binding acceptance or validation rule for learned robot behaviour exists to this day. Operators have to close that gap themselves, in their own tenders and contracts, through targeted technical questions.

Despite rapid development in machine learning, deterministic programming remains the economically and technically superior solution for the greater part of industrial transport and assembly floors. Where routes are clearly structured, processes are cycled and environmental conditions are controllable, deterministic software offers unmatched reliability, minimal latency and predictable operating costs.

A sober look at the market makes the distinction between laboratory research and industrial reality clear. In the report "Where Autonomy Works: Evaluating Robot Capabilities in 2026", Epoch AI finds that navigation is in commercial use, for instance moving goods in warehouses, while most tasks requiring robots to handle, assemble or manipulate objects remain largely in the lab; warehouse picking counts as the clearest example of commercially deployed manipulation in a controlled environment. Transfer of learned capabilities to new objects, environments and tasks is, according to Epoch AI, rarely demonstrated, yet it matters for most applications; most demonstrations show robots fine-tuned on a particular task in a particular setting. Off-the-shelf language and vision models will, according to the same work, play a growing role in the cognitive parts of robot tasks — understanding the task and following multi-step plans — which places them expressly not yet in broad rollout.

Where learned components are already in productive use today, it happens in clearly bounded task areas. One prominent market example is Amazon's Vulcan system. According to Amazon, it can pick and stow around 75 percent of the item types stored in its fulfilment centres. At the fulfilment centres in Spokane, Washington and in Hamburg, Vulcan handles stowing and picking in the top rows of the inventory pods — rows roughly eight feet up that would otherwise require an employee on a step ladder — as well as items stowed just above the floor. Its AI was trained not only in simulation but on physical data including touch and force feedback.

For fleet operators, the key to a sound commercial outcome lies in treating learned and deterministic systems not as opposites but as things to combine deliberately according to what the process requires. Standard routes on tightly cycled paths stay under purely deterministic control, while learned policies go where unstructured load carriers or dynamic handover points call for flexibility. A manufacturer-independent systems integrator such as werob orchestrates such heterogeneous fleets across more than 44 OEM partners. That leaves operators in full control of specification, acceptance and the deterministic protection of their floors.