Lastenheft und Pflichtenheft sind das Rückgrat deutscher Projektverträge: Der Auftraggeber schreibt auf, was er braucht, der Auftragnehmer schreibt auf, wie er liefert, und die Abnahme erfolgt gegen das zweite Dokument. Das Modell funktioniert, weil klassische Software deterministisch ist, bei Eingabe X kann die Spezifikation Ausgabe Y verlangen, immer. KI-Systeme verweigern diesen Deal. Ein Modell, das in 94% der Fälle richtig liegt, ist ein Erfolg oder ein Rechtsstreit, je nachdem, wie die Spezifikation geschrieben wurde. Dieser Artikel erklärt beide Dokumente kurz, zeigt präzise, wo probabilistisches Verhalten die klassische Logik bricht, und liefert Spezifikationsmuster, die die Funktion der Dokumente, klare Verantwortlichkeit, erhalten, ohne so zu tun, als wäre das System deterministisch.
Die zwei Dokumente, kurz erklärt
Das Begriffspaar teilt die Anforderungen in ein auftraggeber- und ein auftragnehmereigenes Dokument, und genau diese Teilung macht es stark, wenn sie funktioniert.
| Lastenheft | Pflichtenheft | |
|---|---|---|
| Eigentümer | Auftraggeber | Auftragnehmer (vom Auftraggeber freigegeben) |
| Beantwortete Frage | Was gebraucht wird, und warum | Wie konkret geliefert wird |
| Detailtiefe | Ziele, Anforderungen, Rahmenbedingungen | Lösungsdesign, Funktionen, technisches Detail |
| Rechtliche Rolle | Grundlage der Ausschreibung / des Vertragsumfangs | Grundlage für Abnahme und Gewährleistungsansprüche |
| Klassische Annahme | Anforderungen sind vorab vollständig erfassbar | Verhalten lässt sich exakt spezifizieren und je Einzelfall prüfen |
Wo probabilistische Systeme die klassische Spezifikationslogik brechen
Jeder dieser Bruchpunkte hat branchenweit schon reale Projektstreitigkeiten erzeugt. Sie lohnen sich als Checkliste gegen Ihren aktuellen Entwurf.
- 1Keine Einzelfall-Garantien: „Bei Eingabe X liefert das System Y“ ist nicht schreibbar, wenn dieselbe Eingabe legitim unterschiedliche, gelegentlich falsche Ausgaben erzeugen kann. Ehrlich sind nur Aggregat-Aussagen über definierte Testmengen.
- 2Abnahme wird Messung: Die Abnahme gegen eine KI-Spezifikation ist ein Evaluationslauf, also müssen Testdaten, Metriken und Verfahren selbst spezifiziert, versioniert und vereinbart sein, sonst ist die Abnahme willkürlich.
- 3Anforderungen verschieben sich mit den Daten: Was erreichbar ist, hängt von der Datenqualität ab, die erst im Projekt entdeckt wird, eine vor der Datenexploration eingefrorene Spezifikation ist Fiktion mit Unterschriften.
- 4Verhalten driftet nach der Abnahme: Modelle degradieren, wenn sich die Welt ändert, eine Spezifikation, die mit der Abnahme endet, ignoriert die Phase mit dem größten KI-Risiko; Monitoring- und Retraining-Pflichten gehören ins Pflichtenheft.
- 5„Fehler“ braucht eine Definition: Eine Fehlklassifikation innerhalb der vereinbarten Fehlerrate ist kein Mangel im Gewährleistungssinn, und die Dokumente müssen das explizit sagen, sonst wird jeder Treffer daneben zum Anspruch.
Abnahmekriterien für Modellverhalten formulieren
Das Muster: deterministische Klauseln für Grenzen, statistische Klauseln für Qualität, und ein spezifiziertes Evaluationsverfahren, das die statistischen Klauseln prüfbar macht. Die Tabelle stellt klassische Klauseln neben ihre KI-tauglichen Umformulierungen.
| Klassische Klausel (bricht mit KI) | KI-taugliche Klausel |
|---|---|
| „Das System klassifiziert eingehende Dokumente korrekt“ | „Macro-F1 >= 0,90 auf der eingefrorenen Testmenge TS-v1.2 (5.000 Dokumente, stratifiziert, gemeinsam freigegeben); Evaluationsskript und Seed im Repository versioniert“ |
| „Der Chatbot beantwortet Kundenfragen korrekt“ | „Auf dem vereinbarten 300-Fragen-Eval-Set >= 92% der Antworten nach definierter Rubrik von zwei unabhängigen Bewerter:innen als korrekt eingestuft; null Antworten, die gegen die Sperrthemen-Liste verstoßen (hartes Kriterium)“ |
| „Das System antwortet innerhalb von 2 Sekunden“ | Klassisch belassen: Latenz, Verfügbarkeit und Kosten pro Anfrage bleiben deterministische Klauseln, p95-Latenz <= 2s unter definierter Last |
| „Mängel werden innerhalb der Gewährleistung behoben“ | „Ein Qualitätsabfall unter den Schwellenwert der vereinbarten Monitoring-Metrik an 7 aufeinanderfolgenden Tagen löst den Nachbesserungsprozess nach Abschnitt X aus; Fehlklassifikationen innerhalb der vereinbarten Fehlerrate sind keine Mängel“ |
Iterative Spezifikationsmuster, die die Dokumente brauchbar halten
Das Ziel ist nicht, die Lastenheft-/Pflichtenheft-Disziplin aufzugeben, sondern sie zu phasieren. Diese Muster sind vertragskompatibel und branchenweit in Varianten im Einsatz.
- 1Zweistufiges Pflichtenheft: eine verbindliche Fassung nach der Datenexplorations-Phase, nicht davor; der Vertrag vor der Exploration umfasst nur die Exploration selbst, mit definierten Ergebnissen (Datenreport, Machbarkeitseinschätzung, Vorschlag für Zielmetriken).
- 2Korridor-Ziele statt Punkt-Ziele: Das Lastenheft nennt ein minimal akzeptables und ein Ziel-Qualitätsniveau; eine Landung dazwischen löst eine vorab vereinbarte Preis-/Scope-Anpassung aus statt eines Streits.
- 3Eingefrorene Eval-Sets als Vertragsanlagen: Testdaten, Metrik-Definitionen und Evaluationsskripte sind versionierte Anlagen; Änderungen laufen als Change Request wie jede andere Vertragsänderung.
- 4Gestufte Abnahme-Gates: getrennte Teilabnahmen für Datenpipeline, Offline-Modellqualität, Verhalten in der Pilotphase und Produktionsstabilität nach N Wochen, jeweils mit eigenen Kriterien und eigener Freigabe.
- 5Living-Document-Klausel: ein definierter Takt (etwa quartalsweise), in dem beide Seiten Monitoring-Ergebnisse gegen die Spezifikation prüfen und Schwellenwerte formal aktualisieren, mit benannten Verantwortlichen auf beiden Seiten.
Ein ausgefülltes Miniaturbeispiel
Ein illustrativer Auszug aus einem KI-angepassten Dokumentenpaar für ein fiktives Rechnungsverarbeitungs-Projekt, der zeigt, wie klassische und statistische Klauseln nebeneinander stehen.
| Dokument | Klausel (verdichtet) | Typ |
|---|---|---|
| Lastenheft | Die manuelle Rechnungserfassung (derzeit ca. 3 FTE, fiktive Zahl) soll um mindestens 60% sinken, ohne dass die Buchungsfehlerquote steigt | Geschäftsziel |
| Lastenheft | Rechnungen, die das System nicht sicher verarbeiten kann, müssen in eine menschliche Queue laufen, nie in die Auto-Buchung | Harte Grenze |
| Pflichtenheft | Extraktionsgenauigkeit auf Feldebene >= 97% auf der eingefrorenen Testmenge TS-A (2.000 Rechnungen, gemeinsam gezogen); Konfidenz-Schwelle so eingestellt, dass auto-gebuchte Rechnungen >= 99,5% Feldgenauigkeit erreichen | Statistisch |
| Pflichtenheft | Dokumente unter der Konfidenz-Schwelle werden innerhalb von 5 Sekunden markiert und eingereiht; kein Dokument wird ohne die Validierungsregeln V1-V14 auto-gebucht | Deterministisch |
| Pflichtenheft | Wöchentlicher Monitoring-Report zur Extraktionsgenauigkeit auf einer rollierenden gelabelten Stichprobe; zwei Wochen in Folge unter 95% lösen den Nachbesserungsprozess aus | Nach der Abnahme |
Typische Fehler in KI-Spezifikationen
- 1Einen Festpreis-Vertrag mit eingefrorener Spezifikation unterschreiben, bevor jemand die Daten gesehen hat: die häufigste Wurzel von KI-Projektstreitigkeiten.
- 2Qualitätsziele ohne spezifizierte Testmenge und Verfahren formulieren, das macht die Abnahme zur Verhandlung statt zur Messung.
- 3Sicherheitsgrenzen in den statistischen Teil schreiben: Was das System nie tun darf, gehört in deterministische Klauseln mit Null-Toleranz-Tests.
- 4Das Pflichtenheft mit der Abnahme enden lassen: keine Monitoring-Metriken, keine Drift-Schwellen, kein benannter Betreiber, die riskanteste Phase bleibt unspezifiziert.
- 5Dem Auftragnehmer die Testdaten allein überlassen: Eval-Sets müssen gemeinsam freigegeben und eingefroren sein, sonst lässt sich die Spezifikation von beiden Seiten austricksen.
