Construimos un solver de tripulaciones aéreas más rápido. Solo falló más rápido.

La primera vez que estuve en un centro de control de operaciones de una aerolínea durante una cascada real, era un poco después de las 3 de la madrugada y una tormenta invernal había cerrado una estación clave horas antes. El muro de vídeo a lo largo del frente de la sala se iba llenando de rojo —cancelación tras cancelación— y lo que más recuerdo es que nadie estaba usando el solver de programación de tripulaciones multimillonario que la aerolínea había pagado. Los despachadores habían apartado los teclados y trabajaban a mano los emparejamientos de tripulación rotos, en hojas de cálculo y una pizarra, justo en el momento en que se suponía que el software debía justificar su coste.

Esa imagen es lo que con el tiempo nos llevó a construir IA de programación de tripulaciones aéreas para la recuperación IROPS —pero no de la manera que yo esperaba, y no antes de apostar por el arreglo equivocado y verlo fracasar. IROPS, si nunca has tenido el placer, es la palabra que usa la industria para las operaciones irregulares: las tormentas, los cierres, el caos en cascada cuando un itinerario se descompone. Le cuesta a la industria aérea unos 60 000 millones de dólares al año, aproximadamente el 8 % de los ingresos aéreos mundiales, según la IATA. Alrededor de uno de cada cinco vuelos en el mundo se ve afectado por ello. Y el sucio secreto que aprendí esa noche es que el software de optimización más sofisticado de la aviación está esencialmente diseñado para ser inútil durante los mismísimos eventos que más cuestan.

El solver estaba optimizando una aerolínea que ya no existía

Ayuda saber qué hacen realmente los solvers de tripulaciones heredados. Ejecutan generación de columnas —una técnica de optimización de branch-and-price que es genuinamente brillante para encontrar la forma legal más barata de dotar de personal un itinerario conocido. La trampa está en la palabra conocido. El solver toma una instantánea de la red, congela el tiempo y calcula la asignación óptima de tripulación para ese mundo congelado. Se ejecuta en ciclos por lotes, normalmente cada 30 a 60 minutos.

Durante las operaciones normales, eso está bien. El mundo apenas se mueve entre ciclos. Pero durante una cascada, el estado de la red cambia cada pocos minutos. Las tripulaciones se mueven. Las conexiones se rompen. Las aeronaves quedan varadas. Para cuando el solver devuelve una solución, las entradas que se le dieron ya son incorrectas —así que la respuesta es un plan perfecto para una aerolínea que ya no existe.

Empecé a llamar a esto la brecha entre optimización y ejecución: la distancia entre el mundo que el solver supuso y el mundo que realmente está ahí fuera en la plataforma. La brecha es inofensiva durante un retraso aislado. Durante una cascada, es fatal, porque el solver se construyó para la eficiencia —el itinerario más barato en un mundo conocido— y lo que desesperadamente necesitas a las 3 de la madrugada es resiliencia: un itinerario que pueda sobrevivir en uno desconocido.

La parte más cruel de un solver de tripulaciones heredado es que durante un colapso sigue funcionando —entregándote con calma un plan impecable para una red que se desmoronó mientras él calculaba.

¿Por qué no podíamos simplemente hacer el solver más rápido?

Esta es la parte de la que no estoy orgulloso, y es la parte que realmente importa.

Cuando mi equipo miró el problema por primera vez, nuestro diagnóstico fue el diagnóstico obvio de ingeniero: el solver es demasiado lento. El mundo cambia cada cinco minutos y el optimizador tarda de treinta minutos a una hora, así que cierra la brecha —hazlo más rápido. Dedicamos tiempo real a construir un motor de recuperación más rápido, apoyándonos en heurísticas más baratas para obtener una respuesta factible dentro de la ventana de decisión operativa en lugar de esperar una demostrablemente óptima.

Y funcionó, en el sentido estricto de que devolvía respuestas más rápido. Luego lo probamos contra datos reales de interrupciones y lo vi producir con confianza planes de recuperación que ya eran inválidos, solo que antes. Habíamos construido una máquina que optimizaba una aerolínea fantasma a mayor velocidad.

El error fue tratar la velocidad como el cuello de botella. No lo era. El cuello de botella era que las entradas eran ficción. El solver —incluido el nuestro— necesita hechos concretos: «El capitán Smith está en la puerta B7 en Denver». Pero durante una cascada, el capitán Smith podría estar en el hotel, podría estar en el autobús de empleados, podría haber alquilado un coche y estar a mitad de camino de Colorado Springs. El estado honesto del mundo es «probablemente en Denver», y un solver de generación de columnas no puede hacer nada con un probablemente. Habíamos estado afinando la respuesta a una pregunta cuyos datos eran basura.

Ese fracaso es la razón por la que el producto existe. Si hubiéramos lanzado el solver rápido, habríamos vendido a las aerolíneas una forma más rápida de cometer el mismo error costoso.

El agujero negro de datos de 1200 millones de dólares

Si quieres ver este fracaso exacto a plena escala, mira lo que le pasó a Southwest en diciembre de 2022. El colapso le costó a la aerolínea aproximadamente 1200 millones de dólares, canceló alrededor de 16 900 vuelos y dejó varados a cerca de dos millones de pasajeros durante las fiestas.

La versión popular es «software viejo». La versión real es más específica y más útil. El sistema de programación de tripulaciones de Southwest, SkySolver, chocó con una explosión combinatoria que no pudo calcular. Pero por debajo de eso, la aerolínea perdió el rastro de dónde estaban físicamente sus propios pilotos y auxiliares de vuelo. El reporte de posición de la tripulación se hacía en gran medida por teléfono —tripulaciones varadas en estaciones remotas llamando a un centro de programación donde los tiempos de espera subían a horas. Esa latencia creó lo que yo pienso como un agujero negro de datos: el sistema generaba itinerarios para tripulaciones que no estaban donde creía que estaban. Estaba optimizando una red fantasma, y la estructura de rutas punto a punto significaba que no había «puntos de regeneración» de hub donde las tripulaciones y las aeronaves reconvergen naturalmente, así que el radio de impacto simplemente siguió expandiéndose de estación en estación.

Esto no es historia antigua que todo el mundo ya haya arreglado. En julio de 2024, el sistema de programación de Spirit creó asignaciones en conflicto para el 43 % de sus tripulaciones de vuelo disponibles, un evento estimado en entre 50 y 100 millones de dólares, porque el sistema carecía de la flexibilidad para reasignar tripulaciones de forma limpia durante la interrupción. El patrón se repite porque la arquitectura subyacente —optimizar una instantánea congelada, exigir entradas seguras— es la misma en toda la industria.

Southwest, hay que reconocérselo, respondió gastando: unos 1700 millones de dólares en tecnología en 2024 como parte de un programa plurianual más amplio, una migración a AWS que redujo drásticamente la huella de sus centros de datos, y un algoritmo de programación aproximadamente un 30 % más rápido. Ese es el instinto correcto. Pero una versión más rápida de la misma arquitectura —que es la trampa en la que casi caemos nosotros mismos— cierra la brecha de velocidad mientras deja la brecha de certeza de los datos completamente abierta.

¿Qué pasa ahora cuando un retraso supera las tres horas?

Durante la mayor parte de la historia de la aviación, una recuperación lenta te costaba buena voluntad. Pasajeros enfadados, mala prensa, algunos vales. Esa cuenta cambió el 28 de octubre de 2024.

Fue entonces cuando entró en vigor la regla de reembolso automático del Departamento de Transporte de EE. UU. —el primer requisito obligatorio de reembolso automático de la historia. Cualquier retraso nacional de más de tres horas (seis para internacional) ahora desencadena un reembolso en efectivo, pagado dentro de siete días hábiles, sin que el pasajero siquiera lo pida. Ni un vale. Ni una reubicación. Efectivo.

Haz la aritmética para una aerolínea de tamaño medio que opera 300 salidas al día. En un día genuinamente malo, si aunque sea una sexta parte de ellas —50 vuelos— se pasan de la marca de las tres horas, con un valor medio de billete de 280 dólares y 150 pasajeros por vuelo, estás ante alrededor de 2,1 millones de dólares de exposición a reembolsos obligatorios en un solo día. Una recuperación IROPS lenta solía ser un problema de reputación. Ahora es una partida contable que golpea la misma semana.

Ahora hay un contador en marcha por cada hora que tu recuperación se atrasa, y desde octubre pasado paga en efectivo, automáticamente, a cada pasajero al que afecta.

Esta es la parte que reformuló toda la conversación para mí. El coste de la brecha entre optimización y ejecución ya no es abstracto. Se acumula, en dólares, contra un reloj que empezó en el momento en que empezó la tormenta.

Aumenta el solver, no lo reemplaces

Aquí está la decisión que define nuestro enfoque, y es deliberadamente poco atractiva: no reemplazamos tu solver.

Los solvers establecidos codifican décadas de conocimiento de dominio específico de las aerolíneas, y el campo a su alrededor se está consolidando, no colapsando. Jeppesen —el estándar de la industria, con más de un centenar de aerolíneas clientes— fue vendido por Boeing a Thoma Bravo por 10 550 millones de dólares en abril de 2025, una de las mayores desinversiones tecnológicas en la historia aeroespacial, y desde entonces ha lanzado Stratosphere, una capa de IA para la gestión predictiva de interrupciones. La plataforma iFlight de IBS Software está ganando despliegues modernos y nativos de la nube —Korean Air entró en operación a principios de 2026, con aerolíneas como Aeroitalia y las del Groupe Dubreuil también adoptándola— respaldada por un acuerdo de coingeniería con AWS. CrewSolver de Optym ofrece una reducción documentada del 3 al 7 % en los costes de tripulación en el lado de la planificación.

Ninguno de esos es el enemigo. Pero fíjate en qué es fuerte cada uno: optimización de la fase de planificación y análisis predictivo —el mundo conocido, calculado a la perfección. El problema de la recuperación en tiempo real con entradas inciertas es la brecha que permanece abierta. Un reemplazo completo de plataforma es también un proyecto de 12 a 18 meses, y ningún líder de operaciones quiere arrancar el sistema que funciona 350 días al año para arreglar los 15 que no. Para el CIO que de verdad firma el contrato, la cuenta es peor que el calendario: arrancar un sistema con décadas de lógica de convenios colectivos específica de la aerolínea codificada en él —justo en el momento en que la propia propiedad de Jeppesen acaba de cambiar de manos por 10 550 millones de dólares y su hoja de ruta a largo plazo es una incógnita— es una apuesta que la mayoría de las organizaciones tecnológicas no harán. Situarse junto a la instalación existente, consumiendo sus flujos de datos en lugar de reemplazar su esquema, es la única integración que darán luz verde.

Así que construimos un motor de recuperación IROPS impulsado por aprendizaje automático que se sitúa junto a una instalación existente de Jeppesen o IBS y maneja aquello que el solver central no puede: interrupciones en cascada con posiciones de tripulación inciertas, análisis del radio de impacto en toda la red, y planes de recuperación producidos en minutos en lugar de las 4 a 12 horas que suele tardar la recuperación manual. Los datos de casos regionales sugieren que la automatización puede recortar ese tiempo de recuperación en alrededor de un 78 %. El objetivo no es ser más listo que el proveedor establecido. Es ser útil en las condiciones exactas para las que el establecido nunca se diseñó.

Enseñar a un modelo a trabajar con «probablemente en Denver»

Una vez que dejamos de intentar hacer el solver más rápido, el verdadero problema de ingeniería se enfocó: construir algo que prospere con la incertidumbre en lugar de atragantarse con ella.

La primera pieza es la inteligencia de posición de la tripulación. En lugar de exigir una ubicación segura, alimentamos un modelo con posiciones probabilísticas —fusionando cualquier señal en tiempo real que exista con el comportamiento histórico, de modo que el sistema razona sobre dónde es probable que esté una tripulación en lugar de esperar una llamada telefónica que lleva cuatro horas en una cola de espera. Ese único cambio —de «seguro o nada» a «distribución de probabilidad»— es lo que permite a un plan de recuperación sobrevivir al contacto con una cascada real.

La segunda pieza es tratar la red como un grafo y analizar dónde se propagarán los fallos antes de que lo hagan —el radio de impacto, mapeado sobre la estructura de rutas específica de esta aerolínea, para que puedas ver qué cierre de estación cancela silenciosamente seis vuelos posteriores dentro de dos horas.

La tercera pieza es un simulador de escenarios, en la práctica un gemelo digital de la operación, para que un equipo de operaciones pueda ensayar un escenario de tormenta invernal de antemano y probar estrategias de recuperación cuando no hay tormenta real ni reloj real. La aviación ya confía en los gemelos digitales donde los datos son ricos —la plataforma AVIATAR de Lufthansa ingiere 23,7 terabytes al día en 34 integraciones de aerolíneas y alcanza un 93,6 % de precisión en la predicción de fallos de mantenimiento. Los gemelos de tripulación y programación aún son incipientes, que es precisamente donde está la oportunidad.

Y atravesándolo todo está el motor de restricciones. Cada recomendación tiene que ser legal bajo las reglas de fatiga de la Parte 117 de la FAA —los límites de tiempo de vuelo de 8 a 9 horas, los periodos de servicio de 9 a 14 horas— y bajo el convenio sindical de la aerolínea, que con frecuencia es más restrictivo que la regulación. La mayoría de los proveedores tratan esas reglas como «configuración». Nosotros tratamos codificar el convenio colectivo específico de una aerolínea, por flota y por base, como ingeniería central, porque un plan de recuperación que viola una cláusula de un convenio no es un plan —es una reclamación laboral.

Por qué primero operamos en modo sombra

La gente de esta industria tiene razón en desconfiar de una caja negra que les dice cómo mover pilotos a las 3 de la madrugada. Así que te contaré la objeción que más escucho, porque yo mismo la tenía.

Un vicepresidente de operaciones nos dijo al principio, más o menos, que acababan de licenciar el complemento de IA para interrupciones de su proveedor establecido y no veían por qué nos necesitaban. Justo. Luego vino la siguiente tormenta, el complemento les dio predicciones y no una recuperación de tripulación ejecutable, y los despachadores estaban de vuelta en la pizarra. La distinción que me enseñó esa conversación: hay un mundo de diferencia entre la agentic AI para el chat de cara al pasajero —la palabra de moda del circuito de conferencias de 2026— y la IA que toma decisiones operativas sobre tripulaciones y aeronaves. Un chatbot que reubica a un pasajero es algo estupendo. No es el mismo problema de ingeniería que recuperar una red.

Por eso, la primera vez que cualquier aerolínea ejecuta nuestro motor, no toca las operaciones. Se ejecuta en modo sombra: la recomendación de nuestro modelo se sitúa junto a la decisión real del despachador humano, y medimos la brecha, día tras día, con las propias interrupciones de la aerolínea. La confianza no se afirma en una presentación de ventas. Se gana en una hoja de comparación, sin riesgo operativo, hasta que el equipo de operaciones decide por sí mismo que las recomendaciones son mejores que la pizarra.

No te ganas el derecho a redirigir a los pilotos de alguien con un benchmark. Te lo ganas acertando, en silencio, junto a un humano, durante semanas, antes de que nadie tenga que creerte.

La verdad honesta es que observar el modo sombra fue cuando entendí qué estábamos vendiendo en realidad. No un optimizador. No velocidad. Estábamos vendiendo una forma para que un líder de operaciones crea en una máquina en la peor noche de su año —y la creencia hay que construirla antes de la tormenta, no durante ella.

Lo que realmente valen los 15 días

Si diriges la operación de una aerolínea de tamaño medio, tu solver de tripulaciones funciona bien 350 días al año. No estoy aquí para discutir lo contrario. La pregunta es qué pasa en los 15 días que no —y esos son los días que producen los titulares de mil millones de dólares, las auditorías del 43 %-de-tripulaciones-mal-asignadas y ahora, desde octubre pasado, los reembolsos automáticos en efectivo medidos por hora.

El error que toda la industria sigue cometiendo —el error que cometí yo primero, con mi propio solver más rápido— es tratar esos 15 días como un problema de velocidad que se resuelve calculando con más fuerza. No lo son. Son un problema de certeza, y no resuelves un problema de certeza exigiendo más certeza a un mundo que se está desmoronando activamente. Lo resuelves construyendo algo que razona bajo la incertidumbre, ensaya el desastre antes de que llegue y se demuestra en las sombras antes de que se confíe en él a plena luz. Ese es el motor que construimos, y está descrito en su totalidad en nuestra solución de IA de programación de tripulaciones aéreas.

En algún lugar esta noche hay un centro de control de operaciones donde el muro de vídeo está en calma y verde, y un solver de tripulaciones zumba a través de su ciclo por lotes exactamente como fue diseñado. El trabajo que hacemos es para la noche en que esa sala se vuelve roja —cuando los teléfonos se saturan, los emparejamientos se rompen más rápido de lo que nadie puede anotarlos, y un despachador echa mano de una pizarra porque la certeza que el software exige ha abandonado silenciosamente el edificio. El objetivo de todo esto es asegurar que, en esa noche, la máquina siga razonando honestamente sobre una aerolínea que ya no puede ver del todo.