Wenn Code schneller generiert wird und Teile des Systems nicht mehr deterministisch sind, wird die Verifikation unerlässlich: Sie ist die einzige Möglichkeit, die Funktionsfähigkeit zu überprüfen. Die gegenteilige Intuition – »Wenn KI besseren Code schreibt, wird weniger Qualitätssicherung benötigt» – verwechselt zwei unterschiedliche Dinge: die syntaktische Korrektheit des Codes und seine Eignung für die Geschäftsanforderungen.
Ein Modell erzeugt Code, der kompiliert und etwas Sinnvolles tut. Es weiß aber nicht, ob dieses „Etwas“ den Bedürfnissen Ihres Unternehmens entspricht, denn diese Information ist nicht im Code enthalten: Sie steckt im Prozess, in den Vorschriften und in Ausnahmen, die niemand formuliert hat.
Aktuelle Systeme kombinieren deterministische und probabilistische Komponenten, die jeweils unterschiedlich verifiziert werden. Die Vermischung dieser Komponenten ist die Ursache der meisten Produktionsprobleme.
|
Aspekt |
Deterministische Komponente |
probabilistische Komponente |
|---|---|---|
|
Was wird geprüft? |
Möge das Ergebnis den Erwartungen entsprechen. |
Dass das Ergebnis oft genug akzeptabel ist |
|
Testergebnis |
Bestanden oder nicht bestanden |
Qualitätsverteilung über ein Set |
|
Wenn es läuft |
Bei jeder Veränderung |
Mit jeder Änderung und periodisch in der Produktion |
|
Was es erkennt |
Regressionen |
Regressionen und Verhaltensdrift |
|
Wer legt die Kriterien fest? |
Das technische Team |
Wirtschaft, mit Auswertung von Fallstudien aus der Praxis |
Die wichtigste Zeile ist die letzte. Hinsichtlich der Wahrscheinlichkeit kann das «richtige» Kriterium nicht allein vom technischen Team festgelegt werden, da es davon abhängt, was das Unternehmen als akzeptabel erachtet: Eine Zusammenfassung, die eine sekundäre Information auslässt, kann in einem Kontext perfekt und in einem anderen inakzeptabel sein.
Deshalb ist der wertvollste Bestandteil eines KI-Projekts nicht das Modell oder die Aufgabenstellung, sondern … die Gesamtheit der bewerteten Fälle, mit der jeweils von der Organisation als korrekt erachteten Antwort. Dieses Set übersteht Anbieterwechsel problemlos, ermöglicht einen objektiven Vergleich von Alternativen und erkennt, ob eine neue Version Verschlechterungen mit sich gebracht hat. Es ist das Element, das einen Modellwechsel ohne Bedenken ermöglicht.
Als das Team den gesamten Code noch manuell schrieb, deckte die Peer-Review einen Großteil der Überprüfung ab. Bei einem größeren Umfang verringert sich diese Abdeckung: nicht weil die Reviewer schlechter wären, sondern weil in derselben Zeit mehr Code überprüft werden muss.
Der DORA-Bericht 2024 untersuchte die praktischen Folgen: Mit zunehmender KI-Nutzung sank die Stabilität der Bereitstellung um 7,21 Tsd. 300 Tsd., was mit dem wachsenden Umfang der Änderungen zusammenhing. Zudem gaben 39,21 Tsd. 300 Entwickler an, wenig bis gar kein Vertrauen in den generierten Code zu haben, was zu einem selten berücksichtigten Kostenfaktor führte: dem Zeitaufwand für die manuelle Überprüfung von etwas, das eigentlich Zeit sparen sollte.
Die Lösung besteht nicht darin, die Prüfstunden zu erhöhen. Vielmehr geht es darum, manuelle Prüfungen nach Möglichkeit durch automatisierte Verifizierung zu ersetzen und die menschliche Aufmerksamkeit für das zu reservieren, was nur ein Mensch beurteilen kann: ob dies den Bedürfnissen des Unternehmens entspricht.
Komponententests und Integration. Das gleiche Spiel, und jetzt noch notwendiger, weil es mehr Code gibt. Geschrieben oder zumindest von einer Person geprüft: Wenn dasselbe System Implementierung und Tests generiert, schließt sich der Kreislauf.
KI-Komponenten-Bewertungsset. Reale Szenarien mit erwarteten Ergebnissen sollten bei jeder Modell-, Eingabeaufforderungs- oder Konfigurationsänderung durchgespielt werden. Ohne dies lässt sich nicht feststellen, ob ein Update das System verbessert oder verschlechtert hat.
Hinweise auf Ausnahmen. Die seltenen Fälle im Prozess dienen als Tests. So stellen wir sicher, dass das System sich an den jeweiligen Nutzer anpasst, anstatt zu improvisieren.
Spezifische Sicherheitstests. Schnelles Erkennen von Einschleusungsversuchen, Überprüfung, ob die Komponente ihre Berechtigungen nicht überschreiten kann, und Sicherstellen, dass sie keine unzulässigen Informationen preisgibt. OWASP zählt diese Sicherheitsmaßnahmen zu den Top 10 für LLM-Anwendungen im Jahr 2025.
Kontinuierliche Überprüfung in der Produktion. Regelmäßige Stichproben aus realen Anwendungsfällen, überprüft von einem Menschen. Nur so lässt sich eine Abweichung feststellen: Ein System kann sich verschlechtern, ohne dass eine einzige Zeile Code geändert wurde, weil sich das Modell, die Daten oder der Nutzungskontext geändert haben.
Die fünfte Schicht ist diejenige, die so gut wie nie existiert und die die meisten Zwischenfälle verhindert, aus dem Grund, den wir bereits im Zusammenhang mit … erläutert haben. Beobachtbarkeit und Automatisierung [interner Link]Ohne kontinuierliche Messung kommt das Signal, dass etwas nicht stimmt, über den Kunden.
Dies ist kein konservatives Argument. Das Profil der Qualitätssicherung verändert sich grundlegend, und zwar zum Besseren:
Es geht um einen Wandel von «Überprüfen, ob es funktioniert» hin zu «Definieren, was es bedeutet, dass es funktioniert». Die zweite Aufgabe ist schwieriger, wertvoller und kann nicht automatisiert werden.
Wenn jemand vorschlägt, die Investitionen in Qualität zu reduzieren, weil «KI besseren Code schreibt», lautet die Leitfrage der Diskussion: Woran werden wir erkennen, dass es nicht mehr funktioniert?
Lautet die Antwort, dass es schon jemandem auffallen wird, hat das Unternehmen seine Qualitätskontrolle der Geduld seiner Kunden überlassen. Umfasst die Antwort hingegen automatisierte Tests, eine versionierte Testsuite und kontinuierliche Stichproben im Produktivbetrieb, so lässt sich Effizienz realistisch diskutieren.
Nein, es erhöht sie sogar. Ein Modell erzeugt zwar Code, der kompiliert und etwas Sinnvolles tut, aber es weiß nicht, ob das den Geschäftsanforderungen entspricht, da diese Information im Prozess und den Ausnahmen, nicht aber im Code selbst, enthalten ist. Darüber hinaus verringert die höhere Anzahl an Änderungen die Aussagekraft der Peer-Reviews.
Anhand einer Reihe realer Anwendungsfälle und deren erwarteter Reaktion, die bei jeder Modelländerung, Eingabeaufforderung oder Konfiguration ausgeführt werden, ergibt sich kein «bestanden/nicht bestanden», sondern eine Qualitätsverteilung. Die Akzeptanzkriterien sollten vom Fachbereich und nicht nur vom technischen Team definiert werden.
Es handelt sich um eine Sammlung realer Fallstudien mit den vom Unternehmen als richtig erachteten Antworten. Sie ist der wertvollste Bestandteil eines KI-Projekts: Sie ermöglicht objektive Anbietervergleiche, die Erkennung von Systemverschlechterungen durch neue Versionen und den Modellwechsel ohne blindes Risiko.
Fünf: Unit- und Integrationstests, Evaluierungssuite für KI-Komponenten, Tests auf Prozessausnahmen, spezifische Sicherheitstests (Prompt-Injection, Berechtigungsüberschreitung, Informationspreisgabe) und kontinuierliche Verifizierung durch Produktionsstichproben.
Ja. Die Situation kann sich verschlimmern, weil sich die Modellversion, die Eingabedaten oder der Nutzungskontext geändert haben. Deshalb darf die Verifizierung nicht mit der Bereitstellung enden, sondern muss durch regelmäßige, von Personen überprüfte Stichproben fortgesetzt werden.
Der Prozess verlagert sich von der sich wiederholenden manuellen Ausführung hin zur Fallstudienentwicklung, dem Aufbau und der Pflege von Testumgebungen sowie der Analyse der Ergebnisse im Produktivbetrieb. Er geht von der Überprüfung der Funktionsfähigkeit zur Definition dessen über, was es bedeutet, dass es funktioniert.
Woran würden Sie erkennen, dass Ihr KI-System nicht mehr ordnungsgemäß funktioniert? Wir haben die Testsuite, die Ausnahmeprüfung und die kontinuierliche Überprüfung so konzipiert, dass die Reaktion nicht von einer Kundenbeschwerde abhängt. Lass uns reden →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
