Hace poco tiempo, publicaba un análisis sobre la conveniencia o no de tener un solo piloto en la fase de crucero. Incidentalmente, utilicé como ejemplo el caso AF447, donde el comandante se encontraba fuera de la cabina cuando se iniciaron los problemas y, aunque los diagnosticó correctamente, no tuvo tiempo suficiente para resolverlos.

Alguien, en tono amistoso, me criticó la selección del ejemplo puesto que, en ese caso, no se trataba precisamente de una tripulación con un único piloto sino, muy al contrario, una tripulación reforzada y, por tanto, el argumento podía no ser válido.

La crítica tiene fundamento, especialmente si consideramos que, en caso de haber habido un único piloto y ser precisamente el que percibió con claridad la situación, tal vez el accidente no se habría producido.

Es posible, pero no hay ninguna garantía de que ése hubiera sido el resultado: Una tripulación compuesta por dos pilotos expertos puede encontrarse en una situación de resolución de problemas; las ideas de uno realimentan las del otro y, tal vez, de ese proceso podría nacer alguna solución que a ninguno de ellos se le habría ocurrido de forma individual. Al fin y al cabo, en este proceso y en cómo manejarlo de la mejor forma posible se fundamenta toda la práctica de CRM.

Podemos dar razones que hacen no aconsejable dejar sólo a un piloto en la cabina con el hipotético soporte de un sistema de información más avanzado que los actuales; una de ellas, fundamental y claramente perceptible, es la aparición de un evento de rápido desarrollo que pueda requerir la contribución de, como mínimo, dos personas pero…no hay datos. ¿Por qué no hay datos?

Aquí es donde tendríamos que entrar en el hecho de que un no-evento es un evento: Un accidente es un evento dramático y de alta visibilidad. Una situación que de lugar a un incidente grave puede lograr visibilidad a través de los sistemas de reporte -si es reportada- pero ¿cuántas situaciones no llegan a ser reportadas porque, simplemente, los pilotos perciben una anomalía y, al buscar su origen, encuentran un problema con capacidad para generar un problema serio?

Ahí están los no-eventos; al no ser visibles no entran en el proceso de toma de decisiones y, simplemente, son ignorados. Quizás se debería hacer el esfuerzo de darles visibilidad a los no-eventos para conseguir que sean tenidos en cuenta.

Hay sistemas de reporte excelentes como, por ejemplo, el ASRS pero, por su propia naturaleza, no están enfocados a la toma de decisiones regulatorias como admitir o no la posibilidad de que un avión a altitud de crucero tenga sólo un piloto en cabina.

Proyectos como el eMCO de EASA están enfocados a la realización de distintos análisis que permitan una conclusión final sobre la conveniencia o no de esta práctica pero, por mucha sabiduría académica que se les quiera poner a estos proyectos, les seguirán faltando datos y, sin embargo, estos datos serían muy fáciles de obtener. Bastaría con un esfuerzo por parte de los profesionalmente implicados en el asunto:

La aviación se ha distinguido por tener un conjunto de medios de información y gestión específicos para casi cualquier cosa imaginable: FDM, OBM, LOFT, LOSA, sistemas de reporte, seguimiento individualizado de elementos críticos del avión, reconocimientos médicos, grupos de soporte psicológico…

Sin embargo, en toda esa masa de información todavía falta algo que sería crítico para aceptar o rechazar una decisión tan importante como la de tener un único piloto en crucero:

Una base de datos de no-eventos, es decir, detección de señales débiles o no-señales en las que el disparador de un proceso de solución de problemas es, precisamente, que no hay disparador y, sin embargo, pueden tener el potencial de un rápido desarrollo hacia una situación crítica, evitada mediante la colaboración entre los dos pilotos en cabina.

No se trata de “jugar a la contra” sino de asegurarse de que datos muy relevantes son tenidos en cuenta en el momento de tomar una decisión final. Sin embargo, para esto, se necesitarían varias cosas:

1. La más obvia: Recoger información sobre casos con ese perfil: Señales débiles o no-señales con potencial para derivar a situaciones críticas y que requieran la intervención de los dos pilotos.
2. Evaluación de los reportes recibidos, estableciendo si cumplen las condiciones requeridas y si son susceptibles de ser atendidos con soporte tecnológico.
3. Utilización de los datos en la discusión correspondiente con los reguladores.

Un último apartado es la necesidad de requerir que no haya trampas desde el lado tecnológico. “Trampas” en este caso significaría utilizar los sucesos reportados para añadirlos uno a uno al sistema que, supuestamente, serviría de soporte al piloto único.

Podríamos plantearnos si eso es realmente una trampa o, simplemente, es una forma de aprendizaje tecnológico perfectamente legítima; en tal caso, la respuesta sería simple y clara: Es una trampa. ¿Por qué?

Simplemente, se trata de situaciones poco comunes y no previstas; a medida que se van reportando, se pueden ir introduciendo en un sistema como “previstas” pero seguirá habiendo muchas más que puedan aparecer y que no estarán presentes entre las previstas.

El piloto humano -cualquier humano- tiene como característica propia la capacidad para detectar un entorno completo y, al hacerlo, una señal débil o una ausencia de señal le permitirá entrar en un proceso de solución de problemas. Un sistema, por avanzado que sea, no tiene esa capacidad y se limita a las situaciones previstas: Alimentarlo con los resultados de un sistema de reporte encaminado a evaluar la conveniencia o no de tener un solo piloto en crucero contribuye a disimular pero no a eliminar un simple hecho: La tecnología puede ejecutar pero carece de sentido común y de respuesta situaciones no previstas.

Un sistema, por avanzado que sea, no tiene esa capacidad y se limita a situaciones previstas: alimentarlo con los resultados de un sistema de informes destinado a evaluar la conveniencia de contar con un solo piloto a nivel de crucero contribuye a disimular pero no a eliminar un hecho simple:

La tecnología puede realizar tareas -algunas de ellas con más precisión que los humanos y sin fatiga- pero sigue careciendo de sentido común y de la posibilidad de responder a situaciones imprevistas. Los humanos, en cambio, pueden resolver situaciones que no estaban en su «base de datos» personal.

Estos hechos deberían bastar para ser extremadamente cuidadosos a la hora de decidir los lugares en los que la tecnología tendrá un papel importante.