Automatización letal: el MCAS y el 737 MAX

Cómo una función de seguridad automatizada se convirtió en parte de una catástrofe

Cuando dos aviones Boeing 737 MAX se estrellaron con pocos meses de diferencia entre 2018 y 2019, los investigadores hallaron un hilo conductor en el software de control de vuelo de la aeronave. Un sistema diseñado para ayudar a que el avión se manejara a pesar de la distinta forma de sus motores —el Sistema de Aumentación de Características de Maniobra, o MCAS— fue remodelado al final del desarrollo de formas que hicieron su comportamiento más agresivo y, lo que es más crítico, dependiente de un solo sensor de ángulo de ataque. Esos cambios eliminaron capas de protección y dejaron a las tripulaciones expuestas a un modo de fallo rápido y confuso que no habían sido entrenadas para reconocer o contrarrestar.

MCAS: qué se suponía que debía hacer

El MCAS se introdujo para ayudar a que el MAX se manejara como los modelos 737 anteriores, después de que unos motores más grandes y montados más adelante cambiaran la aerodinámica. Su función nominal era modesta: cuando ciertas condiciones sugerían que el morro podría elevarse demasiado (encabritamiento), el MCAS compensaba el estabilizador horizontal ligeramente hacia abajo para mantener un manejo consistente para los pilotos. En su concepción original, estaba destinado a ser sutil y a operar raramente.

Cómo cambió el sistema y por qué fue importante

Durante el desarrollo, Boeing amplió el papel del MCAS. La versión implementada podía activarse con más frecuencia y aplicar comandos al estabilizador de mayor magnitud que en los borradores anteriores, y fue configurada para reaccionar a los datos de un único sensor de ángulo de ataque en lugar de verificar múltiples fuentes. En los accidentes de Lion Air y Ethiopian Airlines, datos erróneos del ángulo de ataque activaron repetidos comandos de morro abajo que los pilotos combatieron pero no pudieron superar a tiempo. El paso de un diseño conservador y redundante a una implementación agresiva de un solo sensor fue un factor decisivo en los fallos.

Por qué llamar al MCAS «IA» es engañoso y por qué la etiqueta sigue siendo importante

En los medios y en el debate público, los accidentes a veces se presentan como un fallo de la «IA». Esa simplificación es tentadora pero imprecisa. El MCAS no era un modelo de aprendizaje automático que se entrenara a sí mismo a partir de datos; era una lógica de control de vuelo determinista: reglas codificadas para actuar ante entradas específicas de los sensores. El peligro, sin embargo, es el mismo que preocupa con los sistemas de IA opacos: un comportamiento automatizado oculto a los usuarios finales y a los reguladores, que interactúa con señales del mundo real de formas que sus diseñadores no anticiparon por completo.

Etiquetar al MCAS simplemente como «automatización» puede restar importancia a cómo las decisiones de diseño —especialmente en torno a la transparencia, la redundancia y la interacción hombre-máquina— convirtieron una función protectora en un peligro. Los vuelos revelan que incluso los algoritmos que no aprenden exigen una ingeniería de seguridad rigurosa, el mismo tipo de requisitos trazables y pruebas independientes que ahora pedimos a los sistemas de IA en otros ámbitos.

Los fallos organizativos y regulatorios amplificaron las deficiencias técnicas

Las decisiones técnicas no ocurrieron en el vacío. Múltiples revisiones y audiencias determinaron que los problemas en la supervisión, la comunicación y la cultura corporativa amplificaron el riesgo. No siempre se presentó a los reguladores todos los detalles del MCAS a medida que este evolucionaba; los manuales de pilotaje omitieron inicialmente la función; y las suposiciones de que el MCAS rara vez se activaría redujeron el entrenamiento de los pilotos sobre cómo responder cuando lo hiciera. Estas rupturas institucionales convirtieron un error de ingeniería en una crisis de seguridad pública.

Las correcciones que Boeing y los reguladores implementaron

Tras la inmovilización en tierra de la flota MAX, Boeing y las autoridades de aviación exigieron cambios de software y operativos. El diseño revisado limita el MCAS para que solo actúe cuando ambos sensores de ángulo de ataque coincidan, lo restringe a una única activación por evento y modera la magnitud de los comandos de compensación. Los reguladores también endurecieron los requisitos de documentación, entrenamiento de pilotos y verificación independiente antes de que el modelo fuera autorizado para volver al servicio. Esos cambios abordaron los modos de fallo inmediatos, pero no borran las cuestiones de gobernanza más amplias expuestas por la crisis.

Lecciones para el debate más amplio sobre la IA y la automatización

La historia del MAX es un manual de advertencia para cualquiera que despliegue automatización a escala. Destacan cuatro lecciones:

Estos son estribillos familiares en los círculos de ética y seguridad de la IA, pero el 737 MAX demuestra que no son abstractos. En sistemas críticos para la seguridad, los costes de equivocarse son inmediatos y definitivos.

Hacia dónde debe dirigirse la conversación a continuación

Las correcciones técnicas han devuelto al MAX al servicio bajo condiciones más estrictas, pero el episodio sigue siendo un punto de referencia sobre cómo no gestionar la automatización en industrias reguladas. Para los responsables políticos y los ingenieros, el imperativo es traducir las lecciones en estándares exigibles: vías de certificación más claras para los sistemas de decisión automatizados, notificación obligatoria de cambios sustanciales de diseño y estructuras institucionales que reduzcan los conflictos de intereses entre fabricantes y certificadores.

Para los periodistas y el público, también es un recordatorio para ser precisos con los términos. La «IA» acapara titulares, pero el problema subyacente en el caso del MAX no fue la inteligencia artificial en el sentido del aprendizaje automático; fue una combinación de automatización agresiva, falta de transparencia y prácticas de seguridad debilitadas. Tratar esa combinación como un desafío de ingeniería y gobernanza nos ofrece un camino más productivo para evitar que se repita.

Conclusión

Los desastres del 737 MAX no fueron inevitables. Fueron el resultado de decisiones de diseño específicas, suposiciones no verificadas y fallos institucionales. A medida que la automatización y la IA se adentran en más dominios, el caso del MAX debe erigirse como un ejemplo crudo: los sistemas más seguros no surgen de la confianza en un fragmento de código, sino de un diseño conservador, una comunicación clara con los usuarios, una revisión independiente y una supervisión regulatoria robusta. Esas no son sutilezas técnicas; son condiciones previas para la seguridad pública.