Was passiert, wenn KI das Lastenheft liest? Ein Erfahrungsbericht aus der Bahntechnik

Einleitung

Was passiert eigentlich, wenn man einem KI-System ein Lastenheft mit 800 technischen Anforderungen gibt und sagt: „Bewerte das“? Die Antwort ist weder die Science-Fiction-Vision einer vollautomatischen Angebotsmaschine noch die zynische Variante „nichts Brauchbares“. Die Realität liegt dazwischen, und sie ist differenzierter, als die meisten Marketingversprechen von KI-Anbietern vermuten lassen.

Dieser Artikel beschreibt, Schritt für Schritt, was tatsächlich passiert, wenn ein KI-System ein reales Lastenheft aus der Bahntechnik verarbeitet. Basierend auf Erfahrungen mit realen Ausschreibungsunterlagen, inklusive der Stellen, an denen die Technik funktioniert, und derer, an denen sie scheitert.

Die Frage ist nicht akademisch. Laut dem Loopio 2025 RFP Response Trends & Benchmarks Report nutzen branchenübergreifend bereits 68 % der Proposal-Teams generative KI, eine Verdopplung gegenüber 34 % im Jahr 2023. Die Bahnindustrie steht hier noch am Anfang, obwohl spezialisierte Plattformen wie Tendric genau diesen Anwendungsfall adressieren. Der jährliche NLP4RE-Workshop (Natural Language Processing for Requirements Engineering) zeigt aber, dass die Automatisierung der Anforderungsanalyse mittels NLP längst aus der Nische herausgewachsen ist.

Was sieht die KI, wenn sie ein Lastenheft öffnet?

Ein Lastenheft ist aus Sicht eines KI-Systems zunächst einmal ein Dokument: eine Excel-Datei mit 8 Tabellenblättern (LH1 bis LH8), tausenden Zeilen und einem Dutzend Spalten. Oder ein PDF. Oder, im Idealfall, ein strukturierter Datensatz im ReqIF-Format (Requirements Interchange Format), dem OMG-Standard für den werkzeugübergreifenden Austausch von Anforderungen, der seinen Ursprung in der Automobilindustrie hat und zunehmend auch in der Bahntechnik eingesetzt wird.

Bevor irgendeine inhaltliche Verarbeitung stattfinden kann, muss das System drei Grundaufgaben lösen:

1. Strukturerkennung: Welche Zeilen sind Anforderungen, welche sind Abschnittsüberschriften, welche sind Leerzeilen oder Kommentare? Im VDB-Leitfaden Anforderungsmanagement empfiehlt der Verband der Bahnindustrie in Deutschland eine einheitliche Attributstruktur für Lastenhefte. In der Praxis weicht die Realität aber erheblich davon ab.
2. Feldextraktion: Wo steht die Anforderungs-ID, wo der Text, wo die Verbindlichkeit (muss/soll/option), wo die Normenreferenz? Der internationale Standard ISO/IEC/IEEE 29148:2018 definiert zwar, welche Attribute eine Anforderung haben sollte, aber Besteller in der Bahnindustrie folgen diesem Standard selten explizit.
3. Bereinigung: Zusammengeführte Zellen, Zeilenumbrüche mitten im Text, Unicode-Sonderzeichen (‰ vs. %), verschiedene Datumsformate, und semantisch relevante Zellformatierungen (Farben, Fettdruck), die beim reinen Textexport verloren gehen.

Diese Vorverarbeitung klingt trivial, ist es aber nicht. Jeder Besteller strukturiert sein Lastenheft anders. Die Spaltenreihenfolge variiert, Abschnittsüberschriften stehen in derselben Spalte wie Anforderungstexte, und manche Besteller verwenden Farben oder Formatierungen als semantische Information, die beim Import verloren geht. Das Forschungsfeld Document Parsing beschreibt genau dieses Problem: Dokumente sind „visually rich text data“. Ihre Bedeutung ergibt sich nicht allein aus dem Text, sondern auch aus Layout, Schriftart, Tabellenstruktur und visuellen Elementen.

Phase 1: Anforderungsextraktion

Die Extraktion einzelner Anforderungen aus dem Rohdokument ist der erste und kritischste Schritt. Fehler hier pflanzen sich durch alle nachfolgenden Verarbeitungsschritte fort. Eine fehlerhafte Extraktion lässt sich weder durch eine gute Klassifizierung noch durch ein gutes Routing kompensieren.

Die Extraktion umfasst mehrere Teilschritte, die jeweils eigene Herausforderungen mit sich bringen:

• ID-Erkennung: Das typische Format X.35.YYYY.ZZ wird per Mustererkennung identifiziert. Die Trefferrate ist hoch, solange der Besteller ein konsistentes ID-Schema verwendet. Problematisch wird es bei abweichenden Formaten: Manche Besteller nutzen hierarchische IDs (3.2.1.4), andere verwenden laufende Nummern (REQ-0412), wieder andere verzichten ganz auf formale IDs und arbeiten mit Zeilennummern.
• Verbindlichkeitserkennung: „muss“, „soll“, „kann“, „ist zu“, „hat zu“ werden als Verbindlichkeitsindikatoren erkannt. Dies folgt der in der INCOSE-Systematik verankerten Unterscheidung zwischen imperativen und optionalen Formulierungen. Schwierig wird es bei kontextabhängigen Formulierungen wie „sollte nach Möglichkeit“ (ist das „soll“ oder „kann“?). Oder bei Passivkonstruktionen: „Die Einhaltung der Norm wird vorausgesetzt“ enthält kein explizites „muss“, ist aber eindeutig verpflichtend.
• Normenreferenz-Extraktion: Identifikation von Standards wie „DIN EN 45545-2:2020+A1:2023“ inklusive Versionsnummer und Amendments. Auch hier ist die Trefferrate bei standardisierten Schreibweisen hoch. Aber Besteller schreiben manchmal „gem. Brandschutznorm“ ohne konkrete Normennummer. Oder verweisen auf „aktuelle Fassung“ einer Norm, was bei Vertragsabschluss eine andere sein kann als bei Angebotsabgabe.
• Kontextuelle Anforderungsgrenzen: Wo endet eine Anforderung, wo beginnt die nächste? In Freitextdokumenten enthält ein einzelner Absatz manchmal mehrere implizite Anforderungen: „Das Fahrzeug muss die Streckenklasse D4 befahren können und dabei die Lärmgrenzwerte nach TSI Noise einhalten.“ Das sind technisch zwei unabhängige Anforderungen (Achslast und Lärm), verpackt in einen Satz.

Phase 2: Klassifizierungsvorschläge

Nach der Extraktion wird es inhaltlich: Jede Anforderung wird gegen die interne Wissensbasis abgeglichen. In der Praxis wird das heute typischerweise über eine RAG-Architektur (Retrieval-Augmented Generation) gelöst: Das System durchsucht Produktdatenblätter, Herstellerspezifikationen und Normenregister nach den relevantesten Passagen, übergibt diese zusammen mit der Anforderung an ein Sprachmodell und erhält einen Klassifizierungsvorschlag: OK, OKB, NOK, OKM oder R.

Warum RAG? Statt ein allgemeines Sprachmodell „frei antworten“ zu lassen (was zu Halluzinationen führt), wird das Modell auf konkrete Quelldokumente eingeschränkt. Es kann nur auf Informationen zugreifen, die tatsächlich in der Wissensbasis vorhanden sind, und muss seine Antwort mit Quellenreferenzen belegen. Das reduziert Halluzinationen. Eliminieren tut es sie nicht.

Die Qualität dieser Vorschläge variiert stark je nach Anforderungstyp:

Geschätzte Trefferquote der KI-Erstklassifizierung nach Anforderungstyp (qualitative Einschätzung basierend auf Praxiserfahrung, nicht als Benchmark zu verstehen). Aktuelle Forschung zur automatischen Anforderungsklassifizierung per NLP zeigt ähnliche Muster: F1-Scores von 0,73–0,84 je nach Methodenansatz (Nature Scientific Reports, 2024).

Wo es gut funktioniert

Parametrische Anforderungen sind der Sweet Spot: „Höchstgeschwindigkeit mindestens 100 km/h“ wird gegen das Produktdatenblatt abgeglichen (unser Wert: 100 km/h), die Vergleichslogik angewendet (≥ 100 → erfüllt), und das Ergebnis ist ein begründetes „OK“ mit Quellenreferenz. Das funktioniert, weil der Anforderungstyp eindeutig quantitativ ist, die Vergleichsoperation klar (≥, ≤, =) und die Quelldaten maschinenlesbar.

Ähnlich gut funktioniert der Abgleich bei Normenanforderungen, wenn das interne Normenregister gepflegt ist: Die KI erkennt die Normenreferenz im Anforderungstext, sucht im Normenregister nach dem Compliance-Status und liefert die Klassifizierung samt Zertifikatsnummer.

Wo es schwierig wird

Qualitative Anforderungen und neuartige Formulierungen sind die Schwachstelle. Wenn eine Anforderung lautet „Der Bieter muss ein Instandhaltungskonzept vorlegen, das den Lebenszyklus des Fahrzeugs über 30 Jahre abbildet“, kann die KI:

• Erkennen, dass es um Instandhaltung geht (korrekt)
• Den Subsystem-Bereich „Instandhaltung“ zuordnen (korrekt)
• Den RAMS-Bezug herstellen, also dass die Anforderung die Maintainability-Dimension betrifft im Sinne der EN 50126 (RAMS) (korrekt)
• Aber nicht bewerten, ob das Unternehmen ein solches Konzept hat oder erstellen kann (das hängt von internem Wissen ab, das selten vollständig dokumentiert ist)

In solchen Fällen ist „R“ (Rückfrage erforderlich) die ehrlichste Klassifizierung. Ein gutes KI-System sollte genau das vorschlagen, statt ein unbegründetes „OK“ zu halluzinieren. Die Forschung zu LLM-Halluzinationen zeigt das Problem: Sprachmodelle „lernen, konfident zu raten, statt kalibrierte Unsicherheit auszudrücken“. Bei der Anforderungsklassifizierung ist das gefährlich, weil ein falsches „OK“ direkte vertragliche Konsequenzen hat.

Quelle: CONTACT Software, Bummelzug zum Anforderungsmanagement. Dieses Zitat stammt von 2014. Seitdem hat sich die Anforderungsdichte weiter erhöht. Aktuelle Fahrzeugausschreibungen umfassen regelmäßig 1.500–3.000 Anforderungen über alle Teillastenhefte hinweg.

Phase 3: Normen erkennen und verknüpfen

Die automatische Normenerkennung bringt in der Praxis den größten Zeitgewinn. Ein typisches Lastenheft für ein Schienenfahrzeug referenziert, direkt und indirekt, eine dreistellige Zahl von Normen. Das Normenökosystem der Bahntechnik wird auf europäischer Ebene von ERA (European Union Agency for Railways) über die Technischen Spezifikationen für die Interoperabilität (TSI) definiert und von CEN/CENELEC in harmonisierte europäische Normen umgesetzt.

Für einen Anbieter bedeutet das: Wenn ein Lastenheft „EN 45545-2“ fordert (Brandschutz), muss er nicht nur den Status dieser einen Norm kennen, sondern auch:

• Die zugehörige TSI SRT (Safety in Railway Tunnels), die den regulatorischen Rahmen definiert
• Die Prüfmethoden in EN 45545-1 (allgemeine Anforderungen)
• Die Materialklassifizierungen nach EN 45545-2 (Brandverhalten)
• Produktspezifische Zertifizierungen und deren Gültigkeitszeitraum

Die KI kann diese Verknüpfungen in vier Schritten sichtbar machen:

Der DIN-Normenausschuss Fahrweg und Schienenfahrzeuge (FSF) koordiniert die Erarbeitung und nationale Umsetzung von Bahnnormen. Die resultierende Normenlandschaft umfasst rund 50–60 relevante Standards für Schienenfahrzeuge. Als strukturierter Katalog ist das handhabbar, wenn es einmal erfasst und gepflegt wird. Das Problem ist die Dynamik: Normen werden novelliert, Amendments veröffentlicht, TSIs aktualisiert. Die ERA hat allein im Jahr 2025 mehrere aktualisierte TSI-Spezifikationen veröffentlicht, darunter die neue TSI Telematics, die am 2. März 2026 in Kraft tritt und erstmals Anforderungen an Datenqualität und Cybersecurity für den Schienenverkehr definiert.

Phase 4: Experten-Routing-Vorschläge

Auf Basis der erkannten Thematik und Normenreferenzen kann die KI vorschlagen, welche Fachabteilung für jede Anforderung zuständig sein sollte. Laut dem Loopio 2025 RFP Response Trends Report berichten 48 % der Proposal-Teams branchenübergreifend von Schwierigkeiten bei der Zusammenarbeit mit Fachexperten. Automatisiertes Routing kann das zumindest teilweise abfangen.

In der Bahnindustrie ist das Routing-Problem ausgeprägt. Ein Lastenheft für ein Vollbahnfahrzeug adressiert 10–15 verschiedene Subsysteme, vom Fahrzeugkasten über Antrieb und Bremse bis zu Fahrgastinformation und Instandhaltungsdokumentation. Die zuständigen Fachexperten sitzen in verschiedenen Abteilungen, manchmal an verschiedenen Standorten. Ohne strukturiertes Routing verbringt der Angebotsmanager einen erheblichen Teil seiner Zeit damit, Anforderungen manuell den richtigen Personen zuzuordnen.

Wie die KI technisch arbeitet: RAG und Embedding-basierte Suche

Für Leser mit technischem Hintergrund lohnt ein Blick unter die Haube. Das Grundprinzip moderner KI-Systeme für die Lastenheftbearbeitung basiert auf einer Retrieval-Augmented-Generation-Architektur (RAG), die zwei Komponenten kombiniert:

1. Retrieval (Suche): Die Anforderung wird in einen numerischen Vektor (Embedding) umgewandelt und gegen eine Vektordatenbank der internen Wissensbasis abgeglichen. Das Ergebnis sind die 5–10 relevantesten Textpassagen aus Produktdatenblättern, Normenregistern und früheren Angeboten.
2. Generation (Bewertung): Ein Large Language Model (LLM) erhält die Anforderung zusammen mit den gefundenen Quelldokumenten und generiert einen Klassifizierungsvorschlag mit Begründung und Quellenreferenz.

Der Vorteil gegenüber einem „nackten“ LLM: Das System kann nur auf Informationen zugreifen, die tatsächlich in der Wissensbasis vorhanden sind. Wenn keine relevante Quelle gefunden wird, sollte das System ehrlich „R“ (Rückfrage) vorschlagen, statt eine plausibel klingende aber unbelegbare Antwort zu halluzinieren.

Wo die KI an Grenzen stößt

Ein ehrlicher Blick auf die Grenzen ist wichtiger als jede Erfolgsmeldung. KI-Systeme in der Lastenheftbearbeitung stoßen heute an fünf systematische Grenzen:

1. Implizites Wissen

Das wertvollste Wissen in einem Unternehmen ist oft nicht dokumentiert. Wenn ein erfahrener Ingenieur weiß, dass eine bestimmte Anforderung bei einer früheren Ausschreibung zum Ausschluss geführt hat und deshalb eine strategische Antwort formuliert, hat die KI keinen Zugang zu dieser Information. Sie sieht nur die Dokumente, die ihr zur Verfügung gestellt werden. Dieses „Tacit Knowledge“ spielt in der Bahnindustrie eine große Rolle, weil die Community überschaubar ist. Erfahrene Angebotsmanager kennen die Präferenzen und Bewertungsmaßstäbe spezifischer Besteller aus jahrelanger Zusammenarbeit.

2. Strategische Bewertung

Die Klassifizierung einer Anforderung als NOK ist manchmal eine strategische Entscheidung, keine rein technische. Erfahrene Angebotsmanager formulieren gezielt Rückfragen, um Anforderungen zu „entschärfen“, etwa indem sie den Besteller fragen, warum eine Anforderung strenger als die zugrunde liegende Norm ist. Oder sie nutzen die Gelegenheit, eine innovativere Alternative vorzuschlagen, die den Besteller überzeugt. Diese Art der strategischen Kommunikation liegt außerhalb der KI-Fähigkeiten.

3. Dokumentenqualität

Die Qualität der KI-Ergebnisse hängt direkt von der Qualität der internen Dokumente ab. Veraltete Produktdatenblätter, unvollständige Normenregister oder widersprüchliche Herstellerspezifikationen führen zu fehlerhaften Klassifizierungsvorschlägen. Das Prinzip „Garbage in, garbage out“ gilt uneingeschränkt. Das Paradoxe: Unternehmen, die ihre Dokumentation gut pflegen, hätten KI-Unterstützung am wenigsten „nötig“. Und die, die sie am meisten bräuchten, haben die schlechteste Datengrundlage.

4. Fehlender Verhandlungskontext

Ein Lastenheft ist kein statisches Dokument. Es ist der Ausgangspunkt einer Verhandlung. Die zweite Revision wird andere Anforderungen enthalten als die erste, basierend auf dem Feedback aller Bieter. Die KI kann die aktuelle Version verarbeiten, aber sie kann nicht antizipieren, welche Anforderungen der Besteller voraussichtlich lockern wird. Diesen Instinkt entwickeln erfahrene Angebotsmanager aus jahrelanger Zusammenarbeit mit bestimmten Bestellern.

5. Das Halluzinationsrisiko

Auch mit RAG-Architektur besteht das Risiko, dass das Sprachmodell Zusammenhänge herstellt, die nicht existieren. Oder Quelldokumente so interpretiert, dass sie die Anforderung scheinbar erfüllen, obwohl bei genauer Betrachtung wesentliche Unterschiede bestehen. Ein aktueller Survey zu LLM-Halluzinationen beschreibt das Problem: Sprachmodelle sind darauf optimiert, plausible Antworten zu generieren, nicht, kalibrierte Unsicherheit auszudrücken. In einem Angebotsprozess, in dem jede Klassifizierung eine vertragliche Zusage impliziert, ist das ein reales Risiko.

Was sich verändert: Der Workflow mit und ohne KI

Laut dem Loopio 2025 RFP Response Trends Report nutzen branchenübergreifend bereits 68 % der Proposal-Teams generative KI (eine Verdopplung gegenüber 34 % im Jahr 2023). 65 % setzen spezialisierte RFP-Software ein (gegenüber 48 % im Vorjahr), und die durchschnittliche Win-Rate liegt bei 45 %. Die Bahnindustrie, die beim digitalen Anforderungsmanagement traditionell zurückhaltender ist, steht hier noch am Anfang. Laut Bidara liegt die Content-Wiederverwendungsrate branchenübergreifend bei 66 %. Die meisten Bahnunternehmen schöpfen dieses Potenzial mangels durchsuchbarer Wissensbasis nicht aus. Plattformen wie Tendric setzen hier an, indem sie die Wissensbasis projektübergreifend aufbauen und durchsuchbar machen.

Fazit

Was passiert, wenn KI ein Lastenheft liest? Sie erledigt die Routinearbeit: Extraktion, Strukturierung, Parameterabgleich, Normenerkennung. Schneller und vollständiger als ein manueller Prozess. Für 70–80 % der Anforderungen liefert sie einen brauchbaren Erstvorschlag mit Quellenreferenz. Bei den restlichen 20–30 %, den strategischen, qualitativen und neuartigen Anforderungen, markiert sie korrekt ihre Unsicherheit und übergibt an den menschlichen Experten.

Das ist kein Versagen, das ist der Punkt. Die KI gibt dem Fachexperten die Freiheit, sich auf die Anforderungen zu konzentrieren, bei denen sein Urteil tatsächlich den Unterschied macht. Statt Stunden mit der Suche in Produktdatenblättern zu verbringen. Die INCOSE-Arbeitsgruppe für AI Systems nennt das „AI for SE“: KI zur Unterstützung von Systems-Engineering-Prozessen.

Die nächste Aufgabe sind nicht bessere Modelle. Es sind gepflegte Normenregister, aktuelle Produktdatenblätter, durchsuchbare Archive früherer Angebote. Werkzeuge wie Tendric adressieren genau diesen Punkt: Sie schaffen die strukturierte Datenbasis, auf der KI-gestützte Klassifizierung überhaupt erst zuverlässig funktioniert.