Risk depends on the application, not just the robot
An autonomous mobile robot (AMR) can move materials, but that description alone is not enough to determine whether an installation will be safe. Consider the complete system: the vehicle, its load, attached equipment, routes, people sharing the space and the way traffic is managed. The same unit may raise different questions when carrying a bulky load, travelling alongside pedestrians or passing through an area with limited visibility. So the useful question is not “Is this model safe?” in the abstract, but “Have the risks of this task and environment been identified and controlled?”
As a practical principle, link the assessment to specific tasks and workplace conditions. Document the intended use and foreseeable uses that could change the scenario: travelling with and without a load, charging, cleaning, maintenance, recovery after a stop and shift changes. Record who controls each activity and who can change routes, parameters or accessories. Safety must be assessed in the specific deployment, rather than assumed on the basis of a sales label.
Connecting task, condition and responsible person helps expose gaps. A function may be described for the vehicle but fail to address the needs of an area with frequent crossings, or a configuration in which an accessory changes the outline of the load. The assessment should cover the complete system that will actually be installed and the activities that will actually take place—not just the unit in an abstract configuration.
Define the scope and check which requirements apply
Do not assume that every piece of equipment called an AMR is covered by the same requirements. Ask the manufacturer to identify the equipment category, the technical framework used and any relevant exclusions or limits. A commercial name alone does not prove that a particular standard applies to a product or a specific integration. Deciding this requires documented scope, configuration and conditions of use.
Keep three questions separate: what the law requires in the market where the machine is installed; which technical reference was used to design or verify it; and what additional review the local integration requires. In the European Union, EUR-Lex states that Regulation (EU) 2023/1230 replaces the Machinery Directive, which remains applicable until 19 January 2027. Check the applicable regime and provisions for the specific date and case; citing a standard does not, by itself, demonstrate legal conformity.
The documentation should make it possible to understand which equipment, version and situation were assessed. If a proposal cites a standard or certification, ask for the edition, scope and configuration it covers. Do not treat a general reference as an automatic conclusion about the safety of the planned deployment: that conclusion depends on how well it matches the actual installation and on the applicable requirements.
Request traceable evidence, not just a sales claim
Request documentation that explains what was assessed and in which configuration. It is useful to ask for the model and variant identification, intended use, operating limitations, loads considered, assumed environmental conditions and criteria used. If the supplier claims that a function reduces a risk, ask for a description of the function, the conditions required for it to operate and how it was verified. A generic statement about “obstacle detection” does not clarify which obstacles are recognised or what happens if a sensor becomes dirty, is blocked or operates outside its specified conditions.
Review the safety functions and any dependencies they may have. Ask what state the equipment enters after a loss of communication, sensor failure, localisation error, low battery or stop command. Request relevant test results and associated restrictions rather than inferring behaviour from the name of a function. If the supplier attributes a protective effect to a sensor or setting, ask for its coverage, limits and the conditions needed to maintain that protection.
Check who prepared each document and which unit it concerns. A report covering a product family does not necessarily cover every accessory, software version, load configuration or change made by the integrator. Record the model, serial number where applicable, version and assessed configuration. If traceability is missing, that does not prove the equipment is unsafe; it means the available documents cannot confirm that the cited assessment covers the proposed installation.
Assess routes, people and responses to failures
Walk the actual routes, not just the planned map. Identify crossings, doors, corners, loading and unloading areas, blind spots, uneven surfaces and places where materials accumulate. Also consider interaction with people who are not directly involved in the operation, visitors and other vehicles. For each scenario, ask what hazard could arise, who might be exposed and what measure prevents or reduces the risk. Include normal use and non-routine tasks, such as removing a jammed object or restarting the system after a stop.
Do not assume that a maximum speed alone solves the problem. The load, visibility, floor condition and traffic conditions can change the scenario. Ask for an explanation of the conditions and limits associated with navigation and any reduced-speed zones. There is no basis here for setting universal distances, speeds or performance levels; those values must correspond to the equipment, application and available evidence.
Define what happens in foreseeable failures and who can reset the equipment. Clarify how a stop is signalled, how a person is prevented from entering a hazardous area during an intervention and what procedure allows operation to resume. Check whether one vehicle stopping could affect other equipment or site traffic, and establish how the responsible person is notified of the fault. A stop must fit into a clear and workable procedure, rather than being merely a technical function that staff do not know how to identify or use.
Plan verifiable acceptance and follow-up
Before commissioning, write an acceptance protocol with observable scenarios and expected results. Include usual routes, intersections, loading and unloading manoeuvres, and interruption scenarios that can be tested without exposing people to danger. Define who witnesses each test, which configuration is tested, what criterion counts as a pass and where the result is filed. If a function cannot be tested safely on site, agree on a documented alternative method with the supplier and the person responsible for safety; do not improvise a contact test or an actual-failure test.
Acceptance does not end the assessment. Establish change control for route, software, load, configured speed, sensors, attached equipment and work organisation changes. Before allowing a change, determine whether it affects the assumptions underlying the previous assessment and whether a review or new tests are needed. Assign responsibility for inspections, maintenance and incident management, and keep a record of deviations, stops and corrective measures so you can review whether the controls remain adequate.
Use a simple decision rule: proceed when intended use is defined, risks and controls are documented, the evidence matches the model and configuration offered, and acceptance tests have produced satisfactory results. If there are gaps, turn them into prerequisites with an owner and deadline, or suspend integration until they are resolved. Missing documentation does not, by itself, prove a technical failure, but it does prevent verification of a safety claim. This distinction makes it possible to request specific evidence instead of relying on promises or rejecting equipment based on impressions.