Al final de mi anterior artículo prometí escribir algo sobre modelos de seguridad y el concepto de Cultura Justa. Como lo prometido es deuda, en esta ocasión repasaremos la evolución de la idea de seguridad ante los accidentes en el mundo de la aviación. Gran parte de lo tratado en este nuevo artículo será fácilmente extrapolable a otros ámbitos en los que tengamos un sistema que haya que proteger contra accidentes potencialmente catastróficos.

Consideremos en primer lugar los inicios de la aviación. Era un campo totalmente nuevo y, por tanto, experimental. Los accidentes eran frecuentes por cualquier causa: motores poco fiables, escasa resistencia de los materiales, desconocimiento de fenómenos que hoy consideramos elementales, etc. Volar era tan arriesgado que los primeros aviadores eran considerados héroes. La única forma de prevenir accidentes era investigar los que ya habían ocurrido e intentar corregir los errores. Gradualmente se fueron consiguiendo mejores materiales, motores más fiables, aparecieron nuevos y mejores equipos, mejoró el conocimiento de la meteorología… y volar se fue convirtiendo en una actividad menos arriesgada.

Al terminar la Segunda Guerra Mundial el progreso técnico era tal que podemos considerar que la aviación estaba alcanzando su madurez. Hacia 1950 se puede hablar de una industria segura y enormemente regulada en todos sus aspectos. Se desarrolla la idea de que el cumplimiento de la infinidad de normas existentes garantiza la seguridad, mientras que desviarse de ellas lleva al desastre. Ya no es fácil encontrar fallos técnicos evidentes y los accidentes se achacan al fallo humano asociado al incumplimiento de la normativa. Se desarrolla así una cultura centrada en las ideas de culpa y castigo mientras se pasa de la era del fallo técnico a la del fallo humano.

Es una cultura tranquilizadora puesto que el error humano es una explicación simple y basta con recomendar mayores precauciones para recuperar la sensación de seguridad. Pero la aviación es cada vez más complicada, y conforme pasa el tiempo más aún: ya no hay sólo unos pocos aviones, sino que hay todo un entramado de aeronaves, sistemas de comunicaciones, de navegación, de vigilancia, control aéreo, control de afluencia… es un sistema complejo en el que hay una parte, el ser humano, de la que se espera que supla las carencias de todos los demás componentes mientras se le achacan todos los errores. Es a partir de los años 70 cuando se desarrolla un modelo en el que se trata de sistematizar todos los componentes. Se trata del modelo SHEL, a veces conocido como SHELL. Tiene 4 componentes:

• S: Software. Es la parte inmaterial formada por procedimientos, documentación, reglas, etc. Digamos que es el conocimiento.
• H: Hardware. Es la parte material pura y dura. La máquina.
• E: Environment. Es el ambiente entendido como condiciones de luz, ruido, condiciones sociales, económicas, etc.
• L: Liveware. Es el ser humano responsable de operar el sistema.

Lo novedoso es que más que diseccionar los componentes del sistema en su conjunto se presta atención a las relaciones entre componentes poniendo al ser humano (L) en el centro y analizando su interacción con el resto de las partes (S, H, E). Como además los seres humanos interaccionan entre sí se añade una segunda L al modelo. Gráficamente:

Imagen tomada de Atlasaviation.com. Click para visitar la página original.

En los años 90 se empieza a abandonar el modelo del fallo humano y se empieza a considerar el fallo organizacional. El principal responsable es James Reason y su célebre modelo de múltiples capas de seguridad. Lo novedoso es que no busca fallos puntuales, que por sí solos no explican el accidente, sino que afirma que cada capa tiene sus propios fallos latentes, consecuencia de decisiones tomadas en los niveles más altos de la organización. Los fallos activos son consecuencia de errores o de desviaciones de las normas y se producen habitualmente sin que den lugar a mayores problemas. Sin embargo si estos fallos activos se alinean con otros fallos latentes puede ocurrir que el accidente consiga abrirse paso por todas las capas de seguridad que protegen el sistema. El operador del sistema (la L del modelo SHEL) hereda esas condiciones en forma de diseños erróneos, averías en los equipos, objetivos de productividad y seguridad contrapuestos, etc.

Imagen tomada del blog An Eye in the Sky. Click para visitarlo.

La consecuencia es que el error es algo natural en el sistema y no puede ser eliminado por completo. Se trata de intentar crear las condiciones para neutralizarlo. Dado que los errores normalmente se producen sin dar lugar al accidente es posible detectarlos con antelación, puesto que lo normal es que el error que resultó ser catastrófico haya tenido lugar en cientos de ocasiones sin que se le pusiera remedio y sólo a posteriori se reconoce su importancia con la manida frase «se veía venir». Para detectar los fallos a tiempo se desarrollan sistemas de notificación de incidentes, pero para que sean eficaces es preciso que quienes hacen funcionar el sistema reconozcan sus propios errores y eso, en una cultura de culpa y castigo, es imposible puesto que quien comete una equivocación prefiere ocultarla a incriminarse.

Por eso se está intentado implantar el concepto de Just Culture, que se traduce como Cultura Justa o Cultura de Equidad y que consiste en que el operador del sistema no pueda ser sancionado por acciones, omisiones o decisiones tomadas conforme a su experiencia y formación, sin que sean tolerables los actos negligentes o intencionadamente destructivos. En otras palabras: se reconoce el derecho al error honesto.

Pongamos un ejemplo imaginario, pero que podría ser perfectamente real. Tenemos dos vuelos de una misma aerolínea, a los que llamaremos Gelves7665 y Gelves7265. El primero está sobrevolando Zaragoza con destino Madrid y el segundo tiene destino Bilbao y está a la altura de Huesca. Ambos vuelan a 35.000 pies de altitud, no son conflicto entre ellos y están en contacto con el mismo controlador. Éste observa que el descenso del Gelves7665 es problemático porque hay varios aviones en ruta hacia Barcelona que se interponen a distintos niveles: 34.000, 32.000 y 30.000 pies. Por su parte el Gelves7265 sólo tiene un obstáculo, que es un avión en rumbo opuesto a 32.000 pies.

Nuestro controlador decide que el Gelves7265 aún no necesita iniciar el descenso. Está bastante lejos de Bilbao y tiene tiempo de esperar hasta haberse cruzado con el avión que le pasará por debajo. Sin embargo el Gelves7665 debería empezar a bajar cuanto antes para que tenga tiempo de descender lo suficiente como para pasar por debajo de los otros tres aviones, ya que de no hacerlo así el avión llegará muy alto a las cercanías de Madrid. Es un problema sencillo y sólo falta dar las órdenes correspondientes. El procedimiento es que el controlador da la orden y el piloto responde repitiéndola, para que así el controlador compruebe que se ha recibido correctamente. En principio se ordenará el descenso a 25.000 pies. El diálogo sería:

-Controlador: Gelves siete seis seis cinco, descienda a nivel de vuelo 2-5-0.

-Piloto: Descendemos a nivel de vuelo 2-5-0, Gelves siete dos seis cinco.

Y ya tenemos el error: ha respondido el piloto equivocado. Si el controlador no se da cuenta y no lo corrige inmediatamente tendremos al avión que va a Bilbao descendiendo directamente hacia el avión que viene de frente, mientras que el avión que va a Madrid seguirá volando a la misma altitud que llevaba. Nuestro controlador, que quiere estar seguro de que el Gelves7665 desciende cuanto antes, observa el radar concentrándose en el avión que le interesa y por eso, mientras se pregunta por qué el piloto no empieza a bajar ya y empieza a pensar en repetir la orden, no se da cuenta de que en otro punto de la pantalla se está gestando un incidente grave o algo peor.

Veamos posibles puntos de conflicto según el modelo SHELL, analizando unas interacciones imaginarias, pero verosímiles:

• L-H: Los altavoces de la posición de control no funcionan demasiado bien y eso contribuye a la confusión de indicativos similares.
• L-S: Hay un equipo de reserva que se oye mejor, pero al controlador no le ha llegado la información de que ya está disponible.
• L-E: En la sala de control hay ruido porque han entrado de visita los alumnos de un colegio. Además el controlador está preocupado porque su hijo pequeño está enfermo y como además el niño no ha dejado de llorar en toda la noche, tenemos el efecto de fatiga por no haber dormido bien.
• L-L: El controlador que debe hacer el papel de ayudante tuvo hace unos días un altercado con nuestro protagonista y por eso le molesta formar equipo con él y está más ocupado rumiando su disgusto que prestando atención a la situación, que por otra parte, no parecía difícil de resolver.

Desde el punto de vista de Reason tenemos varios fallos latentes (indicativos de llamada similares, un equipo que no funciona correctamente, error en la transmisión de información referente al equipo de reserva) unidos a fallos activos (error del piloto que creyó que la transmisión de la orden era para él, error del controlador que no detectó el fallo anterior). Los fallos activos son difíciles de evitar, pero los fallos latentes pueden corregirse: se podría haber corregido el problema del altavoz, se puede mejorar la distribución de información interna de la empresa y se puede informar a la compañía aérea de que mantienen dos indicativos de llamada parecidos en rutas cercanas y pueden dar lugar a confusión. En referencia al último punto existe un programa de Eurocontrol para detectar y corregir este tipo de situaciones; si alguien quiere información sobre él puede visitar esta página.

¿Dónde entra aquí la Cultura Justa de la que hablábamos antes? En un entorno en el que esté implantada todos los implicados harán un informe del incidente para intentar que se tomen las medidas adecuadas, pero en un entorno punitivo posiblemente ocultarán el incidente: el controlador para que no le sancionen por no detectar la respuesta incorrecta, el piloto que se confundió para que no le amonesten por creer que le llamaban a él y el piloto al que estaba destinada la orden para que nadie le eche en cara el no haberse dado cuenta de que le llamaban a él y respondía otro. En un ambiente así, si el incidente llega a conocerse los protagonistas se intentarán echar la culpa unos a otros. Si no llega a conocerse, los aviones de indicativos similares seguirán volando y los fallos latentes seguirán agazapados, al acecho, esperando el momento en que aparezca un fallo activo que se una a ellos y les permita abrir paso al accidente, que atravesará con limpieza todas las capas de seguridad del sistema.

Nota: Para no alargar el artículo he renunciado a poner un ejemplo real, pero creo que puede ser muy instructivo releer mi artículo sobre el terrible accidente de Überlingen considerando los fallos desde el punto de vista del modelo SHEL y del modelo de Reason.