Simulator-Training: KI analysiert Piloten-Performance und findet versteckte Schwächen

Das echte Ausmaß des Problems

Ein moderner Full-Flight-Simulator der Level-D-Klasse zeichnet während jeder Trainingseinheit kontinuierlich auf: Steuerknüppelpositionen, Ruderausschläge, Triebwerksparameter, FMS-Eingaben, EFIS-Anzeigen, Autopilot-Zustände, Radioaltimeter-Werte, Sink Rate, Groundspeed — typisch 300 bis 500 Parameter mit bis zu 64 Datenpunkten pro Sekunde. Eine vierstündige Simulator-Session erzeugt damit rund 50.000 bis 70.000 verwertbare Datenpunkte pro Manöver-Typ.

Diese Daten liegen vor. Sie werden gespeichert. Sie werden für Rechnungszwecke und EASA-Konformitätsnachweise genutzt — und dann archiviert.

Was nicht passiert: systematische, manöverübergreifende Auswertung über Piloten und Sessions hinweg. Stattdessen basiert das Urteil über einen Piloten auf dem, was der Instructor in Echtzeit beobachtet und im mündlichen Debriefing formuliert. Das ist gut — aber es ist selektiv, subjektiv und notwendigerweise auf die einzelne Session beschränkt.

Das führt zu drei strukturellen Blindstellen:

• Wiederkehrende Subtilmuster bleiben unsichtbar, weil kein einzelner Instructor dieselbe Crew über mehrere Sessions begleitet. Drei verschiedene Instructors in drei verschiedenen Perioden sehen drei Ausreißer — das Muster dahinter ist systemisch, aber keiner der Beobachter kann es als solches erkennen.
• Curriculumfehler werden spät entdeckt. Wenn 28 % einer Traineekohorte bei denselben Manövern unterdurchschnittlich abschneidet, ist das ein Hinweis auf ein Designproblem im Programm — nicht auf 28 % schwache Kandidaten. Ohne aggregierte Datenauswertung dauert es Monate oder Jahre, bis dieser Trend erkannt wird.
• Instructors tragen die Last subjektiver Bewertung ohne objektive Datenstütze. Im Nachgang zu Zwischenfällen, in Bewährungsentscheidungen bei Type-Ratings, bei Competency-Check-Grenzfällen — der Instructor muss entscheiden, und er hat nur seine eigene Beobachtung.

Der Verband der Europäischen Fluglinien (AEA) und IATA schätzen, dass ein Full-Flight-Simulator in der Betreiberkalkulation europäischer ATOs — inklusive Kapitalkosten, Maintenance, Instructor-Stunden, Facility-Overhead — zwischen 2.500 und 4.000 Euro pro Stunde kostet (interne Kalkulation variiert stark). Jede Simulator-Stunde, die ein Pilot unnötig wiederholt, weil eine Schwäche zu spät erkannt wurde, kostet damit real 2.500 bis 4.000 Euro — und das ist der ROI-Anker für jede Investition in Trainingsanalytik.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Paladin AI / TXT InstructIQ, laut Produktunterlagen (2024); keine unabhängig verifizierten Vergleichsstudien verfügbar.

Der Vergleich klingt klar — ist es aber nur bedingt. Die KI ändert nicht, wie Piloten trainieren. Sie ändert, welche Information der Instructor vor und während des Debriefings hat. Das ist ein Hilfsmittel, keine Entscheidungsmaschine.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Der direkte Zeitgewinn entsteht im Debriefing: Ein Instructor, der die Session-Auswertung manuell vorbereitet, braucht 30 bis 60 Minuten. Mit einem automatisierten Performance-Report reduziert sich die Vorbereitung auf 10 bis 15 Minuten — ein reales, aber nicht dramatisches Delta. Verglichen mit Use Cases wie der KI-Wartungsdokumentation, die täglich repetitive Schreibarbeit eliminiert, ist die Zeitersparnis hier weniger dominant.

Kosteneinsparung — niedrig (2/5) Die Einsparung ist real, aber teuer zu realisieren: Jede vermiedene Simulator-Wiederholungsstunde spart 2.500 bis 4.000 Euro. Wenn eine Airline pro Jahr 300 Type-Ratings durchführt und im Schnitt 0,3 Stunden je Trainee einspart, sind das 225.000 bis 360.000 Euro — auf dem Papier überzeugend. Die Integration der Simulator-Datensysteme kostet jedoch typisch 150.000 bis 400.000 Euro einmalig, zuzüglich laufender Lizenz- und Betriebskosten. Amortisation frühestens nach 18 bis 24 Monaten — und nur, wenn die Einsparung kausal nachweisbar ist (was schwierig ist). Für kleinere ATOs mit weniger als 100 Type-Ratings pro Jahr ist die Wirtschaftlichkeit fraglich.

Schnelle Umsetzung — sehr niedrig (1/5) Das ist der schwierigste Aspekt dieses Use Case — und der ehrlichste Grund, ihn nicht zu unterschätzen. Der Weg vom Konzept zum Produktivbetrieb dauert realistisch 9 bis 18 Monate: Simulator-Datenschnittstelle erschließen (proprietäre Formate je OEM), Modell trainieren, EASA-konforme Aufzeichnungsstruktur einrichten, Betriebsrat einbinden (in Deutschland obligatorisch, §87 BetrVG), Instructor-Akzeptanz aufbauen. Kein anderer Use Case im luft-raumfahrt-Portfolio hat so viele aufeinander folgende Blockaden vor dem ersten Nutzwert.

ROI-Sicherheit — mittel (3/5) Der ROI ist grundsätzlich messbar — weniger Simulator-Stunden pro Type-Rating, kürzere Zeit bis zur Kompetenz-Freigabe. Das Problem ist die Kausalitätsfrage: Lässt sich die Verbesserung auf die Analytics-Plattform zurückführen, oder auf den gleichzeitig überarbeiteten Lehrplan, den neuen Chief Instructor oder die neue Instructorengeneration? In der Praxis braucht man mindestens zwei volle Trainingszyklen (18 bis 24 Monate) für eine belastbare Aussage. Vergleichbar mit der Treibstoffoptimierung — Nutzen real, aber Attribution erfordert Geduld.

Skalierbarkeit — hoch (4/5) Einmal aufgebaut, skaliert das System gut: Mehr Simulatoren desselben Typs sind marginalkostenarme Erweiterungen. Mehr Piloten bedeuten mehr Trainingsdaten, die die Modellqualität verbessern. Fleet-Level-Dashboards amortisieren den Infrastrukturaufwand mit wachsender Flotte. Die Einschränkung: Herstellerwechsel (z. B. neue Simulator-Generation eines anderen OEM) erfordern erneut Datenintegrations-Engineering.

Richtwerte — stark abhängig von Flottengröße, Simulator-OEM-Mix und vorhandener IT-Infrastruktur der ATO.

Was das System konkret macht

Das technische Prinzip ist dieselbe Predictive Analytics-Logik, die in der Industrie für Qualitätssicherung und Predictive Maintenance eingesetzt wird — angewendet auf Zeitreihen aus Pilot-Control-Inputs statt auf Sensordaten einer Produktionsmaschine.

Datenbasis: Der Simulator zeichnet kontinuierlich alle relevanten Zustandsparameter auf — Ruderposition, Trim, Autopilot-Eingriffe, ILS-Abweichungsanzeige (Localizer, Glidepath), Groundspeed, Windkomponenten, Thrust-Lever-Position. Diese Rohdaten werden pro Manöver-Typ segmentiert: Jeder ILS-Anflug, jede Engine-Failure-After-Takeoff-Prozedur, jede Go-Around-Einleitung bekommt ein eigenes Datensegment mit definierten Anfangs- und Endmarken (z. B. „Flare Initiation” bis „Touchdown”).

ML-Analyse: Ein trainiertes Modell berechnet für jedes Datensegment einen Abweichungsvektor gegenüber einem Benchmark — entweder dem FCOM-Sollwert, dem Flottendurchschnitt oder einer definierten Expertenkurve. Die interessanten Ausgaben sind keine Einzelwerte, sondern zeitliche Muster: Reagiert dieser Pilot bei Crosswind-Anflügen systematisch 1,2 Sekunden zu spät mit dem Seitenruder? Verschlechtert sich die ILS-Stabilisierung bei gleichzeitig aktiver ATC-Kommunikation? Kommt das Muster bei hoher Cockpit-Workload, aber nicht bei normaler Belastung vor?

Instructor-Interface: Das System liefert keinen Grading-Ersatz, sondern einen vorbereiteten Fokus-Report für das Debriefing. Auf einer Seite: Manöver-Zusammenfassung, auffällige Abweichungen, Vergleich zu vorherigen Sessions desselben Piloten, Vergleich zum Flottenmittel. Der Instructor entscheidet, was er davon im Debriefing thematisiert — das System gibt keine Note.

Fleet-Dashboard: Trainingsmanager sehen aggregierte, anonymisierte Trends über Kohorten: Welche Manöver-Typen haben die höchste Abweichungsrate in dieser Quartalsstichprobe? Gibt es eine neue Schwäche im ILS-Backcourse-Training, die auf ein Curriculum-Problem hindeutet? Diese Aggregationsebene ist das eigentliche strategische Werkzeug — und die Ebene, auf der kaum ein ATO heute strukturiert auswertet.

FOQA vs. Simulator-Analyse — ein wichtiger Unterschied

Wer im Pilotentraining über Datenanalyse spricht, stößt fast immer auf FOQA — Flight Operations Quality Assurance. Das sind dieselben Buchstaben, aber eine andere Sache.

FOQA analysiert Flugdaten aus echten Linienflügen. Ziel ist Sicherheitsüberwachung: Hat die Crew die Stabilized-Approach-Kriterien eingehalten? Gab es Exceedances? FOQA ist nach EASA Part-ORO Annex II für kommerzielle Luftfahrtbetreiber obligatorisch, und die Daten unterliegen einer strikten Anonymisierungslogik — mit klarer Beteiligung der Pilotengewerkschaft (in Deutschland: ver.di/Vereinigung Cockpit).

Simulator-Analyse (manchmal als SOQA — Simulator Operations Quality Assurance — bezeichnet) wertet Daten aus kontrollierten Trainingsumgebungen aus. Ziel ist Trainingsoptimierung. Die Daten sind kein operativer Sicherheitsnachweis, sondern didaktisches Werkzeug. Die rechtliche Grundlage und die Datenschutzlogik sind verschieden.

Für die Einführung in einem deutschen ATO bedeutet das konkret:

• FOQA-Daten und Simulator-Analytics sind organisatorisch zu trennen — unterschiedliche Datenschutzkonzepte, unterschiedliche Betriebsvereinbarungen
• Die für FOQA vereinbarte Anonymisierungslogik gilt nicht automatisch für Simulator-Daten
• Simulator-Analytics können, anders als FOQA, individuell nachverfolgbare Piloten-Profile erstellen — was Betriebsratspflichten auslöst (dazu mehr unten)

Wer diese Unterscheidung nicht frühzeitig macht, läuft in Zuständigkeitskonflikte, die ein Projekt auf Monate blockieren.

Proprietäre Simulatordatenformate: Die eigentliche Projektbremse

Die mit Abstand unterschätzte technische Hürde ist die Datenbeschaffung — nicht die KI-Analyse.

Die beiden Marktführer für kommerzielle Full-Flight-Simulatoren sind CAE und L3Harris (ehemals Link Simulation, heute TRU Simulation). Hinzu kommen Entrol, Alsim und kleinere Hersteller. Jeder Hersteller hat sein eigenes Datenformat, seine eigene Recording-Architektur und seine eigene Schnittstellen-Philosophie:

CAE-Simulatoren speichern Daten in einem proprietären Format, das über das CAE-eigene Datensystem zugänglich ist. Für Betreiber, die ausschließlich CAE-Hardware nutzen, bietet CAE Rise eine vorgefertigte Analytics-Lösung — aber nur für diese Hardware. Kein offenes API, kein Export in Standardformate ohne Sonderlizenz.

L3Harris/TRU-Simulatoren haben eine andere Architektur, andere Parameter-Benennungen, andere Recording-Intervalle. Ein A320-Anflug auf einem CAE-Simulator heißt intern anders als derselbe Anflug auf einem L3Harris-Gerät — selbst wenn die physikalischen Parameter identisch sind.

Für eine ATO mit gemischter Flotte bedeutet das: Bevor das erste ML-Modell laufen kann, muss ein Datenarchitekt die Ausgaben beider (oder mehrerer) Simulator-Typen normalisieren — auf ein gemeinsames Schema mit einheitlichen Parameter-Definitionen, identischen Zeitstempel-Formaten und konsistenten Manöver-Segmentierungen. Das ist kein Sprint-Ticket, das ist ein 3- bis 6-monatiges Engineering-Projekt.

Konkrete Konsequenz für die Projektplanung:

• ATOs mit ausschließlich CAE-Hardware: Direkte Evaluation von CAE Rise als Fertiglösung — kein Data-Engineering-Aufwand für die Datenbeschaffung
• ATOs mit gemischten Flotten oder Nicht-CAE-Hardware: TXT InstructIQ als OEM-unabhängige Plattform evaluieren — aber Engineering-Aufwand für Datennormalisierung einplanen (typisch 60 bis 120 Personentage)
• ATOs, die eine vollständig eigene Analytics-Infrastruktur aufbauen wollen: Python-basierte Pipeline auf Basis von pandas/scikit-learn, Datenhaltung in eigenem Data Warehouse, Dashboard-Ausgabe über Grafana oder Power BI — maximale Flexibilität, maximaler Aufwand

Betriebsrat und Mitbestimmung: Ohne Betriebsvereinbarung keine Einführung

In einem deutschen ATO oder einer deutschen Airline ist das der nicht-optionale Schritt, der über Timing und manchmal über Machbarkeit entscheidet.

Simulator-Analytics-Systeme erfassen individuelle Pilotenleistung mit Zeitstempel. Damit sind sie per Definition technische Einrichtungen, die zur Verhaltens- und Leistungsüberwachung geeignet sind — unabhängig davon, ob die Absicht Monitoring oder Trainingsoptimierung ist. §87 Abs. 1 Nr. 6 BetrVG schreibt vor: Einführung und Anwendung solcher Systeme unterliegen dem Mitbestimmungsrecht des Betriebsrats. Eine Betriebsvereinbarung muss geschlossen sein, bevor das System in Betrieb geht.

Was die Betriebsvereinbarung typischerweise regeln muss:

• Welche Daten werden auf welcher Granularitätsebene gespeichert?
• Wer hat Zugriff auf individuelle Pilotenprofile — und wer explizit nicht?
• Werden Daten für Beschäftigungsentscheidungen (Nichtbestehen Type-Rating, Versetzung) herangezogen — oder ausschließlich zu Trainingszwecken?
• Nach welcher Frist werden individuelle Daten anonymisiert oder gelöscht?
• Hat der Pilot Zugriff auf seine eigenen Daten?

In der Praxis dauert die Betriebsratskoordination in einer Airline oder einem größeren ATO drei bis sechs Monate — manchmal länger, wenn der Piloten-Betriebsrat externe Rechtsberatung einschaltet. Projekte, die diese Phase erst nach der technischen Implementierung angehen, werden nach der technischen Implementierung gestoppt. Das ist kein Seltenheitsfall.

Was konkret hilft: Den Betriebsrat und die Personalvertretung von Monat eins an einbinden — nicht als Hürde, sondern als Mitgestalter. ATOs, die Piloten-Vertretungen früh in die Datenschutzkonzeption einbeziehen, berichten von deutlich kürzeren Verhandlungszeiten und höherer Piloten-Akzeptanz des fertigen Systems.

Konkrete Werkzeuge — was wann passt

CAE Rise — für reine CAE-Flotten Die direkte Wahl für ATOs, die ausschließlich CAE-Simulatoren betreiben. Rise ist in CAE-Simulator-Leasingverträge integrierbar, benötigt keine separate Datenextraktion und deckt EBT-konforme Grading-Workflows ab. Einschränkung: kein OEM-übergreifender Einsatz, kein offenes API, Pricing auf Anfrage.

TXT InstructIQ (ehemals Paladin AI) — für gemischte Flotten OEM-unabhängige Analytikplattform für ATOs mit mehreren Simulator-Herstellern. Erfordert einmaligen Datenintegrations-Engineering-Aufwand, bietet danach einen einheitlichen Analytics-Layer über alle Simulator-Typen. Von TXT Group / PACE Aerospace übernommen (2024), Datenhosting EU-fähig. Pricing Enterprise auf Anfrage.

Custom-Pipeline mit Python + Grafana Für ATOs mit eigenem Data-Engineering-Team und dem Bedarf nach maximaler Kontrolle. Pandas für Zeitreihen-Segmentierung und Feature-Engineering, scikit-learn oder PyTorch für Clustering und Anomalie-Detection, Grafana für das Instructor-Dashboard. Voller Aufwand — aber die einzige Option, die vollständige Datensouveränität und unbegrenzte Anpassbarkeit bietet. Empfehlenswert nur für ATOs mit dediziertem IT/Data-Team.

Power BI oder MATLAB Aerospace Toolbox — für den analytischen Einstieg Bevor ein vollständiges ML-System entschieden wird, lohnt es sich, mit einfacheren Auswertungen zu beginnen: Simulator-Rohdaten in CSV/JSON exportieren, mit Power BI Trend-Dashboards bauen, manuell Anomalie-Schwellen setzen. Das ist kein produktives Analytics-System, aber ein valider Proof-of-Concept, der in 4 bis 8 Wochen Erkenntnisse über Datenverfügbarkeit und Instructor-Akzeptanz liefert — bevor 400.000 Euro Implementierungsbudget freigegeben werden.

Zusammenfassung: Wann welcher Ansatz

• Nur CAE-Simulatoren → CAE Rise direkt evaluieren
• Gemischte Flotten → TXT InstructIQ
• Eigenes Team, maximale Kontrolle → Python + Grafana
• Proof-of-Concept vor Budgetentscheidung → Power BI auf exportierten Rohdaten

Datenschutz und Datenhaltung

Simulator-Performance-Daten sind Beschäftigtendaten. Die DSGVO gilt vollumfänglich, und Art. 88 DSGVO gibt nationalen Gesetzgebern explizit Raum für strengere Arbeitnehmerdatenschutzregeln — in Deutschland durch das Bundesdatenschutzgesetz (BDSG) realisiert.

Was das in der Praxis bedeutet:

Jede Plattform, die individuelle Pilotenprofile erstellt, benötigt eine Rechtsgrundlage nach Art. 6 DSGVO. Im Beschäftigtenverhältnis ist das typisch §26 BDSG (Datenverarbeitung für Zwecke des Beschäftigungsverhältnisses) — aber nur für Zwecke, die zur Begründung, Durchführung oder Beendigung des Arbeitsverhältnisses erforderlich sind. Reine Trainingsoptimierung bewegt sich in einer Grauzone, wenn die Daten potenziell auch für Beschäftigungsentscheidungen genutzt werden könnten.

Lösung in der Praxis: Klare Zweckbindung in der Betriebsvereinbarung, Zugriffsrechte auf anonymisierte Aggregate für Trainingsmanagement, individuelle Rohdaten nur für den betroffenen Piloten und den Instructor in der konkreten Session.

Zur Datenhaltung der Tools:

• CAE Rise: Cloud-gehostet auf CAE-Infrastruktur, Region auf Anfrage zu klären
• TXT InstructIQ: EU-Hosting möglich, AVV verfügbar
• Custom-Pipeline: vollständige Datensouveränität im eigenen Rechenzentrum oder EU-Cloud (Azure Frankreich/Deutschland, AWS Frankfurt)

Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist bei allen externen Diensten Pflicht — einschließlich Cloud-Provider, die nur die Hosting-Infrastruktur stellen.

Was es kostet — realistisch gerechnet

Einmalige Integrationskosten

• Datenextraktion und Normalisierung (Simulator-API-Integration): 60.000–150.000 Euro, je nach OEM-Mix und Datenzustand
• ML-Modell-Training und Validierung: 30.000–80.000 Euro (extern) oder 6–12 Monate internes Data-Engineering-Team
• Betriebsrat-Prozess: intern nicht null — je nach Komplexität und Begleitung durch Arbeitsrechtler 5.000–20.000 Euro
• EASA-Compliance-Dokumentation (falls Anpassung bestehender Trainingsaufzeichnungspflichten nötig): 10.000–30.000 Euro

Laufende Kosten

• CAE Rise: Preisgestaltung im Rahmen des CAE-Simulator-Vertrags — auf Anfrage
• TXT InstructIQ: Enterprise-Lizenz auf Anfrage, schätzungsweise 30.000–80.000 Euro/Jahr für mittlere Flotten
• Custom-Pipeline (Infrastruktur + Wartung): 20.000–60.000 Euro/Jahr

ROI-Rechnung — konservativ Eine ATO mit 200 Type-Ratings und 80 Recurrencies pro Jahr, durchschnittliche Session-Dauer 4 Stunden, Kosten pro FFS-Stunde intern: 3.000 Euro.

Wenn die Analytics-Plattform im Schnitt 0,5 Stunden Wiederholung pro Pilot einspart (konservative Schätzung; Paladin AI nannte 20 % Gesamtersparnis — das wäre deutlich mehr):

200 × 0,5 Stunden × 3.000 Euro = 300.000 Euro/Jahr potenzielle Einsparung.

Dem stehen Integrationskosten von 150.000–300.000 Euro einmalig und 40.000–80.000 Euro/Jahr laufend gegenüber. Amortisation im günstigsten Fall: 18 Monate. Realistisch: 24–36 Monate. Diese Rechnung funktioniert nur für ATOs mit signifikantem Volumen.

Wie du den ROI tatsächlich nachweist Nicht durch Kalkulation — durch Messung: Führe für das erste Jahr nach Einführung ein kontrolliertes Tracking der Simulator-Stunden je Type-Rating gegenüber dem Vorjahresmittel. Wenn die Analytics-Plattform wirkt, sollte der Effekt in diesem Vergleich sichtbar sein — vorausgesetzt, keine anderen wesentlichen Curricula-Änderungen im gleichen Zeitraum.

Fünf typische Einstiegsfehler

1. Den Simulator-OEM als selbstverständliche Datenquelle behandeln. Nicht jeder Simulator gibt seine Daten ohne Weiteres heraus. Bei älteren CAE- und L3Harris-Geräten (Baujahr vor 2015) fehlt häufig eine digitale Echtzeit-Schnittstelle für Rohdaten — die Daten existieren intern, sind aber nicht ohne Umbau zugänglich. Wer ein Analytics-Projekt plant, ohne zuerst zu prüfen, welche Daten über welche Schnittstelle verfügbar sind, plant in einem Vakuum.

2. Den Betriebsrat erst nach der Implementierung einbinden. Das passiert regelmäßig, weil der technische Aufbau schneller geht als die organisatorische Koordination. Das Ergebnis: Das fertige System darf nicht in Betrieb gehen, bis die Betriebsvereinbarung unterschrieben ist. Wer mit dem Betriebsrat von Monat eins startet, hat das System zum Projektende produktionsreif und genehmigt.

3. Instructor-Akzeptanz als selbstverständlich annehmen. Instructors, die jahrzehntelang auf Basis ihrer eigenen Beobachtung geurteilt haben, reagieren auf ein System, das ihre Einschätzung mit Parameterdaten konfrontiert, nicht automatisch positiv. „Das System sagt, der Pilot war auffällig — ich sehe das anders” ist keine Ausnahme, das ist die Regel in den ersten Monaten. Ohne aktive Einbindung der Instructors in die Systemkonfiguration (welche Metriken zählen, welche Schwellen gelten) und ohne klare Kommunikation, dass das System Unterstützer und nicht Richter ist, erodiert die Nutzungsrate schnell.

4. Datenvolumen überschätzen, Datenqualität unterschätzen. Simulator-Daten sind roh — voller Artefakte, Kalibrierungsoffsets, Datenlücken bei System-Neustart und Rauschen. Ein ML-Modell, das auf unbereinigten Rohdaten trainiert wird, erkennt Datenfehler als Pilotenschwächen. Datenbereinigung und Feature-Engineering sind kein Anhang des Projekts, sie sind das Fundament.

5. Das System nach dem Go-Live sich selbst überlassen. Simulator-Hardware wird regelmäßig mit Software-Updates versorgt. Jedes Update kann die Datenstruktur verändern — neue Parameter, geänderte Parameternamen, veränderte Zeitstempelformate. Wer kein Monitoring für Datenpipeline-Brüche einrichtet, merkt das erst, wenn das Dashboard seit Wochen falsche Werte zeigt — oder gar keine.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Einführung ist in der Regel das Unkomplizierteste. Die menschliche Seite ist schwieriger — und sie hat zwei Hauptakteure mit sehr unterschiedlichen Interessen.

Die Instructors. Erfahrene Instructor-Piloten haben ein sehr fundiertes implizites Modell davon, was einen guten Piloten ausmacht. Sie bewerten nach Jahrzehnten Erfahrung — ein System, das mit Parameterdaten kommt und sagt „hier war die Sink Rate auffällig”, wird nicht automatisch als Unterstützung empfunden. Es kann sich anfühlen wie Kontrolle.

Was konkret hilft: Instructors frühzeitig als Co-Konfigurer einbinden. Lass sie entscheiden, welche Manöver zuerst analysiert werden, und welche Metriken für ihr Training relevant sind. Instructors, die das System mitgebaut haben, nutzen es — und sie erklären es auch den Piloten.

Die Piloten. Für Piloten ist das Simulator-Training keine neutrale Übungsumgebung — es ist eine Bewertungsumgebung, in der ihre Qualifikation auf dem Spiel steht. Ein Analytik-System, dessen Daten möglicherweise in eine Grading-Entscheidung einfließen könnten, erzeugt Misstrauen. Besonders, wenn die Betriebsvereinbarung unklar ist oder noch nicht existiert.

Die entscheidende Aussage für Piloten: Die Daten unterstützen das Debriefing, sie ersetzen kein Instructor-Urteil und sie fließen nicht in Beschäftigungsentscheidungen ein. Diese Aussage muss vertraglich verankert sein — nicht nur mündlich versprochen.

Was konkret hilft:

• Piloten-Vertretung (Betriebsrat, VC/ver.di) von Anfang an als Partner einbinden — nicht als Genehmigungsinstanz am Ende
• In den ersten drei Monaten ausschließlich aggregierte, anonymisierte Berichte zeigen — keine Einzelprofile
• Jedem Piloten Zugang zu seinen eigenen Daten geben — Transparenz reduziert Misstrauen schneller als jede Erklärung
• 90-Tage-Pilotphase mit expliziter Opt-in-Option für Piloten, die zuerst dabei sein wollen

Realistischer Zeitplan mit Risikohinweisen

EASA-konforme Trainingsaufzeichnung: Was bereits Pflicht ist

Bevor Analytics eingeführt werden, lohnt ein Blick auf den regulatorischen Status quo: Was muss eine ATO unter EASA Part-ORO (Organisation Requirements for Air Operations) ohnehin aufzeichnen?

Nach ORO.MLR.115 müssen Trainings- und Qualifikationsnachweise für jeden Besatzungsangehörigen mindestens drei Jahre aufbewahrt werden — inklusive Bewertungsblätter aus Simulator-Sessions. Was nicht explizit gefordert ist: die strukturierte Auswertung dieser Daten über den einzelnen Piloten hinaus.

Das ist die regulatorische Lücke, die Analytics schließt — und gleichzeitig die Chance, ein Analytik-System als Compliance-Upgrade zu positionieren statt als neues Tool. Wer die Einführung als Erweiterung der bestehenden ORO.MLR.115-Aufzeichnungen versteht und die EASA-Compliance-Dokumentation entsprechend anpasst, hat eine stärkere Begründung gegenüber Betriebsrat und Piloten: Das ist nicht Kontrolle — das ist bessere Dokumentation dessen, was ohnehin passiert.

Wichtig: Wenn Analytik-Daten zukünftig in Competency-Check-Entscheidungen einfließen sollen (z. B. als Zusatzinformation für die Check-Airman-Entscheidung bei einem nicht bestandenen Type-Rating), braucht das explizite EASA-Guidance. Aktuell (Stand Mai 2026) gibt es keine klare AMC/GM-Grundlage dafür — Vorsicht vor vorauseilendem Compliance-Anspruch.

Häufige Einwände — und was dahintersteckt

„Unsere Instructors sind gut genug. Wir brauchen keine Daten.” Kein Instructor bestreitet seine eigene Qualifikation. Die Frage ist eine andere: Kann ein Instructor, der eine Session begleitet, gleichzeitig beobachten, instruieren und alle 300 Parameter im Auge behalten? Nein. Das ist keine Kritik am Instructor — es ist eine physische Limitation des menschlichen Aufmerksamkeitssystems. Die Daten sind kein Ersatz für Instruktoren-Urteil, sie sind Information, die der Instructor sonst nicht hätte.

„Die Piloten werden Widerstand leisten.” Das ist realistisch — und vermeidbar. Pilotengewerkschaften in Deutschland (ver.di, Vereinigung Cockpit) haben FOQA-Programme in den 1990ern und 2000ern maßgeblich mitgestaltet. Sie wissen, wie anonymisierte Daten zu einem Sicherheitswerkzeug werden — und wie überwachende Systeme zu Misstrauen führen. Der Unterschied liegt in der Transparenz der Datenschutz-Architektur und in der echten Einbindung von Beginn an. Projekte, die das sauber machen, berichten von überraschend wenig Gegenwind.

„Wir haben zu wenig Daten für ML.” Bei einer ATO mit drei Simulatoren und 150 Sessions pro Jahr sind nach einem Jahr 450 Sessions mit je 50 bis 100 Manöver-Segmenten vorhanden — das sind 22.500 bis 45.000 Datenpunkte. Für viele Manöver-Typen (ILS, Engine Failure ATOP, Go-Around) sind das statistisch auswertbare Mengen. Für sehr seltene Manöver (z. B. Dual-Engine-Failure-Prozedur in bestimmten Szenarien) ist Clustering über Flottendaten sinnvoller als Einzelpiloten-Tracking.

„Das kostet mehr als es bringt.” Für kleine ATOs stimmt das möglicherweise. Für Airline-Trainingsabteilungen mit 300+ Type-Ratings pro Jahr und Simulator-Stundenkosten von 3.000+ Euro ist die Rechnung anders. Die entscheidende Voraussetzung: Datenverfügbarkeit, Datenvolumen und Instructor-Akzeptanz müssen vor dem Business Case geprüft werden — nicht danach.

Woran du merkst, dass das zu dir passt

• Ihr betreibt mindestens drei Full-Flight-Simulatoren und führt mehr als 150 Type-Rating- oder Recurrency-Sessions pro Jahr durch — darunter ist das Datenvolumen für statistisch belastbare Muster zu gering
• Ihr habt bereits ein strukturiertes EBT-Competency-Framework (Evidence-Based Training nach EASA) in Betrieb — ohne definiertes Sollverhalten kann das System keine Abweichungen messen
• Ihr habt einen Betriebsrat oder Personalrat, mit dem ihr IT-Systeme erfahrungsgemäß konstruktiv verhandeln könnt — oder ihr seid bereit, diesen Prozess mit entsprechend Zeit einzuplanen
• Ihr habt mindestens eine Person, die Erfahrung mit Datenintegration hat oder bereit ist, einen externen Datentechniker einzubeziehen — ein Analytics-Projekt ohne IT-Kompetenz geht schief, unabhängig vom Tool

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter drei Simulatoren und unter 150 Sessions pro Jahr. Das Datenvolumen reicht nicht aus, um verlässliche Muster zu erkennen — das System erzeugt mehr Rauschen als Signal. Investiere stattdessen in strukturiertes Debriefing mit einfachen Checklisten.

2. Kein definiertes Kompetenz-Assessment-Framework (kein EBT). Wenn eure Instructors heute ohne formales Grading-Schema bewerten, hat ein ML-Modell keine Referenz, gegen die es Abweichungen messen kann. Schritt eins ist Curriculumstruktur, nicht Datenanalyse.

3. Ältere Simulator-Hardware ohne digitale Datenschnittstelle. Simulatoren der Baujahre vor etwa 2010 haben häufig keine zugängliche Rohdaten-API. Ohne Zugang zu den Parameterdaten gibt es nichts zu analysieren — und Retrofit-Lösungen übersteigen oft den Nutzen des Analytics-Systems bei Weitem.

Das kannst du heute noch tun

Bevor Budget freigegeben oder ein Anbieter kontaktiert wird: Schick einer Handvoll Instructors in deiner ATO eine einfache Frage. Die Antwort zeigt dir, ob das Datenproblem real ist.

Quellen & Methodik

• Paladin AI / AWS: „Improving Pilot Training with Machine Learning — Paladin AI” (AWS Startups Blog, 2021). Beschreibt den ML-Ansatz von Paladin AI (heute TXT InstructIQ) zur Identifikation von Profizienzlücken aus Simulator-Daten. URL: aws.amazon.com/blogs/startups/improving-pilot-training-with-machine-learning-paladin/
• CAE Rise Data Analytics: Produktinformation und Fallstudie AirAsia India (cae.com/civil-aviation/aviation-software/cae-rise/). AirAsia India als erstes indisches Carrier in Betrieb genommen (2023). CAE Rise: Real-time Insights and Standardized Evaluations.
• TXT Group / InstructIQ-Übernahme: TXT e-solutions erwirbt InstructIQ von Paladin AI Inc., Integration in PACE Aerospace & IT Portfolio (TXT Group Pressemitteilung, 2024).
• EASA Part-ORO, ORO.MLR.115: Aufbewahrungspflicht für Trainings- und Qualifikationsnachweise (3 Jahre). Zugriff über easa.europa.eu/en/the-agency/faqs/flight-simulation-training-devices-fstds (Mai 2026).
• §87 Abs. 1 Nr. 6 BetrVG: Mitbestimmungsrecht des Betriebsrats bei Einführung technischer Einrichtungen zur Leistungs- und Verhaltensüberwachung. Betriebsverfassungsgesetz in der aktuell gültigen Fassung.
• Simulator-Stundenkostenrahmen (2.500–4.000 Euro): Eigene Kalkulation auf Basis publizierter Beschaffungskosten für FFS Level D (12–20 Mio. Euro Anschaffung, 15–20 Jahre Nutzungsdauer, Instructor-Burden, Facility-Overhead) und Branchenangaben von CAE und AEA. Keine publizierten ATO-Kalkulationen öffentlich zugänglich.
• Paladin AI Einsparungsangabe (20 % jährliche Trainingskosten): Produktunterlagen Paladin AI / InstructIQ, intern erhoben, nicht durch unabhängige Studie bestätigt.
• Springer Link / Aeronautical Journal: „Design of simulation-based pilot training systems using machine learning agents”, Aeronautical Journal, Cambridge Core (2021). Peer-reviewed Grundlagenarbeit zu ML-Ansätzen in Pilotentraining-Simulatoren.

Du willst wissen, ob eure Simulator-Flotte das nötige Datenfundament hat, und wie ein Business Case für eure ATO realistisch aussieht? Das lässt sich in einem kurzen Gespräch eingrenzen — meld dich.