Southwest Airlines aveva perso le tracce dei suoi stessi piloti. È lì che ho capito che i chatbot non avrebbero salvato la logistica.

La telefonata che ha cambiato il mio modo di pensare all'IA non veniva da un cliente né da un investitore. Veniva da un amico — un pilota — che ha passato il Natale del 2022 dormendo sul pavimento dell'aeroporto internazionale di Denver.

Non era bloccato a causa del maltempo. La tempesta era passata. Era bloccato perché Southwest Airlines aveva letteralmente perso le tracce di dove si trovasse. Il sistema di pianificazione degli equipaggi della compagnia — un vecchio ottimizzatore chiamato SkySolver — calcolava i piani di ripristino basandosi su posizioni degli equipaggi vecchie di ore. Generava orari per una compagnia aerea fantasma. Il mio amico ha chiamato la linea diretta della pianificazione e ha aspettato in attesa per otto ore. Quando qualcuno ha finalmente risposto, l'orario che avevano appena calcolato era già di nuovo sbagliato.

Quella settimana, Southwest ha cancellato oltre 16.900 voli. Due milioni di passeggeri sono rimasti bloccati. La compagnia ha perso più di 1 miliardo di dollari. Ed ecco la parte che mi ha ossessionato: ogni altro grande vettore statunitense ha affrontato la stessa tempesta, gli stessi piazzali ghiacciati, la stessa carenza di personale. United, Delta, American — si sono tutti ripresi nel giro di 48 ore. Southwest è precipitata nel caos per un'intera settimana.

Continuavo a tornare su una sola domanda: perché il software di una compagnia aerea è collassato mentre quello delle altre si è piegato ed è tornato a funzionare? La risposta, ho scoperto, non aveva nulla a che vedere con il meteo e tutto a che vedere con il modo in cui abbiamo costruito i cervelli computazionali delle operazioni complesse negli ultimi trent'anni. È quella consapevolezza che mi ha portato a fondare Veriprajna — e a scrivere questo articolo di ricerca che espone per intero l'argomentazione tecnica.

Ma la versione breve è questa: abbiamo ottimizzato la logistica per l'efficienza in un mondo che non premia più l'efficienza. Abbiamo costruito sistemi che trovano la risposta più economica a una domanda nota, quando ciò di cui abbiamo davvero bisogno sono sistemi che trovano una risposta a cui si sopravvive a una domanda ignota.

La topologia che ha ucciso il Natale

Per capire perché Southwest si è rotta, bisogna comprendere un concetto della teoria dei grafi — e vi assicuro che è più interessante di quanto sembri.

Delta, United e American operano reti hub-and-spoke. I voli si irradiano da hub centrali come Atlanta o Newark. Se una tempesta colpisce il Nordest, un vettore hub-and-spoke può "isolare" il danno — cancellare tutti i voli in arrivo a Newark per una mattinata, azzerare il sottografo e ripartire. Equipaggi e aerei ritornano frequentemente attraverso l'hub, creando punti di ripristino naturali.

Southwest ha aperto la strada a un modello diverso: point-to-point. Un aereo e il suo equipaggio percorrono una catena lineare — da Baltimora a Denver a San Diego a Phoenix a Sacramento. Economicamente geniale. Si spremono più ore di volo da ogni aeromobile. Ma matematicamente? È un castello di carte. Un ritardo sulla prima tratta non incide solo sul ritorno — si propaga a cascata lungo l'intera catena. L'equipaggio che doveva volare da San Diego a Phoenix resta bloccato a Denver. L'aereo che li aspetta a San Diego rimane a terra.

In termini di teoria dei grafi, il diametro del grafo delle dipendenze in una rete point-to-point è enormemente maggiore che in una hub-and-spoke. Il raggio d'azione di una singola interruzione è incontenibile.

Ricordo la notte in cui ho tracciato per la prima volta tutto questo su una lavagna nel nostro ufficio. Io e il mio team avevamo discusso se il fallimento di Southwest fosse un problema di software o un problema di progettazione della rete. Uno dei miei ingegneri, esasperato dalla mia insistenza sul fatto che fosse entrambe le cose, ha aperto i dati di volo reali e ha iniziato a disegnare le catene di dipendenza. Abbiamo guardato la cascata svolgersi sulla mappa. Un ritardo a Baltimora si è propagato a Denver, che ha interrotto una connessione con San Diego, che ha lasciato a terra un equipaggio che avrebbe dovuto volare su Phoenix, che…

"Non è una catena," ha detto. "È una frattura."

Aveva ragione. E la frattura era invisibile al software che avrebbe dovuto risolverla.

Perché SkySolver si è inceppato?

SkySolver è costruito sulle stesse fondamenta matematiche che alimentano la maggior parte dell'ottimizzazione logistica: la programmazione lineare intera mista e una tecnica chiamata generazione di colonne (Column Generation). Sono i cavalli di battaglia della Ricerca Operativa, la disciplina che governa il modo in cui spostiamo atomi in giro per il mondo fin dagli anni '50.

Ecco come funziona in parole povere: il sistema scatta un'istantanea del mondo — dove si trova ogni membro dell'equipaggio, qual è lo stato di ogni aereo — congela il tempo e calcola il modo matematicamente più economico per coprire tutti i voli. Per una grande compagnia aerea con 4.000 voli giornalieri, il numero di possibili combinazioni equipaggio-volo è praticamente infinito. La generazione di colonne gestisce questo generando iterativamente combinazioni "promettenti" e restringendo la ricerca.

È elegante. È potente. E ha un presupposto fatale radicato nel proprio DNA: il mondo resta immobile mentre il sistema pensa.

Durante le operazioni normali, un ciclo del risolutore di 30-60 minuti va bene. Ma durante il tracollo, lo stato della rete di Southwest cambiava ogni pochi minuti. Gli equipaggi non riuscivano a comunicare le proprie posizioni perché le linee telefoniche erano intasate. I dati che alimentavano SkySolver erano vecchi di ore. Il sistema stava ottimizzando un mondo che non esisteva più.

Quando il ritmo delle interruzioni supera la velocità dell'informazione, l'ottimizzazione non si degrada in modo controllato. Collassa.

Questo è ciò che io chiamo il divario ottimizzazione-esecuzione — il disallineamento letale tra la velocità con cui un risolutore può calcolare e la velocità con cui la realtà si muove. E non è esclusivo delle compagnie aeree. Ho visto lo stesso schema di fallimento nella logistica portuale, nella gestione del traffico ferroviario e nelle catene di fornitura manifatturiere. La matematica è la stessa. La fragilità è la stessa.

Il momento in cui ho smesso di credere nei chatbot per la logistica

Circa sei mesi dopo la crisi di Southwest, ero seduto in una riunione con un investitore che mi ha detto, con assoluta sicurezza: "Basta usare GPT. Fai fine-tuning sui dati di pianificazione. Problema risolto."

Ho cercato di spiegargli perché non avrebbe funzionato. Mi ha interrotto: "Ma sa ragionare. L'ho visto risolvere problemi di matematica."

Quella conversazione ha cristallizzato qualcosa che faticavo ad articolare. L'intero settore stava commettendo un errore di categoria — confondendo la fluidità linguistica dei Large Language Model con il ragionamento operativo necessario per gestire sistemi complessi. I fornitori inondavano il mercato di "Copiloti IA" che sovrapponevano un'interfaccia di chat a risolutori legacy. Un dispatcher chiede: "Come recuperiamo l'orario di Denver?" e l'LLM lo traduce in una chiamata API allo stesso ottimizzatore rotto sottostante.

È una nuova mano di vernice su un motore grippato.

Ecco il problema di fondo: gli LLM sono motori probabilistici progettati per prevedere il token successivo in una sequenza. Emulano la forma del ragionamento senza possedere un modello del mondo. In termini di scienze cognitive, sono enormi motori di Sistema 1 — riconoscimento di schemi rapido e intuitivo. L'ottimizzazione logistica è un compito di Sistema 2 — verifica lenta, deliberata e passo dopo passo dei vincoli.

Ed è nel problema dei vincoli che la cosa diventa pericolosa. Nella scrittura creativa, un'accuratezza del 99% è eccellente. Nella pianificazione degli equipaggi, un'accuratezza del 99% è illegale. Se un LLM genera un orario che assegna a un pilota con 7 ore e 59 minuti di riposo un volo che ne richiede 8, l'intero orario è invalido. Gli LLM non gestiscono naturalmente la rigida natura binaria dei vincoli di fattibilità. Danno priorità alla coerenza linguistica rispetto alla correttezza logica.

Un chatbot che sa spiegare un orario non è la stessa cosa di un agente che sa ripararne uno.

I benchmark su problemi combinatori come il problema del commesso viaggiatore (Traveling Salesman Problem) lo confermano su larga scala. Man mano che il numero di nodi aumenta, gli LLM "visitano" alcune città due volte, ne saltano altre del tutto e perdono traccia dello stato lungo sequenze lunghe. Non riescono a simulare futuri ramificati né a fare backtracking. Sono ciechi all'effetto farfalla — la realtà per cui una piccola decisione di pianificazione presa ora può causare una catastrofe tre giorni dopo.

Ciò che funziona davvero: insegnare a un'IA a pensare per grafi

Quindi, se i risolutori legacy sono troppo lenti e gli LLM troppo inaffidabili, cosa si costruisce?

Questa è la domanda a cui io e il mio team abbiamo dedicato anni a rispondere, e l'architettura a cui siamo arrivati è costruita sul Graph Reinforcement Learning — una fusione di reti neurali a grafo (Graph Neural Networks, per comprendere la topologia della rete) e apprendimento per rinforzo (Reinforcement Learning, per apprendere politiche decisionali dinamiche). Siamo passati dal calcolare un orario all'apprendere come pianificarlo.

L'intuizione che ha sbloccato tutto era ingannevolmente semplice: le reti logistiche non sono fogli di calcolo. Sono grafi. Gli aeroporti sono nodi. I voli sono archi. I magazzini sono nodi. I camion sono archi. Le architetture tradizionali di machine learning — quelle progettate per immagini o testo — faticano con questa struttura relazionale. Le reti neurali a grafo sono l'architettura nativa per essa.

Usiamo le Graph Attention Networks per codificare lo stato dell'intera rete logistica. Ogni entità — pilota, aereo, aeroporto — diventa un nodo con un embedding ad alta dimensionalità che cattura sia proprietà statiche (tipo di aeromobile, qualifiche dell'equipaggio) sia stato dinamico (ritardo attuale, stato di manutenzione, affaticamento accumulato). Le connessioni tra loro trasportano informazioni su durata del volo, rischio meteo e assegnazioni degli equipaggi.

La magia sta in ciò che si chiama passaggio di messaggi (message passing). Quando una bufera di neve chiude Denver, la GNN aggiorna l'embedding di Denver. Quell'aggiornamento fluisce lungo ogni arco collegato — ogni volo in arrivo, ogni assegnazione di equipaggio. Un pilota a Baltimora che si prepara a volare verso Denver riceve un "segnale di rischio" nel proprio embedding prima ancora di partire. Il sistema vede la connettività. Comprende il raggio d'azione. Questo tipo di consapevolezza topologica è impossibile nelle rappresentazioni di dati piatte e tabellari che i sistemi legacy utilizzano.

Sopra questo livello di percezione del grafo, facciamo girare agenti di apprendimento per rinforzo. Un agente RL osserva lo stato, compie un'azione (scambiare un equipaggio, cancellare un volo, ritardare una partenza, trasferire un equipaggio a vuoto verso una nuova posizione) e riceve una ricompensa. Nel corso di milioni di iterazioni di addestramento, apprende una politica che massimizza i risultati a lungo termine.

Quell'espressione — a lungo termine — è tutto. Un'euristica potrebbe dire: "Non cancellare questo volo, fa perdere ricavi." Il nostro agente RL apprende: "Se non cancello questo volo, l'equipaggio resta bloccato a Denver e domani perdo dieci voli. Cancellalo ora." Apprende il sacrificio strategico per la sopravvivenza del sistema.

Come si addestra un'IA per disastri che non sono ancora accaduti?

Ovviamente non si può addestrare un agente di apprendimento per rinforzo su una compagnia aerea reale. Il tentativo ed errore nel mondo reale costa milioni e crea rischi per la sicurezza. È qui che entra in gioco il gemello digitale (Digital Twin) — e non intendo un cruscotto con una resa 3D di un aeroporto.

I nostri gemelli digitali sono motori di transizione di stato. Modelliamo ogni aeromobile con cicli di manutenzione specifici per matricola, ogni gate, ogni membro dell'equipaggio con contatori di affaticamento individuali e stati contrattuali. Digitalizziamo il regolamento — FAA Part 117, contratti sindacali, manuali di manutenzione. Ogni transizione di stato viene verificata rispetto a queste regole.

Poi iniettiamo il caos.

Usiamo generatori stocastici per simulare 10.000 anni di operazioni in una settimana. Creiamo super-tempeste, imponenti fermate meccaniche a terra, scioperi. Iniziamo gli agenti con giornate facili — bel tempo, orari leggeri — e aumentiamo gradualmente la difficoltà, introducendo guasti a cascata che farebbero sembrare il tracollo di Southwest un lieve inconveniente.

Ricordo la prima volta che abbiamo fatto girare la crisi Southwest del dicembre 2022 attraverso il nostro simulatore. Avevamo costruito un surrogato del risolutore legacy per fare da riferimento di confronto. Il risolutore legacy ha fatto esattamente ciò che ha fatto SkySolver — si è inceppato sulla latenza dei dati, ha ottimizzato per lo stato sbagliato e ha prodotto lo stesso groviglio di equipaggi bloccati. Tempo di ripristino: sette giorni simulati.

Il nostro agente GRL ha fatto qualcosa che nessuno di noi si aspettava. Ha rilevato lo schema di frattura point-to-point emergere a Denver ore prima della cascata completa. Poi ha eseguito quella che ora chiamiamo una strategia di firewall preventivo — ha cancellato in anticipo il 20% dei voli in arrivo a Denver, intrappolando l'interruzione a livello locale, e ha trasferito a vuoto degli equipaggi a Phoenix per creare una base operativa secondaria.

La rete della costa orientale è rimasta operativa al 95%. Le cancellazioni totali sono scese del 66%. Il tracollo è stato contenuto a un'interruzione regionale.

Il mio ingegnere — lo stesso che aveva disegnato la frattura sulla lavagna — fissava lo schermo. "Ha sacrificato Denver per salvare la rete," ha detto. "Nessun dispatcher umano avrebbe avuto il fegato di farlo alle 6 del mattino del 22 dicembre."

Aveva ragione. Ed è questo il punto. L'agente aveva "vissuto" migliaia di crisi in simulazione. Aveva esplorato i confini dello spazio degli stati dove i risolutori legacy vanno in crash, e aveva appreso che aspetto ha la sopravvivenza. Per la analisi tecnica completa dell'architettura — gli embedding GAT, il ciclo di addestramento PPO, il mascheramento delle azioni — ho pubblicato la ricerca integrale.

E il problema della scatola nera?

Le persone qui oppongono sempre resistenza, e fanno bene. "Mi sta dicendo di affidare il controllo delle operazioni di una compagnia aerea a una rete neurale? Come faccio a sapere che non allucinerà un orario illegale?"

Questa è l'obiezione più importante nell'IA critica per la sicurezza, e chiunque la liquidi non è serio. Ecco come la risolviamo.

Non lasciamo mai che la rete neurale produca direttamente la decisione finale. Usiamo quella che chiamiamo un'architettura a sandwich — ispirata al framework NICE per la programmazione intera guidata dall'apprendimento per rinforzo. Il livello neurale (il nostro agente GRL) analizza lo stato complesso e rumoroso e propone una distribuzione di probabilità sulle azioni. Poi un livello simbolico deterministico — un motore di vincoli che codifica ogni regola rigida dell'operazione — applica una maschera. Se la rete neurale suggerisce un'azione che viola un regolamento (il pilota supera le ore di servizio, l'aereo vola con un intervento di manutenzione aperto), il livello simbolico azzera la probabilità di quell'azione.

Il sistema non può eseguire un'azione illegale. Non "probabilmente non lo farà." Non può.

Questo ci offre qualcosa di notevole: l'ottimalità delle politiche IA apprese unita alle garanzie di sicurezza della logica formale. E risolve anche il problema computazionale dall'altra direzione. Invece che il risolutore legacy esplori un miliardo di possibilità, la rete neurale pota l'albero fino ai dieci rami più promettenti. Il risolutore deve solo convalidare e affinare quelle poche opzioni. Il tempo di calcolo scende da ore a secondi.

Non si tratta solo di compagnie aeree

Il tracollo di Southwest è l'esempio più drammatico, ma la fragilità che ha rivelato è universale. Stiamo adattando la stessa architettura GRL + gemello digitale ai porti marittimi e alle reti ferroviarie.

Nei porti, una nave in ritardo perde il suo slot di ormeggio, le gru vengono riassegnate e i camion programmati per il ritiro dei container fanno la fila per ore. Distribuiamo un'IA agentica in cui un "Agente Rada" negozia con un "Agente Terminal" in tempo reale, appianando i picchi e le valli della congestione ai gate man mano che le interruzioni si sviluppano.

Nel settore ferroviario, dove i colli di bottiglia a binario unico fanno sì che una sola decisione errata di "incrocio-sorpasso" possa bloccare treni a centinaia di chilometri di distanza, i nostri agenti GRL superano i dispatcher umani e le regole euristiche del 15-20% nella riduzione dei ritardi. Compiono mosse non intuitive — fermando anticipatamente un treno merci per liberare la strada a un treno espresso 80 chilometri più a monte — che nessun sistema basato su regole prenderebbe in considerazione.

Lo schema è sempre lo stesso: una rete complessa, vincoli rigidi, interruzioni a cascata e una finestra decisionale misurata in minuti. I risolutori legacy non riescono a tenere il passo. Gli LLM non riescono a ragionarci. Il Graph Reinforcement Learning ci riesce.

Il vero ROI non è l'efficienza — è la sopravvivenza

Il tracollo di una settimana di Southwest è costato 1,2 miliardi di dollari. Quel singolo evento ha cancellato anni di guadagni di efficienza ottenuti gestendo una rete point-to-point snella. Un Canale di Suez bloccato costa all'economia globale miliardi al giorno. Il rischio di coda — l'evento catastrofico, quello "una volta ogni decennio" che ora sembra accadere ogni anno — non è più una nota a piè di pagina nel registro dei rischi. Su un orizzonte di dieci anni, è il principale fattore di costo.

I nostri agenti offrono un risparmio sui costi operativi del 2-5% durante le operazioni normali grazie a una gestione più intelligente dei margini e a una riduzione degli straordinari degli equipaggi. Quella è la posta in gioco minima. Il vero valore è ciò che non accade: il tracollo che viene contenuto a un'interruzione regionale, la cascata che viene isolata prima di raggiungere la costa orientale, la settimana da un miliardo di dollari che non si materializza mai.

L'efficienza è una strategia per un mondo stabile. Non viviamo più in un mondo stabile.

L'era della matematica statica è finita

Ho iniziato questo saggio con un pilota che dorme sul pavimento dell'aeroporto internazionale di Denver. Vola ancora per Southwest. Da allora la compagnia ha investito molto nell'aggiornamento dei propri sistemi. Ma il problema più profondo — la dipendenza dell'intero settore da risolutori deterministici costruiti per un mondo di interruzioni prevedibili — resta in gran parte irrisolto.

La corsa verso l'IA generativa come salvatrice della logistica mi preoccupa più dei sistemi legacy. Almeno chi gestiva SkySolver ne conosceva i limiti. Chi implementa wrapper LLM sopra ottimizzatori rotti spesso no. Vedono testo fluente e lo scambiano per ragionamento operativo. Vedono un chatbot che sa spiegare un orario e presumono che sappia ripararne uno.

Costruire Veriprajna mi ha insegnato che la parte più difficile di questo lavoro non è la matematica — è l'argomentazione. Convincere un settore che gli strumenti di cui si è fidato per decenni hanno un tetto strutturale. Che la novità scintillante (l'IA generativa) è puntata sul problema sbagliato. Che la soluzione vera richiede di ripensare la logistica come un grafo, l'interruzione come un segnale di apprendimento e la resilienza come qualcosa per cui ci si addestra — non qualcosa che si spera.

Il futuro della logistica non appartiene ai sistemi che trovano il piano più economico per un mondo noto. Appartiene ai sistemi che trovano un piano a cui si sopravvive per un mondo ignoto. Non è un forse. È ciò che stiamo costruendo.