Das Ende des klassischen „Given-When-Then“
Egal, ob klassisch im Lastenheft oder agil im Product Backlog: Jahrzehntelang basierte Requirements Engineering auf dem beruhigenden Prinzip des Determinismus. Eine gute Anforderung beschreibt das Systemverhalten als eindeutige Funktion. In der agilen Welt bringen Akzeptanzkriterien nach dem bekannten Given-When-ThenMechanismen und Regeln, die das Verhalten eines KI-Systems begrenzen und kontrollieren. Sie legen beispielsweise fest, welche Inhalte eine KI erzeugen darf, welche Anfragen sie ablehnen muss oder wann eine menschliche Freigabe erforderlich ist.Schema diese Logik prägnant auf den Punkt: „Angenommen X, wenn Y passiert, dann führt das System genau Z aus.“
Sobald Künstliche Intelligenz ins Spiel kommt, bricht dieses Denkmodell jedoch zusammen. Ein Machine-Learning-Modell (ML) wird nicht mehr Zeile für Zeile programmiert. Sein Verhalten entsteht stattdessen aus Trainingsdaten, Modellarchitektur und Lernverfahren. Deshalb lässt sich für einen einzelnen Eingabefall vorab kein eindeutiges, starres Thesenpapier formulieren. Stattdessen können wir nur festlegen, mit welcher statistischen Güte, innerhalb welcher Grenzen und unter welchen Randbedingungen sich das System verhalten muss.
Genau an dieser Schnittstelle greift der EU AI Act ein. Was bisher eine methodische Herausforderung im Team war, wird nun zur rechtlichen Verpflichtung: Die EU-Verordnung fordert für Hochrisiko-KI-Systeme nachweisbare Qualität, Transparenz, Robustheit, menschliche Aufsicht und lückenlose Rückverfolgbarkeit über den gesamten Lebenszyklus.
Der eigentliche Paradigmenwechsel reicht jedoch noch tiefer: Während die Spezifikation im klassischen Engineering das Verhalten direkt beschreibt, definiert sie bei KI-Systemen zunehmend die Eigenschaften der Daten, aus denen dieses Verhalten überhaupt erst entsteht. Der bekannte Leitsatz „Code is Specification” wird somit durch eine neue Realität abgelöst: Daten sind die neuen Spezifikationen.
Vom deterministischen Verhalten zum zulässigen Verhaltensraum
Klassische Anforderungen diktieren konkrete Funktionen. Das System berechnet… Das System speichert… Das System sendet…
KI-Anforderungen spannen dagegen einen zulässigen Verhaltensraum1 auf. Anstatt jede einzelne Entscheidung des Modells vorab festzuschreiben, legen Sie präzise fest:
- mit welchen Daten das Modell trainiert und validiert werden darf,
- welche statistische Mindestleistung im Einsatz erreicht werden muss,
- welche Fehlerrisiken akzeptabel sind und wo die Einsatzgrenzen liegen,
- und wie das System im Moment von Unsicherheit reagieren muss.
Der Schwerpunkt des Requirements Engineerings verschiebt sich damit von der reinen Funktionsbeschreibung hin zur Definition von Qualitätsgrenzen, Datenanforderungen und Governance-Regeln. Da die Qualität der Trainingsdaten die spätere Systemqualität unmittelbar bestimmt, wird die Datenanalyse zum festen Bestandteil der Spezifikation.
Der EU AI Act stuft Daten als Engineering-Artefakte ein
Gemäß Artikel 10 des EU AI Acts müssen Trainings-, Validierungs- und Testdaten strengen Qualitätsanforderungen genügen: Sie müssen relevant, repräsentativ und möglichst fehlerfrei sein, sowie dokumentiert und nachvollziehbar verwaltet werden. Dadurch werden Datensätze zu vollwertigen Artefakten, die denselben Stellenwert wie Anforderungen, Architekturmodelle oder Testfälle besitzen.
Für Requirements Engineers bedeutet dies einen grundlegenden Rollenwechsel: Daten sind kein internes Implementierungsdetail der Data Scientists mehr, sondern werden Teil der Spezifikation. Zu modernen KI-Anforderungen gehören deshalb:
- Dokumentierte Datenherkunft (Data Lineage): Lückenloser Nachweis über Ursprung und Transformation der Datensätze.
- Repräsentativität: Vorgaben zu den realen Einsatzszenarien (z. B. Abdeckung verschiedener Sensorauflösungen oder Umgebungsbedingungen), die im Datensatz enthalten sein müssen.
- Bias-Grenzwerte: Definierte Schwellenwerte zur Vermeidung statistischer Einseitigkeit.
- Versionierung: Dokumentierte Regeln für das Änderungsmanagement von Datensätzen.
Damit etablieren sich Data Requirements2 als eigenständige, unverzichtbare Klasse von Anforderungen.
Von Funktionsanforderungen zu Risikokontrollen
Der EU AI Act verfolgt einen konsequent risikobasierten Ansatz. Risiken werden nicht erst im Betrieb isoliert betrachtet, sondern fließen bereits bei der Spezifikation systematisch ein: Jede Risikoanalyse führt unmittelbar zu neuen, konkreten Systemanforderungen.
Dazu gehören beispielsweise Vorgaben für menschliche Eingriffe, Nachvollziehbarkeit, Robustheit und Monitoring. Anforderungen beschreiben damit nicht mehr nur Funktionen, sondern werden zugleich zu Kontrollmechanismen für KI-Risiken.
→ Warum der EU AI Act das klassische Risikomanagement sprengt, lesen Sie demnächst auf unserem Blog.
Statistische Leistungsanforderungen statt binärer Korrektheit
Ein Machine-Learning-System ist selten einfach nur 100 % „richtig“ oder „falsch“. Seine Güte bemisst sich in mathematischen Wahrscheinlichkeiten. Anforderungen an KI-Systeme benötigen messbare statistische Zielwerte, beispielsweise für Precision und Recall.
Beispiel: „Das Bilderkennungssystem muss auf dem freigegebenen Testdatensatz ‘Dataset_V3’ eine Precision von mindestens 99,2 % bei einem Recall von mindestens 98,5 % erreichen.“
Ebenso wichtig ist die Spezifikation der Evaluierungsdaten: Eine statistische Metrik ist wertlos, wenn nicht exakt dokumentiert ist, auf welchem Testdatensatz sie ermittelt wurde.
Nichtfunktionale KI-Qualitätsattribute und das Prinzip „Unsicherheit“
Besonders wichtig sind Anforderungen an das Verhalten bei Unsicherheit. KI-Systeme benötigen klare Grenzen, ab wann eine automatische Entscheidung zulässig ist und wann ein Mensch eingreifen muss.
Beispiel: „Das Qualitätssicherungssystem darf Bauteile nur automatisch freigeben, wenn das Konfidenzniveau mindestens 90 % beträgt. Unterhalb dieses Werts muss eine manuelle Prüfung erfolgen.“
So wird die geforderte menschliche Aufsicht zu einer konkret prüfbaren Anforderung.
Auch generative KI benötigt spezifizierbare Anforderungen
Die gleichen Grundsätze gelten auch für generative KI. Hier können beispielsweise Qualitätsanforderungen an Grounding3, Guardrails4 oder menschliche Freigaben formuliert werden. Auch Prompts und ihre Versionen sollten bei geschäftskritischen Anwendungen nachvollziehbar verwaltet werden.
Entscheidend bleibt das gleiche Prinzip: Alle Faktoren, die das Verhalten des KI-Systems wesentlich beeinflussen, müssen spezifizierbar und rückverfolgbar sein.
Akzeptanzkriterien neu gedacht: Kontinuierliche Evaluierung
Im klassischen Requirements Engineering gilt eine Anforderung nach bestandenem Testfall als abgehakt. Bei KI-Systemen beginnt die Arbeit hier erst: Modelle altern, reale Daten verändern sich und Nutzungsmuster verschieben sich im Laufe der Zeit. Phänomene wie Data Drift oder Concept Drift5 führen dazu, dass ein ursprünglich perfekt validiertes Modell im laufenden Betrieb schleichend an Genauigkeit verliert.
Akzeptanzkriterien müssen deshalb auch festlegen,
- wann Modelle auf aktuellen Felddaten erneut validiert werden und
- welche Schwellenwerte Monitoring, erneutes Training oder eine Neufreigabe auslösen.
Die Abnahme einer KI-Anforderung wandelt sich damit von einem einmaligen Haken zum kontinuierlichen Qualitätsprozess.
Logging und Audit Evidence als Anforderungsbausteine
Bei Hochrisiko-KI wird Logging zum Bestandteil der Spezifikation. Dabei müssen Modell- und Datensatzversionen, relevante Eingaben, Konfidenzwerte, Entscheidungen und menschliche Eingriffe nachvollziehbar dokumentiert werden. Auf Basis dieser Informationen können Audits, Fehleranalysen und Konformitätsnachweise durchgeführt werden.
Neue Normen schaffen methodischen Halt
Während der EU AI Act vorgibt, was erreicht werden muss, liefern internationale Standards das methodische Wie. Die wichtigsten Orientierungspunkte für Requirements Engineers sind beispielsweise:
- ISO/IEC 42001 für KI-Managementsysteme,
- ISO/IEC 5338 für den KI-Lebenszyklus und
- ISO/IEC 25059 für KI-spezifische Qualitätsmerkmale.
Gemeinsam schlagen diese Normen die Brücke zwischen regulatorischen Gesetzen und der täglichen Engineering-Praxis.
Die neue Traceability-Kette für KI-Systeme
Je mehr Anforderungen, Datensätze, Modellversionen, Risiken und Tests miteinander zusammenhängen, desto schwieriger wird es, diese Beziehungen mit Excel und Word zuverlässig nachzuhalten.
Für klassische Software reichte die gewohnte Kette (Anforderungen Architektur Tests) aus. Für ein auditierbares KI-System unter dem EU AI Act muss die Rückverfolgbarkeit um alle daten- und modellbezogenen Artefakte erweitert werden:

Erst diese lückenlose Vernetzung beweist einem Auditor zweifelsfrei, auf welchen Daten und Validierungen eine konkrete KI-Entscheidung beruhte. Bricht diese Kette an einer Stelle, etwa weil ein Datensatz unvollständig dokumentiert ist, entstehen sofort gravierende Haftungs- und Compliance-Risiken.
KI-Anforderungen in objectiF RPM beherrschen
Diese Fülle an neuen Artefakten und hochdynamischen Abhängigkeiten lässt sich mit manuellen Excel-Tabellen oder statischen Word-Dokumenten nicht mehr beherrschen.
Werkzeuge wie objectiF RPM ermöglichen es, KI-Spezifikationen als lebendige, vernetzte Artefakte im Entwicklungsalltag zu führen:
- Spezifische Anforderungstypen: Definieren Sie eigene Artefakte für Data Requirements, Modellanforderungen, Prompt-Spezifikationen und Risikokontrollen.
- Strukturierte Qualitätsmetriken: Verwalten Sie statistische Schwellenwerte zentral und koppeln Sie diese an Testfälle.
- Automatisierte Traceability: Verknüpfen Sie Anforderungen direkt mit KI-Modellen, Datensatz-Versionen und Testberichten.
| Tech-Glossar: Die Schlüsselbegriffe auf einen Blick
Verhaltensraum1: Die Gesamtheit aller zulässigen Leistungsgrenzen, Konfidenzschwellen und Qualitätsmetriken, innerhalb derer sich ein probabilistisches KI-System bewegen darf. Data Requirements2: Eine eigenständige Anforderungsklasse, die Qualitätsmerkmale von Trainings-, Validierungs- und Testdaten (z. B. Repräsentativität, Herkunft, Bias-Grenzwerte) als verbindliche Systemanforderung spezifiziert. Grounding3: Das gezielte Verankern der Ausgaben von generativer KI oder Large Language Models in verifizierten, internen Wissensquellen (z. B. via RAG), um Halluzinationen zu verhindern. Guardrails4: Mechanismen und Regeln, die das Verhalten eines KI-Systems begrenzen und kontrollieren. Sie legen beispielsweise fest, welche Inhalte eine KI erzeugen darf, welche Anfragen sie ablehnen muss oder wann eine menschliche Freigabe erforderlich ist. Concept Drift5: Die schleichende Veränderung der statistischen Beziehung zwischen den Eingangsdaten und der Zielvariablen im laufenden Betrieb, wodurch ein Modell an Vorhersagegenauigkeit verliert. |
Fazit
Der EU AI Act erweitert das Requirements Engineering für KI-Systeme erheblich. Neben Funktionen müssen Sie nun auch die Datenqualität, Leistungsgrenzen, Risiken, menschliche Eingriffe und Nachweise als überprüfbare Anforderungen behandeln.
Dadurch wächst zugleich die Zahl der Artefakte und Abhängigkeiten. Deshalb ist eine durchgängige Traceability von der Anforderung über Daten und Modell bis zu Test und Betrieb entscheidend.
Genau hierbei unterstützt Sie objectiF RPM. Sie können KI-Anforderungen strukturiert erfassen, miteinander verknüpfen und Änderungen nachvollziehbar verwalten.
Möchten Sie Ihr Requirements Engineering rechtssicher für KI-Systeme aufstellen?
Erfahren Sie in einer individuellen Live-Präsentation, wie Sie mit objectiF RPM erweiterte KI-Anforderungen strukturieren, Daten-Artefakte einbinden und Traceability sicherstellen.


