Drei Tage Workshop, ein gebundenes PDF, ein Handover an die Entwicklung: So sah Anforderungsmanagement in mittelständischen IT-Projekten zwei Jahrzehnte lang aus. Dieses Muster prägt in vielen mittelständischen IT-Projekten bis heute den Projektstart, nur trägt es nicht mehr wie früher.
Große Sprachmodelle sitzen mittlerweile mit am Workshop-Tisch, lesen vorhandene Spezifikationen mit, generieren User-Story-Entwürfe und stellen Rückfragen, die früher erst in der Architektur-Phase aufgetaucht wären, also dann, wenn die Antwort schon richtig teuer wurde. Die Frage ist nicht mehr, ob KI das Lastenheft verändert. Die Frage ist, in welche Richtung, wer die Verantwortung trägt, wenn es schiefgeht, und welche Risiken in der Anfangs-Euphorie unsichtbar bleiben.
Warum klassische Lastenhefte an Grenzen stoßen
Das Lastenheft beschreibt, was gebaut werden soll. Das Pflichtenheft beantwortet, wie. So weit die Theorie. Die Praxis in KMU-IT-Projekten der letzten Jahre sieht anders aus: Diese Trennung hält im Workshop-Raum, nicht im laufenden Sprint. Fachabteilungen wissen nicht präzise genug, was sie wollen. Das Pflichtenheft entsteht in halber Hand parallel zur ersten Codezeile. Lücken im Lastenheft tauchen erst auf, wenn der Entwickler im Sprint-Planning fragt: „Und was passiert, wenn die Datei zu groß für unser Upload-Limit ist?“
Dazu kommt das zweite, leiser wirkende Problem: Lastenhefte veralten. Eine Funktion, die im ersten Workshop selbstverständlich war, wird im Projektverlauf durch eine bessere Idee ersetzt. Das Dokument bleibt.
Spätestens beim Abnahmetest entsteht die Schlüsselfrage: Abgenommen wird, was im PDF steht, oder was tatsächlich gewollt war? An dieser Stelle geraten Projekt-Endspurt regelmäßig in Schieflage. Das Lastenheft war nie schuld an dieser Misere, aber es ist auch nicht das Werkzeug, das sie auflöst.
Was sich konkret verändert, wenn LLMs mitschreiben
Vom statischen Dokument zum lebenden Spezifikations-Korpus
Anforderungen sind im KI-gestützten Vorgehen kein PDF mehr, das einmal entsteht und dann abgelegt wird. Sie sind ein Text-Korpus: lebendig, indexiert, durchsuchbar. Workshop-Protokolle, E-Mail-Antworten aus dem Fachbereich, abfotografierte Whiteboard-Skizzen, nachträgliche Klarstellungen aus dem Sprint Review, alles fließt in einen gemeinsamen Speicher. Das Sprachmodell liest diesen Korpus, generiert daraus konsolidierte Lastenheft-Kapitel auf Anfrage, markiert Inkonsistenzen („Sektion 3.2 widerspricht Sektion 7.1“) und stellt Versionsvergleiche her. Das Lastenheft wird vom Standbild zum Film.
Anforderungs-Lücken werden früher sichtbar
Ein gut konfiguriertes LLM erkennt unspezifizierte User-Stories früh. Beispiel: „Der Benutzer kann eine Datei hochladen.“ Das Modell fragt zurück: Welche Dateitypen? Welche Maximalgröße? Was passiert, wenn der Upload mitten in der Übertragung abbricht? Was, wenn die Datei Schadcode enthält? Diese Fragen tauchten früher (oft) erst in der Implementierungsphase auf, wenn die Architektur schon stand und die Antwort lautete: „Das hatten wir doch besprochen.“
Sie tauchen jetzt im Workshop selbst auf, während die Beschreibung noch frisch ist. Anforderungs-Lücken, die in der Spezifikation auffallen, lassen sich klären, bevor sie wirklich Geld kosten; denn Lücken, die erst im Produktivbetrieb sichtbar werden, sind ungleich teurer zu reparieren. Dieser Hebel ist ein ökonomisch wesentlicher Effekt der Verschiebung, über den wenig gesprochen wird, weil er weniger spektakulär klingt als „KI schreibt Lastenhefte“.
Die veränderte Rolle der Fach-Stakeholder
Wenn das Modell strukturierte Rückfragen aus einer Erstbeschreibung generiert, kippt die Workshop-Dynamik. Stakeholder sind nicht mehr Sender unstrukturierter Wünsche, sondern Antwortgeber präziser Fragen. Das setzt voraus, dass sie die Antwort tatsächlich kennen. Fehlt sie, ist das ein Befund: Die Anforderung war nie konkret genug. Eine gute Workshop-Leitung erkennt diesen Moment und unterbricht das Modell, bevor es eine plausible, aber erfundene Antwort selbst formuliert. Wer diesen Moment verpasst, hat am Ende ein Lastenheft, das aussieht, als sei alles geklärt, obwohl nichts geklärt ist.
Strukturierte Einführung im KMU-Kontext
Datenbasis: Welche Quellen das LLM lesen darf
Vor der ersten KI-gestützten Anforderungs-Session steht eine Entscheidung, die fast immer zu spät getroffen wird: Welche Dokumente fließen in den Modell-Kontext, welche nicht? Personenbezogene Daten, Kundenverträge, schutzwürdige Lieferantenkonditionen gehören grundsätzlich ausgeschlossen oder vorab anonymisiert.
Statt den kompletten SharePoint zu öffnen, lohnt eine reduzierte Workshop-Daten-Schicht, die nur enthält, was für das konkrete Vorhaben relevant ist. Wer den so entstehenden Anforderungs-Korpus nicht als lose Dokumentensammlung, sondern als semantisch verknüpftes Wissensnetzwerk versteht, in dem User-Storys, Fachbereichs-Antworten, Skizzen und Architektur-Entscheidungen aufeinander referenzieren, findet bei Wissensgraphen für KMU-Anforderungs-Engineering einen Bezugsrahmen, der über klassische Lastenheft-Schablonen hinausgeht.
Workshop-Format mit Mensch und Modell
Das Workshop-Format, das in der Praxis tatsächlich trägt, behandelt das LLM nicht als autonomen Anforderungs-Generator, sondern als strukturierten Sparringspartner. Die Workshop-Leitung stellt eine Frage in den Raum, sammelt die menschlichen Antworten, lässt das Modell anschließend nach Lücken und Widersprüchen suchen und führt die Diskussion auf Basis dieser Rückmeldung weiter. Dieses Setup verhindert einen verbreiteten „Anfängerfehler“ im Umgang mit KI: Eine Gruppe hält die Anforderung für verstanden, weil das Modell sie flüssig formuliert hat. Flüssig ist nicht dasselbe wie korrekt, und der Unterschied wird oft erst weit später sichtbar, wenn die Korrektur teuer ist.
Abgrenzung Lastenheft und Pflichtenheft
Die Trennung zwischen Lastenheft und Pflichtenheft bleibt auch im KI-gestützten Vorgehen bestehen, das sollte sie auch. Was sich verkürzt, ist der Übergang. Liegt das Lastenheft als strukturierter Korpus vor, kann ein zweiter Modell-Durchlauf erste Architektur-Vorschläge daraus ableiten: „Wenn wir Anforderung 4.2 so verstehen, wäre ein Event-Driven-Ansatz eine Option, alternativ ein synchroner REST-Call.“
Das sind keine fertigen Pflichtenhefte, sondern Diskussionsvorlagen. Architekturgespräche werden früher konkret, und die typische Wartezeit zwischen Fachbereichsfreigabe und Entwicklungsstart schrumpft sichtbar.
Risiken, die im Mittelstand oft unterschätzt werden
Halluzinierte Funktionen im generierten Lastenheft
Ein gut formuliertes Lastenheft sieht plausibel aus, auch dann, wenn es Funktionen enthält, die niemand spezifiziert hat. LLMs füllen Lücken gern mit branchenüblichen Standard-Anforderungen, die im konkreten Vorhaben nichts zu suchen haben: Mehrsprachigkeit für ein internes Werkzeug, Rollen-Berechtigungen für eine Single-User-App, Audit-Logs, die kein Mensch jemals einsehen wird. Jede maschinell generierte Lastenheft-Passage gehört einer expliziten menschlichen Gegenprüfung unterzogen. In der Begeisterung über die gewonnene Geschwindigkeit ist das genau der Schritt, der gestrichen wird. Wer auf Tempo optimiert, ohne den Validierungsschritt zu härten, optimiert auf Halluzinationen.
Dokumentationspflichten gegenüber dem EU AI Act
Fällt das geplante System selbst unter eine Hochrisiko-Kategorie nach Annex III des EU-AI-Acts (Annex III nennt unter anderem Personalauswahl, Bonitätsbewertung, biometrische Identifikation, kritische Infrastruktur und Bildungs-Assessment), greifen ab dem 2. August 2026 verbindliche Dokumentations- und Transparenzpflichten, die in der Anforderungsarbeit beginnen, nicht erst beim Go-Live:Welche Modelle wurden (auch in der Spezifikations-Phase) eingesetzt? Welche Daten flossen in den Modell-Kontext? Welche Annahmen treffen die maschinell generierten Lastenheft-Passagen, die später ins Pflichtenheft kaskadieren? Diese Klauseln gehören in das Lastenheft selbst, nicht erst in das Pflichtenheft, und schon gar nicht in eine Fußnote des Wartungsvertrags.
Außerhalb der Hochrisiko-Kategorien ist die rechtliche Pflicht entspannter, dieselben Klauseln bleiben aber gelebte Sorgfaltspflicht, sobald im Streitfall geklärt werden muss, wer welchen Entwurf zu verantworten hat.
Anbieter-Lock-in auf Modell-Ebene
Sobald die Anforderungs-Arbeit nicht mehr ad hoc, sondern strukturell mit einem Modell-Anbieter verzahnt wird (eigene Prompt-Bibliotheken, Embedding-Indizes über interne Quellen, vendor-spezifische Schnittstellen-Schemata, eigene Setups), entsteht eine Abhängigkeit, die anfangs unsichtbar bleibt, weil alles so reibungslos läuft.
Die Anforderungsdokumente selbst liegen in den meisten Häusern ohnehin in offenen Formaten vor (Word, Confluence, Markdown, SharePoint); das eigentliche Lock-in steckt nicht in den Texten, sondern in der Infrastruktur drumherum. Beim Wechsel des Anbieters müssen in der Regel die Embedding-Schicht neu aufgebaut, die Prompt-Bibliothek neu kalibriert und vendor-spezifische Integrationen umgeschrieben werden.
Für mittelständische Vorhaben lohnt es sich deshalb, diese Bausteine von Anfang an austauschbar zu halten: standardisierte Prompt-Templates, separierbare Embedding-Schichten, offene RAG-Architekturen. In einem Jahr, in dem Modell-Anbieter Preise einseitig anpassen und APIs deprecaten, ist das kein Luxus, sondern Risiko-Management.
Häufig gestellte Fragen
Wie unterscheidet sich ein KI-gestütztes Lastenheft von einem klassisch erstellten?
Inhaltlich gar nicht. Beschrieben wird in beiden Fällen, was das System leisten soll. Der Unterschied liegt im Prozess: Anforderungen entstehen schneller, Lücken werden früher sichtbar, das Dokument bleibt während der Projektlaufzeit auf einem aktuellen Stand. Eine Bedingung bleibt nicht verhandelbar: Jede generierte Passage braucht eine menschliche Validierung. Ohne die ist es kein Lastenheft, sondern ein gut formulierter Vorschlag.
Welche Modelle eignen sich für vertrauliche Anforderungs-Dokumente?
Für vertrauliche Inhalte kommen primär europäische oder selbst gehostete Modelle in Frage, die eine Trainings-Verwendung der eingegebenen Daten vertraglich ausschließen. Open-Source-Modelle wie Mistral oder LLaMA-basierte Varianten, lokal betrieben oder bei einem DSGVO-konformen Hoster, sind eine naheliegende Wahl. Cloud-LLMs sind nur dann tragfähig, wenn der Anbieter die Nicht-Verwendung vertraglich garantiert. Wer das nicht in einem unterschriebenen Vertrag stehen hat, hat es nicht.
Wann lohnt sich der Einsatz für mittelständische IT-Projekte?
Praktisch immer, der Effekt schwankt nur stark in der Größe.
Am deutlichsten ist der Hebel bei Projekten mit hoher Anforderungs-Unschärfe, also dort, wo der Fachbereich noch nicht weiß, was er will, oder wo mehrere Stakeholder mit unterschiedlichen Vorstellungen koordiniert werden müssen. Bei klar umrissenen Standardprojekten, etwa der Anbindung eines weiteren Lieferanten an ein bestehendes ERP, fällt der Mehrwert kleiner aus, ohne zu verschwinden: Auch dort findet ein gut konfiguriertes Modell Lücken im Template, Inkonsistenzen zur bestehenden Lieferantendoku und vergessene Fehlerpfade.
Die Entscheidung ist deshalb keine Ja-oder-Nein-Frage, sondern eine Frage der Dosierung.
