Niemand testet gerne Software. Es ist langweilig, repetitiv, und am Ende sind alle genervt: Die Entwickler müssen nachbessern, was für sie längst erledigt war, und die Nutzer warten noch ein paar Wochen länger auf das Release. Trotzdem zweifelt niemand daran, dass Tests wichtig sind. Sie gehören in der agilen Softwareentwicklung und in modernen DevOps-Prozessen fest dazu. Die „Definition of Done“ hält fest, welche Qualitätskriterien etwas erfüllen muss, bevor es als abgeschlossen gilt.

Richtig umgesetzt funktionierte das sehr gut. Die Testszenarien standen fest, bevor die erste Codezeile geschrieben wurde. Bei jedem Release und jeder Änderung am zugrunde liegenden System wurde wieder getestet. War der Test bestanden, unterschrieb jemand die Freigabe, und das System ging live. Diese Unterschrift bedeutete „verifiziert“ und meinte: Solange sich nichts ändert, können wir uns auch nächste Woche noch auf das verlassen, was heute funktioniert.

Dahinter steckte eine so selbstverständliche Annahme, dass sie selten dokumentiert wurde: Derselbe Input liefert im selben System dasselbe Ergebnis. IF, THEN, ELSE … Deshalb ließ sich bei funktionalen Tests schon im Voraus festlegen, welches Ergebnis zu erwarten war. Risiken entstanden durch Änderungen – und dann wurde erneut getestet, bis alles im grünen Bereich war.

Darauf können wir uns bei KI nicht mehr verlassen.

Testen, während sich das System verändert

Vor allem auf Deep Learning basierende KI-Systeme, darunter auch alle LLMs, verhalten sich anders. Wenn ein Large Language Model (LLM) bei seinen Antworten etwas kreativen Spielraum bekommt, ändert sich der Output jedes Mal. Passt die Antwort heute exakt, kann sie morgen womöglich deutlich schlechter ausfallen. In unseren GenAI Audits erleben wir das regelmäßig.

Das ist kein Systemfehler, denn genau dieser Spielraum macht die Technologie für Aufgaben nützlich, bei denen nicht schon feststeht, wie das Ergebnis aussehen muss. Dadurch sagt allerdings ein einzelner Testlauf fast nichts über die Qualität und Stabilität aus. Bei generativer KI kommt noch etwas hinzu: Eine falsche Antwort kann durchaus richtig klingen - selbstsicher formuliert, aber mit Aussagen, für die es in den Quellen keine Belege gibt.

Auch im Hintergrund kann sich etwas ändern. Bei cloudbasierten KI-Modellen kann der Anbieter Modelle aktualisieren oder das Routing verändern, ohne dass solche Änderungen den kontrollierten Änderungsprozess der eigentlichen Anwendung durchlaufen. Bei dynamischem Routing landen Anfragen unter Umständen bei unterschiedlichen Modellvarianten und sorgen so für weitere Variabilität.

Und die Inputs ändern sich auch, beispielsweise wenn die Wissensbasis, auf die ein Retrieval-System zugreift, aktualisiert wird, neue Dokumente hinzukommen, während alte verschwinden. Oder Nutzer stellen plötzlich andere Fragen, die sich von denen entfernen, auf die das System trainiert und abgestimmt wurde. All das kann das Systemverhalten verändern, ohne dass eine neue Version ausgeliefert wurde. Was gestern funktioniert hat, muss morgen nicht zwingend auch noch funktionieren.

Tests als Endlosschleife

Was ein System leisten muss, um abgenommen zu werden, sollte feststehen, bevor die erste Zeile Code geschrieben wird. Das gehörte schon immer zu guter Softwareentwicklung. Bei Deep-Learning-Systemen ist es noch wichtiger. Sonst werden die Kriterien bei schwankenden Ergebnissen schnell so angepasst, dass schon das beste Einzelergebnis für die Abnahme reicht.

Daraus entsteht ein Widerspruch: Einerseits braucht KI besonders strenge Quality Gates, damit nicht ein paar gute Antworten für die Freigabe reichen. Andererseits bietet auch ein bestandener Test auf Dauer keine Garantie. Dieselben Tests müssen immer wieder laufen, damit eine GenAI- oder ML-Lösung, die heute noch mit Bravour besteht, nicht morgen kläglich scheitert.

Eine Release-Entscheidung braucht es selbstverständlich weiterhin. Sie gilt aber nicht pauschal, sondern nur für den festgelegten Einsatzzweck und die bekannte Konfiguration der Komponenten, die das Verhalten des Systems bestimmen. Die Qualitätssicherung geht deshalb im Produktivbetrieb immer weiter. Mit anderen Worten: Bei KI hört das Testen nie auf.

Wann ist ein KI-System gut genug?

Bei klassischen Softwaretests geht es meistens um richtig oder falsch. Ein Prozess muss funktionieren, einen Input korrekt verarbeiten und den erwarteten Output liefern. Ob der Test bestanden ist, lässt sich klar entscheiden.

Bei KI ist das schwieriger. An der Erwartung, in allen Testfällen zu 100 % richtige Antworten zu liefern, dürfte praktisch jedes KI-System scheitern. Reichen also 95 %? Und was lassen wir bei den restlichen 5 % durchgehen? Eine selbstsicher vorgetragene falsche Antwort auf 20 Prompts? Oder erwarten wir dann ein ehrliches „Ich weiß es nicht“?

Manche Fehler dürfen allerdings gar nicht passieren, zum Beispiel umgangene Zugriffskontrollen, die Weitergabe vertraulicher Daten oder nicht autorisierte Handlungen. Hier hilft auch kein ansonsten guter Durchschnitt. Solche Fehler gehören ausgemerzt.

Und wie viele Durchläufe muss ein System zuverlässig schaffen, bevor wir es als stabil betrachten? Drei? Fünfzig? Dafür gibt es keine allgemeingültige Zahl. Das hängt davon ab, wie hoch das Risiko ist, wie häufig Fehler zu erwarten sind und welche statistische Sicherheit wir brauchen. Die Wiederholungen sollten mit derselben Konfiguration laufen wie im Produktivbetrieb. Last und Latenz werden getrennt davon in einem Performance-Test geprüft.

Kriterien, die diese Variabilität messen, fehlen oft. Und genau deshalb gehen so viele generative KI-Systeme live, die nicht produktionsreif sind. Einmal hat das System überzeugt, einmal war die Antwort genau richtig. Was nicht funktioniert hat, wird kleingeredet.

Oder ein System besteht endlich die Tests, mit denen die Entwickler ständig gearbeitet und auf die sie das Modell mit gezieltem Finetuning zugeschnitten haben. Doch genau dieses sogenannte Overfitting macht das System anfällig. Ein leicht veränderter Prompt, ein Tippfehler oder ein ungewohnter Begriff hätte genügt, um das Problem zu entdecken. Nur wurden solche Varianten nie getestet - und das System war schlicht nicht bereit für den Produktivbetrieb.

Was das in der Praxis bedeutet

Softwaretests müssen nicht komplett neu erfunden werden. Die bewährten Grundsätze gelten weiter, manche müssen wir sogar strenger anwenden. Was sich ändern muss, ist der Ablauf - und die Art, wie wir die zuverlässige Funktion nachweisen. Für LLMs heißt das konkret:

Use Cases brauchen Abnahmekriterien und Testfälle. Wenn wir festlegen, wozu wir KI einsetzen und welchen Business Value wir erwarten, müssen wir auch festlegen, was als Erfolg gewertet wird. Welche Ergebnisse akzeptieren wir? Wie hoch muss die Erfolgsquote sein? Welche Fehler können wir tolerieren? Die Antworten darauf und die zugehörigen Testfälle müssen stehen, bevor die Entwicklung beginnt.

Risiken benennen. Zuerst kommen die offensichtlichen: Alles, was regulatorische Anforderungen berührt, gehört in den Risk Log. Dazu zählen Datenschutzfragen und alles, was unter die Hochrisikokategorien des EU AI Act fällt. Damit ist es aber nicht getan. Geschäftsrisiken sind genauso wichtig. Gerade bei Anwendungen, deren Entscheidungen nach außen sichtbar sind oder weitreichende Folgen haben, müssen wir durchspielen, was schiefgehen kann. Ein Machine-Learning-Algorithmus kann einen Industrieprozess unnötig stoppen und damit hohe Ausfallkosten verursachen – oder eine Gefahr, die vorher nie aufgetreten ist, übersehen. Ein Chatbot kann Interessenten und Kunden vergraulen, ohne dass es auffällt. Auch das sind Risiken, die zu berücksichtigen sind.

Die Qualität der Outputs steht im Zentrum. Hier scheitern Deep-Learning-Systeme am häufigsten. Zugriffsrechte, Schutz vor Datenabflüssen, die Qualität der Benutzeroberfläche und Performance sind natürlich wichtig und müssen getestet werden, allerdings wissen wir sehr gut, wie wir diese Themen angehen müssen. Was oft zu kurz kommt, ist die Prüfung der Qualität dessen, was die KI selbst liefert. In unseren GenAI Audits sehen wir das immer wieder: Die Antworten sind unzuverlässig oder gehen an der Frage vorbei, während die Bots gut aussehen und schnell sind. Wenn Kunden schnell schlechte Antworten bekommen, bringt dies keinen Mehrwert - der Ruf des Unternehmens wird dennoch beschädigt.

Eine einmalig perfekte Antwort genügt nicht als Begründung für einen Rollout. Zu oft reicht bei der Einführung eines KI-Systems ein Zufallstreffer als Qualifikation für das nächste Stage-Gate. Leider erfüllt sich die Hoffnung selten, dass ein System, das einmal etwas Brauchbares geliefert hat, dies mit mehr Training und Fine-Tuning irgendwann zuverlässig tut.

Besser ist es, zunächst mit einem kleinen Testset zu prüfen, ob das System über viele Durchläufe hinweg konstant gute Ergebnisse liefert. Genau darauf kommt es an: nicht ab und zu richtig zu liegen, sondern verlässlich korrekt zu sein.

Hardcoding ist leider nur zu üblich und birgt ein hohes Risiko: Wer Regeln einbaut, die für die bekannten Testfälle genau die gewünschte Antwort erzeugen, umgeht die eigentliche Evaluation. Das System besteht dann den Test, scheitert aber potenziell an jeder anderen Frage.

Gezielte Stresstests. Die Testfälle ergeben sich aus den Use Cases, für die das System entwickelt wurde. Dazu müssen aber weitere kommen, die es herausfordern – zum Beispiel, wie es mit mehrdeutigen Daten, Tippfehlern umgeht, oder mit Informationen, die es gar nicht gibt? Nur weil ein System unter Idealbedingungen funktioniert, ist es noch lange nicht alltagstauglich.

Ein Testset bleibt unter Verschluss. Sobald ein Prototyp auf ein Testset optimiert wurde, lässt sich mit diesen Tests nicht mehr unabhängig beurteilen, wie gut er mit anderen Fragen zurechtkommt. Für Regressionstests kann er zwar weiter nützlich sein, als einzige Grundlage für eine Release-Entscheidung reicht er aber nicht aus.

Zu oft werden Modelle genau darauf getrimmt, das nächste Gate zu bestehen. Man verändert den Prompt so lange, bis die gewünschte Antwort auf genau diese Testfrage kommt. Oder man schraubt am Retrieval, bis der Score steigt. Das ist manuelles Overfitting und überlebt im Alltag nicht.

Deshalb sollten die Entwickler mit einem Entwicklunsgsset von Tests arbeiten, während ein separates Validierungsset erst bei Release-Entscheidungen zum Einsatz kommt. Für Debugging oder Beispiele in Prompts darf es nicht verwendet werden.

Laufend überwachen und erneut testen. Darauf läuft es hinaus: Das Testen hört nicht auf und jede wesentliche Veränderung der Ergebnisse muss protokolliert werden.

Ohne Automatisierung geht es nicht

Sich beim laufenden Monitoring von LLMs vor allem auf „Human in the Loop“ zu verlassen, ist unrealistisch. Dafür sind die Systeme schlicht zu schnell.

Keine Organisation ist in der Lage, über Jahre hinweg große Mengen an KI-Entscheidungen von Hand zu evaluieren. Entweder erledigt das eine Maschine, oder die Tests werden oberflächlich oder bleiben ganz liegen. Die meist beste Lösung ist ein unabhängiges lokal gehostetes KI-System, das die KI kontrolliert. Dennoch braucht es menschliche Stichproben, um zu beurteilen, ob das System und die prüfende KI zuverlässig funktionieren. Aber wo immer möglich, müssen klar definierte Testroutinen die Prüfung automatisieren.

Dies muss ähnlich funktionieren, wie wir es bei Servern, Routern, Websites und anderen Endpunkten handhaben. Hier überwachen wir Verfügbarkeit und Performance längst routinemäßig. Und genauso müssen bei KI-Lösungen ohne Unterbruch Tests laufen, um sicherzustellen, dass diese auch im laufenden Betrieb ihr Qualitätsniveau halten.

Stabil bauen trotz Treibsand

„Done“ war immer eine Annäherung an Perfektion - irgendwann war das Risiko klein genug, um nicht weiter zu testen. Bei Systemen mit gleichbleibendem Verhalten hat das meist gut geklappt - bei KI hingegen kann der vermeintlich sichere Boden dagegen plötzlich nachgeben wie Treibsand. Was gestern noch stabil lief, kann heute versagen.

Die einmalige Freigabe reicht deshalb nicht mehr, da diese unter bestimmten variablen Bedingungen erfolgt ist. Das benötigt einen laufenden Nachweis, dass diese noch erfüllt sind. Der Augenblick des Releases darf nicht der einzige Zeitpunkt sein, an dem wir die Qualität von KI prüfen. Automatisierte Tests, ergänzt um menschliche Prüfungen von Stichproben, müssen so verlässlich laufen wie ein Health Check für einen Server und nicht erst dann, wenn ein Problem auftritt.