L'automazione diventa letale: l'MCAS e il 737 Max

Come una funzione di sicurezza automatizzata è diventata parte di una catastrofe

Quando due aerei di linea Boeing 737 MAX si sono schiantati a pochi mesi di distanza l'uno dall'altro nel 2018-2019, gli investigatori hanno rintracciato un filo comune nel software di controllo del volo del velivolo. Un sistema progettato per aiutare l'aereo a gestire motori di forma diversa — il Maneuvering Characteristics Augmentation System, o MCAS — è stato rielaborato in una fase avanzata dello sviluppo in modi che hanno reso il suo comportamento più assertivo e, aspetto critico, dipendente da un singolo sensore di angolo d'attacco. Tali modifiche hanno rimosso livelli di protezione e lasciato gli equipaggi esposti a una modalità di guasto rapida e confusionaria che non erano stati addestrati a riconoscere o contrastare.

MCAS: cosa avrebbe dovuto fare

L'MCAS è stato introdotto per aiutare il MAX a manovrare come i precedenti modelli di 737 dopo che motori più grandi e montati più avanti ne avevano cambiato l'aerodinamica. Il suo compito nominale era modesto: quando determinate condizioni suggerivano che il muso potesse inclinarsi troppo verso l'alto, l'MCAS regolava leggermente lo stabilizzatore orizzontale verso il basso per mantenere la manovrabilità coerente per i piloti. Nella sua concezione originale, doveva essere discreto e operare raramente.

Come il sistema è cambiato — e perché è stato importante

Durante lo sviluppo, Boeing ha ampliato il ruolo dell'MCAS. La versione implementata poteva attivarsi più frequentemente e applicare input allo stabilizzatore più ampi rispetto alle versioni precedenti, ed era configurata per reagire ai dati di un singolo sensore di angolo d'attacco invece di incrociare più fonti. In entrambi gli incidenti di Lion Air ed Ethiopian Airlines, dati errati sull'angolo d'attacco hanno innescato ripetuti input di picchiata che i piloti hanno combattuto ma non sono riusciti a superare in tempo. Il passaggio da un design conservativo e ridondante a un'implementazione più aggressiva a sensore singolo è stato un fattore decisivo nei guasti.

Perché definire l'MCAS «I.A.» è fuorviante — e perché l'etichetta è comunque importante

Nei media e nel dibattito pubblico, gli incidenti vengono talvolta inquadrati come un fallimento dell'«I.A.». Questa semplificazione è allettante ma imprecisa. L'MCAS non era un modello di apprendimento automatico che si addestrava dai dati; era una logica di controllo del volo deterministica: regole codificate per agire su specifici input dei sensori. Il pericolo, tuttavia, è lo stesso di cui ci si preoccupa con i sistemi di I.A. opachi: un comportamento automatizzato nascosto agli utenti finali e ai regolatori, che interagisce con segnali del mondo reale disordinati in modi che i progettisti non avevano pienamente previsto.

Etichettare l'MCAS come semplice «automazione» può sottovalutare come le scelte progettuali — specialmente riguardo a trasparenza, ridondanza e interazione uomo-macchina — abbiano trasformato una funzione protettiva in un pericolo. I voli rivelano che anche gli algoritmi che non apprendono richiedono una rigorosa ingegneria della sicurezza, lo stesso tipo di requisiti tracciabili e test indipendenti che ora chiediamo ai sistemi di I.A. in altri domini.

I fallimenti organizzativi e normativi hanno amplificato i difetti tecnici

Le scelte tecniche non sono avvenute nel vuoto. Molteplici revisioni e udienze hanno rilevato che i problemi di supervisione, comunicazione e cultura aziendale hanno amplificato il rischio. Ai regolatori non sono stati sempre presentati i dettagli completi dell'MCAS man mano che evolveva; i manuali dei piloti inizialmente omettevano la funzione; e l'ipotesi che l'MCAS si attivasse raramente ha ridotto l'addestramento dei piloti su come rispondere in caso di attivazione. Questi cedimenti istituzionali hanno trasformato un errore ingegneristico in una crisi di sicurezza pubblica.

Le correzioni implementate da Boeing e dai regolatori

Dopo la sospensione dei voli della flotta MAX, Boeing e le autorità aeronautiche hanno imposto modifiche software e operative. Il design rivisto limita l'MCAS in modo che agisca solo quando entrambi i sensori di angolo d'attacco concordano, lo limita a una singola attivazione per evento e modera l'entità degli input del trim. I regolatori hanno anche inasprito i requisiti per la documentazione, l'addestramento dei piloti e la verifica indipendente prima che il modello fosse autorizzato a tornare in servizio. Tali cambiamenti hanno affrontato le modalità di guasto immediate, ma non cancellano le più ampie questioni di governance esposte dalla crisi.

Lezioni per il più ampio dibattito sull'I.A. e l'automazione

La storia del MAX è un manuale ammonitore per chiunque distribuisca l'automazione su larga scala. Emergono quattro lezioni:

Questi sono ritornelli familiari nei circoli dell'etica e della sicurezza dell'I.A., ma il 737 MAX dimostra che non sono astratti. Nei sistemi critici per la sicurezza, i costi di un errore sono immediati e definitivi.

In quale direzione dovrebbe procedere il dibattito

Le correzioni tecniche hanno riportato il MAX in servizio a condizioni più severe, ma l'episodio rimane un punto di riferimento su come non gestire l'automazione nelle industrie regolamentate. Per i decisori politici e gli ingegneri l'imperativo è tradurre le lezioni in standard applicabili: percorsi di certificazione più chiari per i sistemi decisionali automatizzati, rendicontazione obbligatoria di modifiche sostanziali al design e strutture istituzionali che riducano i conflitti di interesse tra produttori e certificatori.

Per i giornalisti e il pubblico, è anche un promemoria per essere precisi con i termini. L'«I.A.» conquista i titoli, ma il problema di fondo nel caso del MAX non era l'intelligenza artificiale nel senso dell'apprendimento automatico — era una combinazione di automazione aggressiva, scarsa trasparenza e pratiche di sicurezza indebolite. Trattare tale combinazione come una sfida ingegneristica e di governance ci offre un percorso più produttivo per prevenirne la ripetizione.

Conclusione

I disastri del 737 MAX non erano inevitabili. Sono stati il risultato di specifiche decisioni progettuali, assunzioni non verificate e fallimenti istituzionali. Mentre l'automazione e l'I.A. si spingono in sempre più settori, il caso del MAX dovrebbe restare un esempio lampante: sistemi più sicuri non emergono dalla fiducia in un frammento di codice, ma da un design conservativo, una comunicazione chiara con gli utenti, revisioni indipendenti e una robusta supervisione normativa. Queste non sono sottigliezze tecniche — sono precondizioni della sicurezza pubblica.