KI-Wartungsdokumentation: Weniger Papierarbeit, mehr Werkzeugzeit

Das echte Ausmaß des Problems

Wie viel Schichtzeit in Dokumentation geht, veröffentlicht kaum ein Betrieb, und belastbare Branchenzahlen für deutsche MRO-Betriebe haben wir nicht gefunden. Für die Rechnungen auf dieser Seite nehmen wir 45 bis 90 Minuten je Techniker und Tag an. Ob das bei dir stimmt, zeigt eine zweiwöchige Messung, wie sie unten unter „Das kannst du heute noch tun” beschrieben ist.

Konkret: Ein MRO-Betrieb mit 30 Technikern, die je 45 Minuten täglich dokumentieren, bindet damit 30 mal 45 Minuten, also gut 22 Stunden am Tag, knapp drei Vollzeitstellen. Diese Dokumentation ist Pflicht und fällt nicht weg. Einsparen lässt sich nur der Teil, den ein guter Entwurf dem Techniker abnimmt.

Das Ausmaß hängt stark von der Betriebsart ab. Line-Maintenance-Techniker, die täglich viele kurze Transit- und Overnight-Checks bearbeiten, haben einen proportional höheren Dokumentationsanteil als Base-Maintenance-Techniker, die wochen- oder monatelang an einem einzelnen C-Check arbeiten.

Das Problem wächst durch drei Kräfte gleichzeitig:

• AMT-Mangel in Europa: Der Bedarf an lizenzierten Aircraft Maintenance Technicians übersteigt das Angebot. Jede Stunde, die ein lizenzierter B1/B2-Techniker mit Dokumentation verbringt, ist eine Stunde, die nicht für Wartungsarbeit zur Verfügung steht.
• Die Dokumentationspflicht bleibt: Jede Arbeit braucht einen vollständigen, nachvollziehbaren Eintrag mit Bezug auf die Instandhaltungsdaten. Daran ändert keine Digitalisierung etwas, sie kann das Ausfüllen nur beschleunigen.
• Komplexere Flugzeugtypen: Modernere Flugzeugtypen wie der A320neo oder B737 MAX erfordern komplexere Dokumentation mit mehr Querverweisen auf Airworthiness Directives und Service Bulletins.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zeitwerte sind Annahmen für die Rechnung weiter unten, keine Messwerte. Veröffentlichte Vergleichszahlen für deutsche MRO-Betriebe haben wir nicht gefunden, die Messung aus „Das kannst du heute noch tun” liefert deine eigenen.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) KI-Dokumentationsassistenz ist unter allen Anwendungsfällen in dieser Kategorie derjenige mit dem direktesten Zeitgewinn für einzelne Mitarbeitende. Bestätigen sich 30–45 Minuten täglich je Techniker im Pilot, sind das bei einem 20-köpfigen Team täglich 10–15 zurückgewonnene Arbeitsstunden, messbar in mehr abgearbeiteten Arbeitspaketen, nicht nur in abstrakten Produktivitätskennzahlen.

Kosteneinsparung, niedrig (2/5) Die Einsparung ist real, aber indirekt. Mehr verfügbare Technikerkapazität bedeutet: weniger Überstunden, längere Zeitintervalle bis zur nächsten Einstellung, mehr abrechenbare Stunden bei gleichem Personal. Das lässt sich nicht so klar in eine Zahl fassen wie Materialkosten oder reduzierte Fehlerquoten. Im Vergleich zur Ersatzteil-Beschaffungsoptimierung, wo Millionenbeträge an Lagerkapital bewegt werden, ist das Kostenpotenzial dieser Anwendung kleiner.

Schnelle Umsetzung, gut (4/5) Das ist der wichtigste Differenziator gegenüber anderen Luft-Raumfahrt-Anwendungsfällen: Spracherkennung und Formularbefüllung lassen sich ohne Änderung am Flugzeug, ohne Musterzulassung und ohne monatelange Datenvorbereitung in Betrieb nehmen, nötig ist allerdings eine Anpassung des MOE. Ein Pilot mit 5–8 Technikern ist in 8–14 Wochen realisierbar. Die Haupthürde ist die Integration ins bestehende MRO-System, das ist Arbeit, aber handhabbar.

ROI-Sicherheit, mittel (3/5) Der Nutzen ist real, aber das Messen erfordert aktives Tracking. Wer nicht vor dem Projekt festhält, wie viel Zeit Techniker täglich für Dokumentation aufwenden, hat nachher kein klares Vorher/Nachher. Die Einsparung passiert, aber sie muss bewusst erfasst werden. Betriebe, die diesen Schritt überspringen, berichten am Ende von “gefühlter” Verbesserung, aber können sie nicht beziffern.

Skalierbarkeit, hoch (4/5) Jeder zusätzliche Techniker spart proportional. Das System muss nicht neu kalibriert werden, wenn ein Standort wächst. Einschränkung: neue Flugzeugtypen und neue Dokumentenstrukturen erfordern Aktualisierung der Formularvorlagen und AMM-Referenzdatenbank, das ist Pflegeaufwand, der nicht verschwindet.

Richtwerte, stark abhängig von Betriebsgröße, MRO-System und Grad der EASA-Komplexität.

Was das System konkret macht

Das Grundprinzip ist einfach: statt Tastatur und Klemmbrett nutzt der Techniker ein Mikrofon (Headset oder Tablet) und diktiert, was er gemacht hat. Das System transkribiert den gesprochenen Text, erkennt den Kontext (welche Arbeitskarte ist aktiv, welcher Flugzeugtyp, welche Inspektion), und befüllt die entsprechenden Felder im MRO-System automatisch.

Konkret läuft das in drei Schichten:

Schicht 1, Spracherkennung: Whisper (open-source von OpenAI) oder ein Cloud-Spracherkennungsdienst wie Azure AI Speech transkribiert gesprochene Sprache in Text. Whisper unterstützt Deutsch und kann lokal betrieben werden, wichtig für Betriebe mit strengen Datenschutzanforderungen. Fachvokabular (Teilenummern, AMM-Verweise, Inspektionsbezeichnungen) erfordert Fine-Tuning oder einen Vocabulary-Boost mit branchenspezifischem Wortschatz.

Schicht 2, Kontextinterpretation per LLM: Ein Large Language Model interpretiert den transkribierten Text im Kontext der aktiven Arbeitskarte. Es erkennt: „Das klingt nach einer 500-Stunden-Inspektion an einem Hydraulikzylinder” und schlägt den korrekten AMM-Abschnitt vor. Relevante Part-Nummern werden aus der Teile-Datenbank abgerufen. Closing-Statements entwirft es nach dem Muster, das euer MOE vorgibt.

Schicht 3, Integration ins MRO-System: Die ausgefüllten Felder werden per REST-API in AMOS oder ein vergleichbares MRO-System übertragen. Techniker prüfen die vorausgefüllten Einträge, korrigieren bei Bedarf, und signieren digital.

Was das System nicht tut: Es ersetzt keine fachliche Beurteilung. Ob eine Abweichung meldepflichtig ist, ob ein Teil ausgetauscht werden muss, welche Entscheidung bei einem unerwarteten Befund getroffen wird, das bleibt die Aufgabe des lizenzierten Technikers. Die KI befüllt Formulare. Die Freigabebescheinigung (CRS) stellt ausschließlich freigabeberechtigtes Personal nach Part-66 aus, nie das System.

Regulatorischer Kontext: Was EASA dazu sagt

EASA hat am 10. November 2025 mit NPA 2025-07 einen Vorschlag für detaillierte Anforderungen an vertrauenswürdige KI in der Luftfahrt veröffentlicht, als Umsetzung von Artikel 108 der KI-Verordnung. Die Kommentierungsfrist lief bis März 2026. Beschlossen ist damit noch nichts, und welche Pflichten am Ende für ein Dokumentationswerkzeug in einem Part-145-Betrieb gelten, steht nicht fest.

Unabhängig davon gilt schon heute:

• Ein Werkzeug, das Wartungseinträge vorschlägt, gehört in die Verfahren eures MOE, mit einer Beschreibung, wie Einträge entstehen und wer sie prüft
• Den Eintrag verantwortet der Techniker, der ihn zeichnet. Jeder KI-Entwurf wird vor der Unterschrift gelesen und geprüft, eine vollautomatische Freigabe gibt es nicht
• Die Freigabebescheinigung stellt freigabeberechtigtes Personal aus, auf Basis der eigenen Prüfung, nicht auf Basis dessen, was das System vorformuliert hat

Praktisch: Wer jetzt mit einem Piloten beginnt, sammelt die Erfahrung, die er für die MOE-Beschreibung braucht, und kann das Verfahren anpassen, sobald EASA die Regeln festlegt.

Konkrete Werkzeuge, was wann passt

Zymbly , KI-Assistent speziell für MRO-Techniker Zymbly ist für Aviation-MRO entwickelt und setzt diktierte Arbeiten in Text für Job-Karten und Logbucheinträge um. Einschränkungen: Oberfläche, Support und Vertrieb gibt es nur auf Englisch, und das Produkt ist jung (Y-Combinator-Jahrgang Winter 2026, kleines Team, kaum öffentliche Referenzen). Die Datenresidenz ist laut Anbieter wählbar, festschreiben müsst ihr sie im Vertrag. Einsatz sinnvoll für Betriebe mit internationalen Kunden, die ohnehin auf Englisch dokumentieren und als frühe Anwender einsteigen wollen.

Whisper + Azure OpenAI Service , maßgeschneiderte Lösung Für Betriebe, die deutsche Dokumentation brauchen oder spezifische Formularstrukturen aus ihrem MRO-System abbilden wollen. Whisper läuft lokal (kein US-Datentransfer, dafür ein Rechner mit Grafikkarte im Betrieb), Azure OpenAI läuft in einer EU-Region wie West Europe. Aufwand höher als Zymbly, braucht einen Entwickler für die Integration, ist aber der Weg zu einer wirklich maßgeschneiderten Lösung.

AMOS mit AMOSmobile, Fundament für beides AMOS ist nicht das KI-Werkzeug, aber das MRO-System, in das die KI integriert wird. AMOSmobile läuft auf Tablets im Hangar und ist der natürliche Endpunkt für KI-befüllte Arbeitskarten. Wer AMOS bereits betreibt, hat die beste Ausgangslage für eine schnelle Integration.

Azure Document Intelligence , für papierbasierte Übergangsphasen Für Betriebe, die noch teilweise auf Papier arbeiten: Azure Document Intelligence erkennt handschriftliche Einträge und überträgt sie ins System. Sinnvoll als Brückentechnologie während der Digitalisierungsphase.

Datenschutz und Datenhaltung

Wartungsdokumentation in der Luftfahrt enthält teils geschäftskritische Informationen (Flottenzustand, Flugzeugkennzeichen, Kundendaten bei MRO-Dienstleistern) und personenbezogene Daten (Techniker-Lizenznummern, Unterschriften). DSGVO-Konformität ist Pflicht. Prüfen tut sie allerdings die Datenschutzaufsicht, nicht die Luftfahrtbehörde bei ihrem Audit.

Optionen für EU-konforme Datenverarbeitung:

• Azure OpenAI Service in einer EU-Region (etwa West Europe): Datenverarbeitung in der EU, die Auftragsverarbeitung regeln die Microsoft-Vertragsbedingungen. Empfohlene Wahl für die meisten europäischen MRO-Betriebe.
• Whisper lokal on-premise: Die Spracherkennung findet lokal im Betrieb statt, keine Daten verlassen das Netzwerk. Für die LLM-Verarbeitung kann dann ein EU-gehosteter Dienst nachgelagert werden.
• Zymbly: Datenresidenz laut Anbieter wählbar, einzelne Dienstleister können außerhalb der EU sitzen. Für sensible Kundendaten nur mit vertraglich festgelegter EU-Residenz und AVV.

Techniker-Lizenznummern und Unterschriften sind besonders sensibel, da sie Part-66-Lizenzen identifizieren. Diese dürfen nicht unverschlüsselt an externe Dienste übertragen werden. Bei jeder Lösung muss der Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO vor dem Produktivbetrieb unterzeichnet sein.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten:

• Lösung auf Basis Whisper + Azure OpenAI + AMOS-Integration: 15.000–35.000 Euro (Entwicklung, Integration, Testing, EASA-Verfahrensdokumentation)
• Zymbly als Fertiglösung: Preise nur auf Anfrage nach einer Demo; ob die Einrichtung günstiger wird, hängt an der Anbindung an euer MRO-System

Laufende Kosten (monatlich):

• Nutzung von Sprach- und Spracherkennungsmodell in der EU-Cloud, abgerechnet nach Verbrauch: für 20–30 Techniker bei typischem Nutzungsvolumen nach unserer Einschätzung ca. 300–800 Euro/Monat
• AMOS-Lizenz: bereits im Betrieb vorhanden, keine Zusatzkosten für die Grundlizenz
• Systemwartung und Modellpflege: ca. 200–400 Euro/Monat intern oder extern

Was du dagegenrechnen kannst: 30 Minuten täglich je Techniker, bei 20 Technikern: 20 mal 30 Minuten, also 10 Stunden am Tag. Geld wird daraus nur, wenn diese Stunden etwas ersetzen: Überstunden, Leihtechniker oder Aufträge, die ihr sonst ablehnen müsstet. Bewertet mit einem Bruttostundensatz von 35–50 Euro für lizenzierte Techniker sind das 350 bis 500 Euro täglich, bei rund 20 Schichten je Techniker im Monat 7.000 bis 10.000 Euro. Davon rechnen wir nur 40 Prozent als tatsächlich genutzt, der Rest verpufft in Kapazitätsüberhang und Pausen: 2.800 bis 4.000 Euro monatlicher Nutzen. Bei Einrichtungskosten von 25.000 Euro und laufenden Kosten von 1.000 Euro im Monat bleiben 1.800 bis 3.000 Euro Überschuss, die Einrichtung ist nach 25.000 geteilt durch 3.000 bis 1.800, also nach 8 bis 14 Monaten bezahlt.

Der eigentlich überzeugende Fall ist nicht die Kostenrechnung, sondern der Mangel an lizenzierten Technikern. Wer keine neuen Techniker bekommt, aber mehr Kapazität braucht, hat keine andere Option als die vorhandenen besser einzusetzen.

Drei typische Einstiegsfehler

1. Spracherkennung ohne Fachvokabular-Training einsetzen. Standard-Sprachmodelle kennen Alltagsdeutsch. Sie kennen nicht “LPT Stage 3 Disk”, “CSN 12.540”, “AD 2023-0045”, “AMM Chapter 29-10-00” oder “Part Number 65C32501-1”. Wer Whisper oder Azure Speech ohne vorheriges Fachvokabular-Tuning auf Techniker loslässt, bekommt korrekt transkribierte Lautmalerei, aber keine verwendbaren Einträge. Lösung: Vor dem Piloten ein Glossar der 200–300 häufigsten Teile-Bezeichnungen und AMM-Kapitel anlegen und als Custom Vocabulary einpflegen.

2. Die EASA-Verfahrensbeschreibung vergessen. Part-145 verlangt, dass die Verfahren, nach denen Wartungseinträge entstehen, im Maintenance Organisation Exposition (MOE) beschrieben sind. Ein “wir nutzen das Tool einfach mal” ohne angepasstes MOE-Kapitel ist ein Audit-Finding. Lösung: Die Verfahrensbeschreibung für den KI-Assistenten bereits vor dem Piloten als Entwurf aufsetzen. Bis zum Produktivbetrieb muss sie in Kraft sein, je nach Umfang der Änderung mit vorheriger Zustimmung der zuständigen Behörde (in Deutschland das LBA).

3. Einführung ohne Messung des Ausgangszustands. Wer nicht vor dem Pilot erfasst, wie viel Zeit Techniker täglich für Dokumentation aufwenden, kann den Erfolg danach nicht beziffern. Ergebnis: Das System spart nachweislich Zeit, aber niemand kann sagen wie viel, und die Genehmigung für eine Einführung an weiteren Standorten scheitert an fehlenden Zahlen. Lösung: Zwei Wochen vor dem Piloten eine einfache Zeiterfassung einführen: Techniker notieren täglich, wie viele Minuten sie für Dokumentation verwenden. Das reicht.

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

Die technische Integration ist der kleinste Teil des Aufwands. Was wirklich Zeit kostet, ist die Überzeugungsarbeit in zwei Richtungen.

Erfahrene Techniker misstrauen dem System. Wer 20 Jahre lang selbst jeden Eintrag geschrieben hat, entwickelt ein Qualitätsgefühl für “richtigen” Wortlaut und Detailtiefe. Ein KI-generierter Entwurf, der gut aussieht, aber einen subtilen Fehler hat, etwa die falsche Revisions-ID einer Sektion, kostet das Vertrauen sofort. Die Gegenmaßnahme: Techniker in die Entwicklung der Formularvorlagen einbinden. Wer selbst die Vorlage für “Landing Gear Inspection” mit definiert hat, vertraut dem Ergebnis mehr.

Jüngere Techniker übernehmen KI-Entwürfe ohne zu prüfen. Das ist das Gegenteil des ersten Problems und mindestens genauso gefährlich. Ein KI-Entwurf, der 95 Prozent korrekt ist, aber eine falsche Teilenummer enthält, und der ungeprüft signiert wird, ist ein potenziales Safety Issue und ein sicheres Audit-Finding. Lösung: Klare Einweisung, dass die KI einen Entwurf liefert, keine fertige Unterschrift. Jeder Eintrag wird vom Techniker gelesen, bevor er signiert.

Was funktioniert:

• Piloten mit freiwilligen Technikern starten, nicht denen, die das am skeptischsten sehen
• Die ersten 2–3 Wochen täglich kurzes Feedback einsammeln: Was stimmt nicht? Was fehlt?
• Erfolge sichtbar machen: “Heute hat das System 4 korrekte AMM-Verweise vorgeschlagen, die manuell je 8 Minuten Suche bedeutet hätten”

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir haben EASA-Zulassung, wir können nicht einfach neue Systeme einführen.” Stimmt zum Teil. Verfahren, nach denen Wartungseinträge entstehen, müssen im MOE beschrieben sein, und je nach Umfang der Änderung stimmt die Behörde vorher zu. Das ist Arbeit, aber es ist planbar. Der Fehler, den viele machen: sie warten auf die endgültigen EASA-Regeln für KI, bevor sie anfangen zu planen. Die Grundregel ist heute schon klar genug für eine Pilotphase: Das System entwirft, der Mensch prüft und zeichnet.

„Was, wenn das System einen falschen AMM-Verweis generiert?” Das wird passieren, genau wie heute ein Techniker manchmal einen Tippfehler macht. Der Unterschied: Das System macht es konsistenter, aber die Art der Fehler ändert sich. Der Schutz ist derselbe wie immer: vier-Augen-Prüfung, Techniker-Signatur bedeutet fachliche Verantwortung. KI produziert einen Entwurf; die qualifizierte Fachperson prüft und zeichnet ab. Das ist keine Abschwächung der Verantwortlichkeit, es ist dieselbe wie bei manueller Dokumentation.

„Unsere Techniker wollen kein Mikrofon im Hangar.” Das ist ein berechtigtes Bedenken. Lärmpegel in Hangars kann 85–100 dB erreichen, normale Spracherkennung funktioniert dort schlecht ohne Noise-Cancelling-Headset. Lösung: Techniker können Einträge auch an dedizierten ruhigen Stationen diktieren, nachdem die Arbeit abgeschlossen ist. Oder die Eingabe erfolgt per strukturiertem Formular auf dem Tablet, mit KI-Unterstützung für freie Textfelder. Spracheingabe ist eine Option, keine Pflicht.

Woran du merkst, dass das zu dir passt

• Du hast 15 oder mehr Techniker, die täglich routinemäßige Dokumentation erstellen, Line-Maintenance-Checks, Transit-Checks, periodische Inspektionen
• Deine Techniker verbringen täglich sichtbar Zeit mit Formularen, mindestens 30 Minuten, häufiger mehr
• Du betreibst AMOS oder ein vergleichbares integriertes MRO-System mit API-Schnittstelle, ohne Systemintegration ist der Mehrwert erheblich geringer
• Du hast einen internen IT-Ansprechpartner oder externen Dienstleister für die API-Integration, das ist kein Projekt für ein Wochenende, aber auch kein Jahresprojekt
• Du dokumentierst primär auf Englisch (oder bist bereit, dies zu tun), bringt die breiteste Werkzeugauswahl

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

1. Unter 10 Technikern. Der Einrichtungsaufwand (Integration, MOE-Anpassung, Schulung) ist für kleine Betriebe zu hoch im Verhältnis zum Zeitgewinn. Für kleine MRO-Betriebe empfiehlt sich zunächst AMOSmobile oder ein anderes digitales Logbuch ohne KI-Komponente.

2. Kein integriertes MRO-System vorhanden. Wer noch auf Papierbefehle oder Excel-Formulare setzt, braucht zuerst ein MRO-System, die KI-Ebene kommt danach. Eine KI-Schicht auf einem unstrukturierten Papierprozess zu bauen, multipliziert den Aufwand ohne den Nutzen.

3. Keine Ressource für die initiale MOE-Anpassung. Die EASA-Verfahrensdokumentation für ein KI-Werkzeug ist nicht trivial. Wenn die Qualitätsstelle bereits ausgelastet ist und kein externer Support finanzierbar ist, ist der Zeitpunkt falsch. Das ist eine Frage des Timings, nicht des grundsätzlichen Nutzens.

Das kannst du heute noch tun

Starte mit einer einfachen Messung: Bitte fünf Techniker, morgen mit einer Stoppuhr zu erfassen, wie viele Minuten sie für Dokumentationsaufgaben aufwenden, getrennt nach Kategorie (Arbeitskarten, Logbuch, Defect-Reports). Das kostet 30 Minuten Vorbereitung und liefert in einer Woche den Ausgangswert, den du für eine informierte Entscheidung brauchst.

Parallel dazu: Teste, wie ein KI-Assistent auf einen typischen Wartungsvorgang reagiert. Hier ist ein Prompt, den du direkt in ChatGPT oder Claude verwenden kannst, ohne technische Integration, nur als Konzeptvalidierung. Nimm dafür eine erfundene oder bereinigte Beschreibung ohne Kennzeichen, Kundennamen und Lizenznummern. Echte Arbeitskarten gehören erst in ein System mit AVV, siehe Datenschutz oben.

Quellen & Methodik

• Dokumentationszeit je Techniker: Eigene Annahme für die Rechnung, keine Messung. Veröffentlichte Vergleichswerte für deutsche MRO-Betriebe haben wir nicht gefunden.
• EASA NPA 2025-07: EASA Notice of Proposed Amendment NPA 2025-07 „Detailed specifications and associated acceptable means of compliance and guidance material | Artificial intelligence trustworthiness”, veröffentlicht am 10. November 2025, Kommentierung bis März 2026 (easa.europa.eu/en/document-library/notices-of-proposed-amendment/npa-2025-07).
• Zymbly: Anbieterwebsite und Y-Combinator-Profil (Jahrgang Winter 2026), ausgewertet auf unserer Toolseite.
• Preisangaben Azure OpenAI Service: Microsoft-Preisliste, Stand April 2026.

Willst du wissen, welche Formulartypen in deinem Betrieb das größte Zeitsparpotenzial haben und wie eine Integration in euer MRO-System konkret aussieht? Meld dich, das besprechen wir in einem kurzen Gespräch.