Definir correctamente el evento top en BowTie industrial

Definir correctamente el evento top en BowTie no es un detalle semántico: es la decisión que separa un diagrama útil de una lámina decorativa. En muchas organizaciones, el problema no es que falte información; es que sobra causalidad mal ubicada, sobran ambigüedades y sobra confianza en un modelo que nadie puede usar para decidir en campo.

Un caso clásico es el de Buncefield, en 2005. Allí, un tanque de gasolina se sobrellenó y se generó una nube de vapor que terminó en una explosión masiva. Hubo 43 personas heridas y una devastación industrial de enorme costo. Si ese escenario se hubiera modelado como "falla del operador" o "falla del instrumento" en lugar de pérdida de contención por sobrellenado, el BowTie habría nacido mal: amenazas, barreras y consecuencias habrían quedado mezcladas desde el primer minuto.

Lo mismo pasó en Texas City en 2005. Durante un arranque, una secuencia de eventos terminó en una liberación de hidrocarburos y una explosión que dejó 15 muertos y más de 180 heridos. La investigación Baker dejó una lección incómoda para todos los niveles de la organización: el problema no fue un único error humano, sino un sistema que no había definido con precisión qué evento estaba tratando de evitar. Cuando el evento top está mal formulado, todo el BowTie pierde valor operacional.

Este artículo es el punto de partida de la serie. Acá vas a encontrar los fundamentos, el diagnóstico y los criterios para saber si tu organización está partiendo de una formulación demasiado amplia, ambigua o centrada en causas. Si querés ver luego el método operativo paso a paso, más adelante te conviene leer el paso a paso para identificar el evento top en BowTie. Y si ya sospechás que tus modelos tienen errores más sutiles, también vas a querer revisar los errores complejos al definir el evento top y cómo evitarlos.

Si el evento top está mal definido, el BowTie no falla por dibujo: falla por lógica.

Por qué definir correctamente el evento top en BowTie condiciona todo el modelo

En BowTie, el evento top es la frontera entre el control y la pérdida de control. No es la amenaza, no es la causa raíz, no es la consecuencia y tampoco es una barrera. Es el momento en el que el sistema sale de su condición segura y entra en una trayectoria de daño potencial. Todo lo que dibujás a la izquierda y a la derecha depende de que ese punto esté bien ubicado.

Si lo definís demasiado amplio, el modelo se vuelve vago. Si lo definís demasiado estrecho, perdés generalización y utilidad. Si lo definís como una causa, terminás investigando por qué ocurrió algo antes de haber aclarado qué es exactamente lo que querés evitar. Y si lo confundís con una consecuencia, ya llegaste tarde: estás nombrando el daño, no la pérdida de control.

Desde la perspectiva de PSM y disciplina operativa, esto no es una discusión académica. Un BowTie bien definido mejora la coherencia entre análisis de peligros, procedimientos operativos, gestión de barreras, investigación de incidentes y verificación en campo. Uno mal definido genera inconsistencias entre turnos, confusión entre áreas y falsas prioridades en mantenimiento, operaciones y HSE.

Evento top, amenaza, causa, consecuencia y barrera: no son lo mismo

La forma más simple de evitar errores es separar cada elemento por su función dentro del modelo. El evento top es la pérdida de control. La amenaza es el mecanismo que empuja hacia esa pérdida. La causa es el porqué de esa amenaza o de esa falla. La consecuencia es el daño posible si no frenás la secuencia. La barrera es lo que evita, detecta o mitiga el avance del evento.

Un ejemplo práctico: en una planta de amoníaco, "falla del compresor" es una causa o amenaza. "Liberación de amoníaco a atmósfera" suele ser el evento top o una consecuencia inmediata, según el alcance definido. "Exposición del personal" ya es consecuencia. Si el equipo no distingue estas capas, termina discutiendo palabras en lugar de gestionar barreras reales.

Qué dicen los estándares y por qué te conviene escucharlos

BowTie no reemplaza a los marcos normativos; los ordena. OSHA PSM 1910.119 exige análisis de riesgos de proceso, procedimientos operativos, integridad mecánica y gestión del cambio. API 754 separa indicadores Tier 1 a Tier 4 justamente para que no mezcles incidentes mayores con señales tempranas de pérdida de control. IEC 61511 te obliga a definir con claridad el evento peligroso que una función instrumentada de seguridad debe prevenir. ISO 45001 pide control operacional basado en riesgos. Y CCPS insiste en que las barreras solo son útiles si el escenario está bien formulado.

En otras palabras: si querés que un BowTie sirva para la dirección, para el supervisor de turno y para el operador de campo, el evento top tiene que ser comprensible, defendible y accionable. No alcanza con que suene técnico. Tiene que describir una pérdida de control que cualquier persona entrenada pueda reconocer en la operación.

Análisis profundo con casos reales

Las malas definiciones del evento top no se ven siempre en el dibujo. Se ven cuando el diagrama no ayuda a prevenir, no ayuda a investigar y no ayuda a priorizar recursos. Los siguientes casos muestran cómo una formulación incorrecta distorsiona la lógica del modelo y por qué la precisión conceptual importa tanto como el contenido técnico.

Caso 1: Buncefield, cuando el top event no era la falla del instrumento

Situación: en Buncefield, Reino Unido, un tanque de almacenamiento de gasolina fue sobrellenado durante una operación normal. El sistema de medición dejó de entregar una lectura confiable y las defensas existentes no evitaron el rebose. La nube de vapor se inflamó y produjo una explosión mayor, con 43 personas heridas y una devastación severa del sitio.

Problema: muchas organizaciones habrían definido el evento top como "falla del indicador de nivel" o "no detección del sobrellenado". Eso parece razonable, pero no lo es. Esas formulaciones describen una amenaza o una falla de barrera. El evento top correcto está más cerca de "sobrellenado del tanque con liberación de gasolina por pérdida de contención". Ahí sí estás describiendo la pérdida de control, no la causa.

Consecuencia: el modelo cambia por completo. Si el evento top es un instrumento fallado, las barreras parecen ser el propio instrumento, la inspección o la calibración. Si el evento top es el sobrellenado y la liberación, entonces necesitás pensar en alarmas, sistemas independientes de seguridad, límites operativos, contención y detección de vapor. La diferencia no es menor: es la diferencia entre una lista de tareas y una arquitectura de control.

Lección: el top event debe ubicarse en el instante de pérdida de control del peligro. Si lo colocás demasiado temprano, investigás mantenimiento. Si lo colocás demasiado tarde, ya estás en la consecuencia. Un BowTie útil te tiene que permitir contestar: ¿en qué momento exacto dejamos de estar seguros?

Caso 2: Texas City, cuando la causa humana se disfrazó de evento top

Situación: en la refinería de Texas City, en 2005, durante el arranque de una unidad de refinación, una secuencia de fallas técnicas, organizacionales y humanas llevó a una liberación de hidrocarburos y a una explosión de gran magnitud. El evento dejó 15 personas fallecidas y más de 180 heridas. La investigación Baker mostró problemas profundos de cultura, gobernanza y gestión de riesgo.

Problema: en muchas plantas, el BowTie para este tipo de escenario termina escrito como "error del operador durante el arranque" o "falla de cumplimiento del procedimiento". Eso es una explicación causal, no un evento top. La causa puede ser importante, pero si la ponés en el centro del BowTie, el modelo se vuelve moralizante: parece que el problema es que alguien no hizo bien su trabajo. El sistema desaparece del análisis.

Consecuencia: cuando el evento top se formula como una falla humana, los controles se diseñan para vigilar personas en lugar de controlar el proceso. Aparecen más firmas, más supervisión documental y más capacitación genérica, pero no necesariamente mejores barreras físicas, instrumentadas u organizacionales. El resultado es un BowTie que no mejora la prevención ni la resiliencia.

Lección: el evento top debe describir la pérdida de contención o la pérdida de una función crítica, no el fallo de una persona. El error humano existe, pero se entiende dentro del sistema: diseño, carga de trabajo, interfaces, alarmas, entrenamiento, supervisión y presión de producción. Si el BowTie culpará al operador, ya nació equivocado.

Qué une a los dos casos

En ambos eventos hubo fallas técnicas y humanas. Pero el BowTie no debe convertir esas fallas en el centro del análisis. Su función es separar el mecanismo de la pérdida de control. Esa separación es la que permite elegir barreras correctas, definir desempeño esperado y conectar la gestión de riesgo con la operación diaria.

Si hoy tu organización usa BowTie para todo, desde seguridad de procesos hasta actos subestándar, hacete una pregunta simple: ¿el evento top representa una liberación o una pérdida de contención, o está describiendo una conducta, una causa o una deficiencia de gestión? Si la respuesta es lo segundo, estás mezclando capas.

Cuando este diagnóstico te quede claro, vas a estar listo para el método operativo de la serie. Ahí entra el artículo Paso a paso para identificar el evento top en un BowTie, donde bajamos esto a una secuencia concreta de trabajo con equipos multidisciplinarios.

Diagnóstico organizacional: señales de alerta de una mala formulación

La forma más rápida de auditar el estado actual de tus BowTies no es preguntarte si están bonitos. Es preguntarte si sobreviven a una prueba de sentido común. Si un operador, un supervisor y un ingeniero no pueden ponerse de acuerdo sobre cuándo ocurre el evento top, tenés un problema de definición, no de diseño gráfico.

Señales de alerta que no deberías ignorar

• Ambigüedad: el evento top usa palabras como "falla", "pérdida de control" o "incidente" sin especificar qué se perdió y en qué estado.
• Exceso de detalle: el modelo entra al número de válvula, tag del sensor o paso del procedimiento, y pierde la lógica del escenario.
• Foco en causa: aparecen frases como "error del operador", "falla de mantenimiento" o "mala ejecución", que describen por qué pasó, no qué pasó.
• Foco en consecuencia: el supuesto evento top ya es el incendio, la lesión o el derrame final.
• Barriera mal ubicada: una salvaguarda aparece como si fuera el evento central, o el evento top se confunde con la falla de la salvaguarda.
• Inconsistencia entre áreas: operaciones, mantenimiento y HSE usan nombres distintos para el mismo escenario.
• Imposibilidad de medir: no podés asociar indicadores, pruebas de barrera o alertas operativas al evento top porque no está claro dónde empieza y termina.
• Desconexión con API 754: tus eventos top no te permiten clasificar ni priorizar señales Tier 1 a Tier 4.

Preguntas de autoevaluación por rol

Para directores y gerentes: ¿están usando BowTie para gobernar riesgos críticos o solo para cumplir auditorías? ¿Saben cuántos BowTies tienen dueño, versión y criterio de revisión? ¿Pueden vincular los escenarios de mayor riesgo con indicadores de barreras y aprendizaje de incidentes?

Para mandos medios y supervisores: ¿tu equipo puede explicar el evento top en menos de 30 segundos? ¿Las barreras se verifican en campo, o solo existen en el software? ¿Cada desviación de turno tiene una relación clara con el BowTie correspondiente?

Para operadores: ¿sabés reconocer la señal temprana que te dice que el escenario está acercándose al evento top? ¿Tenés claro qué barrera debe actuar primero? ¿Podés detener la tarea o pedir ayuda antes de que la pérdida de control ocurra?

Si marcaste varias señales de alerta, no significa que tu organización esté "mal". Significa que todavía no tiene una convención robusta para definir el evento top. Y eso, lejos de ser un fracaso, es una oportunidad de mejora estructural.

Acá es donde cobra sentido revisar los errores complejos al definir el evento top y cómo evitarlos, porque muchas veces el problema no es obvio: es una mezcla de semántica, cultura y gobernanza.

Solución y metodología para empezar a corregirlo

Definir correctamente el evento top en BowTie no requiere magia; requiere disciplina. La idea es llevar el equipo desde una redacción intuitiva hacia una formulación defendible, repetible y útil. Para eso, conviene trabajar con una secuencia clara y con criterios de validación simples.

Pasos concretos para construir o corregir el evento top

1. Partí del peligro y del daño potencial. Identificá la fuente de energía, sustancia o situación peligrosa. No empieces por la causa humana.
2. Definí el momento de pérdida de control. Preguntate: ¿cuándo deja de estar controlado el proceso? Ahí suele aparecer el evento top.
3. Redactalo sin culpas ni soluciones. Evitá verbos como "no cumplir", "fallar", "olvidar" o "equivocarse" si describen causas. El evento top debe ser un estado o una pérdida, no una conducta.
4. Probalo contra tres tests. ¿Es anterior a la consecuencia? ¿Es posterior a la amenaza? ¿Puede existir aunque cambie la causa?
5. Validalo con operaciones y campo. Si el operador no lo reconoce, o el supervisor no sabe verificarlo, está mal formulado o mal comunicado.
6. Conectalo con barreras reales. Cada barrera tiene que tener una relación lógica con la prevención, detección o mitigación del evento top.
7. Documentá versión y dueño. Un BowTie sin control de cambios se vuelve obsoleto rápido, sobre todo en plantas con cambios de proceso, mantenimiento o personal.

Una forma útil de pensar esto es: el evento top es el instante en que tu barrera primaria ya no te garantiza seguridad. No es el motivo por el cual falló, ni el daño que todavía no ocurrió. Es el umbral entre estar controlando el riesgo y haberlo dejado avanzar.

Quick wins y cambios estructurales

Quick wins: revisá los nombres de tus BowTies actuales y eliminá palabras causales. Un taller de 60 minutos con operaciones y HSE puede corregir más que semanas de edición individual. También sirve tomar tres escenarios críticos y probar si el evento top se puede explicar con una sola frase, sin culpar a personas ni saltar a la consecuencia.

Cambios estructurales: incorporá el criterio de definición del evento top en tu proceso de gestión del riesgo, en la investigación de incidentes y en la revisión de cambios. Si un MOC altera el proceso, el BowTie debe revisarse. Si un incidente revela una barrera fallada, el evento top debe confirmarse o corregirse. Y si la organización está madura, ese criterio debe quedar en una guía corporativa, no en la memoria de una sola persona.

Si necesitás una foto objetiva del punto en que está tu organización en PSM, disciplina operativa y competencias, un diagnóstico de madurez ayuda a convertir percepciones en prioridades. No se trata de vender tecnología; se trata de evitar que un BowTie mal armado te haga perder tiempo, credibilidad y foco.

Aplicación práctica en el día a día

La utilidad de BowTie aparece cuando baja al turno, a la reunión de coordinación y a la verificación en campo. Si la definición del evento top no se puede usar en una conversación de cinco minutos con la gente que opera el proceso, entonces todavía está demasiado lejos de la realidad.

Para profesionales HSE

Usá el evento top como criterio para revisar la calidad del riesgo crítico. En una muestra de BowTies, buscá si el texto central es una pérdida de control o una causa disfrazada. Asegurate de que el modelo sea consistente con tus análisis de incidentes, tus indicadores API 754 y tus controles de cambio. Tu rol no es solo documentar; es gobernar la calidad del modelo.

Para supervisores y mandos medios

En el arranque de turno, preguntá: "¿Cuál es el evento top que más nos importa hoy y qué barrera debe mantenerse viva?" Esa pregunta cambia la conversación. En vez de hablar solo de tareas, conectás el trabajo con el riesgo real. Si el evento top está bien definido, el equipo entiende qué observar, qué avisar y cuándo detenerse.

Para operadores

Traducí el evento top a señales observables. Por ejemplo, si el escenario es sobrellenado, las señales pueden ser nivel anormal, alarma persistente, pérdida de tendencia confiable o respuesta tardía del sistema. No necesitás memorizar un BowTie completo para usarlo bien; necesitás saber qué estado inseguro estás evitando y qué barrera te protege.

Una herramienta simple y muy efectiva es la tarjeta de turno: un resumen de una sola página con el evento top, tres amenazas típicas, tres barreras críticas y dos señales de alarma. Esa tarjeta funciona mejor que un diagrama complejo guardado en una carpeta. Si querés mejorar la adopción, simplificá sin perder rigor.

Y si tu organización ya tiene BowTies pero nadie los usa en campo, el problema no es solamente de diseño. También es de supervisión, entrenamiento y liderazgo. En ese punto, revisar la relación entre BowTie, error humano y verificación operacional puede ayudarte a cerrar la brecha entre papel y práctica.

FAQ: dudas típicas cuando empezás a definir el evento top

• ¿El evento top es lo mismo que la causa raíz? No. La causa raíz explica por qué ocurrió la desviación; el evento top describe el punto donde se pierde el control del peligro. Si lo confundís, el BowTie deja de ser un mapa de riesgos y se convierte en una lista de explicaciones.
• ¿Puede haber más de un evento top para el mismo escenario? Sí, pero si eso pasa conviene revisar si estás mezclando escenarios distintos. Muchas veces lo correcto es separar el análisis en dos BowTies o redefinir el alcance. Un evento top demasiado amplio pierde capacidad de acción.
• ¿Qué pasa si el evento top ya es una consecuencia? Entonces llegaste demasiado tarde en la lógica del modelo. Una explosión, una lesión o un derrame son consecuencias, no el centro del BowTie. El evento top tiene que ubicarse antes, en la pérdida de control.
• ¿Cómo sé si mi evento top está demasiado detallado? Si solo sirve para un equipo, un equipo físico o una válvula específica, probablemente esté demasiado estrecho. El evento top debe ser suficientemente concreto para ser útil y suficientemente general para abarcar escenarios reales comparables.
• ¿El BowTie sirve para seguridad de procesos y para seguridad industrial general? Sí, pero no de la misma forma. En seguridad de procesos, el evento top suele estar ligado a pérdida de contención o liberación de energía peligrosa. En seguridad industrial general, el nivel de detalle y la lógica del escenario pueden cambiar, pero la necesidad de claridad sigue siendo la misma.
• ¿Qué hago si operaciones y HSE no se ponen de acuerdo? Volvé al evento real y a la barrera. Preguntá en qué momento exacto se pierde el control, qué se considera el inicio del escenario y qué barrera debería evitarlo. El desacuerdo suele revelar que el problema no es la opinión, sino la definición.

Cierre: la base para todo lo que sigue

Definir correctamente el evento top en BowTie es la primera decisión seria de todo análisis bien hecho. Si ese punto está mal, todo lo demás se vuelve más frágil: las amenazas pierden contexto, las barreras se vuelven genéricas, los indicadores se vuelven ruido y la organización termina creyendo que está gestionando riesgo cuando solo está documentando formatos.

Este artículo buscó darte fundamentos y diagnóstico: qué es el evento top, qué no es, cómo detectar errores de formulación y cómo revisar si tus BowTies actuales realmente sirven para operar, supervisar y decidir. A partir de acá, la serie entra en la parte metodológica. En el artículo siguiente vas a ver cómo identificarlo paso a paso. Y en el tercero vamos a profundizar en los errores complejos que suelen pasar desapercibidos incluso en organizaciones maduras.

Si querés llevar esto a un nivel más objetivo, empezá por auditar cinco BowTies críticos de tu organización. Si encontrás ambigüedad, causalidad o falta de uso en campo, ya tenés una señal clara de por dónde empezar. Y si querés una lectura más estructurada de madurez en PSM, disciplina operativa y competencias, un diagnóstico bien hecho te puede ahorrar meses de trabajo desordenado.