El riesgo depende de la aplicación, no solo del robot

Un robot móvil autónomo (AMR, por sus siglas en inglés) puede trasladar materiales, pero esa descripción no basta para determinar si una instalación será segura. Hay que mirar el sistema completo: el vehículo, la carga, los equipos acoplados, las rutas, las personas que comparten el espacio y la forma en que se gestiona el tráfico. Una misma unidad puede plantear cuestiones distintas al transportar una carga voluminosa, circular junto a peatones o atravesar una zona con visibilidad limitada. Por eso, la pregunta útil no es «¿es seguro este modelo?» en abstracto, sino «¿se han identificado y controlado los riesgos de esta tarea y este entorno?»

Como criterio práctico, vincule la evaluación a las tareas concretas y a las condiciones del lugar de trabajo. Documente el uso previsto y los usos previsibles que puedan cambiar el escenario: circulación con carga y sin ella, recarga, limpieza, mantenimiento, recuperación tras una parada y cambios de turno. Anote quién controla cada actividad y quién puede modificar rutas, parámetros o accesorios. La seguridad debe evaluarse en el despliegue concreto, no darse por supuesta a partir de una etiqueta comercial.

Esta relación entre tarea, condición y responsable ayuda a detectar lagunas. Una función puede estar descrita para el vehículo, pero no responder a las necesidades de una zona con cruces frecuentes o a una configuración en la que un accesorio cambie el contorno de la carga. La evaluación debe considerar el conjunto que realmente se instalará y las actividades que se realizarán, no únicamente la unidad en una configuración abstracta.

Delimite el alcance y compruebe qué requisitos corresponden

No dé por hecho que todos los equipos llamados AMR quedan cubiertos por los mismos requisitos. Pida al fabricante que identifique la categoría del equipo, el marco técnico que ha utilizado y las exclusiones o límites que considera pertinentes. La denominación comercial, por sí sola, no demuestra que una norma concreta resulte aplicable a un producto o a una integración determinada. Para decidirlo hacen falta el alcance documentado, la configuración y las condiciones de uso.

También deben separarse tres preguntas: qué exige la ley del mercado donde se instala la máquina, qué referencia técnica se empleó para diseñarla o verificarla y qué revisión adicional requiere la integración local. En la Unión Europea, EUR-Lex indica que el Reglamento (UE) 2023/1230 sustituye a la Directiva de máquinas y que esta seguirá siendo aplicable hasta el 19 de enero de 2027. Compruebe el régimen y las disposiciones pertinentes para la fecha y el caso concretos; una referencia a una norma no demuestra por sí sola conformidad legal.

La documentación debe permitir entender qué equipo, versión y situación se evaluaron. Si una propuesta cita una norma o una certificación, pida que precise la edición, el alcance y la configuración a la que se refiere. No trate una referencia general como una conclusión automática sobre la seguridad del despliegue previsto: esa conclusión depende de su correspondencia con la instalación real y de los requisitos aplicables.

Pida evidencia trazable, no solo una declaración comercial

Solicite documentación que permita entender qué se evaluó y en qué configuración. Conviene pedir la identificación del modelo y sus variantes, el uso previsto, las limitaciones de operación, las cargas contempladas, las condiciones ambientales asumidas y los criterios utilizados. Si el proveedor afirma que una función reduce un riesgo, pida que describa la función, las condiciones necesarias para que opere y cómo se verificó. Una declaración genérica de «detección de obstáculos» no aclara qué obstáculos reconoce ni qué ocurre si un sensor se ensucia, queda tapado o trabaja fuera de sus condiciones especificadas.

Revise las funciones de seguridad y las dependencias de las que puedan depender. Pregunte qué estado adopta el equipo ante pérdida de comunicación, fallo de un sensor, error de localización, batería insuficiente o una orden de parada. Solicite resultados de pruebas pertinentes y las restricciones asociadas, en vez de inferir el comportamiento a partir del nombre de una función. Si el proveedor atribuye una protección a un sensor o a un ajuste, pida la descripción de su cobertura, sus límites y las condiciones necesarias para mantenerla.

Compruebe quién ha elaborado cada documento y a qué unidad corresponde. Un informe referido a una familia de productos no necesariamente cubre todos los accesorios, las versiones de software, las configuraciones de carga o los cambios hechos por el integrador. Registre el modelo, el número de serie cuando proceda, la versión y la configuración evaluada. Si falta esa trazabilidad, no se demuestra por ello que el equipo sea inseguro; significa que la documentación disponible no permite confirmar que la evaluación citada cubra la instalación propuesta.

Evalúe rutas, personas y respuesta ante fallos

Recorra las rutas reales, no solo el plano previsto. Identifique cruces, puertas, esquinas, zonas de carga y descarga, puntos ciegos, superficies irregulares y lugares donde se acumulan materiales. Valore también la interacción con personas que no participan directamente en la operación, visitas y otros vehículos. Para cada escenario, pregunte qué peligro puede aparecer, quién podría quedar expuesto y qué medida evita o reduce el riesgo. Incluya el uso normal y tareas no rutinarias, como retirar un objeto atascado o volver a poner en marcha el sistema tras una parada.

No suponga que una velocidad máxima por sí sola resuelve el problema. La carga, la visibilidad, el estado del suelo y las condiciones de tránsito pueden cambiar el escenario. Pida que se expliquen las condiciones y límites asociados a la navegación y a cualquier zona de velocidad reducida. No hay base aquí para fijar distancias, velocidades o niveles de rendimiento universales; esos valores deben corresponder al equipo, la aplicación y la evidencia disponible.

Defina qué ocurre ante fallos previsibles y quién puede rearmar el equipo. Aclare cómo se señala una parada, cómo se evita que una persona entre en una zona de riesgo durante una intervención y qué procedimiento permite reanudar la operación. Compruebe si la parada de un vehículo puede afectar a otros equipos o al tráfico de la instalación y establezca cómo se informa del fallo a la persona responsable. Una parada debe encajar en un procedimiento comprensible y practicable, no limitarse a una función técnica que el personal no sabe identificar o utilizar.

Planifique una aceptación verificable y el seguimiento

Antes de la puesta en servicio, redacte un protocolo de aceptación con escenarios observables y resultados esperados. Incluya rutas habituales, intersecciones, maniobras de carga y descarga y situaciones de interrupción que puedan probarse sin exponer a personas a un peligro. Defina quién presencia cada prueba, qué configuración se ensaya, qué criterio determina que se supera y dónde se archiva el resultado. Si una función no puede probarse de forma segura en el lugar, acuerde un método alternativo documentado con el proveedor y la persona responsable de seguridad; no improvise una prueba de contacto o de fallo real.

La aceptación no cierra la evaluación. Establezca un control de cambios para modificaciones de ruta, software, carga, velocidad configurada, sensores, equipos acoplados y organización del trabajo. Antes de permitir un cambio, determine si altera los supuestos de la evaluación previa y si requiere revisión o nuevas pruebas. Asigne responsables de inspecciones, mantenimiento y gestión de incidentes, y conserve un registro de desviaciones, paradas y medidas correctivas para poder revisar si los controles siguen siendo adecuados.

Use una regla de decisión sencilla: avance cuando el uso previsto esté delimitado, los riesgos y controles estén documentados, la evidencia corresponda al modelo y la configuración ofrecidos, y las pruebas de aceptación hayan dado resultados satisfactorios. Si hay vacíos, conviértalos en condiciones previas con responsable y fecha, o suspenda la integración hasta resolverlos. La falta de documentación no prueba por sí misma un fallo técnico, pero sí impide verificar una afirmación de seguridad. La distinción permite pedir evidencia concreta en vez de confiar en promesas o rechazar equipos por impresiones.