Tödliche Automatisierung: MCAS und die Max

Wie eine automatisierte Sicherheitsfunktion Teil einer Katastrophe wurde

Als in den Jahren 2018–2019 zwei Boeing 737 MAX Verkehrsflugzeuge innerhalb weniger Monate nacheinander abstürzten, stießen Ermittler auf einen gemeinsamen Nenner in der Flugsteuerungssoftware der Maschinen. Ein System, das dazu entwickelt worden war, das Flugverhalten der Maschine an die veränderte Form der Triebwerke anzupassen – das Maneuvering Characteristics Augmentation System oder MCAS –, wurde spät in der Entwicklung so umgestaltet, dass es deutlich aggressiver agierte und, was entscheidend war, von einem einzigen Anstellwinkelsensor abhängig war. Diese Änderungen entfernten Schutzebenen und setzten die Besatzungen einem schnellen, verwirrenden Fehlermodus aus, für dessen Erkennung oder Bewältigung sie nicht geschult worden waren.

MCAS: Was es eigentlich tun sollte

MCAS wurde eingeführt, um der MAX ein ähnliches Flugverhalten wie bei früheren 737-Modellen zu ermöglichen, nachdem größere und weiter vorne montierte Triebwerke die Aerodynamik verändert hatten. Seine nominelle Aufgabe war bescheiden: Wenn bestimmte Bedingungen darauf hindeuteten, dass sich die Nase zu weit aufbäumen könnte, trimmte das MCAS das Höhenleitwerk leicht kopflastig, um das Flugverhalten für die Piloten konsistent zu halten. In seinem ursprünglichen Konzept sollte es unauffällig sein und nur selten eingreifen.

Wie sich das System veränderte – und warum das wichtig war

Während der Entwicklung weitete Boeing die Rolle des MCAS aus. Die implementierte Version konnte häufiger aktiviert werden und stärkere Korrekturen am Höhenleitwerk vornehmen als frühere Entwürfe. Zudem war sie so programmiert, dass sie auf Daten eines einzigen Anstellwinkelsensors reagierte, anstatt mehrere Quellen abzugleichen. Bei den Unfällen von Lion Air und Ethiopian Airlines lösten fehlerhafte Anstellwinkeldaten wiederholte Kommandos zum Senken der Nase aus, gegen die die Piloten ankämpften, sie aber nicht rechtzeitig überwinden konnten. Der Wechsel von einem konservativen, redundanten Design zu einer aggressiveren Implementierung mit nur einem Sensor war ein entscheidender Faktor für die Katastrophen.

Warum es irreführend ist, das MCAS als „K.I.“ zu bezeichnen – und warum der Begriff dennoch eine Rolle spielt

In den Medien und der öffentlichen Debatte werden die Abstürze manchmal als Versagen einer „K.I.“ dargestellt. Diese Kurzform ist verlockend, aber unpräzise. Das MCAS war kein Modell für maschinelles Lernen, das sich selbst anhand von Daten trainierte; es handelte sich um eine deterministische Flugsteuerungslogik: Regeln, die darauf programmiert waren, auf spezifische Sensoreingaben zu reagieren. Die Gefahr ist jedoch dieselbe, die man bei undurchsichtigen KI-Systemen befürchtet – automatisiertes Verhalten, das vor Endnutzern und Regulierungsbehörden verborgen bleibt und mit komplexen Signalen der realen Welt auf eine Weise interagiert, die seine Entwickler nicht vollständig vorhergesehen haben.

Die Bezeichnung des MCAS als bloße „Automatisierung“ kann unterschätzen, wie Designentscheidungen – insbesondere in Bezug auf Transparenz, Redundanz und Mensch-Maschine-Interaktion – eine Schutzfunktion in eine Gefahr verwandelten. Die Flüge zeigen, dass selbst nicht lernende Algorithmen ein strenges Sicherheits-Engineering erfordern, dieselben Arten von rückverfolgbaren Anforderungen und unabhängigen Tests, die wir heute von KI-Systemen in anderen Bereichen verlangen.

Organisatorisches und regulatorisches Versagen verstärkten technische Mängel

Technische Entscheidungen trafen nicht in einem Vakuum aufeinander. Mehrere Überprüfungen und Anhörungen ergaben, dass Probleme bei der Aufsicht, der Kommunikation und der Unternehmenskultur das Risiko verstärkten. Den Regulierungsbehörden wurden nicht immer alle Details des sich weiterentwickelnden MCAS vorgelegt; in den Pilotenhandbüchern fehlte die Funktion zunächst; und die Annahme, dass das MCAS nur selten aktiviert würde, führte zu einer Verringerung des Pilotentrainings für den Fall eines Eingreifens. Diese institutionellen Zusammenbrüche machten aus einem Konstruktionsfehler eine Krise der öffentlichen Sicherheit.

Die Korrekturen, die Boeing und die Aufsichtsbehörden implementierten

Nach dem Grounding der MAX-Flotte forderten Boeing und die Luftfahrtbehörden Softwareänderungen und betriebliche Anpassungen. Das überarbeitete Design schränkt das MCAS so ein, dass es nur aktiv wird, wenn beide Anstellwinkelsensoren übereinstimmen, begrenzt es auf eine einzige Aktivierung pro Ereignis und dämpft das Ausmaß der Trimmbefehle. Die Regulierungsbehörden verschärften zudem die Anforderungen an Dokumentation, Pilotentraining und unabhängige Verifizierung, bevor der Typ wieder für den Flugbetrieb freigegeben wurde. Diese Änderungen behoben die unmittelbaren Fehlermodi, beseitigen jedoch nicht die umfassenderen Fragen der Governance, die durch die Krise offengelegt wurden.

Lehren für die breitere Debatte über KI und Automatisierung

Die Geschichte der Max ist ein warnendes Beispiel für jeden, der Automatisierung in großem Maßstab einsetzt. Vier Lehren stechen hervor:

Dies sind vertraute Refrains in Kreisen der KI-Ethik und -Sicherheit, aber die 737 MAX zeigt, dass sie nicht abstrakt sind. In sicherheitskritischen Systemen sind die Kosten für Fehler unmittelbar und endgültig.

Wohin die Diskussion als Nächstes führen sollte

Technische Korrekturen haben die MAX unter strengeren Auflagen wieder in Betrieb genommen, doch das Ereignis bleibt ein Maßstab dafür, wie man Automatisierung in regulierten Industrien nicht handhaben sollte. Für politische Entscheidungsträger und Ingenieure ist es zwingend erforderlich, die Lehren in durchsetzbare Standards zu übersetzen: klarere Zertifizierungswege für automatisierte Entscheidungssysteme, eine obligatorische Berichterstattung über wesentliche Designänderungen und institutionelle Strukturen, die Interessenkonflikte zwischen Herstellern und Zertifizierern verringern.

Für Journalisten und die Öffentlichkeit ist es zudem eine Mahnung, bei Begriffen präzise zu sein. „KI“ sorgt für Schlagzeilen, aber das zugrunde liegende Problem im Fall der MAX war keine künstliche Intelligenz im Sinne des maschinellen Lernens – es war eine Kombination aus aggressiver Automatisierung, mangelnder Transparenz und geschwächten Sicherheitspraktiken. Diese Kombination als Herausforderung für Engineering und Governance zu behandeln, bietet uns einen produktiveren Weg, um eine Wiederholung zu verhindern.

Fazit

Die Katastrophen der 737 MAX waren nicht unvermeidlich. Sie waren das Ergebnis spezifischer Designentscheidungen, ungeprüfter Annahmen und institutionellen Versagens. Während Automatisierung und KI in immer mehr Bereiche vordringen, sollte der Fall der MAX als mahnendes Beispiel dienen: Sicherere Systeme entstehen nicht aus dem Vertrauen in einen Softwarecode, sondern aus konservativem Design, klarer Kommunikation mit den Nutzern, unabhängiger Überprüfung und robuster behördlicher Aufsicht. Dies sind keine technischen Nettigkeiten – sie sind Voraussetzungen für die öffentliche Sicherheit.