Warum „fast richtig" im Betrieb teurer ist als offensichtlich falsch

Ein roter Build wird nicht ausgeliefert. Eine Antwort, die überzeugend klingt und fachlich danebenliegt, schon. Zwischen diesen beiden Sätzen liegt der ganze Unterschied zwischen klassischer Software und KI-Systemen. Und es ist der Grund, warum Qualitätssicherung gerade vom letzten Schritt zum ersten wird.

KI schreibt Code. KI fasst Tickets zusammen. KI schlägt Testfälle vor. Was sie nicht zuverlässig entscheidet: ob ein System wirklich verstanden wurde, ob ein Ergebnis belastbar ist, ob ein Ablauf, der in der Demo glänzt, morgen im echten Betrieb kippt. Genau an dieser Stelle entsteht die neue Karrierechance für Quality Engineers.

„Fast richtig" ist schlimmer als offensichtlich falsch

In vielen Teams dreht sich die Diskussion gerade um Produktivität: schneller implementieren, weniger Boilerplate, mehr Features pro Sprint. Die Werkzeuge sind längst da. Laut der Stack Overflow Developer Survey 2025 nutzen oder planen 84 Prozent der Befragten KI-Werkzeuge im Entwicklungsprozess. Interessanter ist die zweite Zahl aus derselben Umfrage: Mehr Entwickler:innen misstrauen der Genauigkeit von KI-Ausgaben, als ihr vertrauen: 46 Prozent geben aktives Misstrauen an, nur 33 Prozent Vertrauen. Und 66 Prozent nennen dasselbe Problem: KI-Lösungen, die fast richtig sind, aber eben nicht ganz.

Dieses „fast" ist der Punkt.

Ein roter Build stoppt sich selbst. Eine plausibel formulierte Falschauskunft landet beim Kunden. Ein Agent, der in der Demo überzeugt, im dritten Sonderfall aber vertrauliche Daten preisgibt, wird zum Risiko. Ein Workflow, der in 95 Prozent der Fälle funktioniert, kann im falschen Geschäftsvorfall Kosten, Haftung oder Reputationsschäden verursachen. Offensichtlich falsch fällt auf. Fast richtig geht durch.

Die Leitfrage der Softwareentwicklung verschiebt sich damit. Sie lautet nicht mehr: Wer kann am schnellsten erzeugen? Sie lautet: Wer kann nachweisen, dass das Erzeugte stimmt?

Die Stellenanzeigen für AI Engineers beschreiben längst Quality Engineering, nur steht das Wort nicht drin

Auf den ersten Blick lesen sich aktuelle Ausschreibungen für AI Engineers wie klassische Engineering-Rollen: APIs, Datenpipelines, Cloud, MLOps, RAG, Agenten, LLMs, Observability. Zwischen den Zeilen steht etwas anderes. Unternehmen suchen Menschen, die Qualität beherrschbar machen.

Auf StepStone tauchen KI-Rollen auf, in denen Modelltraining, Evaluation, produktionsreife Services, Ergebnisvalidierung, AI-Governance, Datenschutz und Verständnis des EU AI Act in derselben Anzeige stehen. Eine aktuelle Ausschreibung für AI Security nennt ausdrücklich Guardrails, Input- und Output-Validierung, Prompt-Injection-Schutz, Logging, Monitoring, Anomalieerkennung, Penetration Testing und AI Red Teaming. Und es gibt bereits explizite QA-Rollen für LLM- und Agentic-AI-Systeme, in denen Outputs auf Korrektheit und Konsistenz validiert werden sollen.

International sieht das Muster identisch aus. Eine AI-Engineer-Rolle bei Onit führt „Evaluation, Quality & Iteration" als Kernaufgabe: Evaluation Frameworks, Golden Datasets, adversarial Cases, Regressionstests, rubric-based Scoring, Release Gates, Online-Metriken, Safety Flags, LLM-as-Judge, Observability, dokumentierte Failure Modes, Fallback-Pfade.

Das ist nicht nur Entwicklung. Das ist Quality Engineering unter neuem Namen.

Nicht die Demo entscheidet, sondern der Grenzfall

Wie schnell KI-Systeme im Alltag anders reagieren als im Konzeptpapier, lässt sich inzwischen an echten Fällen zeigen.

Air Canada wurde 2024 für irreführende Informationen seines Chatbots verantwortlich gemacht (Moffatt v. Air Canada, 2024 BCCRT 149). Ein Kunde hatte sich auf eine falsche Aussage zur nachträglichen Beantragung eines Trauertarifs verlassen. Das Gericht hielt fest: Air Canada trägt die Verantwortung für die Genauigkeit der Informationen, die der Chatbot bereitstellt. Die Auskunft war nicht abwegig. Sie war flüssig, hilfsbereit und falsch: genau die Sorte Fehler, die kein Build rot färbt.

DPD musste Teile seines KI-Chatbots deaktivieren, nachdem ein Nutzer den Bot dazu gebracht hatte, das eigene Unternehmen zu kritisieren, zu fluchen und sich selbst als nutzlos zu bezeichnen. Das Unternehmen erklärte, ein Systemupdate habe das ungewöhnliche Verhalten ausgelöst. Ein Update also. Eine Änderung, die in klassischer Software eine Regressionssuite ausgelöst hätte.

Der dritte Fall wurde zum Internet-Klassiker: Ein Chevrolet-Händler geriet in die Schlagzeilen, weil sein Chatbot mit den passenden Prompts scheinbar dem Verkauf eines 2024er Chevy Tahoe für einen Dollar zustimmte. Absurd, aber die Lektion ist ernst. Ein System, das mit Kunden spricht, braucht Grenzen, Rollenverständnis und geprüfte Ausgaben.

Bevor ich Software getestet habe, habe ich in einer Küche gearbeitet. Von meinem damaligen Küchenchef stammt ein Satz, den ich bis heute in jedem Seminar zitiere: „Du kannst nicht so dumm denken, wie die Menschen handeln." Er meinte damit, dass sich nicht vorhersagen lässt, was Leute mit deinem Produkt anstellen werden. Seit ich KI-Systeme teste, stelle ich mir eine Anschlussfrage: Wie dumm wird es, wenn eine KI dabei mithilft?

Diese Fälle sind keine Randnotizen aus der KI-Folklore. Sie zeigen dasselbe Grundproblem: KI-Systeme scheitern nicht an Syntaxfehlern. Sie scheitern an Kontext, Absicht, Berechtigungen, Halluzinationen, Prompt Injection, unklaren Verantwortlichkeiten und fehlender Validierung. Für genau diese Art von Fehlern wurde Qualitätssicherung erfunden.

Im KI-Zeitalter kippt die Reihenfolge: erst prüfen, dann bauen

Softwareentwicklung war lange um das Bauen herum organisiert. Anforderungen erheben, Code schreiben, Tests nachziehen. Qualität war wichtig, kam aber spät: meistens dann, wenn das Produkt schon weitgehend feststand.

Bei klassischen Anwendungen ließ sich das verkraften, weil viele Fehler deterministisch greifbar sind: Eingabe A erzeugt Ausgabe B. Bei LLMs und Agenten gilt das nicht mehr. OpenAI weist in den eigenen Evaluation Best Practices darauf hin, dass generative KI variabel ist und traditionelle Testmethoden allein für KI-Architekturen nicht ausreichen. Evals sind dort strukturierte Tests, um Genauigkeit, Performance und Zuverlässigkeit trotz Nichtdeterminismus zu messen. Empfohlen werden unter anderem eval-driven development, task-spezifische Evals, Logging, Automatisierung und die Kalibrierung automatischer Bewertungen durch menschliches Feedback.

Das ist ein Kulturwechsel, und man hört ihn an den Sätzen, die ein Team über sein Produkt sagt.

Vorher Nachher
„Wir bauen erst und testen später." „Wir definieren zuerst, woran wir erkennen, dass das System richtig handelt."
„Die Demo war überzeugend." „Welche Gegenbeispiele haben wir geprüft?"
„Der Prompt funktioniert bei mir." „Welche Regressionen entstehen, wenn Modell, Prompt, Kontext, Datenquelle oder Tool-Berechtigung sich ändern?"

Die rechte Spalte ist die Sprache der Qualitätssicherung. Sie steht jetzt am Anfang des Prozesses, nicht mehr an seinem Ende.

Dazu passt der Befund der DORA-Forschung von Google, die KI in der Softwareentwicklung als Verstärker beschreibt: Sie vergrößert die Stärken leistungsfähiger Organisationen, und ebenso die Dysfunktionen schwacher. Anders gesagt: KI macht gute Engineering-Praktiken wertvoller, nicht überflüssig.

Beide Seiten müssen sich bewegen, und der Vorsprung der QS hält nicht ewig

Für Entwicklerinnen und Entwickler ist die Botschaft unbequem: Wer sich vor allem über Implementierungsgeschwindigkeit definiert, gerät unter Druck. KI senkt die Kosten des Erzeugens und erhöht gleichzeitig die Anforderungen an Bewertung, Architektur, Sicherheit und Nachvollziehbarkeit.

Weniger technisch wird der Beruf dadurch nicht. Im Gegenteil, die Fragen werden tiefer:

  • Wie baue ich Evaluation Suites für RAG-Systeme?
  • Wie erkenne ich Halluzinationen, die plausibel klingen?
  • Wie teste ich einen Agenten, der Tools aufrufen darf?
  • Wie verhindere ich, dass ein Modell mehr Berechtigungen nutzt, als der Nutzer haben sollte?
  • Wie baue ich Regression Gates für Prompts, Modelle und Datenquellen?
  • Wie mache ich Fehler sichtbar, bevor Kunden sie finden?

Wer AI Engineering ernst meint, braucht QS-Denken als Grundkompetenz. Nicht als Anhängsel, nicht als „nice to have", sondern als Überlebensfähigkeit.

Umgekehrt ist das die große Chance für Quality Engineers. Gewonnen ist sie damit noch nicht. QS bringt etwas mit, das viele Teams gerade dringend brauchen: professionelles Misstrauen. Nicht Zynismus, nicht Blockade. Sondern die Fähigkeit, ein System absichtlich anders zu benutzen, als es gedacht war. Eine fachliche Aussage nicht zu glauben, nur weil sie flüssig formuliert ist. Fehler reproduzierbar zu machen, Risiken zu dokumentieren und aus Einzelfällen belastbare Prüfstrategien abzuleiten. Das war immer wertvoll. Jetzt wird es zentral.

Der Vorsprung hält aber nur, wenn die QS technisch nachlegt. Wer morgen AI Quality Engineer sein will, schreibt heute nicht nur Testfälle, sondern versteht, wie LLM-Anwendungen gebaut werden: APIs, JSON-Schemas, Function Calling, RAG, Embeddings, Vektordatenbanken, Prompt-Versionierung, CI/CD, Observability, Tracing, Datenschutz, Security, Modellwechsel, Kostenmetriken, Fallback-Designs.

Wie weit das Handwerk inzwischen reicht, zeigt PyRIT: Microsoft stellt damit ein Framework für automatisiertes und menschlich geführtes AI Red Teaming bereit, das mehrstufige Angriffsstrategien, standardisierte Evaluationsszenarien, Data-Leakage-Prüfungen, verschiedene Zielsysteme und flexible Scoring-Methoden unterstützt. Die neue QS arbeitet nicht mit Excel-Listen und ein paar manuellen Explorationsrunden. Sie arbeitet mit Frameworks, Pipelines, Telemetrie und Angriffssimulationen.

Der Quality Engineer von morgen ist nicht die Person, die am Ende noch mal draufschaut. Er oder sie entwirft die Sicherheitsnetze, in denen KI überhaupt produktiv werden darf.

Was das konkret heißt

Für Entwicklerinnen und Entwickler: Baut nicht nur Features, baut Beweisbarkeit. Jede KI-Funktion braucht eine Antwort auf die Frage „Woher wissen wir, dass sie unter realen Bedingungen funktioniert?" Diese Antwort besteht aus Golden Datasets, Gegenbeispielen, Prompt-Regressionen, Modellvergleichen, Logging, Metriken, Fallbacks, Human-in-the-loop und klaren Grenzen für die Tool-Nutzung.

Für die Qualitätssicherung: Raus aus der reinen Testdurchführung, rein in die AI Quality Architecture. Lernt, wie ein Agent entscheidet. Lernt, wie RAG die falschen Quellen zieht. Lernt, warum Prompt Injection kein schlechter Input ist, sondern ein Angriff. Lernt, Evals zu automatisieren und LLM-as-Judge kritisch zu kalibrieren. Und lernt, mit Entwickler:innen auf Augenhöhe über APIs, Datenflüsse, Berechtigungen und Observability zu sprechen.

Für Unternehmen: Behandelt QS nicht länger als letzte Station vor dem Release. Setzt Quality Engineers an den Anfang: in die Architektur, in die Produktdefinition, in die Risikoanalyse, in die Auswahl von Modellen und Werkzeugen. Und in die Frage, welche Entscheidungen automatisiert werden dürfen und welche nicht.

Dass es dabei um Architektur geht und nicht um Kosmetik, machen die Standards deutlich. Die OWASP Top 10 für LLM- und GenAI-Anwendungen führen unter anderem Prompt Injection, Sensitive Information Disclosure, Improper Output Handling, Excessive Agency und System Prompt Leakage als zentrale Risikokategorien. Und das NIST beschreibt im AI Risk Management Framework vertrauenswürdige KI als valide und zuverlässig, sicher, resilient, transparent, erklärbar, privacy-enhanced und fair. Diese Eigenschaften entstehen nicht durch Hoffnung. Sie entstehen durch systematische Prüfung.

Die unbequeme Wahrheit

Der klassische Entwickler verliert seinen Beruf nicht, weil KI Code erzeugt. Er verliert an Wert, wenn er nicht lernt, KI-Ergebnisse kritisch zu bewerten.

Der klassische Tester verliert seinen Beruf nicht, weil KI Testfälle generiert. Er verliert an Wert, wenn er nicht lernt, moderne KI-Systeme technisch zu verstehen, zu instrumentieren und zu härten.

Die Zukunft gehört nicht denen, die der KI am schnellsten Aufgaben geben. Sie gehört denen, die merken, wann eine Antwort gefährlich gut klingt.

Der wichtigste Entwickler der nächsten Jahre ist deshalb vielleicht nicht die Person, die heute den meisten Code schreibt. Vielleicht ist es die Person, die im Sprint Review die eine Frage stellt, die niemand hören will:

„Woher wissen wir, dass das auch dann noch stimmt, wenn der Nutzer nicht tut, was wir erwarten?"

Diese Frage war lange das Markenzeichen der Qualitätssicherung. Jetzt wird sie zur Kernkompetenz der Softwareentwicklung.

Mein Küchenchef hätte es kürzer gesagt. Er hatte allerdings auch keine KI, die ihm dabei hilft. QA hieß eben nie nur Quality Assurance. QA hieß immer auch: Question Asker.

Beide Wege lassen sich lernen. Bei der oose eG in Hamburg gehören dazu unter anderem der ISTQB® Certified Tester AI Testing (CT-AI), Testen mit generativer KI (CT-GenAI) und die Grundlagen der KI-Sicherheit.

Wenn du eher am Anfang stehst: ISTQB® Certified Tester Foundation Level (CTFL). Wenn du die Rolle im Team verschieben willst: Der Quality Evangelist und RiskStorming.