El peor fallo en un Ejemplo de evaluación de riesgos según ISO 12100 no es el caos. Es justo lo contrario: el orden bonito. La tabla impecable. La puntuación pulida. Las referencias a normas. El PDF final que le da al equipo esa falsa sensación de asunto cerrado. Pero ISO 12100 no valora si el documento queda elegante. Valora si alguien ha hecho de verdad el proceso de seguridad. Y ahí es donde se abre la grieta.
Una hoja puede almacenar datos. Lo que no hace por sí sola es vigilar la lógica. No obliga a pasar de los límites de la máquina a las tareas reales. No te recuerda que una medida de protección puede generar un riesgo secundario. No mantiene una trazabilidad de decisiones sólida. No deja claro quién aceptó el riesgo inicial, quién cambió la valoración final y por qué una función de seguridad acabó con un requisito de PL d y no con otro. Esa diferencia, aunque a veces se disimule muy bien, es la que separa una tabla de una evaluación de riesgos defendible.
Ejemplo de evaluación de riesgos según ISO 12100: qué demuestra de verdad
Un buen ejemplo no arranca rellenando casillas. Arranca poniendo límites. ¿Para qué se ha diseñado la máquina? ¿Quién la usa? ¿Qué tareas se van a realizar de verdad? ¿Qué acceso existe durante producción, ajuste, limpieza, retirada de atascos, mantenimiento o diagnóstico? ¿Qué fuentes de energía intervienen? Si eso no está claro, la evaluación ya nace torcida.
ISO 12100 tampoco permite jugar al atajo favorito del sector: ver un peligro y saltar directamente a un resguardo, a un procedimiento o a una instrucción. La lógica de reducción del riesgo tiene orden, y ese orden importa. Primero, diseño intrínsecamente seguro. Después, medidas de protección técnicas. Y solo después, información para el uso. Cuando esa secuencia se rompe, el documento puede seguir pareciendo profesional, pero la ingeniería ya va coja.
Por eso una evaluación seria no describe la máquina en general. Describe la relación entre la persona, la máquina y el proceso en situaciones concretas. No evalúa una línea automática como bloque abstracto. Evalúa la mano que entra para retirar un atasco, el técnico que abre el armario eléctrico para diagnosticar una avería, el operario que rearma tras una intervención, el mantenedor que aísla energía neumática y el escenario en el que aparece un arranque no intencionado.
Excel no es documentación de la evaluación de riesgos
Se puede hacer una evaluación de riesgos en Excel. Claro que se puede. Igual que se puede construir un documento que durante un rato parezca creíble. La pregunta útil no es si cabe en una hoja. La pregunta es otra: ¿esa hoja sostiene un proceso que luego puedas reconstruir, verificar y defender?
ISO 12100 no exige Excel. Exige documentación de la evaluación de riesgos. No es lo mismo. Una hoja puede servir como cuaderno de trabajo, como apoyo del equipo o como borrador ordenado. Puede contener peligros, puntuaciones, medidas de protección, comentarios y referencias a normas. Aun así, seguir siendo solo eso: datos de trabajo.
La documentación de la evaluación de riesgos tiene que mostrar, como mínimo, lo siguiente:
- de qué hipótesis se partió;
- cuáles eran los límites de la máquina;
- qué tareas y qué situaciones peligrosas se analizaron;
- qué sucesos peligrosos se consideraron;
- cómo se hizo la estimación del riesgo;
- qué medida de protección se seleccionó y en qué orden se aplicó;
- si apareció riesgo secundario tras la reducción del riesgo;
- cómo se valoró el riesgo residual;
- quién tomó cada decisión relevante.
Ese es el problema real. No que Excel sea simple. Sino que permite fingir con demasiada facilidad que la documentación ya existe cuando en realidad solo existe un archivo bien presentado. Y si mañana tienes que sostener el expediente CE o explicar por qué se aceptó un escenario concreto, el PDF bonito no te rescata.
La diferencia entre administración e ingeniería aparece justo aquí. La documentación de la evaluación de riesgos no es una colección de columnas. Es el registro de un proceso que debe poder seguirse hacia atrás. Si no puedes reconstruir el camino, no estás defendiendo una evaluación de riesgos. Estás defendiendo su última versión.
El riesgo secundario es donde muchas evaluaciones se rompen
Hay una idea peligrosa que sigue viva en demasiados proyectos: añadir una medida de protección y dar el asunto por cerrado. Error. Una medida de protección no cierra el proceso. Cambia el mapa del riesgo. A veces mejora mucho una parte y empeora otra. Y si eso no se vuelve a revisar, la documentación acaba describiendo un mundo más seguro que la planta real.
Ejemplo mecánico: el resguardo que reduce el acceso, pero empeora la intervención
Imagina una estación donde el principal problema es el acceso a movimiento peligroso durante retirada de atascos. El equipo instala un resguardo móvil con enclavamiento. Sobre el papel suena perfecto: durante el ciclo automático ya no se puede acceder libremente a la zona peligrosa.
Ahora mira la operación real. Para limpiar o desatascar, el operario debe introducir más el brazo, trabajar con peor visibilidad, adoptar una postura forzada y maniobrar por una abertura de servicio más estrecha. ¿Ha bajado el riesgo principal? Sí. ¿Ha aparecido otro problema de acceso, visibilidad y ergonomía? También. Eso es riesgo secundario. Y si no se registra ni se reevalúa, el documento cuenta solo media verdad.
Ejemplo de automatización: la función correcta que invita a puentear
Otro caso clásico. Se añade una función de seguridad con enclavamiento, bloqueo del rearranque automático y rearme manual. La lógica es correcta. El fallo no está en la función, sino en implantarla sin mirar cómo trabaja de verdad la gente.
Si cada intervención se alarga, si el rearme exige varios pasos, si el operario pierde ritmo y la producción aprieta, aparece un riesgo secundario organizativo y conductual. Rearmes hechos por reflejo, comprobaciones visuales pobres, intentos de puentear dispositivos de protección y presión para recuperar velocidad fuera de la secuencia segura. La función de seguridad puede estar bien diseñada y, aun así, estar mal integrada en el proceso humano.
Ejemplo eléctrico: la mejora parcial que desequilibra el conjunto
También pasa en la parte eléctrica. Se detecta un problema y alguien decide mejorar la seguridad con una conexión equipotencial añadida solo en una parte del equipo. La intención es buena. El resultado puede no serlo.
Si esa mejora se hace de forma fragmentaria, sin revisar el conjunto, puedes introducir diferencias de referencia entre partes de la máquina o empeorar escenarios transitorios en caso de fallo. Traducido al taller: una mejora local puede crear un escenario más peligroso para quien toca dos puntos del sistema al mismo tiempo. El riesgo de choque eléctrico puede haber bajado en una zona y haber empeorado en otra. Si no se ve el sistema completo, la corrección técnica se convierte en una trampa.
Los tres ejemplos enseñan la misma lección. El problema no es que exista la medida de protección. El problema es no comprobar qué le ha hecho esa medida al resto del sistema persona-máquina-energía-proceso.
La trazabilidad de decisiones no es burocracia
La trazabilidad de decisiones no es un extra para auditorías. Es la memoria técnica del proyecto. Y sin memoria, todo se degrada muy rápido en una ficción ordenada.
En la práctica, el problema rara vez es que falte un resultado final. El resultado suele estar. También la tabla, la puntuación y la medida de protección. El agujero aparece cuando, una semana o un mes después, nadie sabe responder preguntas básicas:
- quién cambió una situación peligrosa de riesgo medio a riesgo bajo;
- por qué se aceptó un escenario sin reducción del riesgo adicional;
- si la nueva valoración se debe a una medida de protección real o a un ajuste de criterio;
- qué función de seguridad concreta debía cumplir el requisito de PL d;
- por qué se tomó esa decisión y no otra.
Ese punto es crítico. El documento final muestra el resultado. La trazabilidad de decisiones muestra el camino. Y en seguridad de máquinas el camino importa tanto como la meta.
Piensa en tres situaciones muy corrientes. Primera: alguien rebaja la estimación del riesgo y un mes después nadie sabe por qué. Segunda: aparece un riesgo bajo aceptable, pero nadie puede justificar si se aceptó por baja frecuencia de exposición, baja severidad, usuarios formados y condiciones controladas, o simplemente porque la cifra salía cómoda. Tercera: se anota ISO 13849 y PL d, todo queda impecable, pero nadie puede explicar qué monitoriza exactamente esa función de seguridad, qué detiene, en qué condición actúa y por qué ese nivel de fiabilidad era el correcto.
Sin trazabilidad de decisiones, esas tres situaciones parecen similares en pantalla. Técnicamente no lo son. En un caso hay criterio. En el otro hay maquillaje.
Ejemplo de evaluación de riesgos según ISO 12100 en una estación de embalaje automatizada
Vamos a bajar esto a tierra. Tomemos una estación de embalaje automatizada con movimientos peligrosos, intervenciones del operario, retirada de atascos, tareas de mantenimiento, acceso a energía eléctrica y neumática y varias funciones de seguridad ligadas a la lógica de control.
En un caso así, una evaluación seria no termina con dos o tres líneas genéricas sobre riesgo mecánico y riesgo eléctrico. Lo correcto es descomponer. En el ejemplo aparecieron dieciséis situaciones diferenciadas: trece escenarios de tarea y tres sucesos peligrosos según la lógica de ISO 12100.
Se analizaron por separado, entre otros, estos contextos:
- intervenciones menores durante funcionamiento;
- retirada de atascos;
- ajuste de dispositivos de protección;
- pruebas funcionales;
- aislamiento de energía;
- sustitución de componentes de desgaste;
- diagnóstico de averías;
- arranque no intencionado;
- proyección de objetos;
- liberación de energía neumática.
Ese nivel de desglose cambia completamente la lectura del riesgo. Deja de existir la máquina en abstracto y aparecen las relaciones reales con la persona usuaria. Ahí es donde se ve la verdad del sistema.
Qué enseñó el ejemplo en la práctica
Primero, el riesgo principal no venía solo de que hubiera movimiento peligroso. Venía del acceso a ese movimiento durante intervención, desatasco y diagnóstico. Ese matiz es decisivo. Porque obliga a diseñar la reducción del riesgo donde de verdad ocurre el contacto, no donde queda más vistoso en la documentación.
Segundo, no todos los escenarios pidieron el mismo tratamiento. Algunos pudieron aceptarse como riesgo bajo, pero no por inercia ni porque la puntuación saliera cómoda. Se aceptaron porque podían defenderse técnicamente: exposición poco frecuente, tarea muy acotada, efecto previsible bajo, condiciones controladas y rol de usuario bien definido.
Tercero, los escenarios con más peso dejaron claro que no bastaba escribir resguardo e instrucción. Hubo que concretar la función de seguridad, el bloqueo del rearranque, el rearme manual, las condiciones de acceso, la secuencia de intervención y la justificación del riesgo residual. Ahí apareció la diferencia real entre una hoja rellena y una evaluación de riesgos con contenido técnico.
Cuarto, la reevaluación fue imprescindible. Tras implantar medidas, hubo que revisar si se había creado riesgo secundario. Por ejemplo, si el nuevo resguardo complicaba el mantenimiento, si la lógica de rearme fomentaba hábitos inseguros o si el acceso a energía seguía siendo claro durante el aislamiento. Sin ese segundo paso, la reducción del riesgo se habría quedado a medio hacer.
Quinto, solo la trazabilidad de decisiones permitió entender quién aceptó qué y con qué base. Eso importa más de lo que a veces se reconoce. Cuando una decisión debe sostenerse frente a producción, mantenimiento, integración o marcado CE, la memoria técnica deja de ser un lujo y pasa a ser defensa básica.
Qué debe verse en una documentación de la evaluación de riesgos que se pueda defender
Si quieres saber si un documento es un buen ejemplo o solo un archivo aparente, haz una prueba simple. Busca si puedes leer con claridad todo esto:
- uso previsto y límites de la máquina;
- usuarios previstos y tareas reales;
- peligro identificado en cada zona o fase;
- situación peligrosa y suceso peligroso asociados;
- estimación del riesgo inicial;
- decisión sobre aceptación o reducción del riesgo;
- medida de protección aplicada en el orden correcto;
- revisión del posible riesgo secundario;
- valoración del riesgo residual;
- trazabilidad de decisiones de principio a fin.
Si eso no puede seguirse sin adivinar, no tienes una documentación sólida. Tienes un resumen incompleto. Y en seguridad de máquinas, lo incompleto sale caro. A veces en forma de retraso de proyecto. A veces en forma de modificación tardía. Y a veces en forma de accidente que ya estaba anunciado en la lógica rota del documento.
La conclusión es directa. Una evaluación de riesgos no vale porque tenga muchas columnas, números o referencias a ISO 12100 e ISO 13849. Vale si soporta preguntas incómodas. Qué se analizó. Qué se aceptó. Qué se redujo. Por qué. En qué orden. Qué cambió después de cada medida de protección. Qué riesgo residual quedó. Y quién asumió cada decisión.
Eso es lo que hace útil un Ejemplo de evaluación de riesgos según ISO 12100. No la cantidad de tablas. No el acabado del PDF. Sino la capacidad de mostrar, sin trucos y sin huecos, que el proceso existió de verdad.