Kurz gesagt: Ein Lastenheft-Generator mit KI erstellt aus einem kurzen Projektbrief und Ihren bisherigen Lastenheften einen strukturierten Erstentwurf. Jede vorgeschlagene Anforderung verweist auf ihre Quelle, die Fachabteilungen prüfen und geben frei. Ein Chatbot, dem Sie nur einen Prompt schicken, liefert das nicht: Ohne Suche über Ihre eigene Doku-Historie (RAG) und ohne Prüfung gegen ein Goldset bleibt der Text generisch.
Aus Kundengesprächen: Unternehmen wollen neben Lastenheften oft auch Angebote, Prüfpläne und Etiketten aus vorhandenen Dokumenten automatisch erstellen. Das Grundmuster, Erstentwurf aus eigenen Dokumenten plus Freigabe durch den Menschen, ist dasselbe. Sie haben ein Kundenlastenheft bekommen und müssen daraus ein Pflichtenheft ableiten? Dann passt Lastenheft und Pflichtenheft mit KI erstellen besser.
TL;DR
Ein Lastenheft-Generator auf GenAI-Basis verkürzt die Time-to-Lastenheft im Engineering von 6 auf 2 Wochen. Aus unserer Erfahrung mit einem Tier-1-Anbieter für Embedded-Engineering-Werkzeuge aus Süddeutschland: 1,5 FTE-Save pro Jahr, 240k Annual Value gegen 55-95k Sprint-Investment. Architekt-Brief rein, strukturierter Erst-Entwurf raus, kein PLM-Vendor-Lock-in. RAG über die eigene Doku-Historie ist der Kern.
Was Engineering 2026 vom Lastenheft-Prozess wirklich will
Wir sprechen aktuell mit Engineering-Leitern in Maschinenbau, Automotive-Tier-1 und Embedded-Elektronik. Die Klage ist immer dieselbe: Senior-Architekten verbringen einen zweistelligen Prozentsatz ihrer Jahreszeit damit, Lastenhefte zu schreiben, zu reviewen und zu konsolidieren. Nicht zu entwerfen. Nicht zu validieren. Nur zu dokumentieren.
Der typische Bottleneck zerfällt in fünf Phasen:
- Woche 1-2 — Architekt schreibt initiale Version, oft aus dem Gedächtnis und mit Copy-Paste aus dem letzten halbwegs ähnlichen Projekt.
- Woche 2-4 — Fachabteilungen (Elektronik, Software, Mechanik, Qualität) reviewen den Entwurf in 2-3 Runden. Jede Runde frisst Tage.
- Parallel — Inkorporierte Quellen recherchieren: alte Lastenhefte, Normen (ISO 26262, IEC 61508), Kundenmails, Meetingprotokolle aus Polarion oder Confluence.
- Pattern-Suche — Vergleichbare Projekte finden, Anforderungs-Kataloge wiederverwenden. Das passiert heute über persönliche Netzwerke oder gar nicht.
- Woche 5-6 — Konsolidierung, Finalisierung, Approval-Loop mit dem Kunden.
Unsere Erfahrung aus mehreren Engineering-Sprints: Der eigentliche Engpass liegt nicht im Architekten-Können, sondern in der Wiederverwendung von Wissen, das bereits im Unternehmen existiert. Fünf bis zehn Jahre Lastenhefte liegen in PDF, Word, Confluence, Polarion — und niemand findet sie schnell genug.
Was wir konkret bauen
Die Lösung ist kein GPT-Wrapper, sondern eine vollständige RAG-Pipeline mit Reflection-Loop. Architektur in groben Zügen:
- Vector-Index über 5-10 Jahre Engineering-Doku: Lastenhefte, Pflichtenhefte, Anforderungs-Spezifikationen, Schnittstellen-Dokumente. Quellen: PDF, Word, Confluence, Polarion-Export.
- Embedding: BGE-M3 (multilingual, 8k Token Kontext) — wichtig für deutschsprachige Engineering-Doku mit langen Anforderungs-Sätzen.
- Re-Ranker: bge-reranker-v2-m3 für die Top-50-zu-Top-10-Verdichtung.
- LLM: GPT-4o oder Claude Sonnet 4 in Azure OpenAI EU-West. Alternativ self-hosted Llama 3.3 70B oder Qwen 2.5 72B, wenn der Kunde keine US-Cloud will.
- Generierung: Strukturiertes 8-Kapitel-Lastenheft-Skelett mit Pattern-Bibliothek pro Domäne.
- Orchestrierung: LangGraph mit Reflection-Loop — der Generator prüft seinen eigenen Output gegen das Goldset und iteriert.
- Eval: Engineering-Lead bewertet gegen 50 historische Lastenhefte als Goldset.
Der Workflow für den Architekten ist drastisch verkürzt: 8-Fragen-Brief in einer Stunde ausfüllen, der Generator zieht aus der Engineering-Historie und produziert einen Erst-Entwurf mit Quellenangaben. Die Fachabteilungen reviewen ab Tag 2 einen vollständigen Entwurf statt einer leeren Seite — und genau hier kollabiert die Zykluszeit.
from langchain_openai import AzureChatOpenAI
from langchain_qdrant import QdrantVectorStore
llm = AzureChatOpenAI(
azure_endpoint="https://pexon-eu.openai.azure.com/",
azure_deployment="gpt-4o",
api_version="2026-05-01",
temperature=0.1,
)
LASTENHEFT_TEMPLATE = """Du bist Engineering-Architekt. Erstelle ein Lastenheft-Skelett
basierend auf dem Kunden-Brief und historischen vergleichbaren Lastenheften.
Kunden-Brief:
{brief}
Vergleichbare historische Lastenhefte (aus Vektor-Suche):
{retrieved_lastenhefte}
Strukturiere als 8-Kapitel-Lastenheft:
1. Zielsetzung und Abgrenzung
2. Funktionale Anforderungen (numeriert FA-001 bis FA-NN)
3. Nicht-funktionale Anforderungen (NFA mit Akzeptanzkriterien)
4. Schnittstellen-Spezifikation
5. Normen, Standards, Compliance
6. Liefer- und Abnahmekriterien
7. Offene Punkte (TODO-Liste für Architekten-Review)
8. Annahmen und Risiken
Zitiere bei jeder Anforderung die Quelle aus den historischen Lastenheften
mit [QUELLE-X.Y]. Markiere mit [NEU] alles ohne historische Vorlage."""Unsere Empfehlung: Den Generator immer mit expliziter Quellen-Zitation bauen. Engineering-Architekten misstrauen jeder Anforderung ohne Herkunftsangabe — zu Recht. Wer ohne Citation arbeitet, verliert die Akzeptanz nach drei Wochen.
Ein zweiter Punkt zur Architektur: Temperatur niedrig halten (0,0-0,2). Engineering-Doku verzeiht keine kreativen Variationen in Anforderungs-Formulierungen. FA-Nummerierung, Bezugnahmen auf Normen, Querverweise auf Schnittstellen — das sind Bereiche, in denen Halluzination teuer wird. Wir setzen zusätzlich ein deterministisches Post-Processing, das Anforderungs-IDs validiert, Cross-References checkt und Normen-Zitate gegen eine kuratierte Liste (ISO 26262, IEC 61508, ISO 13849, branchenspezifisch) abgleicht.
ROI-Rechnung — wo die 240k herkommen
Rechnen wir konservativ. Senior-Engineer-Vollkosten im DACH-Raum: ca. 312k EUR pro Jahr inklusive Arbeitgeberanteil, Overhead, Tools. Anteil der Lastenheft-Zeit bei einem typischen R&D-Architekten: 15-25 Prozent der Jahresarbeitszeit.
Die 240k sind ohne Folge-Effekte gerechnet. Was nicht drin steckt: schnellere Time-to-Market bei Neuprodukten, weniger Anforderungs-Konflikte mit dem Kunden, höhere Wiederverwendungsquote bei Anforderungs-Bausteinen. In unserer Erfahrung verdoppelt sich der Wert über 24 Monate, sobald die Architekten dem Generator vertrauen und die Goldset-Pipeline läuft.
Anti-Lock-in — der eigentliche Differenzierer
Im Mai 2026 haben Siemens Teamcenter AI Chat und PTC Windchill AI General Availability erreicht. Beide sind technisch ordentliche Produkte. Beide haben dasselbe strategische Problem: Sie locken den Engineering-Kunden auf proprietäre Lastenheft-Templates und versuchen, das Doku-Wissen in ihrer Cloud zu halten.
Wer Teamcenter AI als Spec-Generator nimmt, schließt drei Türen gleichzeitig:
- LLM-Wahl — der Vendor bestimmt das Modell, der Kunde hat keine Migrationsoption auf ein günstigeres oder besseres Modell.
- Daten-Hoheit — die Embeddings landen in der Vendor-Cloud. Bei einem späteren PLM-Wechsel ist das Vektor-Wissen weg.
- Template-Hoheit — die Anforderungs-Struktur ist an das Vendor-Datenmodell gekoppelt. Cross-PLM-Wiederverwendung wird zur Migration.
Unsere Empfehlung: BYO-LLM (Bring Your Own LLM) mit Azure OpenAI EU oder self-hosted Llama/Qwen, offene Vector-DB (Qdrant), Code im Kunden-Repo, Templates als YAML im Git. Das ist die Differenzierung gegen die PLM-Vendor-Lösungen. Wir bauen die Pipeline so, dass der Kunde in 18 Monaten das LLM tauschen kann, ohne den Code neu zu schreiben.
Diese Position ist nicht ideologisch. Sie ist ökonomisch. LLM-Preise fallen aktuell pro Quartal zweistellig. Wer sich an einen PLM-Vendor bindet, lässt diese Margen liegen. Wir haben Kunden gesehen, die innerhalb von 9 Monaten von GPT-4 auf GPT-4o-mini wechselten und dabei 60 Prozent Inferenz-Kosten sparten — bei besserer Qualität. Dieser Wechsel kostet bei BYO-LLM einen Tag, beim Vendor-Tool ein Migrationsprojekt.
Zweites Argument gegen die PLM-Vendor-Pfade: Wer mehrere PLM-Systeme in der Konzernlandschaft hat (Teamcenter im Werk A, Windchill im Werk B, Polarion in der R&D-Zentrale), kann keinen vendor-gebundenen Spec-Generator standardisieren. Eine eigene RAG-Pipeline ist PLM-agnostisch und greift via Connector auf alle drei zu.
Eval — ohne Goldset kein Vertrauen
Eine Generator-Pipeline ohne Eval ist nach sechs Monaten ein Risiko. Modelle driften, Doku-Bestand wächst, Anforderungs-Pattern ändern sich. Wir bauen jeden Sprint mit einem Goldset von 50 historischen Lastenheften, die von einem Engineering-Lead auf einer 1-5-Skala bewertet wurden.
from ragas.metrics import faithfulness, answer_correctness
# Golden Set: 50 historische Lastenhefte mit Architekten-Score 1-5
results = evaluate(
dataset=engineering_golden_set,
metrics=[faithfulness, answer_correctness],
llm=AzureChatOpenAI(...),
)
# Pexon-Pattern: Faithfulness >0.88, Architect-Approval-Rate >65% nach 4 WochenKonkrete Schwellen aus unseren Sprints: Faithfulness über 0,88 (keine erfundenen Anforderungen), Architect-Approval-Rate über 65 Prozent in Woche 4 nach Go-Live. Wer unter diese Werte fällt, hat ein Retrieval- oder Re-Ranker-Problem — nicht ein LLM-Problem. Die Reihenfolge der Fehlersuche ist immer dieselbe: Chunking prüfen, dann Re-Ranker-Top-K erhöhen, dann Embedding-Modell wechseln, dann erst am LLM-Prompt schrauben.
Unsere Empfehlung: Kein LangSmith für Eval-Hosting. LangSmith ist US-gehostet und bei Engineering-Doku DSGVO-kritisch, vor allem wenn Spezifikationen Kundennamen oder Patente enthalten. Wir nutzen Ragas lokal oder Phoenix self-hosted. Zusätzlich tracken wir pro Woche, wie viele der vorgeschlagenen Anforderungen unverändert ins Final-Dokument kamen — das ist die belastbarere Metrik als jede Offline-Bewertung.
Anti-Patterns, die wir wiederholt sehen
Der gefährlichste Anti-Pattern ist der letzte. Wir haben gesehen, wie Engineering-Teams eine fertig gebaute Pipeline ablehnten, weil das Tool als „AI schreibt das Lastenheft“ verkauft wurde. Sobald wir die Positionierung auf „AI schreibt den Erst-Entwurf, der Architekt entscheidet jede Anforderung“ drehten, stieg die Akzeptanz von unter 20 auf über 70 Prozent in vier Wochen. Sprache und Framing entscheiden hier mehr als jede Modell-Wahl.
Pattern aus dem Engineering-Sprint
Bei einem deutschen Anbieter von Engineering-Werkzeugen für Embedded Systems aus Süddeutschland haben wir genau dieses Pattern aufgebaut. Ausgangslage: 11 Senior-Architekten, durchschnittlich 7 Wochen Time-to-Lastenheft, hohe Frustration über manuelle Pattern-Suche. Nach 12 Wochen Sprint: Time-to-Lastenheft auf 2 Wochen, 1,5 FTE-Save, 52k Won Pipeline aus Folge-Modulen.
Was hat funktioniert:
- Goldset zuerst — vor jeder Modell-Auswahl 50 historische Lastenhefte mit dem Engineering-Lead annotiert.
- Multilinguales Embedding — BGE-M3 statt OpenAI-Embeddings. Deutsche Anforderungs-Sätze sind oft 200+ Wörter lang, OpenAI-Embeddings verlieren Kontext.
- Architect-in-the-Loop UI — der Architekt sieht jede generierte Anforderung neben der zitierten Quelle und akzeptiert/editiert/verwirft mit einem Klick.
- Festpreis-Sprint — 12 Wochen, 75k EUR, klare Definition of Done mit Eval-Schwellen.
Häufig gestellte Fragen
Was ist ein Lastenheft-Generator mit GenAI und wo unterscheidet er sich von Word-Templates?
Ein Word-Template ist eine leere Seite mit Überschriften. Eine GenAI-Pipeline zieht aus 5-10 Jahren Engineering-Doku, schlägt konkrete Anforderungen mit Quellenangabe vor und liefert ein begutachtbares Skelett. Der Architekt entscheidet weiterhin, was rein und was raus geht — aber er startet auf Stunde 1 mit einem 60-70 Prozent fertigen Entwurf statt einer Gliederung.
Wie sicher ist unser Engineering-Wissen, wenn wir Cloud-LLM nutzen?
Bei Azure OpenAI in EU-West-Region bleiben Prompts und Embeddings in der EU. Microsoft trainiert keine Modelle mit Kundendaten. Wer trotzdem keine US-Cloud will, nimmt self-hosted Llama 3.3 70B oder Qwen 2.5 72B auf eigener GPU-Infrastruktur. Die Pipeline funktioniert identisch, nur das LLM-Backend tauscht.
Warum nicht einfach Teamcenter AI Chat oder Windchill AI nehmen?
Beide Tools sind technisch solide. Beide binden den Kunden an proprietäre Templates und behalten die Vektor-Embeddings in der Vendor-Cloud. Bei einem späteren PLM-Wechsel ist das Doku-Wissen weg. Unser Pattern bleibt im Kunden-Repo: Code in Git, Vektor-DB self-hosted oder in Azure-Tenant, LLM austauschbar. Strategische Optionalität statt Vendor-Bindung.
Wie lange dauert der Pexon-Sprint konkret?
90 Tage. Phase 1 (Woche 1-3): Goldset aufbauen, Doku-Ingestion, Vektor-Index. Phase 2 (Woche 4-8): Generator-Prompt, Reflection-Loop, Architect-UI. Phase 3 (Woche 9-12): Eval gegen Goldset, Pilot mit 2-3 Architekten, Übergabe an internes Team. Definition of Done: Faithfulness über 0,88 und Architect-Approval über 65 Prozent.
Was kostet ein Lastenheft-Generator-Sprint?
Festpreis 55-95k EUR je nach Doku-Bestand und Komplexität der Anforderungs-Strukturen. Kleinerer Korridor bei homogener Doku (nur Confluence, eine Domain), größerer bei heterogener Quellenlage (PDF + Word + Polarion + Mailbox-Export). Annual Value 240k bei 1,5 FTE-Save heißt: Amortisation in 3-5 Monaten nach Go-Live. Wer mehrere Werke oder Geschäftsbereiche ausrollen will, bekommt ab dem zweiten Roll-out 30-40 Prozent Skaleneffekt — derselbe Index, gleiche Pipeline, nur neue Templates und neuer Goldset-Anteil.
Nächster Schritt
Wenn Sie als Engineering-Lead aktuell zwischen Teamcenter AI, Windchill AI und einer eigenen Lösung evaluieren — lassen Sie uns reden, bevor Sie sich auf einen PLM-Vendor festlegen. Wir zeigen Ihnen in 60 Minuten, wie das Pattern in Ihrer Architektur aussieht, wo Ihre Goldset-Quellen liegen und ob 2 Wochen Time-to-Lastenheft für Ihre Domäne realistisch sind.
Lastenheft-Generator Pilot anfragen — 90-Tage-Sprint mit Festpreis 55-95k EUR
