Abbiamo costruito un solver per equipaggi più veloce. Ha solo fallito più in fretta.

La prima volta che mi sono ritrovato in un centro di controllo operativo di una compagnia aerea durante una vera cascata di eventi, erano da poco passate le 3 del mattino e una tempesta invernale aveva chiuso uno scalo chiave alcune ore prima. Il videowall lungo la parete frontale della sala si stava riempiendo di rosso — cancellazione dopo cancellazione — e la cosa che ricordo di più è che nessuno stava usando il solver per la pianificazione degli equipaggi da diversi milioni di dollari che la compagnia aveva pagato. I dispatcher avevano spinto da parte le tastiere e stavano rielaborando a mano gli accoppiamenti di equipaggio saltati, su fogli di calcolo e su una lavagna, esattamente nel momento in cui il software avrebbe dovuto dimostrare il proprio valore.

Quell'immagine è ciò che alla fine ci ha portato a costruire l'AI per la pianificazione degli equipaggi delle compagnie aeree per il recupero IROPS — ma non nel modo in cui mi aspettavo, e non prima di aver puntato sulla soluzione sbagliata e averla vista fallire. IROPS, se non avete mai avuto il piacere, è il termine del settore per indicare le operazioni irregolari: le tempeste, le chiusure, il caos a catena quando un programma di volo va in pezzi. Costa al settore aereo una cifra stimata di 60 miliardi di dollari all'anno, all'incirca l'8% dei ricavi globali delle compagnie aeree, secondo la IATA. Circa un volo su cinque nel mondo ne è toccato. E il segreto scomodo che ho imparato quella notte è che il software di ottimizzazione più sofisticato dell'aviazione è essenzialmente progettato per essere inutile proprio durante gli eventi che costano di più.

Il solver stava ottimizzando una compagnia aerea che non esisteva più

È utile sapere cosa fanno effettivamente i solver legacy per gli equipaggi. Eseguono la generazione di colonne — una tecnica di ottimizzazione branch-and-price davvero brillante nel trovare il modo legale più economico per assegnare il personale a un programma di volo noto. Il trucco sta nella parola noto. Il solver scatta un'istantanea della rete, congela il tempo e calcola l'assegnazione ottimale degli equipaggi per quel mondo congelato. Funziona a cicli batch, tipicamente ogni 30-60 minuti.

Durante le operazioni normali, va bene. Il mondo si muove appena tra un ciclo e l'altro. Ma durante una cascata, lo stato della rete cambia ogni pochi minuti. Gli equipaggi si spostano. Le coincidenze saltano. Gli aeromobili restano bloccati. Nel momento in cui il solver restituisce una soluzione, gli input che gli erano stati forniti sono già sbagliati — quindi la risposta è un piano perfetto per una compagnia aerea che non esiste più.

Ho iniziato a chiamare tutto questo il divario ottimizzazione-esecuzione: la distanza tra il mondo che il solver ha ipotizzato e il mondo che c'è davvero là fuori sul piazzale. Il divario è innocuo durante un ritardo isolato. Durante una cascata è fatale, perché il solver è stato costruito per l'efficienza — il programma di volo più economico in un mondo noto — e ciò di cui hai disperatamente bisogno alle 3 del mattino è la resilienza: un programma di volo che possa sopravvivere in un mondo sconosciuto.

La parte più crudele di un solver legacy per gli equipaggi è che durante un tracollo continua a funzionare — porgendoti con calma un piano impeccabile per una rete che è andata in pezzi mentre lui stava calcolando.

Perché non potevamo semplicemente rendere il solver più veloce?

Questa è la parte di cui non vado fiero, ed è la parte che conta davvero.

Quando il mio team ha esaminato per la prima volta il problema, la nostra diagnosi è stata quella ovvia da ingegneri: il solver è troppo lento. Il mondo cambia ogni cinque minuti e l'ottimizzatore impiega da trenta minuti a un'ora, quindi bisogna chiudere il divario — renderlo più veloce. Abbiamo dedicato tempo reale a costruire un motore di recupero più rapido, appoggiandoci a euristiche più economiche per ottenere una risposta ammissibile entro la finestra decisionale operativa invece di aspettare una risposta dimostrabilmente ottimale.

E ha funzionato, nel senso stretto che restituiva le risposte più in fretta. Poi lo abbiamo testato contro dati di interruzioni reali e l'ho visto produrre con sicurezza piani di recupero che erano già invalidi, solo più presto. Avevamo costruito una macchina che ottimizzava una compagnia aerea fantasma a maggiore velocità.

L'errore è stato trattare la velocità come il collo di bottiglia. Non lo era. Il collo di bottiglia era che gli input erano finzione. Il solver — il nostro compreso — ha bisogno di fatti certi: «Il comandante Smith è al Gate B7 di Denver». Ma durante una cascata, il comandante Smith potrebbe essere in albergo, potrebbe essere sulla navetta dei dipendenti, potrebbe aver noleggiato un'auto ed essere a metà strada verso Colorado Springs. Lo stato onesto del mondo è «probabilmente a Denver», e un solver a generazione di colonne non può farci nulla con un probabilmente. Avevamo affinato la risposta a una domanda i cui dati erano spazzatura.

Quel fallimento è la ragione per cui il prodotto esiste. Se avessimo distribuito il solver veloce, avremmo venduto alle compagnie aeree un modo più rapido per commettere lo stesso costoso errore.

Il buco nero di dati da 1,2 miliardi di dollari

Se volete vedere questo identico fallimento su vasta scala, guardate cosa è successo a Southwest nel dicembre 2022. Il tracollo è costato alla compagnia all'incirca 1,2 miliardi di dollari, ha cancellato circa 16.900 voli e ha lasciato a terra quasi due milioni di passeggeri durante le festività.

La versione popolare è «software vecchio». La storia vera è più specifica e più utile. Il sistema di pianificazione degli equipaggi di Southwest, SkySolver, ha raggiunto un'esplosione combinatoria che non riusciva a elaborare. Ma sotto tutto questo, la compagnia ha perso traccia di dove si trovassero fisicamente i propri piloti e assistenti di volo. La comunicazione della posizione degli equipaggi passava in gran parte per telefono — equipaggi bloccati negli scali che chiamavano un centro di pianificazione dove i tempi di attesa salivano a ore. Quella latenza ha creato quello che io penso come un buco nero di dati: il sistema generava programmi di volo per equipaggi che non erano dove pensava che fossero. Stava ottimizzando una rete fantasma, e la struttura di rotte punto-a-punto significava che non c'erano «punti di rigenerazione» negli hub dove equipaggi e aeromobili si riconvergono naturalmente, così il raggio d'impatto ha continuato a espandersi di scalo in scalo.

Questa non è storia antica che nel frattempo tutti hanno risolto. Nel luglio 2024, il sistema di pianificazione di Spirit ha creato assegnazioni in conflitto per il 43% degli equipaggi di volo disponibili, un evento stimato tra i 50 e i 100 milioni di dollari, perché il sistema mancava della flessibilità per riassegnare gli equipaggi in modo pulito durante l'interruzione. Lo schema si ripete perché l'architettura sottostante — ottimizzare un'istantanea congelata, esigere input certi — è la stessa in tutto il settore.

Southwest, a suo merito, ha risposto spendendo: circa 1,7 miliardi di dollari in tecnologia nel 2024 nell'ambito di un più ampio programma pluriennale, una migrazione ad AWS che ha ridotto drasticamente l'impronta dei loro data center, e un algoritmo di pianificazione più veloce di circa il 30%. È l'istinto giusto. Ma una versione più veloce della stessa architettura — che è la trappola in cui noi stessi stavamo quasi cadendo — chiude il divario di velocità lasciando spalancato il divario di certezza dei dati.

Cosa succede ora quando un ritardo supera le tre ore?

Per gran parte della storia dell'aviazione, un recupero lento ti costava buona reputazione. Passeggeri arrabbiati, cattiva stampa, qualche voucher. Quel calcolo è cambiato il 28 ottobre 2024.

È allora che è entrata in vigore la regola sui rimborsi automatici del Dipartimento dei Trasporti degli Stati Uniti — il primo obbligo in assoluto di rimborso automatico. Qualsiasi ritardo nazionale superiore alle tre ore (sei per l'internazionale) ora fa scattare un rimborso in contanti, pagato entro sette giorni lavorativi, senza che il passeggero debba nemmeno chiederlo. Non un voucher. Non una riprenotazione. Contanti.

Fate i conti per un vettore di medie dimensioni che opera 300 partenze al giorno. In una giornata davvero brutta, se anche solo un sesto di esse — 50 voli — supera la soglia delle tre ore, con un valore medio del biglietto di 280 $ e 150 passeggeri per volo, ti trovi di fronte a circa 2,1 milioni di dollari di esposizione a rimborsi obbligatori in un solo giorno. Un recupero IROPS lento era un problema di reputazione. Ora è una voce di bilancio che colpisce la stessa settimana.

C'è ora un tassametro che gira su ogni ora in cui il tuo recupero rimane indietro, e da ottobre scorso paga in contanti, automaticamente, a ogni passeggero che tocca.

Questa è la parte che ha riformulato l'intera conversazione per me. Il costo del divario ottimizzazione-esecuzione non è più astratto. Si accumula, in dollari, contro un orologio che è partito nel momento stesso in cui è arrivata la tempesta.

Potenzia il solver, non sostituirlo

Ecco la decisione che definisce il nostro approccio, ed è deliberatamente poco appariscente: non sostituiamo il tuo solver.

I solver in uso codificano decenni di conoscenza di dominio specifica delle compagnie aeree, e il settore attorno a loro si sta consolidando, non collassando. Jeppesen — lo standard del settore, con più di cento compagnie aeree clienti — è stato venduto da Boeing a Thoma Bravo per 10,55 miliardi di dollari nell'aprile 2025, una delle più grandi dismissioni tecnologiche nella storia aerospaziale, e da allora ha lanciato Stratosphere, un layer di AI per la gestione predittiva delle interruzioni. La piattaforma iFlight di IBS Software sta vincendo implementazioni moderne e cloud-native — Korean Air è entrata in produzione all'inizio del 2026, con vettori come Aeroitalia e le compagnie del Groupe Dubreuil che anch'esse stanno passando ad essa — sostenuta da un accordo di co-ingegnerizzazione con AWS. CrewSolver di Optym offre una documentata riduzione dei costi degli equipaggi del 3–7% sul lato pianificazione.

Nessuno di questi è il nemico. Ma nota in cosa ciascuno di loro è forte: ottimizzazione in fase di pianificazione e analisi predittiva — il mondo noto, calcolato splendidamente. Il problema del recupero in tempo reale con input incerti è il divario che rimane aperto. La sostituzione completa di una piattaforma è inoltre un progetto da 12-18 mesi, e nessun responsabile operativo vuole smantellare il sistema che funziona 350 giorni all'anno per sistemare i 15 in cui non funziona. Per il CIO che firma effettivamente il contratto, il calcolo è peggiore del calendario: smantellare un sistema con decenni di logica CBA specifica del vettore codificata al suo interno — proprio nel momento in cui la proprietà stessa di Jeppesen è appena passata di mano per 10,55 miliardi di dollari e la sua roadmap a lungo termine è una questione aperta — è una scommessa che la maggior parte delle organizzazioni tecnologiche non farà. Affiancarsi all'installazione esistente, consumandone i feed anziché sostituirne lo schema, è l'unica integrazione a cui daranno il via libera.

Così abbiamo costruito un motore di recupero IROPS basato su ML che si colloca accanto a un'installazione Jeppesen o IBS esistente e gestisce ciò che il solver centrale non può: interruzioni a catena con posizioni degli equipaggi incerte, analisi del raggio d'impatto sull'intera rete e piani di recupero prodotti in minuti anziché nelle 4-12 ore che tipicamente richiede il recupero manuale. I dati di casi regionali suggeriscono che l'automazione può ridurre quel tempo di recupero di circa il 78%. Il punto non è essere più intelligenti del sistema in uso. È essere utili esattamente nelle condizioni per cui il sistema in uso non è mai stato progettato.

Insegnare a un modello a lavorare con «probabilmente a Denver»

Una volta smesso di cercare di rendere il solver più veloce, il vero problema ingegneristico è emerso con chiarezza: costruire qualcosa che prosperi sull'incertezza invece di soffocarci.

Il primo pezzo è l'intelligenza sulla posizione degli equipaggi. Invece di esigere una posizione certa, alimentiamo un modello con posizioni probabilistiche — fondendo qualunque segnale in tempo reale esista con il comportamento storico, così il sistema ragiona su dove un equipaggio probabilmente si trova anziché aspettare una telefonata bloccata da quattro ore in una coda di attesa. Quel singolo cambiamento — da «certezza o niente» a «distribuzione di probabilità» — è ciò che permette a un piano di recupero di sopravvivere al contatto con una cascata reale.

Il secondo pezzo è trattare la rete come un grafo e analizzare dove si propagheranno i guasti prima che accada — il raggio d'impatto, mappato sulla struttura di rotte specifica di questa compagnia aerea, così puoi vedere quale chiusura di scalo cancella silenziosamente sei voli a valle tra due ore.

Il terzo pezzo è un simulatore di scenari, di fatto un gemello digitale dell'operazione, così un team operativo può provare in anticipo uno scenario di tempesta invernale e testare strategie di recupero quando non c'è nessuna tempesta reale e nessun orologio reale. L'aviazione già si fida dei gemelli digitali dove i dati sono ricchi — la piattaforma AVIATAR di Lufthansa ingerisce 23,7 terabyte al giorno attraverso 34 integrazioni con compagnie aeree e raggiunge il 93,6% di accuratezza nella previsione dei guasti di manutenzione. I gemelli per equipaggi e pianificazione sono ancora agli albori, ed è proprio lì che si trova l'opportunità.

E ad attraversare il tutto c'è il motore dei vincoli. Ogni raccomandazione deve essere legale secondo le regole sull'affaticamento della FAA Part 117 — i limiti di tempo di volo di 8-9 ore, i periodi di servizio di 9-14 ore — e secondo il contratto sindacale della compagnia aerea, che è spesso più restrittivo della normativa. La maggior parte dei fornitori tratta quelle regole come «configurazione». Noi trattiamo la codifica dello specifico contratto collettivo di un vettore, per flotta e per base, come ingegneria fondamentale, perché un piano di recupero che viola una clausola del CBA non è un piano — è un reclamo sindacale.

Perché prima operiamo in modalità shadow

Le persone di questo settore hanno ragione a diffidare di una scatola nera che dice loro come spostare i piloti alle 3 del mattino. Quindi vi racconterò l'obiezione che sento più spesso, perché l'avevo io stesso.

Un vicepresidente delle operazioni ci disse all'inizio, più o meno, che avevano appena acquisito in licenza il componente aggiuntivo di AI per le interruzioni dal loro fornitore in uso e non capivano perché avessero bisogno di noi. Giusto. Poi arrivò la tempesta successiva, il componente aggiuntivo diede loro previsioni e non un recupero degli equipaggi eseguibile, e i dispatcher tornarono alla lavagna. La distinzione che quella conversazione mi ha insegnato: c'è un abisso di differenza tra l'AI agentica per la chat rivolta ai passeggeri — la parola d'ordine dei convegni del 2026 — e l'AI che prende decisioni operative su equipaggi e aeromobili. Un chatbot che risistema un passeggero è una buona cosa. Non è lo stesso problema ingegneristico del recupero di una rete.

Ecco perché la prima volta che una compagnia aerea usa il nostro motore, esso non tocca le operazioni. Gira in modalità shadow: la raccomandazione del nostro modello si affianca alla decisione effettiva del dispatcher umano, e noi misuriamo il divario, giorno dopo giorno, sulle interruzioni proprie della compagnia aerea. La fiducia non si afferma in una presentazione di vendita. Si conquista su un foglio di confronto, senza alcun rischio operativo, finché il team operativo non decide da solo che le raccomandazioni sono migliori della lavagna.

Non ti guadagni il diritto di reindirizzare i piloti di qualcuno con un benchmark. Te lo guadagni avendo ragione, in silenzio, accanto a un umano, per settimane, prima che qualcuno debba crederti.

La verità onesta è che è stato osservando la modalità shadow che ho capito cosa stavamo davvero vendendo. Non un ottimizzatore. Non la velocità. Stavamo vendendo un modo perché un responsabile operativo potesse credere in una macchina nella peggiore notte del suo anno — e la convinzione va costruita prima della tempesta, non durante.

Quanto valgono davvero i 15 giorni

Se gestisci le operazioni di una compagnia aerea di medie dimensioni, il tuo solver per gli equipaggi funziona bene 350 giorni all'anno. Non sono qui per sostenere il contrario. La domanda è cosa succede nei 15 giorni in cui non funziona — e quelli sono i giorni che producono i titoli di giornale da un miliardo di dollari, gli audit sul 43%-di-equipaggi-mal-assegnati e ora, da ottobre scorso, i rimborsi automatici in contanti conteggiati a ore.

L'errore che l'intero settore continua a commettere — l'errore che ho commesso io per primo, con il mio solver più veloce — è trattare quei 15 giorni come un problema di velocità da risolvere calcolando più duramente. Non lo sono. Sono un problema di certezza, e non si risolve un problema di certezza esigendo più certezza da un mondo che si sta attivamente disgregando. Lo si risolve costruendo qualcosa che ragiona nell'incertezza, prova il disastro prima che arrivi e si dimostra nell'ombra prima ancora di essere considerato affidabile alla luce del sole. Questo è il motore che abbiamo costruito, ed è descritto per intero nella nostra soluzione di AI per la pianificazione degli equipaggi delle compagnie aeree.

Da qualche parte stanotte c'è un centro di controllo operativo dove il videowall è calmo e verde, e un solver per gli equipaggi ronza attraverso il suo ciclo batch esattamente come è stato progettato. Il lavoro che facciamo è per la notte in cui quella sala diventa rossa — quando i telefoni si intasano, gli accoppiamenti saltano più in fretta di quanto chiunque riesca a metterli per iscritto, e un dispatcher si allunga verso una lavagna perché la certezza che il software esige se n'è andata in silenzio. Tutto il punto è assicurarsi che, in quella notte, la macchina stia ancora ragionando onestamente su una compagnia aerea che non riesce più a vedere del tutto.