Anforderungen für KI- und datengetriebene Systeme: Spezifizieren, was man nicht vorhersagen kann

2. September 2026· 9 Min. Lesezeit

Klassisches Anforderungsmanagement setzt voraus, dass man „das System muss X tun“ schreiben und dann testen kann, ob es das tut. Maschinelles Lernen bricht diese Annahme: Das Verhalten steht nicht im Code, es entsteht aus Daten — und es ist nie zu 100 % richtig. Man kann nicht schreiben „das Modell muss immer recht haben“.

Das bedeutet nicht, dass ML-Systeme bei den Anforderungen freigestellt sind. Es bedeutet, dass sie eine andere Spezifikationssprache brauchen — eine, die auf messbarer Leistung, Evaluierungsdaten und Fehlerbudgets aufbaut statt auf deterministischen Garantien.

Warum ML die klassische Vorlage bricht

Eine traditionelle Anforderung legt ein explizites, aufzählbares Verhalten fest. Ein Spamfilter, ein Übersetzungsmodell oder ein Defektdetektor hat für eine gegebene Eingabe keine einzelne „richtige“ Ausgabe — er hat eine Wahrscheinlichkeitsverteilung, und Korrektheit ist eine Frage des Grades über eine Population von Eingaben, die man nie gesehen hat.

Der Satz „das System muss genau sein“ ist daher nicht nur vage — er ist ein Kategorienfehler. Genauigkeit bedeutet nur etwas relativ zu einem bestimmten Datensatz und einer bestimmten Definition dessen, was als richtige Antwort zählt.

Die Metrik spezifizieren, nicht den Mechanismus

Die Lösung ist, Anforderungen als messbare Leistungsziele auf definierten Daten zu formulieren, statt als Verhaltensbehauptungen über das Modell. Die Anforderung wird zur Metrik, und die Metrik wird testbar.

Klassifikation: „Das Modell muss auf dem zurückgehaltenen Evaluierungssatz einen F1-Wert ≥ 0,90 erreichen.“
Regression: „Das Modell muss auf den letzten 12 Monaten zurückgehaltener Verbrauchsdaten einen mittleren absoluten Fehler ≤ 5 kWh erreichen.“
Latenz: „Die Inferenz muss bei p95 in unter 100 ms abgeschlossen sein.“
Sicherheit: „Das Modell darf auf keiner Eingabe des adversariellen Testsatzes <Kategorie> ausgeben.“

Der Evaluierungssatz ist Teil der Anforderung

Wenn die Metrik die Anforderung ist, dann ist der Datensatz, auf dem die Metrik gemessen wird, genauso wichtig wie der Satz selbst. Eine Anforderung, die „90 % genau“ sagt, ohne die Daten zu benennen, ist bedeutungslos — Genauigkeit auf dem Trainingssatz ist keine Genauigkeit.

Die Spezifikation muss also die Evaluierungsdaten festlegen: was sie enthalten, wie sie erhoben wurden, wie sie vom Training ferngehalten werden und wie sie versioniert sind. Die Daten sind kein Implementierungsdetail — sie sind die Definition von „korrekt“.

Fehlerbudgets und Drift

Ein ML-System bleibt nicht ewig korrekt — die Welt ändert sich, und das Modell driftet. Anforderungen müssen daher festlegen, was bei nachlassender Leistung zu tun ist:

Eine Leistungsschwelle, die Nachtraining oder Prüfung auslöst.
Ein Überwachungssignal — ein Live-Stellvertreter für die Metrik, nach Zeitplan geprüft.
Ein Fehlerbudget — die akzeptable Rate falscher Ausgaben, mit Reaktion bei Überschreitung.
Ein Rollback-Pfad — die vorherige Modellversion, einsatzbereit gehalten.

Was aus dem klassischen Repertoire weiter funktioniert

Nachverfolgbarkeit, Versionierung und Änderungsmanagement verschwinden nicht — sie ändern ihr Ziel. Man verfolgt eine Anforderung nicht zu einer Funktion, sondern zu einer Metrik, einem Evaluierungssatz und einer Modellversion. Ein „Modellwechsel“ ist eine Anforderungsänderung: Ein neues Modell einzuspielen bedeutet, gegen dieselben zurückgehaltenen Daten erneut zu verifizieren und das zu dokumentieren.

Die Disziplin ist dieselbe. Nur der Gegenstand der Anforderung hat sich geändert — von einem Verhalten, das man aufzählen kann, zu einer Leistung, die man messen muss.

Man kann nicht spezifizieren, was ein ML-System für jede Eingabe tun wird. Man kann spezifizieren, wie gut es sein muss, gemessen auf welchen Daten, und was passiert, wenn es das nicht ist — und das ist eine Anforderung.