EASA-Musterzulassung: KI prüft 10.000-seitige Dossiers auf Inkonsistenzen
Musterzulassungsdossiers für neue Flugzeugtypen umfassen 10.000–50.000 Seiten — Verweise, Querverweise, numerische Grenzwerte und Nachweise. KI-NLP findet Inkonsistenzen und fehlende Nachweise, bevor EASA-Prüfer es tun.
- Problem
- Zertifizierungsteams verbringen Monate damit, Compliance-Matrizen manuell gegen CS-25/DO-178C-Anforderungen abzugleichen. Ein einziger widersprüchlicher Grenzwert zwischen zwei Kapiteln kann zu monatelangen EASA-Rückfragen führen — bei einem neuen Flugzeugtyp entstehen dadurch Verzögerungskosten von mehreren Millionen Euro pro Monat.
- KI-Lösung
- NLP-System extrahiert Anforderungen, Nachweise und Querverweise aus dem Dossier. Konsistenzprüfung: Werden alle referenzierten Tests tatsächlich nachgewiesen? Widersprechen sich numerische Werte in verschiedenen Kapiteln? Sind alle CS-25-Paragraphen adressiert? Ausgabe: Lücken- und Inkonsistenz-Report mit Schweregrad-Klassifikation.
- Typischer Nutzen
- Review-Zeit vor EASA-Einreichung um 30–50% reduzierbar. EASA-Rückfragerunden um 1–2 Iterationen weniger. Bei einem Zulassungsprojekt: potenzielle Einsparung von 2–6 Monaten Verzögerung.
- Setup-Zeit
- 6–12 Wochen bis Pilotbetrieb; keine OEM-Systemintegration nötig
- Kosteneinschätzung
- 20.000–45.000 EUR Einrichtung; 1.000–3.000 EUR/Monat Betrieb
Es ist Montag, 8:47 Uhr, Tag 147 des EASA-Reviews.
Markus Hellner, Senior Certification Engineer beim Strukturteam eines Flugzeugherstellers, öffnet die Findings-Liste — 23 neue Punkte, übermittelt am Freitagabend. Er überfliegt die Nummern, bis er bei Punkt 17 stoppt. Die EASA hat eine Inkonsistenz identifiziert: „In Section 4.2.3 wird eine Ausfallrate von 1×10⁻⁷ pro Flugstunde für das Höhenmesser-Subsystem angegeben. In Appendix G-7, Tabelle 4, erscheint derselbe Wert als 1×10⁻⁶.” Eine Zehnerpotenzdifferenz. Das Dossier hat 12.400 Seiten.
Markus weiß, was das bedeutet: Drei Wochen Suche. Nicht weil der Fehler schwer zu verstehen wäre — er ist es nicht. Sondern weil zuerst geklärt werden muss, in welchem der 23 Unterdokumente der Wert ursprünglich definiert wurde, welche anderen Abschnitte diesen Wert zitieren oder darauf aufbauen, und welche Analyse korrekt ist. Die Audittrail-Dokumentation für DO-178C macht das zu einer Archiv-Detektivarbeit in einem System, das für diese Frage nicht gebaut wurde.
Das hätte ein KI-System am Tag der Dossier-Einreichung, also 147 Tage früher, in vier Stunden finden können.
Das ist kein theoretisches Potenzial. Das ist ein strukturelles Problem, das jedes Musterzulassungsprogramm betrifft.
Das echte Ausmaß des Problems
Ein Musterzulassungsdossier für einen neuen Großraumflugzeugtyp umfasst typischerweise zwischen 10.000 und 50.000 Seiten. Darin enthalten: Compliance-Matrizen, die jeden CS-25-Paragraphen gegen einen Nachweisdokument-Verweis abbilden; strukturelle Analysen mit numerischen Grenzwerten, die in mehreren Kapiteln referenziert werden; DO-178C-Softwarenachweise über fünf Software-Review-Ebenen (SDP, SRD, SVD, SCS, SAS); Systemsicherheitsanalysen, die Ausfallraten auf verschiedene Aggregationsebenen verteilen; und Querverweise zwischen hunderten Unterdokumenten.
Die Inkonsistenzrate in solchen Dossiers ist strukturell. Kein menschliches Team kann sicherstellen, dass ein numerischer Wert, der in Kapitel 4, Anhang G und Sicherheitsanalyse B auftaucht, in allen drei Stellen exakt übereinstimmt — besonders wenn er im Laufe eines fünf- bis siebenjährigen Entwicklungsprogramms mehrfach überarbeitet wurde.
Was das kostet, ist gut belegt: Boeing hat beim 777X-Programm kumuliert rund 15 Milliarden USD in Entwicklungskosten geschrieben — ein erheblicher Teil davon resultiert aus Zertifizierungsverzögerungen, die unter anderem durch Findings der FAA und angepasste Prüfanforderungen entstanden (Simple Flying, 2025). Das ist ein extremes Beispiel, aber selbst bei kleineren Zertifizierungsprogrammen bewegen sich Verzögerungskosten von drei Monaten schnell im zweistelligen Millionenbereich: Testflugzeuge stehen still, Lieferverpflichtungen gegenüber Airlines werden nicht erfüllt, Vertragsstrafen greifen.
Die Ursache für viele dieser Verzögerungen liegt nicht in technischen Problemen, sondern in Dokumentationsmängeln: fehlende Nachweise, widersprüchliche Werte zwischen Kapiteln, CS-25-Paragraphen, die in der Compliance-Matrix als “adressiert” markiert, im Nachweisdokument aber nur unvollständig belegt sind.
Der manuelle Review-Status quo:
- Ein qualifizierter DO-178C-Gap-Analysis-Spezialist braucht 2–4 Wochen allein für die Lückenanalyse im Softwareanteil (AFuzion, 2024)
- Die Gesamtdauer eines EASA-Pre-Submission-Reviews durch das Zertifizierungsteam liegt bei größeren Programmen bei 4–9 Monaten
- Jede EASA-Findings-Runde verlängert das Programm um durchschnittlich 3–8 Wochen — und jede Runde, die durch eine früher entdeckte Inkonsistenz vermieden wird, ist direkte Einsparung
Mit vs. ohne KI — ein ehrlicher Vergleich
| Kennzahl | Ohne KI-Unterstützung | Mit KI-Konsistenzprüfung |
|---|---|---|
| Inkonsistenz-Erkennung vor Einreichung | Stichproben, stark personenabhängig | Systematisch, vollständig über alle Seiten |
| Zeit für Querverweisanalyse (12.000 Seiten) | 3–6 Wochen je Runde | 4–12 Stunden je Durchlauf |
| Abgedeckte CS-25-Paragraphen in Compliance-Matrix | Manuell auditiert, selten 100 % | KI-Abdeckungsprüfung gegen CS-25-Volltext |
| DO-178C-Nachweislücken erkannt | Erst durch EASA-Prüfer sichtbar | Vorab als Lückenliste mit Schweregrad |
| Durchschnittliche Anzahl EASA-Findings-Runden | 2–4 | Potenziell 1–2 weniger |
| Kosten je vermiedener Verzögerungsmonat | — | Mehrere Mio. EUR (programmabhängig) |
Vergleichswerte basieren auf Erfahrungen aus DO-178C-Zertifizierungsprojekten sowie Branchenberichten (AFuzion, AdaCore). Keine repräsentative Studie, aber konsistente Beobachtungen aus Fachpublikationen.
Einschätzung auf einen Blick
Zeitersparnis — hoch (4/5) Der größte Einzelhebel ist die systematische Querverweisanalyse: Was ein Team von drei Certification Engineers in drei Wochen durcharbeitet, läuft ein gut konfiguriertes LLM-System in einem Arbeitstag. Über ein vollständiges Zulassungsprogramm mit drei bis vier Pre-Submission-Review-Zyklen summiert sich das auf mehrere Personenmonate. Zeitersparnis=4 (nicht 5), weil der menschliche Review nach der KI-Analyse unverzichtbar bleibt — die KI liefert eine priorisierte Prüfliste, kein fertiges Ergebnis.
Kosteneinsparung — sehr hoch (5/5) Einen Monat Programmverzögerung zu vermeiden spart bei einem Flugzeugzulassungsprogramm typischerweise mehr als das 100-fache der KI-Werkzeugkosten. Das Kosten-Nutzen-Verhältnis ist unter den Anwendungsfällen dieser Branche einzigartig: Der Fix ist günstig (20.000–45.000 EUR Einrichtung, 1.000–3.000 EUR/Monat Betrieb), der vermiedene Schaden ist enorm. Der Wert von 5 ist defensibel — aber nur für Organisationen, die tatsächlich regelmäßig neue Musterzulassungen durchführen.
Schnelle Umsetzung — mittel (3/5) Für den Einstieg ist keine Integration in OEM-Systeme oder Zertifizierungsdatenbanken nötig: Du lädst das Dossier als PDF hoch, konfigurierst ein System-Prompt, und das LLM analysiert. Ein erster Probelauf mit einem einzelnen Unterdokument ist in einem Arbeitstag möglich. Für den produktiven Einsatz auf dem vollständigen 10.000-seitigen Dossier brauchst du 6–12 Wochen: Dokumentenextraktion, Chunking-Strategie, Prompt-Kalibrierung, Validierung gegen bekannte Findings. Das ist deutlich zugänglicher als hardwareintensive Anwendungen wie die FOD-Erkennung (einstieg=1), aber komplexer als reine SaaS-Lösungen.
ROI-Sicherheit — mittel (3/5) Der ROI tritt nur ein, wenn drei Bedingungen erfüllt sind: Das Team hat regelmäßig neue Musterzulassungsprogramme, die KI findet tatsächlich Inkonsistenzen, die sonst EASA-Findings ausgelöst hätten, und die KI-Findings werden rechtzeitig adressiert. Für große OEMs mit kontinuierlichem Zertifizierungsvolumen (Airbus, MTU, Collins Aerospace) ist das klar gegeben. Für kleine MRO-Betriebe oder System-Lieferanten ohne eigene Musterzulassung ist es spekulativ.
Skalierbarkeit — niedrig (2/5) Jede Musterzulassung ist ein Einzelprojekt mit eigenem Dokumentenformat, eigener CS-Amendmentbasis und eigener Compliance-Struktur. Was für Programm A kalibriert wurde, muss für Programm B neu konfiguriert werden. Skalierbarkeit entsteht nur begrenzt durch Prompt-Wiederverwendung und aufgebaute Expertise. Im Vergleich zu anderen Anwendungsfällen in dieser Branche bleibt der Skalierungshebel schwach.
Richtwerte — stark abhängig von Programmgröße, Dossierstruktur und Häufigkeit neuer Zulassungsvorhaben.
Was das System konkret macht
Die technische Grundlage ist eine Kombination aus NLP-Dokumentenextraktion und Retrieval-Augmented Generation (RAG). Im Kern passieren vier Dinge:
1. Dokumentenextraktion und Strukturerkennung Das Dossier — typischerweise ein Verbund aus Dutzenden von PDFs — wird mit OCR-fähigen Extraktionswerkzeugen in strukturierten Text überführt. Dabei werden Kapitelstruktur, Tabellen, Fußnoten und Querverweise erhalten. Ein Werkzeug wie Azure Document Intelligence übernimmt diesen Schritt: Es erkennt Tabellenspalten, Überschriftenhierarchien und referenzierte Abschnittsnummern mit hoher Präzision.
2. Semantische Indexierung Alle extrahierten Textblöcke werden in einem Vektorindex gespeichert — semantisch durchsuchbar, nicht nur nach Stichwörtern. Wenn die KI dann nach allen Textstellen sucht, die sich auf “Ausfallrate für das Höhenmesser-Subsystem” beziehen, findet sie auch Formulierungen wie “MTBF-Anforderung für den Baro-Kanal” oder “Failure Probability für den barometrischen Pfad” — semantisch verwandt, syntaktisch anders.
3. Konsistenzprüfung durch Querverweisanalyse Das LLM erhält einen strukturierten Prompt: “Identifiziere alle Textstellen, in denen numerische Werte für [Anforderungstyp X] angegeben werden. Prüfe, ob diese Werte konsistent sind. Gib für jede Diskrepanz Kapitel, Seite, Wert und Abweichung an.” Für ein 12.000-seitiges Dossier mit einem Modell wie GPT-4o oder Claude — beide mit Kontextfenstern von 128.000 bzw. 200.000 Token — läuft das in mehreren Chunks, die anschließend zusammengeführt werden.
4. Lückenprüfung gegen CS-25/AMC Ein zweiter Analysestrang prüft die Compliance-Matrix: Welcher CS-25-Paragraph ist in der Matrix als “adressiert” markiert, hat aber kein vollständiges Nachweisdokument verknüpft? Dafür wird der CS-25-Volltext als Referenzdatenbank hinterlegt. Das System vergleicht jeden abgehakten Paragraphen mit den verlinkten Dokumenten und markiert Lücken.
Das Ergebnis ist ein strukturierter Report: Gefundene Inkonsistenzen (sortiert nach Schweregrad), Compliance-Lücken (mit Verweis auf den spezifischen CS-25-Paragraphen), und eine Priorisierungsliste, was das Zertifizierungsteam zuerst ansehen sollte.
Grenzen der KI-Konsistenzprüfung — was ein Qualifizierter Prüfer sieht, den die KI nicht sieht
Das ist der ehrlichste und wichtigste Abschnitt dieses Textes.
Ein KI-System findet Diskrepanzen zwischen Zahlen. Es kann nicht beurteilen, ob die Diskrepanz regulatorisch relevant ist.
Was die KI zuverlässig kann:
- Zwei Werte an verschiedenen Stellen vergleichen und eine Abweichung markieren
- Einen CS-25-Paragraphen als “in der Compliance-Matrix erwähnt, aber ohne verlinktes Nachweisdokument” markieren
- Cross-Referenz-Ketten verfolgen: Wenn Dokument A auf Dokument B verweist, prüfen ob B existiert und ob die referenzierte Stelle das Richtige sagt
Was die KI nicht kann — und was einen Designated Engineering Representative (DER) oder Qualified Technical Person (QTP) unersetzlich macht:
- Regulatorische Interpretation: CS-25.1309 erlaubt unterschiedliche Interpretationen je nach Systemarchitektur und Betriebskontext. Die KI kann anzeigen, dass zwei Dokumente unterschiedliche Formulierungen verwenden — aber nicht entscheiden, ob beide rechtlich zulässig sind.
- AMC-Abweichung vs. Compliance-Alternative: Ein Applicant darf von Acceptable Means of Compliance (AMC) abweichen, wenn er eine gleichwertige Alternative nachweist. Die KI sieht eine Abweichung und markiert sie als Inkonsistenz — der DER weiß, ob hier absichtlich ein alternativer Compliance-Weg gewählt wurde.
- Intent-Erkennung: Ein erfahrener Prüfer erkennt, ob ein abweichender Wert ein Tippfehler ist oder eine bewusste Konservativitätsmarge. Die KI sieht nur die Zahl.
- Neuartige Findings: Wenn die KI kein bekanntes Inkonsistenz-Muster erkennt, gibt sie keine Meldung — auch wenn ein erfahrener DER einen strukturellen Fehler in der Nachweiskette sofort sehen würde.
Praxishinweis: In der Praxis bedeutet das, dass KI-Output grundsätzlich durch eine qualifizierte Person im Sinne von EASA Part 21 verifiziert werden muss, bevor er als Grundlage für Submission-Entscheidungen dient. KI ist ein Vorprüfwerkzeug, kein Ersatz für die verantwortliche Überprüfung durch Engineering-Expertise.
Regulatorische Einordnung: CS-25, DO-178C und AMC
Die folgenden Aussagen dienen der Orientierung. Sie ersetzen keine Rechtsberatung durch eine nach EASA Part 21 zugelassene Person oder Organisation.
CS-25 (Certification Specifications for Large Aeroplanes) definiert die Lufttüchtigkeitsanforderungen für große Verkehrsflugzeuge in Europa. Ein Musterzulassungsantrag muss für jeden CS-25-Paragraphen einen Compliance-Nachweis erbringen — entweder durch Übereinstimmung mit den Acceptable Means of Compliance (AMC) oder durch eine äquivalente alternative Methode.
DO-178C / ED-12C ist der Standard für Softwareentwicklung und -nachweis in sicherheitskritischen Luftfahrtsystemen. Ein vollständiger DO-178C-Nachweis umfasst fünf Plandokumente (SDP, SCMP, SVP, SQAP, SAS), Software-Anforderungsdokumente und Designbeschreibungen, Test-Coverage-Nachweise und Software-Accomplishment-Summary. Jede dieser Ebenen kann interne Inkonsistenzen enthalten — und jede kann vom anderen abhängen.
EASA-Findings im Zertifizierungsprozess entstehen typischerweise als Level 1 (Show-Stopper) oder Level 2 (signifikant, klärungsbedürftig). Eine KI-unterstützte Vorabprüfung zielt darauf ab, Level-2-Findings zu reduzieren und Level-1-Risiken früh zu identifizieren.
Was KI-Output nicht ist: Kein KI-Report ersetzt die förmliche Compliance-Erklärung (Declaration of Compliance, DoC) des Antragstellers oder die Stellungnahme eines Prüfers mit DER- oder QTP-Berechtigung. EASA akzeptiert KI-generierte Compliance-Reports nicht als eigenständige Nachweise — sie können aber als Grundlage für interne Quality-Gate-Prozesse dienen.
Konkrete Werkzeuge — was wann passt
Schritt 1: Dokumentenextraktion — Azure Document Intelligence Für das Einlesen der Dossier-PDFs ist Azure Document Intelligence die robusteste verfügbare Lösung mit EU-Datenhaltung. Das Tool erkennt Tabellenstrukturen, Überschriftenhierarchien und Seitennummern mit hoher Präzision. Kosten: ca. 1,50 USD pro 1.000 Seiten (Read-Modell) — ein vollständiges 12.000-seitiges Dossier kostet damit rund 18 USD in der Extraktion. Technisches Level: Developer, benötigt Azure-Konto und API-Integration.
Schritt 2: Semantische Suche und Konsistenzanalyse — Azure OpenAI Service mit GPT-4o Für die eigentliche Konsistenzanalyse empfiehlt sich GPT-4o über den Azure OpenAI Service: DSGVO-konforme Verarbeitung in der EU-Region, Enterprise-SLA, und das nötige 128k-Kontextfenster für große Textblöcke. Die Token-Kosten für das Durchleuchten eines 12.000-seitigen Dossiers bewegen sich — je nach Chunk-Strategie — im Bereich von 50–200 EUR pro Analysedurchlauf.
Alternative für Konsistenzanalyse: Claude (Anthropic) Claude bietet das größte verfügbare Kontextfenster (200.000 Token ≈ ca. 500 Buchseiten) und hat sich bei der Analyse langer, strukturierter Dokumente als besonders konsistent erwiesen (geringeres “Lost-in-the-Middle”-Problem). Für den deutschen Markt ist der DSGVO-saubere Weg über AWS Bedrock (Frankfurt) oder Google Vertex AI — nicht über claude.ai direkt. Für erste Tests ist claude.ai mit einem hochgeladenen Kapitel ausreichend.
Orchestrierung der Analyse-Pipeline: LangChain oder LlamaIndex Wer die Extraktion, das Chunking, den RAG-Index und die Konsistenzanalyse zu einem automatisierten Workflow verbinden will, greift auf LangChain oder LlamaIndex zurück. Beide sind Open-Source und ermöglichen es, die Analyse als reproduzierbaren, dokumentierten Prozess aufzubauen — wichtig für die interne Audit-Compliance. Technisches Level: Developer.
Einstieg ohne Setup: NotebookLM Für einen schnellen Machbarkeitstest ohne technisches Setup: NotebookLM von Google erlaubt das Hochladen von mehreren PDF-Dokumenten und gezielte Fragen über alle Quellen hinweg. Kostenlos, kein API-Zugang nötig. Einschränkung: Nicht DSGVO-konform für operative Dossiers (Google-Server, keine AVV für kostenlose Nutzung), begrenzte Dokumentengröße, kein EU-Hosting. Geeignet nur für nicht-sensible interne Testläufe.
Zusammenfassung: Wann welcher Ansatz
- Erstes Proof-of-Concept mit nicht-sensiblem Kapitel → NotebookLM (kostenlos, 1 Tag)
- Vollständiger Pilot mit EU-Datenhaltung → Azure Document Intelligence + Azure OpenAI Service (6–12 Wochen Setup)
- Alternative mit größtem Kontextfenster → Claude über AWS Bedrock Frankfurt
- Produktive Pipeline mit Versionierung und Reproduzierbarkeit → LangChain/LlamaIndex + Azure OpenAI
Datenschutz und Datenhaltung
Ein Musterzulassungsdossier enthält vertrauliche Konstruktionsdaten, proprietäre Systemarchitektur und technisches Wissen, das Jahrzehnte wettbewerbsrelevant bleibt. Das macht die Datenhaltungsfrage zur ersten und wichtigsten Entscheidung — noch vor der Tool-Auswahl.
Absolute Anforderung: Keine Verarbeitung auf US-Servern ohne vertragliche Absicherung Zertifizierungsdossiers enthalten typischerweise Export-kontrollierte Informationen (ITAR/EAR in den USA, EU-Dual-Use für europäische Programme). Die Verarbeitung auf US-Cloud-Servern kann zusätzliche Export-Compliance-Anforderungen auslösen. Das ist keine hypothetische Sorge: Airbus und andere europäische OEMs haben strikte Richtlinien, welche Systeme für Konstruktionsdaten zugelassen sind.
DSGVO — Dossiers enthalten selten personenbezogene Daten der Endnutzer, aber Mitarbeiterinformationen aus Signaturseiten, Review-Protokollen und Engineering-Orders können darunter fallen. Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist für jeden genutzten Cloud-Anbieter erforderlich.
Empfehlung für den produktiven Betrieb:
- Azure OpenAI Service in der EU-Region (West Europe oder Germany West Central): EU-Datenhaltung, Enterprise-AVV, ITAR-unproblematisch für die meisten europäischen Programme
- Alternativ: On-Premise-Betrieb mit einem Open-Weight-Modell (z.B. Llama 3.1) auf eigener Infrastruktur — höherer Setupaufwand, dafür maximale Kontrolle
- Nicht geeignet für produktive Dossieranalyse: Kostenlose Consumer-Tiers (NotebookLM Free, claude.ai Free/Pro), da keine AVV, kein EU-Hosting
Was es kostet — realistisch gerechnet
Einmalige Einrichtungskosten
- Dokumentenextraktion und Pipeline-Aufbau (Azure Document Intelligence + Azure OpenAI): 2–4 Wochen Entwickleraufwand, typisch 15.000–30.000 EUR extern
- Prompt-Kalibrierung und Validierung gegen bekannte Findings eines bestehenden Dossiers: 1–2 Wochen Spezialistenzeit
- Gesamteinrichtung: realistisch 20.000–45.000 EUR, abhängig von Komplexität des Dossiers und internem Know-how
Laufende Kosten (pro Analysedurchlauf)
- Azure Document Intelligence: ca. 18 USD für ein 12.000-seitiges Dossier (1,50 USD/1.000 Seiten)
- LLM-API-Kosten für Konsistenzanalyse: 50–200 EUR je Durchlauf (GPT-4o, abhängig von Chunk-Strategie)
- Azure-Infrastruktur und Storage: ca. 100–300 EUR/Monat laufend
- Gesamtbetriebskosten: ca. 1.000–3.000 EUR/Monat bei aktivem Einsatz, deutlich weniger in Phasen ohne aktives Zertifizierungsprojekt
Wie du den Nutzen misst Der direkte Nachweis funktioniert über einen kontrollierten Vergleich: Nimm ein bereits abgeschlossenes Dossier, für das EASA-Findings vorliegen. Lass die KI das Dossier zum Zeitpunkt der Einreichung analysieren. Wie viele der späteren EASA-Findings hätte das System damals identifiziert? Diese Rückwärtsvalidierung gibt dir ein reales Recall-Maß und ein ehrliches Bild der Erkennungsrate.
Was du dagegen rechnen kannst Ein vermiedener EASA-Findings-Zyklus spart typischerweise 3–8 Wochen Programmzeit. Bei Programmkosten von 5–15 Millionen EUR pro Monat (alle Overheads: Testflugzeug, Testpersonal, Flottenverzögerungskosten) ergibt sich eine Einsparung von 4–25 Millionen EUR je vermiedener Runde. Selbst im konservativsten Szenario (3 Wochen, 5 Mio. EUR/Monat) übersteigt der ROI die Einrichtungskosten um den Faktor 50–100 — sobald auch nur ein einziges Finding früher erkannt wird.
Typische Einstiegsfehler
1. Mit dem vollständigen Dossier starten statt mit einem Kapitel Der häufigste Fehler: Das Team konfiguriert die Pipeline für das gesamte 12.000-seitige Dossier, läuft in Token-Limits oder Chunking-Probleme, und verliert mehrere Wochen mit technischer Fehlersuche. Richtig ist der umgekehrte Weg: Ein einzelnes, gut bekanntes Unterdokument (z.B. das System Safety Assessment für ein spezifisches Sub-System), für das bereits bekannt ist, was darin steht. Damit kalibriert man Extraktionsqualität, Prompt-Präzision und False-Positive-Rate, bevor man das volle Volumen angeht.
2. False Positives unterschätzen und das Team damit verbrennen LLM-basierte Konsistenzprüfungen erzeugen zuverlässig False Positives. Eine Finanzinstitution berichtete, dass 83 von 200 durch KI markierten Vertragsproblemen beim manuellen Review nicht existierten (Adlib Software, 2024). In der Luftfahrt ist die Konsequenz dieselbe: Wenn das Team einmal zwei Stunden mit einem False Positive verbringt, das eine triviale sprachliche Variante war, verliert es das Vertrauen in das System. Lösung: In der Kalibrierungsphase einen Threshold für Confidence-Scores einbauen und jeden False Positive dokumentieren — als Feedback für die Prompt-Optimierung, nicht als Zeichen des Scheiterns.
3. Die KI als finalen Prüfer behandeln und den DER-Review weglassen Kein KI-Output darf ohne qualifizierte Überprüfung in Submission-Entscheidungen einfließen. Das klingt offensichtlich, aber in der Praxis entsteht Druck, den menschlichen Review zu verkürzen, wenn die KI-Liste bereits überzeugend aussieht. Das konkrete Risiko: Gelangt ein KI-Fehlbefund unkontrolliert in eine Submission-Entscheidung, kann daraus ein Level-1-EASA-Finding entstehen — das typischerweise 6–12 Wochen Programmverzögerung und mehrere hunderttausend Euro Folgekosten erzeugt. Außerdem akzeptiert die EASA keine KI-generierten Compliance-Nachweise ohne Bestätigung durch eine verantwortliche Person nach Part 21. Die KI reduziert den Prüfaufwand, ersetzt ihn nicht. Lösung: DER-Review als verpflichtenden Prozessschritt vor jedem Submission-Gate dokumentieren — nicht als informelle Konvention.
4. Die Analyse nicht in Programmtiming einplanen Ein häufiger Fehler: Die KI-Analyse wird als Spät-Review-Werkzeug eingesetzt — kurz vor Einreichung, wenn keine Zeit mehr ist, gefundene Probleme zu beheben. Der Wert entsteht früh: Jede Inkonsistenz, die in Monat 2 des Dokumentationsprozesses gefunden wird, kostet 10 Prozent des Aufwands im Vergleich zu einer Inkonsistenz, die in Monat 18 — zwei Wochen vor Submission — gefunden wird. Plane mindestens drei KI-Analysepunkte im Programmzeitplan ein: beim ersten vollständigen Dossier-Draft, nach jeder signifikanten Überarbeitung, und vor der finalen Einreichung.
Was mit der Einführung wirklich passiert — und was nicht
Der Widerstand der Erfahrenen In Zertifizierungsteams sitzen Menschen, die über Jahre tiefes Dossier-Wissen aufgebaut haben. Sie wissen, wo welcher Wert definiert ist und warum bestimmte Formulierungen bewusst gewählt wurden. Ein KI-System, das in vier Stunden eine Liste von 200 potenziellen Inkonsistenzen produziert, wird von diesen Menschen nicht als Hilfe, sondern als Lärm erlebt — solange die Signal-zu-Rausch-Ratio nicht bewiesen ist.
Was hilft: Diese Personen in die Kalibrierungsphase einbinden. Sie sollen die False Positives identifizieren und erklären, warum bestimmte Abweichungen regulatorisch zulässig sind. Ihr Wissen fließt in verbesserte Prompts, und sie entwickeln ein Gefühl dafür, was das System gut und schlecht kann.
Das Übergabeproblem zwischen Programmphasen Musterzulassungsprogramme dauern fünf bis sieben Jahre. Teams wechseln. Wer das KI-System in Jahr 2 konfiguriert hat, ist in Jahr 5 möglicherweise nicht mehr im Programm. Wenn die Prompt-Konfiguration, die Chunking-Strategie und die Schwellenwerte nicht dokumentiert sind, muss die Kalibrierungsarbeit von vorne beginnen. Lösung: Prompt-Versionierung und Entscheidungsprotokoll von Anfang an — nicht als nachträgliche Hausaufgabe.
Was die KI nicht ändert: die Submission-Entscheidung ist Menschensache Auch nach erfolgreicher Einführung trifft das Zertifizierungsteam die finale Entscheidung, welche Findings in einer Einreichungsrunde adressiert werden und welche bewusst offen bleiben. Die KI liefert die Prüfliste — aber Priorisierung, Risikobewertung und Kommunikation mit der EASA bleiben menschliche Domäne.
Realistischer Zeitplan mit Risikohinweisen
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Machbarkeitstest | Woche 1–2 | Ein bekanntes Unterdokument in NotebookLM oder Claude hochladen; bekannte Inkonsistenzen suchen lassen; False-Positive-Rate einschätzen | System findet alle bekannten Probleme nicht → Prompt überarbeiten, nicht abbrechen |
| Technischer Aufbau | Woche 3–8 | Azure Document Intelligence für Extraktion einrichten; Chunking-Strategie definieren; RAG-Index aufbauen; Erstkalibrierung | Schlecht gescannte Seiten mit OCR-Fehlern → Extraktion reparieren, Dossier nachbessern |
| Kalibrierung mit Experten | Woche 6–10 (Überlappung mit Aufbau) | Erfahrene Certification Engineers bewerten KI-Findings; False-Positive-Rate messen; Prompts iterieren | False-Positive-Rate über 40% → Threshold anheben; Ergebnis-Akzeptanz im Team bricht ein |
| Produktiver Erstlauf | Woche 10–12 | Vollständiges Dossier analysieren; Report erstellen; Team adressiert identifizierte Punkte | Findings-Liste zu lang für verfügbare Manpower → Priorisierung nach Schweregrad einführen |
| Integration in Programmplan | Woche 12–16 | KI-Analyse-Touchpoints in Programmzeitplan verankern; Zuständigkeiten klären; Dokumentation abschließen | Programmleitung sieht KI als Zusatzaufwand → ROI-Demo mit Rückwärtsvalidierung zeigen |
Häufige Einwände — und was dahintersteckt
„Unser Dossier ist zu komplex für KI” Das ist ein echtes Argument — aber kein abschließendes. Die Komplexität ist real: AMC-Abweichungen, programmspezifische Konventionen, 15 Jahre Dokumentationsgeschichte. Die Frage ist nicht, ob die KI das vollständig versteht — sie tut es nicht. Die Frage ist, ob sie den Anteil der offensichtlichen Zahlenkonsistenz-Checks, der heute Wochen dauert, auf Stunden reduzieren kann. Das kann sie zuverlässig.
„Das hat die EASA noch nie gesehen — die werden das nicht akzeptieren” Die EASA akzeptiert keine KI-generierten Compliance-Nachweise als eigenständige Dokumente — das stimmt. Aber die EASA schreibt nicht vor, wie du dein internes Quality-Gate-Verfahren organisierst. Ein KI-unterstützter Pre-Submission-Review ist ein internes Qualitätswerkzeug, kein Submission-Dokument. Es gibt keinen regulatorischen Grund, ihn nicht einzusetzen.
„Wir haben das bisher ohne KI gemacht und keine größeren Findings bekommen” Das ist das stärkste Gegenargument — und das ehrlichste. Wenn ein Team in der Vergangenheit saubere Submissions abgeliefert hat, ist der inkrementelle Wert der KI geringer. Die Frage ist dann: Wie viel Kapazität hat das Team, wenn das nächste Programm größer wird oder gleichzeitig mit einem anderen läuft? Die KI-Investition lohnt sich besonders dann, wenn Engpässe durch parallele Programme oder knappe Seniorkapazität entstehen.
Woran du merkst, dass das zu dir passt
Das passt zu eurer Organisation, wenn:
- Du regelmäßig Musterzulassungen oder Major-Changes nach Part 21 durchführst — mindestens eine Submission alle drei bis fünf Jahre; bei seltenerem Zertifizierungsvolumen übersteigt der Einrichtungsaufwand den ROI
- Dein Dossier aus suchbaren PDFs besteht — nicht aus gescannten Papierarchiven ohne sauberes OCR; die KI kann nur so gut sein wie die Textqualität, die sie bekommt
- Du mindestens eine Person im Team hast, die technisch in der Lage ist, eine Azure-Pipeline aufzubauen — das ist kein No-Code-Werkzeug; ohne Developer-Kapazität intern oder extern kommt man nicht produktiv an
- Du bereits eine strukturierte Compliance-Matrix hast — wenn die CS-25-Paragraphen nicht bereits einem Nachweis-Dokument zugeordnet sind, hat die KI keine Basis für die Lückenprüfung
Drei harte Ausschlusskriterien — wann du es lassen solltest:
-
Dein Unternehmen führt seltener als alle sieben Jahre eine eigene Musterzulassung durch. Dann bist du als System-Lieferant oder MRO-Betrieb vermutlich kein Antragsteller nach Part 21A, sondern unterstützt Primär-Antragsteller bei Teilaspekten. Der Gesamtaufwand für Aufbau und Pflege der Analyse-Pipeline ist für diese Rolle nicht gerechtfertigt — stattdessen kann Einzelkapitel-Analyse mit Claude ad-hoc ausreichen.
-
Das Dossier liegt überwiegend als gescanntes Papier oder schlecht qualifiziertes OCR vor. OCR-Fehler in Tabellenspalten produzieren systematische False Positives: Die KI sieht “1×10⁻07” und “1×10⁻07” als unterschiedlich, weil ein Sonderzeichen falsch erkannt wurde. Das Ergebnis ist eine unbrauchbare Findings-Liste mit hohem Lärmpegel. Erst Dokumentenqualität herstellen, dann KI-Analyse einführen.
-
Kein Certification Engineer hat Zeit und Mandat, False-Positive-Feedback zu geben. Ohne diese Kalibrierungsschleife bleibt die KI ein ungenaues Instrument, das mehr Misstrauen als Nutzen erzeugt. Der Erfolg hängt davon ab, dass Domänenexperten aktiv am Aufbau beteiligt sind — nicht als Reviewer am Ende, sondern als Kalibrierungspartner während der Einrichtung.
Das kannst du heute noch tun
Lade ein einzelnes Kapitel deines letzten Dossiers — idealerweise eines, für das du ein EASA-Finding erhalten hast — in NotebookLM oder Claude hoch. Stelle dann die folgende Frage manuell. Das dauert 30 Minuten, kostet nichts und zeigt dir sofort, ob das Konzept für dein Dokumentenformat funktioniert.
Für einen strukturierten ersten Konsistenz-Check kannst du diesen Prompt direkt verwenden:
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- Boeing 777X — $15 Milliarden Entwicklungskosten, sieben Jahre Verzögerung: Simple Flying, „Confirmed: Boeing 777X To Enter Service In 2027 After 7-Year & $15 Billion Delay” (2025); bestätigt durch Globe and Mail, „Boeing takes near $5-billion hit on 777X jet program delays” (2024).
- DO-178C Gap-Analysis-Dauer 2–4 Wochen: AFuzion, „DO-178C Costs vs Benefits Analysis” (2024), afuzion.com/do-178c-costs-versus-benefits/. Schätzwert aus Branchenpraxis, keine repräsentative Studie.
- DO-178C Reviews zur frühzeitigen Inkonsistenz-Erkennung: AdaCore, „A Fresh Take on DO-178C Software Reviews” (2023), adacore.com/blog/a-fresh-take-on-do-178c-software-reviews.
- LLM False-Positive-Rate in Dokumentenprüfung: Adlib Software, „Why LLMs Hallucinate More on Enterprise Documents” (2024); Evidently AI, „LLM Hallucinations and Failures: Lessons from 5 Examples” (2024). Das genannte Beispiel (83 von 200 False Positives) stammt aus einem Finanzsektorbericht, nicht aus der Luftfahrt — aber illustriert das strukturelle Problem.
- Azure Document Intelligence Preise: Microsoft Azure offizielle Preisseite (Stand Mai 2026), azure.microsoft.com/pricing/details/document-intelligence/.
- EASA CS-25: EASA, Easy Access Rules for Large Aeroplanes (CS-25), revision June 2022 und aktuell, easa.europa.eu/en/document-library/easy-access-rules/easy-access-rules-large-aeroplanes-cs-25.
- EASEL-AI (Mosaic ATM): Mosaic ATM, „EASEL-AI for Airlines”, mosaicatm.com/aviation-ai/easel-ai-for-airlines/. Vergleichbares System für FAA-Part-121-Dokumentenanalyse — zeigt, dass aviation-spezifische LLM-Dokumentenanalyse praktisch einsetzbar ist.
- LLM-Halluzinationsraten in regulierten Branchen: SQ Magazine, „LLM Hallucination Statistics 2026: AI Gets Facts Wrong Up to 82% of the Time” (2026).
- Programmkosten-Orientierungswerte: Erfahrungswerte aus öffentlich zugänglichen Branchenberichten (Boeing, Airbus) sowie Verzögerungskosten-Schätzungen aus Analysten-Reports. Keine firmenspezifischen Angaben.
Du willst wissen, ob eure spezifische Dossierstruktur für einen KI-gestützten Konsistenzcheck geeignet ist — und was ein erster Probelauf ergeben würde? Meld dich — das klären wir in einem kurzen Gespräch.
Diesen Inhalt teilen:
Interesse an diesem Use Case?
Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.
Weitere Use Cases
Triebwerksborescope: KI erkennt Beschichtungsschäden die Augen übersehen
Thermische Schutzschichten an Turbinenschaufeln spallen mikroskopisch ab — für menschliche Inspektoren kaum erkennbar, bis es zu spät ist. KI-Bildanalyse auf Borescope-Aufnahmen macht frühe Degradation sichtbar.
Mehr erfahrenKI-Wartungsdokumentation: Weniger Papierarbeit, mehr Werkzeugzeit
MRO-Techniker verbringen bis zu 30 % ihrer Schicht mit Dokumentation. KI-gestützte Spracherkennung und automatische Formularausfüllung geben diese Zeit zurück — EASA-konform und ohne Medienbruch.
Mehr erfahrenCFK-Delaminierung nach Vogelschlag: KI kartiert Schäden im Ultraschall
Nach Vogelschlag oder Impakt an CFK-Strukturen muss die Tiefe einer Delaminierung präzise kartiert werden — ein Prozess, der heute stundenlang dauert und stark von Erfahrung abhängt. KI beschleunigt die Auswertung von Ultraschall-Scans um 70–80%.
Mehr erfahren