Wann ist ein KI-System gut genug?

Abnahme ist in klassischer Software eine bekannte Disziplin. Anforderungen werden beschrieben, Testfälle werden geprüft, Fehler werden priorisiert, Änderungen laufen durch Regression. In frühen KI-Projekten gerät diese Logik leicht in den Hintergrund. Dann entsteht ein anderes Ritual: Das System wirkt gut, die Beispiele sind plausibel, die Demo überzeugt, also wird aus dem Pilot ein Rollout.

Genau dort entsteht das Risiko. Ein KI-System kann in zehn sichtbaren Fällen hilfreich sein und im elften Fall einen relevanten Fehler produzieren. Es kann im Pilot stabil wirken und nach einem Prompt-, Modell-, Daten- oder Tool-Wechsel anders reagieren. Es kann im Durchschnitt gut sein und gerade in den Fällen scheitern, die geschäftlich oder regulatorisch kritisch sind.

Evaluation wird damit zur Abnahmedisziplin für KI. Sie verbindet den Business Case, die Governance, die Modellstrategie, die Adoption in der Linie und den späteren Betrieb. Ohne Evaluation bleibt offen, ob das System nur beeindruckt oder belastbar arbeitet.

1. Gut genug vor dem Pilot definieren

Die wichtigste Evaluationsentscheidung fällt vor dem Pilot. Nicht nach der Demo, nicht im Rollout, nicht bei der ersten Eskalation. Vor dem Start muss feststehen, welche Qualität für diesen konkreten Use Case nötig ist.

Für einen internen Schreibassistenten kann ein Fehler harmlos sein, wenn ein Mensch den Text ohnehin vollständig prüft. Für eine Vertragsanalyse, eine Kreditvorbereitung, einen HR-Prozess, eine medizinische Triage oder einen Agenten mit Schreibrechten ist dieselbe Fehlerlogik nicht vertretbar. Entscheidend ist, welche Restfehler das Unternehmen tragen kann und welche zwingend verhindert, erkannt oder eskaliert werden müssen.

Damit wird Evaluation zur Geschäftsentscheidung. Fachbereich, IT, Risk, Compliance und CFO müssen nicht dieselben Details prüfen. Aber sie brauchen dieselbe Abnahmelogik: Zweck, Risikoklasse, Qualitätsziel, Fehlerschwellen, Eskalationsregeln und Betriebsaufwand.

2. Golden Set statt Demo-Fälle

Allgemeine Modellbenchmarks helfen bei der Marktbeobachtung. Sie ersetzen keine Abnahme im eigenen Unternehmen. Entscheidend ist ein Golden Set: ein kuratiertes Prüfset aus echten oder realistisch nachgebildeten Aufgaben, Dokumenten, Fällen und Grenzsituationen des geplanten Einsatzes.

Für die frühe Auswahl reicht als Sixtyfour-Umsetzungsheuristik zunächst ein Set aus fünf bis zehn priorisierten Geschäftstasks, um Modellkandidaten, Architekturvarianten oder Prompt-Ansätze gegeneinander zu stellen. Für die Abnahme vor Produktivsetzung muss das Set breiter werden: typische Fälle, seltene kritische Fälle, schlechte Eingaben, unvollständige Informationen, vertrauliche Inhalte, Quellenkonflikte, Prompt-Injection-Versuche, Ablehnungsfälle und bekannte Fehlerklassen aus dem Pilot.

Ein gutes Golden Set prüft neben der sprachlichen Plausibilität auch Aufgabe, Faktentreue, Quellenbindung, Unsicherheit, erlaubte Handlung, Datenschutz, Sprache, Format und Eskalation. Bei RAG-Systemen gehört die Frage dazu, ob die Antwort aus den freigegebenen Quellen ableitbar ist. Bei Agenten gehört dazu, ob der Weg zur Antwort vertretbar war: Welche Tools wurden genutzt, welche Zwischenschritte wurden ausgelöst, welche Rechte wurden berührt?

3. Der Fachbereich bewertet

KI-Qualität ist fachlich. Ein Modell kann formal gut antworten und trotzdem eine relevante juristische, kaufmännische, technische oder operative Nuance verfehlen. Die Abnahme darf deshalb nicht vollständig an IT, Anbieter oder automatische Scores delegiert werden.

Der Fachbereich muss bewerten, ob die Antwort im Prozess brauchbar ist. Dafür braucht es einfache, wiederholbare Kriterien: korrekt, teilweise korrekt, falsch, nicht entscheidbar; vollständig oder unvollständig; nutzbar ohne Nacharbeit, nutzbar mit Nacharbeit, nicht nutzbar; zwingend eskalationspflichtig oder unkritisch.

Automatisierte Bewertung kann helfen, vor allem bei großen Fallzahlen oder regelmäßiger Regression. LLM-as-Judge, regelbasierte Checks, Quellenprüfungen und Vergleichsmetriken sind nützliche Werkzeuge. Sie ersetzen aber nicht die fachliche Kalibrierung. Gerade am Anfang braucht es menschliche Doppelbewertungen, Diskussion strittiger Fälle und eine klare Definition, was als Fehler zählt.

4. Komponenten und Strecke prüfen

In frühen Tests wird häufig nur der Output betrachtet. Für einfache Assistenzfälle kann das genügen. Bei produktionsnahen KI-Systemen muss die Abnahme die Strecke prüfen: Eingabe, Kontextaufbau, Retrieval, Prompt, Modell, Tool-Nutzung, Antwort, Freigabe und Logging.

Das gilt besonders für Agenten. Ein Agent kann die richtige Antwort liefern und trotzdem einen falschen Weg genommen haben: zu breite Suche, unnötiger Datenzugriff, falsche Tool-Reihenfolge, unklare Zustimmung, unzulässige Schreibaktion. Deshalb braucht Agentenprüfung neben Output-Tests auch Trajectory-Tests: Welche Entscheidungsschritte wurden durchlaufen, welche Abzweigungen waren erlaubt, wo hätte das System stoppen müssen?

Für RAG-Systeme ist die Kernfrage anders: Wurde die richtige Quelle gefunden? Wurde sie richtig verstanden? Hat das System sauber getrennt zwischen Quelle, Schlussfolgerung und Unsicherheit? Hat es bei fehlender Evidenz abgelehnt oder trotzdem plausibel weitergeschrieben?

5. Jede Änderung braucht Regression

Ein KI-System bleibt nicht gleich. Prompts werden angepasst, Modelle werden aktualisiert, Dokumente kommen hinzu, Embeddings ändern sich, Tools erhalten neue Rechte, Anbieter ändern Produktverhalten. Jede dieser Änderungen kann Qualität, Kosten, Latenz, Sicherheit oder Fehlermuster verändern.

Deshalb braucht die Abnahme einen Baseline-Zustand. Welche Modellversion, welcher Prompt, welche Datenbasis, welche Tool-Rechte, welche Systemparameter und welche Bewertungslogik wurden freigegeben? Wenn sich etwas davon ändert, läuft das Golden Set erneut. Der Zweck ist Schutz gegen schleichende Verschlechterung, keine akademische Testübung.

Regression heißt nicht, dass jede kleine Änderung ein Großprojekt auslöst. Die Prüftiefe folgt dem Risiko. Ein interner Textassistent braucht andere Schwellen als ein Agent mit externen Auswirkungen. Aber ohne Versionierung und Vergleichspunkt gibt es keine belastbare Aussage, ob das System nach der Änderung besser, schlechter oder nur anders geworden ist.

6. Betriebsmessung nach dem Go-live

Abnahme endet nicht mit Produktivsetzung. Im Betrieb ändern sich Nutzung, Daten, Nutzerverhalten und Fehlerlandschaft. Gute Systeme brauchen deshalb Stichproben, Monitoring und klare Eskalation. Maßgeblich ist, ob das System in realer Nutzung weiter innerhalb der akzeptierten Schwellen arbeitet.

Zur Betriebsmessung gehören mindestens Nutzungsvolumen, Fehlertypen, Override-Rate, Eskalationsrate, manuelle Nacharbeit, Kosten pro Vorgang, Latenz, Beschwerden, Incident-Meldungen und Stichprobenqualität. Bei höherem Risiko kommen Audit Trail, Stopprecht, Incident-Flow und Wiederinbetriebnahmeentscheidung hinzu.

Diese Messung verbindet Evaluation mit Adoption. Hohe Nutzung ist kein Erfolg, wenn die Nacharbeit steigt oder kritische Fehler unbemerkt bleiben. Niedrige Nutzung ist kein reines Schulungsthema, wenn der Fachbereich dem System fachlich nicht traut. Qualität, Vertrauen und Prozesswirkung müssen zusammen gelesen werden.

7. Kontrollaufwand gehört in den Business Case

Evaluation kostet Zeit. Fachliche Prüfer müssen Fälle bewerten, IT muss Versionen halten, Risk und Compliance müssen Schwellen verstehen, Betrieb muss Stichproben und Eskalationen organisieren. Dieser Aufwand gehört zu den Kosten des Systems.

Gerade deshalb gehört Evaluation früh in die Wirtschaftlichkeitsrechnung. Wenn der Kontrollaufwand den erwarteten Nutzen auffrisst, liefert die Evaluation eine wichtige Erkenntnis über den Use Case. Manche Fälle sind technisch möglich, aber wirtschaftlich nicht sinnvoll zu betreiben. Andere Fälle werden erst durch gute Evaluation breiter einsetzbar, weil Qualität, Verantwortung und Änderungsmanagement nicht jedes Mal neu verhandelt werden müssen.

Der Managementfehler wäre, Evaluation als Bremse zu betrachten. Sie ist der Mechanismus, der aus einem Pilot eine vertretbare Betriebsentscheidung macht.

Entscheidungsvorlage für die Abnahme

Eine Abnahmevorlage muss kurz genug sein, um benutzt zu werden. Sie sollte die harten Führungsfragen sichtbar machen und technische Details nur dort aufnehmen, wo sie die Entscheidung verändern.

Feld	Leitfrage	Stoppsignal
Zweck Use Case und Wirkung	Welche Aufgabe wird unterstützt, vorbereitet oder automatisiert?	Der Fall ist als Tool-Funktion beschrieben, nicht als Prozessverantwortung.
Qualität Fehler und Schwellen	Welche Fehler sind tolerierbar, welche müssen erkannt, verhindert oder eskaliert werden?	Es gibt nur eine allgemeine Zielgröße wie „hohe Genauigkeit“.
Golden Set Eigene Testfälle	Welche realistischen Fälle, Grenzfälle und Fehlerklassen prüft das System vor Freigabe?	Die Abnahme beruht auf Demo-Beispielen oder Anbieter-Benchmarks.
Bewertung Fachbereich und Automatisierung	Wer bewertet fachlich, wie werden strittige Fälle kalibriert, und welche automatischen Checks sind zulässig?	Niemand kann erklären, warum eine Antwort als richtig oder falsch gilt.
Strecke RAG, Agent, Tool-Nutzung	Werden Kontextaufbau, Quellen, Tool-Schritte, Rechte und Eskalationen geprüft?	Nur die finale Antwort wird bewertet.
Regression Änderungen	Was löst einen neuen Testlauf aus: Prompt, Modell, Datenbasis, Tool, Rechte oder Anbieteränderung?	Nach Änderungen wird nur geprüft, ob das System technisch noch läuft.
Betrieb Monitoring und Stopprecht	Welche Stichproben, Fehlertypen, Eskalationen, Logs und Kosten werden nach Go-live verfolgt?	Die Abnahme endet mit Produktivsetzung.

Drei Fehler, die sich wiederholen

Demo ersetzt Abnahme. Gute Beispiele zeigen, dass etwas möglich ist. Sie zeigen nicht, ob das System in der Breite, im Grenzfall und nach Änderungen belastbar bleibt.
Eine Durchschnittsmetrik verdeckt kritische Fehler. Ein hoher Score kann unbrauchbar sein, wenn das System in rechtlich, finanziell oder reputativ kritischen Fällen falsch liegt.
Evaluation findet nur vor dem Go-live statt. KI-Systeme ändern Verhalten über Modelle, Daten, Prompts, Tools und Nutzung. Ohne Regression und Betriebsmessung veraltet die Abnahme.

Damit schließt Evaluation eine Lücke in der Umsetzungsstrecke. Gute Use Cases brauchen vor dem Pilot eine wirtschaftliche Hypothese. Der Business Case braucht Kontrollaufwand und Qualitätskosten. Governance braucht Entscheidungsschwellen. Wissensarchitektur braucht freigegebene Quellen. Und die Modellstrategie braucht eigene Messung statt Anbieterpräferenz. Ohne diese Verbindung entstehen die bekannten Pilotmuster: beeindruckende Technologie, aber keine belastbare Betriebsentscheidung.