Anforderungen an KI-Systeme formulieren: Vom vagen Wunsch zum testbaren Kriterium

Das System soll eingehende Kundenanfragen verstehen und passend beantworten. So oder ähnlich steht es in vielen Anforderungsdokumenten für KI-Vorhaben, und der Satz klingt vernünftig, bis man versucht, ihn zu prüfen. Was heißt verstehen. Was heißt passend. Woran erkennt man am Ende, ob die Anforderung erfüllt ist. Der Dienstleister liest den Satz anders als der Auftraggeber, beide merken es erst bei der Abnahme, und dann streiten zwei Parteien über ein Kriterium, das nie eines war.

Anforderungen an KI-Systeme zu formulieren ist deshalb schwieriger als bei klassischer Software, weil die alten Werkzeuge nur noch teilweise greifen. Ein Lastenheft beschreibt Funktionen, die ein System entweder hat oder nicht hat. KI-Systeme antworten aber probabilistisch: Dieselbe Aufgabe gelingt in vielen Fällen und misslingt in einigen, und die Grenze verschiebt sich mit jedem Modellwechsel. Wer das ignoriert und Anforderungen wie für einen Webshop schreibt, bekommt Dokumente, die Präzision vortäuschen und im Streitfall nichts entscheiden.

Warum klassische Lastenhefte an KI-Systemen scheitern

Ein klassisches Lastenheft lebt von der Formel: Das System muss X können. Diese Formel setzt voraus, dass X eindeutig definierbar ist und dass die Erfüllung binär prüfbar ist. Bei einer Exportfunktion trifft beides zu. Bei der Aufgabe, ein Anschreiben zusammenzufassen oder eine Anfrage der richtigen Kategorie zuzuordnen, trifft beides nicht zu: Es gibt viele richtige Zusammenfassungen, es gibt Grenzfälle zwischen Kategorien, und ein System, das neunzehn von zwanzig Fällen gut löst, kann trotzdem genau am wichtigsten Fall scheitern.

Die Konsequenz ist nicht, auf präzise Anforderungen zu verzichten. Die Konsequenz ist, anders zu präzisieren: nicht über abstrakte Fähigkeitsbeschreibungen, sondern über Beispiele, Quoten und definiertes Verhalten in Zweifelsfällen. Diese drei Bausteine ersetzen das klassische Muss-Kriterium.

Beispielpaare als Kern der Anforderung

Der wirksamste Baustein sind Beispielpaare: konkrete Eingaben mit der jeweils erwarteten Ausgabe. Zwanzig echte Kundenanfragen mit der jeweils korrekten Kategorie sagen mehr über die Anforderung als drei Seiten Prosa, und sie sind später direkt als Prüffälle verwendbar.

Gute Beispielsammlungen haben drei Eigenschaften. Erstens stammen sie aus dem echten Betrieb, nicht vom Schreibtisch, denn ausgedachte Beispiele sind systematisch zu freundlich. Zweitens decken sie bewusst die unangenehmen Fälle ab: unvollständige Eingaben, widersprüchliche Angaben, Grenzfälle zwischen zwei richtigen Antworten. Drittens enthalten sie zu jedem Fall eine kurze Begründung, warum die erwartete Ausgabe die richtige ist. Diese Begründung ist oft wertvoller als das Beispiel selbst, weil sie das implizite Fachwissen sichtbar macht, an dem KI-Projekte sonst vorbeilaufen.

Bei generierenden Aufgaben, etwa Textentwürfen, funktioniert das Prinzip ebenfalls, nur prüft man Eigenschaften statt Wortlaut: Die Antwort muss diese drei Informationen enthalten, darf keine Zusagen über Preise machen, muss auf die Quelle verweisen. Auch das ist testbar, ohne eine einzige exakte Formulierung vorzuschreiben.

Akzeptable Fehlerquoten je Aufgabentyp

Der zweite Baustein ist die ehrliche Antwort auf eine unbequeme Frage: Wie viele Fehler sind tragbar. Ein KI-System ohne Fehler gibt es nicht, also muss die Anforderung festlegen, welche Fehlerhäufigkeit für welchen Aufgabentyp akzeptabel ist. Diese Festlegung ist eine Geschäftsentscheidung, denn sie hängt davon ab, was ein Fehler kostet und ob ihn jemand abfängt.

Dabei hilft eine einfache Unterscheidung: Aufgaben, deren Ergebnis ein Mensch ohnehin prüft, vertragen eine höhere Fehlerquote, weil der Schaden eines Fehlers eine kurze Korrektur ist. Aufgaben, deren Ergebnis ungeprüft nach außen geht oder eine Folgeaktion auslöst, vertragen fast keine. Wichtig ist außerdem, Fehlerarten zu trennen. Bei einer Dokumentenprüfung ist ein übersehener Problemfall meist deutlich teurer als ein fälschlich markierter unproblematischer Fall. Eine Anforderung, die nur eine Gesamtquote nennt, erlaubt dem System, den billigen Fehler gegen den teuren zu tauschen, ohne die Anforderung zu verletzen.

Verhalten bei Unsicherheit und die Grenzen des Systems

Der dritte Baustein wird am häufigsten vergessen: Was soll das System tun, wenn es sich nicht sicher ist oder die Eingabe außerhalb seines Auftrags liegt. Ohne Vorgabe produziert ein KI-System auch in solchen Fällen eine flüssige, überzeugend klingende Antwort, und genau das ist das Risiko. Die Anforderung muss deshalb definieren: In welchen Situationen soll das System die Bearbeitung ablehnen, an einen Menschen übergeben oder ausdrücklich kennzeichnen, dass es unsicher ist. Ein System, das zuverlässig weiß, wann es nichts weiß, ist in der Praxis wertvoller als eines, das im Durchschnitt etwas genauer rät.

Ebenso wichtig ist die Negativabgrenzung: eine explizite Liste dessen, was das System nicht können muss. Keine Fremdsprachen außer den zwei genannten, keine handschriftlichen Dokumente, keine Rechtsauskünfte. Jede dieser Zeilen spart Aufwand, verhindert Diskussionen bei der Abnahme und schützt vor dem schleichenden Wachstum des Auftrags während des Projekts.

Eine Vorlage für die Dokumentation ohne KI-Vorwissen

Ein KMU braucht für all das kein spezialisiertes Werkzeug. Ein Dokument mit fünf Abschnitten genügt und lässt sich ohne KI-Vorwissen befüllen:

Abschnitt	Inhalt	Leitfrage
Aufgabe	Der Prozessschritt in zwei, drei Sätzen	Was passiert heute manuell
Beispielpaare	Zwanzig oder mehr echte Fälle mit erwarteter Ausgabe und Begründung	Woran erkennt ein erfahrener Kollege die richtige Antwort
Fehlertoleranz	Akzeptable Quote je Fehlerart	Welcher Fehler kostet was, wer fängt ihn ab
Unsicherheit	Verhalten bei Zweifel und bei fremden Eingaben	Wann soll das System an einen Menschen übergeben
Nicht-Ziele	Was das System nicht können muss	Was lassen wir bewusst weg

Die Beispielpaare sind der aufwendigste Teil, und sie sind Aufgabe des Fachbereichs, nicht des Dienstleisters. Wer sie vor dem ersten Anbietergespräch zusammenstellt, führt diese Gespräche auf einem anderen Niveau: Der Anbieter kann konkret einschätzen, was machbar ist, und das Unternehmen kann Angebote an denselben Fällen vergleichen.

Fazit

Anforderungen an KI-Systeme werden nicht dadurch präzise, dass man sie länger formuliert, sondern dadurch, dass man sie testbar macht. Beispielpaare aus echten Fällen ersetzen abstrakte Fähigkeitsbeschreibungen, Fehlerquoten je Aufgabentyp ersetzen das binäre Muss-Kriterium, definiertes Verhalten bei Unsicherheit schließt die gefährlichste Lücke, und die Liste der Nicht-Ziele hält den Auftrag beisammen. Ein solches Dokument passt auf wenige Seiten und verlangt kein KI-Vorwissen, nur ehrliche Auseinandersetzung mit dem eigenen Prozess. Genau daran entscheidet sich später, ob die Abnahme ein Abgleich ist oder ein Streit.