Wanneer automatisering dodelijk wordt: MCAS en de Max

Hoe een geautomatiseerde veiligheidsfunctie onderdeel werd van een catastrofe

Toen in 2018–2019 twee Boeing 737 MAX-toestellen kort na elkaar verongelukten, vonden onderzoekers een gemeenschappelijke factor in de vluchtbesturingssoftware van het vliegtuig. Een systeem dat ontworpen was om het toestel te helpen omgaan met anders gevormde motoren — het Maneuvering Characteristics Augmentation System, of MCAS — werd laat in de ontwikkeling aangepast op een manier die het gedrag assertiever maakte en, cruciaal, afhankelijk van een enkele invalshoeksensor. Die wijzigingen verwijderden beschermingslagen en stelden bemanningen bloot aan een snelle, verwarrende storingsmodus die ze niet hadden geleerd te herkennen of te bestrijden.

MCAS: wat het geacht werd te doen

MCAS werd geïntroduceerd om de MAX hetzelfde te laten vliegen als eerdere 737-modellen, nadat grotere en meer naar voren geplaatste motoren de aerodynamica veranderden. De nominale taak was bescheiden: wanneer bepaalde omstandigheden suggereerden dat de neus te ver omhoog zou kunnen komen (pitch-up), trimde MCAS de horizontale stabilisator iets omlaag om de besturing voor piloten consistent te houden. In het oorspronkelijke concept was het de bedoeling dat het subtiel zou werken en slechts zelden in actie zou komen.

Hoe het systeem veranderde — en waarom dat uitmaakte

Tijdens de ontwikkeling breidde Boeing de rol van MCAS uit. De uiteindelijke versie kon vaker worden geactiveerd en grotere stabilisatoraanpassingen doorvoeren dan eerdere ontwerpen, en was geprogrammeerd om te reageren op gegevens van één enkele invalshoeksensor in plaats van het controleren van meerdere bronnen. In zowel het ongeluk met Lion Air als dat met Ethiopian Airlines veroorzaakten foutieve gegevens van de invalshoeksensor herhaalde neus-omlaag-commando's waartegen piloten vochten, maar die ze niet op tijd konden overmeesteren. De verschuiving van een conservatief, redundant ontwerp naar een agressievere implementatie met een enkele sensor was een doorslaggevende factor in de fatale fouten.

Waarom MCAS “A.I.” noemen misleidend is — en waarom het label toch van belang is

In de media en het publieke debat worden de crashes soms gepresenteerd als een falen van “A.I.”. Die afkorting is verleidelijk maar onnauwkeurig. MCAS was geen machine-learning-model dat zichzelf trainde op basis van data; het was deterministische vluchtbesturingslogica: regels die gecodeerd waren om te reageren op specifieke sensorinput. Het gevaar is echter hetzelfde als waar mensen zich zorgen over maken bij ondoorzichtige AI-systemen: geautomatiseerd gedrag dat verborgen is voor eindgebruikers en toezichthouders, en dat reageert op onvoorspelbare signalen uit de praktijk op manieren die de ontwerpers niet volledig hadden voorzien.

Door MCAS louter als “automatisering” te bestempelen, kan de impact van ontwerpkeuzes — met name rond transparantie, redundantie en mens-machine-interactie — worden onderschat. De vluchten laten zien dat zelfs niet-lerende algoritmen een rigoureuze veiligheidstechniek vereisen, met dezelfde traceerbare eisen en onafhankelijke tests die we nu vragen van AI-systemen in andere domeinen.

Organisatorische en regelgevende tekortkomingen versterkten technische gebreken

Technische keuzes vonden niet plaats in een vacuüm. Diverse onderzoeken en hoorzittingen toonden aan dat problemen in het toezicht, de communicatie en de bedrijfscultuur het risico vergrootten. Toezichthouders kregen niet altijd de volledige details van MCAS te zien naarmate het systeem evolueerde; pilotenhandboeken vermeldden de functie aanvankelijk niet; en de aanname dat MCAS zelden zou activeren, leidde tot minder training voor piloten over hoe te reageren als het systeem wél in werking trad. Deze institutionele tekortkomingen veranderden een technische fout in een crisis voor de openbare veiligheid.

De oplossingen die Boeing en toezichthouders implementeerden

Nadat de MAX-vloot aan de grond was gezet, eisten Boeing en de luchtvaartautoriteiten softwarematige en operationele wijzigingen. Het herziene ontwerp beperkt MCAS, zodat het alleen werkt wanneer beide invalshoeksensoren het eens zijn, beperkt het tot één enkele activatie per incident en matigt de grootte van de trim-inputs. Toezichthouders verscherpten ook de eisen voor documentatie, pilotentraining en onafhankelijke verificatie voordat het toesteltype weer in gebruik mocht worden genomen. Die wijzigingen verhielpen de directe storingsmodi, maar nemen de bredere governance-vraagstukken die door de crisis aan het licht kwamen niet weg.

Lessen voor het bredere debat over AI en automatisering

Het MAX-verhaal is een waarschuwende inleiding voor iedereen die automatisering op grote schaal inzet. Vier lessen vallen op:

Dit zijn bekende thema's in kringen van AI-ethiek en veiligheid, maar de 737 MAX laat zien dat ze niet abstract zijn. In veiligheidskritische systemen zijn de kosten van fouten direct en definitief.

Waar de discussie nu naartoe moet gaan

Technische aanpassingen hebben de MAX onder strengere voorwaarden weer in de lucht gekregen, maar het voorval blijft een ijkpunt voor hoe men automatisering in gereguleerde industrieën niet moet beheren. Voor beleidsmakers en ingenieurs is het zaak om lessen te vertalen naar handhaafbare normen: duidelijkere certificeringstrajecten voor geautomatiseerde beslissingssystemen, verplichte rapportage van wezenlijke ontwerpwijzigingen en institutionele structuren die belangenverstrengeling tussen fabrikanten en certificeerders verminderen.

Voor journalisten en het publiek is het ook een herinnering om nauwkeurig te zijn met termen. “AI” haalt de krantenkoppen, maar het onderliggende probleem in het geval van de MAX was geen kunstmatige intelligentie in de zin van machine learning — het was een combinatie van agressieve automatisering, gebrekkige transparantie en verzwakte veiligheidspraktijken. Door die combinatie te behandelen als een uitdaging op het gebied van techniek en bestuur, ontstaat een productiever pad om herhaling te voorkomen.

Conclusie

De rampen met de 737 MAX waren niet onvermijdelijk. Ze waren het resultaat van specifieke ontwerpbeslissingen, ongecontroleerde aannames en institutionele tekortkomingen. Nu automatisering en AI in steeds meer domeinen doordringen, moet de MAX-casus dienen als een scherp voorbeeld: veiligere systemen ontstaan niet uit vertrouwen in een stuk code, maar uit een conservatief ontwerp, duidelijke communicatie met gebruikers, onafhankelijke toetsing en robuust regelgevend toezicht. Dat zijn geen technische futiliteiten — het zijn randvoorwaarden voor de openbare veiligheid.