Construí una IA para vencer al solver en la recuperación de tripulaciones aéreas. Perdió, y esa derrota se convirtió en el producto.
El benchmark que construí para ganar, y perdí
Construí la primera versión de StormCrew para vencer al solver. Esa era toda la propuesta en mi cabeza. El control de operaciones aéreas corre sobre motores de optimización de décadas, así que si podía entrenar algo más inteligente, tendría una historia que valiera la pena contar. Pasé semanas en ello. Luego comparé mi motor de recuperación contra CBC, un solver maduro de programación lineal entera mixta de código abierto, probado en batalla desde antes de que yo pudiera escribir un for-loop, y CBC ganó. No por un error de redondeo.
Recuerdo mirar las dos columnas de números y sentir ese vacío concreto que sientes cuando el experimento que diseñaste para demostrarte que tenías razón te demuestra que estabas equivocado. El solver fue más rápido. Sus planes eran más baratos. Ni una sola vez devolvió un horario inviable. Mi versión ingeniosa perdió en los tres.
Así que hice lo único honesto que se me ocurrió. Cambié la afirmación, no los números.
Construí la IA para vencer al solver. El solver ganó. Lo interesante resultó ser todo lo que esa pelea estaba ocultando.
Esa reversión es la columna vertebral de lo que StormCrew realmente llegó a ser, y creo que es la historia más útil que la que me propuse contar. Puedes ejecutar todo tú mismo en veriprajna.com/es/demos/stormcrew-recuperacion-de-tripulacion-irops-aerea-en-segundos-legal-por-construccion, pero déjame recorrer lo que me hizo cambiar de opinión, porque el giro es el punto.
¿Qué se rompe de verdad cuando una tormenta deja en tierra un hub?
Volví a leer las autopsias del colapso después de que CBC me humillara, y casi ninguno de los fallos era «las matemáticas eran un poco subóptimas». Las operaciones irregulares, lo que la industria llama IROPS, cuestan a las aerolíneas aproximadamente 60.000 millones de dólares al año (IATA). El desastre canónico, Southwest en diciembre de 2022, rondó los 1.200 millones de dólares, con unas 16.900 cancelaciones y aproximadamente 2 millones de pasajeros varados. Cuando rastreé cómo se deshilachan realmente esos días, el optimizador nunca fue el villano.
En su lugar se rompen tres cosas. La recuperación es demasiado lenta: cuando una tormenta deja en tierra un hub, reasignar tripulaciones en la cascada aguas abajo sigue siendo en gran medida una carrera manual de 4 a 12 horas (un benchmark con fuentes, no un número que me inventé). Es demasiado arriesgada: cada reasignación de tripulación debe respetar los límites de servicio y descanso de la FAA Part 117 y un CBA sindical por compañía, y una sola violación es un evento de cumplimiento, no una nota al pie. Y es demasiado opaca: la cascada de vuelos aguas abajo que acaba de perder su tripulación es invisible hasta que esos vuelos ya se están cancelando.
Eso último es lo que las herramientas heredadas no ven, y es lo primero que hice que la demo mostrara. Inyecta una tormenta en el hub más ocupado y la app resalta el radio de impacto: los vuelos varados más los vuelos aguas abajo a un salto que pierden su tripulación a través de la rotación. En el escenario sembrado son 53 vuelos en riesgo en toda la red.
Desde la norma de reembolso automático del DOT (oct. 2024), cada retraso en cascada de 3 horas o más es ahora también un golpe financiero automático. Así que el coste de ser lento, ilegal o ciego subió precisamente mientras las herramientas se quedaban igual. Ninguno de esos tres fallos se arregla con una mejor función objetivo. Yo había estado optimizando lo único que ya estaba bien.
¿Por qué dejé de intentar vencer a CBC y empecé a alimentarlo?
Hice las paces con perder contra CBC dándole un trabajo distinto. En lugar de competir con el solver, lo envolví. El pipeline es todo código real, determinista y sembrado: una red aérea sintética y el estado de las tripulaciones, un inyector de disrupciones que calcula el radio de impacto por alcanzabilidad en el grafo sobre la rotación, un generador de servicios, luego CBC como el motor que elige el plan, después una comparación en sombra contra no hacer nada, y un certificado firmado.
Cuando lo ejecuto sobre la tormenta sembrada, el generador produce 1.762 servicios legales de recuperación (52 de ellos reposicionamientos deadhead para mover tripulación donde se necesita), más 53 cancelaciones de respaldo, para 1.815 columnas candidatas en total. CBC resuelve la partición en conjuntos de coste mínimo resultante de 1.815 variables y 115 restricciones hasta OPTIMAL y devuelve un plan en unos 0,11 segundos. Resultado en ese escenario: 52 de 53 vuelos reasignados (98 por ciento), 1 cancelación, 34 tripulaciones usadas (25 de línea y 9 de reserva).
El problema de la aerolínea nunca fue que el solver fuera demasiado débil. Fue que la recuperación era demasiado lenta, demasiado arriesgada e invisible hasta que era demasiado tarde.
Fíjate en la honestidad de esa captura. El motor de recuperación es CBC, nombrado en el panel. La afirmación duradera no es que mi código optimice mejor que un solver. Es que el plan llega en mucho menos de un segundo donde el proceso manual documentado tarda de 4 a 12 horas, y la app mide esa brecha a la vista de todos. Quiero ser preciso sobre el alcance, porque esto es una demo y me niego a maquillarla para que parezca más de lo que es: esas cifras exactas son resultados de una red sintética sembrada, no una garantía de mundo abierto. La afirmación velocidad frente a lo manual es la que viaja.
La garantía de legalidad pertenece al código, no al juicio de un modelo
Tengo una opinión fuerte que solo gané construyendo esto, así que la digo con claridad. Una garantía de legalidad no puede vivir en el juicio de un modelo. Tiene que vivir en código determinista, por construcción. La forma de impedir que jamás se recomiende un servicio ilegal de tripulación no es entrenar un modelo para evitarlo, ni añadir un término de penalización al objetivo y esperar que el optimizador lo rodee. Es hacer imposible generar el servicio ilegal desde el principio.
Así que las restricciones se aplican en el momento de la generación, no se puntúan después. La Part 117 limita un período de servicio a 780 minutos, el tiempo de vuelo a 480 minutos, y exige un sit mínimo de 30 minutos; el CBA de muestra limita un servicio a 4 segmentos. Solo los servicios que cumplen todo eso llegan a ser columnas candidatas. Esto es enmascaramiento de acciones. Una asignación ilegal no se penaliza, es irrepresentable. Lo que CBC haga con las columnas que recibe, y lo que el copiloto opcional diga después sobre el plan, ninguno puede devolver a la vida un servicio ilegal, porque nunca estuvo en el conjunto.
Eso me da un invariante en lugar de una puntuación: 0 asignaciones ilegales, jamás, con pruebas unitarias (la suite de tests está 3/3 en verde, comprobando que el radio de impacto no está vacío, que solo se generan columnas legales y que el plan recuperado es una partición legal). Una puntuación puede sufrir regresión. Un invariante se puede prometer.
Esto también explica por qué ya no me convencen los argumentos de «ops de IA autónomas» cuando la historia de seguridad es «el modelo aprendió a no hacerlo». Confié en que un modelo respetara una regla dura exactamente una vez durante esta construcción, al principio, y estuvo bien hasta la única entrada en la que no lo estuvo. En un dominio donde una sola violación es un evento regulatorio, «usualmente legal» es lo mismo que «no legal». Prefiero eliminar la posibilidad antes que supervisarla.
¿Qué ocurre en el peor día del año?
Casi envié una versión que autoaprobaría cualquier cosa, y me alegro de que un escenario me detuviera. Cambia la demo a severe, donde el evento es lo bastante malo como para que se agoten las reservas y solo quede alrededor del 30 por ciento de las tripulaciones. CBC sigue encontrando un plan plenamente legal, en unos 0,05 segundos, todavía 0 ilegales. Pero ese plan cancelaría 20 de 53 vuelos, que es el 38 por ciento del radio, muy por encima del umbral de autoaprobación del 15 por ciento del OCC.
La decisión correcta ahí no es sellar en silencio un plan que cancela más de un tercio de la red afectada. Así que el estado pasa a ESCALATE, se requiere firma humana, con el motivo a la vista. El plan sigue calculado, sigue siendo legal, sigue mostrándose al controlador (33 vuelos recuperados, el 62 por ciento del radio). Simplemente no está autoaprobado.
La parte que la mayoría de los argumentos «autónomos» omiten es saber cuándo la acción correcta es no actuar, y entregar el día a un humano.
Construir esa puerta cambió cómo siento toda la categoría. La escalada no es que el sistema falle. Es el sistema siendo honesto sobre un mal día. Un asesor que siempre devuelve una respuesta confiada es fácil de demostrar y peligroso de confiar. El que de vez en cuando dice «este está por encima de tu línea, tú decides» es el que realmente pondría junto a un controlador a las 3 de la madrugada.
El artefacto que querría si yo fuera el controlador
Seguí preguntándome qué necesitaría un controlador de operaciones a la mañana siguiente, y la respuesta no era un panel, era un registro. Así que cada recuperación se sella en un recovery_plan.json firmado: la disrupción, el plan elegido acción por acción con tripulación y vuelo, la cláusula concreta de Part 117 y CBA comprobada por acción contra su techo, el tiempo de pared de la recuperación y las cifras de ahorro. Es el registro de auditoría del OCC de por qué se recomendó esta recuperación, exportable en un clic.
También hay un copiloto opcional de plan, y quiero ser claro sobre dónde se sitúa. Es un adaptador delgado a un LLM (Claude por defecto, proveedor intercambiable, o un puente local sin clave) que explica el plan en inglés sencillo. Se abstiene por completo sin una clave, todo lo demás corre offline y sin clave, y vive fuera del núcleo de decisión. La máscara determinista, CBC y la puerta de escalada deciden. El modelo solo narra después del hecho. Lo puse ahí a propósito, porque el momento en que el modelo de lenguaje influye en si un servicio es legal, he perdido la garantía que me costó toda la construcción ganar.
Sobre los ahorros, aplica la misma disciplina. En el escenario normal la comparación en sombra muestra 52 cancelaciones evitadas y aproximadamente 2,37 millones de dólares de exposición a reembolsos DOT evitados (un modelo de 300 dólares por pasajero) frente a no hacer nada. Ese es el encuadre más favorecedor posible, porque la línea base es varar todo el radio de impacto, y está etiquetado como ilustrativo de ese único escenario. No es un titular, y desde luego no es prueba de que mi código optimice mejor que cualquier otra cosa. Perdí ese argumento contra CBC el primer día. No voy a recuperarlo en silencio con un número de marketing.
¿Qué significa realmente «aumentar, no reemplazar»?
Solía pensar que aumentar era la opción tímida, lo que dices cuando no puedes construir lo audaz. Ahora pienso lo contrario. El comprador aquí ya posee un buen stack de solvers, Jeppesen o IBS, y no puede tolerar un rip-and-replace, un lock-in ni una recomendación sin explicación en el peor día de su año. Decirle a ese comprador «tíralo por mi modelo más inteligente» no es audaz, es una afirmación que ya me desmentí a mí mismo con un benchmark.
Lo que puedo ofrecer con honestidad es la capa operativa alrededor del solver en el que ya confían. Hacer visible la cascada antes de que muerda. Hacer imposibles de generar los movimientos ilegales en lugar de meramente desaconsejados. Colapsar horas en segundos. Y saber cuándo el día es lo bastante malo como para que la respuesta correcta sea escalar, no autoaprobar. Todo en la demo es sintético y sembrado: la red, las tripulaciones, la disrupción, las cifras en dólares; no hay datos reales de aerolínea en ningún sitio. Lo que es real es el mecanismo, y puedes verlo correr de extremo a extremo en veriprajna.com/es/demos/stormcrew-recuperacion-de-tripulacion-irops-aerea-en-segundos-legal-por-construccion.
Y si prefieres verlo a leerme describirlo, aquí está todo corriendo de extremo a extremo.
Aquí está la pregunta que no he dejado de darle vueltas desde que CBC me venció. Cuando el solver con el que compites ya es bueno, y el comprador ya lo posee, lo que queda por construir no es una mejor respuesta. Es una mejor relación con la respuesta: más rápida, demostrablemente legal, visible y lo bastante humilde para escalar. Así que, ¿cuánto de la IA que te venden este año está resolviendo realmente la parte difícil, y cuánto está resolviendo de nuevo la parte que nunca estuvo rota?
