La IA en la evaluación de riesgos de máquinas ha entrado en planta con una promesa seductora: menos tiempo, mejor redacción, tablas completas en segundos. Y sí, puede ahorrar trabajo. Pero aquí va la verdad incómoda: una tabla impecable no es una evaluación de riesgos conforme a ISO 12100. Si la IA trabaja sin contexto real de la máquina, de las tareas, de los accesos y de las decisiones de diseño, no analiza; adivina. Y en seguridad de máquinas, adivinar con estilo sigue siendo adivinar. El valor de una buena evaluación no está en cuántas filas tiene, sino en si deja una trazabilidad de las decisiones que permita entender por qué se eligió una medida de protección y no otra.
IA en la evaluación de riesgos de máquinas: el viejo error, más rápido
Durante años, muchas evaluaciones de riesgos de máquinas fueron un ritual conocido: hoja de cálculo, lista de peligros, consecuencias genéricas, medidas de protección estándar y, al final, reducción del riesgo casi automática. El documento existía. Las casillas estaban llenas. Los colores quedaban bien. Pero a menudo faltaba lo esencial: el vínculo real entre el peligro, la tarea humana, la fase de vida de la máquina, la situación peligrosa y el suceso peligroso.
Ese era el problema de fondo. No la herramienta. No la hoja de cálculo. El problema era confundir un documento con un proceso de ingeniería. Hoy la IA permite cometer el mismo error más deprisa y con mejor apariencia. Antes una mala tabla delataba sus costuras: frases copiadas, fórmulas repetidas, medidas de protección puestas por inercia. Ahora el texto puede sonar maduro, coherente y técnicamente correcto. Ahí está el riesgo. Ya no parece flojo. Parece serio.
ISO 12100 no describe el arte de fabricar documentos que suenan técnicos. Describe una metodología para lograr seguridad en el diseño de máquinas mediante evaluación de riesgos y reducción del riesgo. Eso exige entender cómo se usa realmente la máquina, cómo se limpia, cómo se regula, cómo se mantiene, qué pasa en una avería, qué hace el operador en un cambio de formato y qué acaba haciendo el equipo de mantenimiento cuando la realidad aprieta. Si eso no está en la base, la tabla podrá ser bonita, pero seguirá vacía por dentro.
Y conviene decirlo sin rodeos: una lista de peligros generada automáticamente no demuestra que alguien haya pensado. Solo demuestra que alguien ha pedido texto.
ISO 12100 no empieza por la lista de peligros
Uno de los errores más habituales es arrancar con una pregunta demasiado pobre: ¿qué peligros tiene la máquina? Suena razonable, pero se queda corta. Una máquina puede tener partes móviles, energía eléctrica, neumática, superficies calientes, ruido o aristas vivas. Perfecto. Eso todavía no es una evaluación de riesgos. Es, como mucho, un catálogo de posibilidades.
El riesgo aparece cuando ese peligro se cruza con una persona, una tarea, una fase de vida y unas condiciones reales. Un mecanismo puede estar totalmente aislado en funcionamiento automático y convertirse en crítico durante la limpieza. Un eje puede no ser relevante en producción normal y serlo durante el ajuste en modo manual. Un resguardo puede proteger en condiciones ideales y fracasar en cuanto el trabajo real empuja a la elusión de protecciones.
La pregunta útil no es solo qué peligro existe. La pregunta útil es esta: quién, durante qué tarea, en qué fase de vida de la máquina y en qué condiciones puede entrar en una situación peligrosa. A partir de ahí sí tiene sentido seguir tirando del hilo. ¿Qué puede iniciar el suceso peligroso? ¿Un arranque inesperado? ¿Una pérdida de estabilidad? ¿La liberación de energía residual? ¿Un atasco? ¿Un error de lógica de control? ¿Mala visibilidad? ¿Presión de producción? ¿Trabajo en solitario? ¿Un acceso mal diseñado?
Aquí además conviene no simplificar en exceso. Hay escenarios que nacen de la tarea: limpiar, regular, cambiar formato, retirar un atasco, diagnosticar, intervenir en mantenimiento. Y hay escenarios que nacen del evento: rotura de un conducto, pérdida de energía, fallo de control, caída de carga, liberación de un elemento. Una evaluación sólida sabe trabajar en ambos sentidos. La máquina real no siempre cabe en una cadena rígida del tipo tarea, situación, suceso y medida. Forzar todos los casos en una única fila cómoda es una receta perfecta para dejar fuera lo importante.
IA en la evaluación de riesgos de máquinas: cuándo ayuda de verdad
La IA puede ser muy útil. Pero solo si entra en escena como asistente del proceso, no como sustituto del proceso. Cuando recibe información real de la máquina, puede acelerar mucho trabajo útil y bastante ingrato.
Lo que sí puede hacer bien
- Comprobar si faltan fases de vida de la máquina, tareas o perfiles de usuario.
- Plantear preguntas de control sobre limpieza, atascos, acceso en modo manual, cambio de formato, mantenimiento o uso indebido razonablemente previsible.
- Ayudar a ordenar escenarios, justificar decisiones y mantener terminología consistente.
- Detectar incoherencias entre el peligro identificado, la medida de protección elegida y el riesgo residual declarado.
- Comparar escenarios similares para ver si el criterio aplicado es estable o caprichoso.
Eso tiene valor. Mucho valor, de hecho. Porque obliga a pensar y ayuda a no dejar huecos.
Lo que no debe hacer sola
- Inventar frecuencias de exposición o asumir cómo trabaja de verdad un operador.
- Decidir la reducción del riesgo sin datos sobre accesos, tiempos de parada, modos de funcionamiento y secuencias de movimiento.
- Dar por buena una instrucción, una formación o un procedimiento LOTO como si fueran remedios universales.
- Bajar el riesgo residual porque la tabla pide una última columna más tranquila.
- Sustituir la observación de la máquina real, la conversación con diseño, producción y mantenimiento, o la revisión del uso efectivo.
Si la IA responde antes de que existan datos sólidos, no está evaluando. Está rellenando huecos con probabilidad estadística. Y en seguridad de máquinas eso es peligrosamente convincente.
Una instrucción a la IA no es una metodología ISO 12100
Existe otra tentación muy moderna: pensar que todo se arregla escribiendo una instrucción más larga y más sofisticada a la IA. Algo como considerar ISO 12100, todo el ciclo de vida, los peligros mecánicos, eléctricos, térmicos, ergonómicos, las medidas de protección y el riesgo residual. Sí, el resultado suele mejorar. Pero sigue sin resolver el problema principal. Una instrucción mejor no crea hechos que nadie ha recogido.
La IA no sabe que el panel está en el lado equivocado y obliga al operador a observar el movimiento desde un punto no previsto. No sabe que un resguardo pesa tanto que al cabo de dos semanas se deja abierto. No sabe que la limpieza exige una herramienta que nadie usa porque hace perder tiempo. No sabe que la instrucción habla de dos personas y en la práctica siempre trabaja una. No sabe que un cambio de formato teórico ocasional se repite varias veces por turno. No sabe que una avería considerada rara para diseño es el pan de cada lunes para mantenimiento.
Ese tipo de detalle no es anecdótico. Es justo donde suelen nacer los accidentes, las desviaciones y la mala ingeniería defensiva. Por eso la mejor aplicación de la IA en este campo no es pedirle que redacte una evaluación cerrada, sino pedirle que obligue a formular preguntas incómodas. ¿Se ha considerado la limpieza? ¿Hay acceso a la zona de movimiento durante la retirada de un atasco? ¿Esta tarea es realmente de mantenimiento o la hace el operador en producción normal? ¿La reducción del riesgo se basa en diseño intrínsecamente seguro, en medidas de protección técnicas o solo en información para el usuario?
Cuando la herramienta hace mejores preguntas, aporta valor. Cuando fabrica respuestas sin contexto, fabrica apariencia.
Ejemplo práctico: sensor de horquilla en un slitter
Vamos a un caso muy de planta. En un slitter, una cortadora longitudinal, un sensor de horquilla detecta la posición de la banda. Al cambiar el ancho del material, el operador tiene que mover ese sensor. El problema es que el punto de ajuste está dentro de una zona peligrosa: rodillos, puntos de arrastre, ejes, banda tensionada y, según el diseño, elementos de corte cercanos.
¿Qué suele responder una IA si se le da una descripción general? Algo bastante estándar: aplicar LOTO, formar al operador, señalizar la zona peligrosa, usar equipos de protección individual, incorporar instrucciones de cambio de formato, añadir resguardos y disponer de parada de emergencia. Suena correcto. Suena profesional. Y, sin embargo, puede ser una salida documental que esquiva el núcleo del problema.
La pregunta importante no es cómo describir el acceso a la zona peligrosa. La pregunta importante es por qué el operador tiene que entrar ahí para realizar un cambio de formato normal. Si esa regulación forma parte del trabajo repetitivo de producción, tratarla como si fuera una intervención excepcional de servicio es autoengaño. Meter LOTO en la fila no arregla nada si en la práctica nadie va a aislar energías varias veces por turno para una acción que el diseño ha convertido en rutinaria.
La jerarquía de reducción del riesgo importa. Primero toca preguntarse por el diseño intrínsecamente seguro. ¿Puede ajustarse el sensor desde fuera de la zona peligrosa? ¿Puede añadirse una guía externa? ¿Una escala mecánica? ¿Posiciones por receta? ¿Otro principio de detección que evite la intervención manual? ¿Puede reubicarse el soporte? ¿Puede cambiarse la secuencia de ajuste para no exigir proximidad al movimiento?
Solo si esa vía no elimina el problema tiene sentido bajar al siguiente escalón: medidas de protección técnicas. Ahí entran opciones como un resguardo con enclavamiento y bloqueo, un modo de ajuste con velocidad limitada, una parada segura, un dispositivo de validación o condiciones de acceso controladas. Y solo al final encajan la instrucción, la formación y las advertencias. Al revés, no. ISO 12100 no empieza por formar al operador para convivir con un mal diseño.
Este ejemplo resume el gran límite de la automatización textual. La IA tenderá a proponer un paquete genérico que queda bien escrito. Un ingeniero serio debe ir a la causa: ¿de verdad esta tarea debería exigir acceso a la zona peligrosa? Esa sola pregunta vale más que veinte filas perfectamente redactadas.
La trazabilidad de las decisiones vale más que una tabla bonita
Toda evaluación seria debería poder reconstruirse meses o años después. No solo leerse. Reconstruirse. ¿Por qué se asignó esa gravedad? ¿Por qué se consideró esa frecuencia de exposición? ¿Por qué se eligió esa medida de protección y no otra? ¿Por qué se aceptó ese riesgo residual? ¿Qué alternativa se descartó y por qué? Sin esa trazabilidad de las decisiones, la evaluación es frágil.
Y esa fragilidad aparece justo cuando más duele: en una auditoría, en una modificación de máquina, en una disputa con cliente, en una inspección o después de un incidente. En ese momento, frases como la IA lo generó así no sirven. Igual que antes no servía salió así en la hoja de cálculo. Hay que enseñar el razonamiento.
Aquí la IA puede jugar en los dos bandos. Si el proceso está bien armado, ayuda a documentar mejor, detectar lagunas y reforzar la coherencia. Si el proceso no existe, genera una niebla elegante: más texto, mejor estilo, menos claridad real. El documento crece, la defensa técnica no.
Por eso merece la pena imponer un proceso repetible. No para que todas las evaluaciones sean iguales, sino para que todas recorran los mismos pasos: límites de la máquina, fases de vida, tareas, situaciones peligrosas y/o sucesos peligrosos, daños posibles, estimación, evaluación, reducción del riesgo, riesgo residual y justificación. Lo que debe cambiar es la máquina. No el rigor del camino.
AI Act y funciones de seguridad: otra liga
Hay además una frontera que no conviene confundir. Una cosa es usar IA para apoyar el trabajo del ingeniero. Otra muy distinta es usar IA o aprendizaje automático dentro de la propia máquina para desempeñar una función de seguridad. Ahí cambian las reglas, la exigencia técnica y el nivel de escrutinio.
El Reglamento (UE) 2023/1230 deja claro que el fabricante debe realizar la evaluación de riesgos para determinar los requisitos esenciales de salud y seguridad aplicables y definir las medidas necesarias. Esa obligación no se delega en un modelo de lenguaje. Además, cuando entran en juego sistemas con comportamiento autoevolutivo que proporcionan funciones de seguridad, el asunto pasa a una categoría especial de evaluación de conformidad. No es un detalle burocrático. Es la consecuencia lógica de meter variabilidad, dependencia de datos y opacidad en una función donde el fallo puede causar daño.
El AI Act refuerza exactamente esa lógica. Si un sistema de IA actúa como componente de seguridad de un producto cubierto por legislación armonizada de la Unión o el producto requiere evaluación de conformidad por un tercero, puede entrar en la categoría de alto riesgo. Y eso implica gestión continua del riesgo durante todo el ciclo de vida, supervisión humana efectiva, requisitos de exactitud, solidez, ciberseguridad y capacidad de funcionar de forma segura también cuando algo va mal.
Dicho de forma práctica: no basta con afirmar que el modelo acierta el 95 % de las veces. En seguridad, la pregunta incómoda siempre es la misma: ¿qué ocurre en el otro 5 %? ¿Qué pasa si no detecta a una persona? ¿Qué pasa si cambia la iluminación, aparece suciedad en el sensor, vibra la estructura, entra un material no previsto o falla una entrada? ¿Qué pasa si el sistema se comporta de forma distinta tras una actualización o por deriva en los datos? Eso no es filosofía. Es ingeniería de seguridad.
Cuanto más cerca esté la IA de una función de seguridad, menos espacio queda para la fe y más espacio ocupan la validación, la evaluación de conformidad, la robustez técnica y la supervisión humana. Ahí ya no hablamos de una ayuda para redactar. Hablamos de un elemento cuyo error puede lesionar a alguien.
Conclusión
La IA sí tiene sitio en la evaluación de riesgos de máquinas. Pero como asistente del ingeniero, no como autora de la responsabilidad. Su mejor versión no es la que entrega una tabla en diez segundos, sino la que obliga a mirar mejor la máquina, a cuestionar supuestos y a dejar una trazabilidad de las decisiones limpia y defendible.
Si la herramienta evita preguntas incómodas, empeora el trabajo. Si obliga a formularlas, puede mejorar mucho el proceso. Ese es el criterio útil. En seguridad de máquinas, el objetivo nunca ha sido rellenar celdas. El objetivo es entender dónde se encuentra la persona con el peligro, qué puede desencadenar el daño y cómo debe responder el diseño para reducir el riesgo de verdad. Todo lo demás es decoración documental.