Logo Predyc
Predyc

El Modelo de Causalidad STAMP en el RCA para Accidentes Complejos

 Articulo 11 de abril de 2026
Román Ventura
Autor: Román VenturaIngeniero de Mantenimiento Industrial, Especialista Jr. en Ingeniería de Confiabilidad y Gestión de Activos.
EmailLinkedIn

El modelo STAMP, acrónimo de Systems‑Theoretic Accident Model and Processes, define los accidentes industriales como resultado de un control inadecuado porque la estructura jerárquica que gobierna un sistema no impuso las restricciones de seguridad necesarias durante el diseño, el desarrollo o la operación; en lugar de buscar la cadena de eventos que condujo a la rotura de un componente, se trata el sistema como un problema de control dinámico y se demuestra que la seguridad depende de que cada nivel de la organización imponga y reciba las restricciones correctas sobre los niveles que controla, de modo que el accidente no resulta de lo que falló sino de lo que el sistema no fue capaz de impedir.

Fue desarrollado por la investigadora Nancy Leveson como extensión de los modelos sistémicos para abordar la complejidad de los sistemas automatizados modernos porque se constató que los accidentes más graves de finales del siglo XX no podían explicarse con herramientas que asumían comportamientos aleatorios e independientes de los componentes. En particular, los sistemas digitales no se desgastan probabilísticamente como una válvula mecánica y los algoritmos de control ejecutan exactamente lo que fueron programados para ejecutar; por tanto, cuando el entorno operativo cambia sin que el software se actualice se demuestra que el accidente no proviene del fallo del componente sino de la interacción entre dos estados del sistema que nadie diseñó para coexistir.

La investigación bajo STAMP audita la estructura de control sociotécnica del sistema y en primer lugar determina quién debía imponer qué restricción sobre cada elemento y qué información recibía para verificar su cumplimiento. Desde el desarrollo se examina cómo y qué decisiones se tomaron con base en esa información y cómo esas decisiones afectaron la dinámica operativa. Aplicado con disciplina desde el nivel operativo hasta las políticas corporativas y regulatorias, este recorrido revela los puntos exactos donde el sistema de control cedió sin que ningún componente se rompiera y demuestra que el accidente puede ser consecuencia de fallos en los lazos de control más que de fallos aislados de componentes.

El propósito de aplicar STAMP en el RCA es producir acciones correctivas que reestructuren los mecanismos de control de la organización para reducir las condiciones que hicieron el accidente predecible aunque nadie lo hubiera previsto. No se trata de sancionar al operador ni de reemplazar la pieza que cedió bajo presiones para las que no fue diseñada sino de identificar y corregir los lazos de información defectuosos, los modelos mentales incorrectos y las decisiones gerenciales que construyeron ese entorno. Así se demuestra que las medidas eficaces son las que modifican los flujos de información y las responsabilidades de control y por tanto evitan que coexistieran estados del sistema que nadie diseñó para convivir.

Fundamentos teóricos del modelo STAMP en la seguridad industrial

El punto de partida conceptual de STAMP rechaza la premisa estadística que sustenta la mayoría de las herramientas cuantitativas de confiabilidad, pues parte de la idea de que en sistemas complejos la estimación de probabilidades resulta engañosa y que la seguridad depende de imponer y mantener restricciones de comportamiento más que de calcular cifras y actuar solo a partir de ellas.

En los métodos clásicos se calcula la probabilidad de falla de un sistema partiendo de la suposición de que los componentes fallan de forma independiente y de que esas tasas permanecen constantes en el tiempo. De acuerdo con esas condiciones, la seguridad se garantiza combinando capas redundantes hasta que la probabilidad de falla simultánea de todos los elementos quede por debajo de un umbral aceptable.

El problema es que esa premisa no se aplica a los sistemas sociotécnicos complejos: los errores de software no obedecen a tasas probabilísticas porque el código produce resultados deterministas para las mismas condiciones de entrada; las decisiones gerenciales no se modelan con distribuciones de Weibull; y las presiones de producción que empujan a los operadores a omitir pasos de seguridad son fenómenos organizacionales que ninguna ecuación diferencial captura adecuadamente. Por tanto, STAMP propone abordar la seguridad como un problema de control y de restricciones más que como una suma de capas redundantes basada en estimaciones probabilísticas.

De la cadena de eventos a la teoría de control de sistemas

Los modelos lineales que conciben un accidente lo hacen como una cadena causal:

  • A causa B,

  • B causa C,

  • C causa finalmente el evento.

STAMP, en cambio, entiende el accidente como un problema de control fallido, de modo que el sistema contaba con un conjunto de restricciones de seguridad que debían mantenerse activas. Sin embargo, la estructura de control no fue capaz de imponer esas restricciones en las condiciones reales de operación y por tanto se produjo el accidente.

En el enfoque lineal el accidente se explica como una secuencia de hechos en la que un fallo provoca el siguiente, por eso identificar el elemento que falló suele considerarse suficiente para establecer la causa raíz. Según STAMP se interpreta como un fallo del control, de modo que localizar el componente que cedió o la decisión tomada es apenas el punto de partida. ¿Por qué la estructura de control no interceptó la condición peligrosa antes de que causara daño? Esa pregunta conduce a las políticas, los presupuestos y los modelos mentales que configuraron el entorno operativo.

Restricciones de seguridad y lazos de retroalimentación

El concepto central es la restricción de seguridad, es decir la condición que el sistema debe mantener para operar con seguridad. Para garantizarla cada nivel de la estructura de control necesita poder imponer esa restricción sobre el nivel inferior y disponer de información de retroalimentación que le permita verificar si la restricción se cumple.

Cuando el canal de retroalimentación está deteriorado, por ejemplo por reportes incompletos, instrumentación insuficiente o software que no procesa las variables relevantes, el controlador toma decisiones basadas en una imagen incorrecta del estado real del sistema. Esto es lo que el modelo denomina modelo mental defectuoso, no una incompetencia del decisor sino el resultado predecible de operar con información que no refleja la realidad del proceso supervisado.

Metodología para modelar la estructura de control jerárquica

Construir la estructura de control STAMP de un sistema es el primer paso metodológico antes de cualquier análisis de causas. Ese mapa organiza quién controla a quién, qué restricciones debe imponer cada nivel sobre el nivel inferior y qué información de retroalimentación debería recibir para verificar el cumplimiento.

En términos visuales, los controladores se representan como rectángulos de esquinas rectas, el proceso físico como rectángulos redondeados, las acciones de control como flechas que entran por el lado izquierdo de los nodos y la retroalimentación como flechas que entran o salen por la parte superior o inferior.

El mapa nos muestra de inmediato la brecha entre la estructura de control que fue diseñada y la que realmente operaba durante el evento. Por tanto, la investigación debe centrarse en los niveles donde el canal de retroalimentación estaba deteriorado, donde las restricciones no se habían formalizado y donde los controladores trabajaban con modelos mentales incorrectos del sistema.

Evaluación de fallos de control y modelos mentales inadecuados

La técnica CAST convierte el marco de STAMP en un análisis estructurado y aplicable. Para cada controlador en la jerarquía se documentan cuatro elementos clave

  1. restricciones de seguridad que debía imponer

  2. acciones de control inadecuadas que ejecutó

  3. fallas en su modelo mental del sistema

  4. contexto que moldeó sus decisiones Estos elementos, registrados por nivel, generan un diagnóstico que conecta el evento físico con las políticas y decisiones corporativas que lo hicieron posible.

La evaluación del modelo mental es quizás la parte más exigente porque exige comprender por qué las acciones del controlador parecían razonables desde su perspectiva. No se trata de buscar culpables sino de reconstruir qué creían saber y qué ignoraban; esto se demuestra cuando la decisión tiene sentido con la información disponible. Por tanto, las recomendaciones resultantes deben orientarse a mejorar la calidad de la información y la formación del personal además de corregir fallos técnicos, y no limitarse a reemplazar la pieza que cedió.

Adaptación dinámica y migración estructural al riesgo

El modelo STAMP incorpora un concepto que las herramientas estáticas no capturan, ya que los sistemas industriales no permanecen en el estado para el que fueron diseñados. En la práctica las presiones de producción, los recortes presupuestarios y las modificaciones empíricas introducidas para mantener el ritmo operativo generan una migración progresiva hacia condiciones de mayor riesgo, un proceso gradual y a menudo imperceptible.

Cada decisión que amplía los parámetros operativos sin revisar los controles existentes, cada inspección aplazada para no interrumpir la producción y cada procedimiento que no refleja el estado actual del activo son desplazamientos pequeños que, acumulados, llevan al sistema a una región de operación donde los controles originales ya no son suficientes. Por tanto, STAMP exige rastrear esa migración a lo largo de la línea de tiempo del incidente para identificar cuándo y por qué una decisión condujo al estado que hizo posible el evento.

Integración del enfoque sociotécnico en la investigación deductiva

Una ventaja práctica de STAMP es que se integra con técnicas causales consolidadas en la industria.

El Arbol de fallas (FTA) describe las combinaciones de condiciones a nivel físico y el Árbol de Eventos ETA traza las trayectorias desde el evento iniciador, evaluando las capas de protección en secuencia. Aplicadas dentro del marco de STAMP, estas herramientas no solo muestran qué falló, sino que conectan ese fallo con las decisiones y controles organizacionales que lo hicieron posible.

Usadas de forma individual las técnicas pueden como el FTA pueden limitarse al nivel hasta dónde llegue la investigación.

En el marco de STAMP esa observación se convierte en punto de partida para averiguar cosas como: ¿por qué el algoritmo no detectó la condición? ¿quién era responsable de mantenerlo actualizado? ¿qué decisión presupuestaria o procedimental impidió la corrección? Son esas decisiones organizacionales las que explican la recurrencia.

Ejemplo práctico de análisis STAMP en un evento catastrófico

Contexto operativo del sistema bajo análisis

El caso corresponde a una contaminación biológica masiva del suministro hídrico de una pequeña localidad por E. coli, que provocó enfermedades agudas y motivó una investigación de máxima prioridad. El sistema físico comprende pozos subterráneos de extracción, una red de distribución y una planta de tratamiento con dosificación de cloro, y la estructura de control involucra al operador de turno, a la gerencia de la empresa de servicios públicos y al ministerio responsable de la supervisión y las auditorías de calidad hídrica.

La restricción de seguridad central era que el agua distribuida cumpliera los parámetros bacteriológicos antes de llegar a la red de consumo; para garantizarlo cada nivel debía imponer su función: el operador dosificar y muestrear correctamente, la gerencia supervisar y verificar y el ministerio auditar y exigir cumplimiento. Sin embargo, en el momento del evento ninguna de esas responsabilidades se impuso de forma efectiva, lo que demuestra que la falla fue sistémica y que los controles en los distintos niveles estaban desactualizados o inoperantes.

Contexto Operacional
Contexto Operacional
Iniciación
Iniciación
Image

Construcción de la estructura de control y descarte de hipótesis individuales

Las primeras hipótesis siguieron una lógica lineal. Primero se consideró una falla mecánica en la bomba inyectora de cloro y luego la posible negligencia del operador que no activó el panel de dosificación. Ambas suposiciones se verificaron mediante inspección de equipos y revisión de bitácoras y, sin embargo, los resultados descartaron las dos porque la bomba estaba operativa y el operador había seguido el protocolo vigente.

Ese descarte llevó a ascender en la jerarquía de control y a aplicar el análisis CAST para documentar las tarjetas de cada controlador. Así se reveló un patrón sistémico que ninguna hipótesis individual habría mostrado y se demuestra que la causa residía en la interacción entre decisiones, procedimientos y controles, más que en un fallo aislado.

Hipótesis y descarte
Hipótesis y descarte

Identificación del control inadecuado y los modelos mentales defectuosos

Acciones correctivas desde las cuatro tarjetas por nivel de control
Acciones correctivas desde las cuatro tarjetas por nivel de control
  • El análisis del Nivel 3, la gerencia, mostró un modelo mental defectuoso, porque los directivos asumían que las fuentes subterráneas eran intrínsecamente seguras y que la cloración era una precaución excesiva para una fuente local protegida. Desde su perspectiva la decisión de relajar controles parecía razonable, pero desde la microbiología del agua constituyó un riesgo no gestionado y, en consecuencia, no se priorizó el cumplimiento estricto de los estándares de dosificación ni se mantuvo la capacidad del sistema para prevenir la contaminación.

  • Al nivel 4, el ministerio regulador presentó una causa sistémica porque recortes presupuestarios redujeron la dotación de inspectores y la frecuencia de auditorías, y como consecuencia el canal de retroalimentación quedó deteriorado; los reportes que llegaban eran en gran parte declaraciones de los propios operadores y no verificaciones independientes, por lo que el ministerio tendía a asumir cumplimiento cuando la información confirmaba esa suposición. En suma, la supervisión existía en apariencia, pero no en efecto y esa falta de verificación externa permitió que fallas locales permanecieran ocultas.

Las causas raíces
Las causas raíces

Las acciones correctivas prioritarias:

A partir del diagnóstico multinivel emergen cuatro medidas, una por nivel, que atacan la falla de control específica de cada estrato

  • Nivel 4 restablecer dotación de inspectores y aumentar la frecuencia de auditorías

  • Nivel 3 capacitación técnica obligatoria en bacteriología para la dirección

  • Nivel 2 actualizar procedimientos de dosificación e incorporar verificación de cloro residual al cierre de cada turno

  • Nivel 1 instalar medición en línea con retroalimentación directa al operador

    Los resultados
    Las causas raíces

Estas acciones buscan corregir tanto las fallas técnicas como los modelos mentales y los canales de información que permitieron la recurrencia.

Conclusión

El modelo STAMP redefine la seguridad como un problema de control y no solo como la ausencia de fallas físicas, por tanto, obliga a mirar más allá del componente que falló y a escalar la investigación hasta los niveles organizacionales donde debían mantenerse las restricciones; de este modo se puede demostrar que un accidente ocurre cuando las restricciones no se impusieron, y no basta con reemplazar el elemento que cedió si las presiones que lo afectaron siguen presentes.

Desde la técnica CAST nos aporta el procedimiento concreto para ejecutar ese enfoque porque permite documentar la jerarquía de control, identificar las restricciones vulneradas en cada nivel y evaluar los modelos mentales de los responsables; así se obtiene un diagnóstico más profundo que los métodos lineales y se diseñan acciones que atacan causas organizacionales que de otro modo permanecerían invisibles.

Cuando una organización incorpora este marco en su protocolo de investigación aprende a leer sus propias estructuras de control con honestidad, a detectar dónde la información que asciende no refleja la realidad operativa y a restablecer la verificación antes de que esas brechas se alineen con una condición que provoque un nuevo accidente, con lo cual las lecciones del caso se traducen en cambios sostenibles.

Dinos qué te ha parecido el artículo

starstarstarstarstar