AI Testing: Wie Sie KI-Features und LLMs verlässlich prüfen

Wenn aus einem KI-Demo plötzlich ein Produkt wird

Eine KI-Demo ist schnell gebaut. Ein Prompt, ein Modellzugang, ein paar überzeugende Antworten, fertig ist der erste Prototyp. Schwierig wird es erst sobald das Feature echte Kundendaten verarbeitet, Entscheidungen vorbereitet oder Inhalte veröffentlicht, die jemand für verlässlich hält.

Dann stellen sich unangenehme, aber notwendige Fragen. Was bedeutet „richtig“ bei einer offenen Antwort, wie viel Schwankung ist akzeptabel, welche Fehler dürfen niemals auftreten und wie weist ein Team nach, dass es Risiken nicht nur diskutiert, sondern systematisch getestet hat?

Genau hier beginnt AI Testing. Es ersetzt klassische Softwaretests nicht, es erweitert sie um Verfahren, die mit probabilistischem Verhalten, sprachlicher Mehrdeutigkeit und einem veränderlichen technischen Umfeld umgehen können. Für QA Engineers heißt das: Testfälle werden weniger binär. Für CTOs bedeutetes: Qualität braucht messbare Leitplanken. Und für RegTech-Teams gilt: Nachweise, Verantwortlichkeiten und Monitoring gehören von Anfang an in die Architektur.

1. Warum KI-Systeme anders getestet werden müssen

Bei einer klassischen Software lassen sich für viele Funktionen eindeutige Soll-Ergebnisse definieren. Ein Warenkorb berechnet einen Betrag, eine API liefert einen Statuscode und ein Berechtigungsmodell erlaubt oder verweigert einen Zugriff. Das lässt sich automatisieren, wiederholen und klar als bestanden oder fehlgeschlagen bewerten.

Generative KI verhält sich anders. Ein Large Language Model (LLM) erzeugt keine fest hinterlegte Antwort, sondern berechnet wahrscheinliche Fortsetzungen. Schon kleine Änderungen an Prompt, Modellversion, Kontext oder Retrieval-Daten können das Ergebnis beeinflussen. Wer die Besonderheiten generativer KI im Softwaretest systematisch verstehen und praktisch anwenden möchte, findet im Seminar „ISTQB CT-GenAI – Testen mit generativer KI“ passende Methoden und Werkzeuge für die Qualitätssicherung KI-basierter Systeme.  Zwei unterschiedlich formulierte Antworten können beide brauchbar sein. Umgekehrt kann aber eine sprachlich elegante Antwort auch fachlich falsch sein.

Das verändert die Prüfentscheidung. Statt nur einen erwarteten String abzugleichen, braucht das Team Bewertungskriterien. Dazu gehören zum Beispiel fachliche Korrektheit, Vollständigkeit, Relevanz, Quellenbezug, Tonalität, Sicherheit und die Einhaltung vorgegebener Formate. Nicht jede Dimension lässt sich mit derselben Methode messen.

Trotzdem bleibt viel klassische QA-Arbeit unverzichtbar. Authentifizierung, Rollenrechte, Schnittstellen, Fehlerbehandlung, Latenz, Lastverhalten und Protokollierung sind weiterhin normale Softwarequalität. Wer beim LLM-Testing nur auf Modellantworten schaut, übersieht häufig die Fehler, die im Gesamtsystem entstehen: eine falsche Dokumentversion im Retrieval, ein fehlender Filter, ein abgeschnittener Kontext oder ein unzuverlässiger Fallback.

2. Aus „guten Antworten“ werden prüfbare Qualitätsziele

Der Satz „Das Modell soll gute Antworten liefern“ taugt nicht als Testziel. Er ist zu offen und führt fast zwangsläufig zu Diskussionen nach Bauchgefühl. Besser ist ein kleines Qualitätsmodell, das zum konkreten Use Case passt.

Für einen internen Wissensassistenten könnten die wichtigsten Kriterien so aussehen:

• Groundedness: Stützt sich die Antwort auf die bereitgestellten Unternehmensquellen?
• Faktische Korrektheit: Stimmen Aussagen, Zahlen und Bezüge mit den Referenzen überein?
• Relevanz: Beantwortet das System die eigentliche Frage, ohne unnötig auszuweichen?
• Vollständigkeit: Sind die für die Aufgabe erforderlichen Punkte enthalten?
• Sicherheit und Datenschutz: Gibt das System keine unzulässigen oder sensiblen Inhalte preis?
• Formattreue: Hält die Ausgabe Vorgaben für Sprache, Struktur oder maschinenlesbare Formate ein?

Für einen Code-Assistenten wären dagegen Ausführbarkeit, Testabdeckung, Sicherheitsregeln und Kompatibilität wichtiger. Bei einem RegTech-Feature rücken Nachvollziehbarkeit, Aktualität der Regelbasis, Eskalationslogik und revisionsfähige Protokolle nach vorn. Die Metriken müssen also aus dem Risiko und dem Nutzungskontext abgeleitet werden, nicht aus einer allgemeinen Tool-Liste.

Hilfreich ist eine Gewichtung. Eine stilistisch etwas holprige Antwort kann akzeptabel sein. Eine erfundene Rechtsgrundlage ist es nicht. Teams sollten deshalb definieren, welche Kriterien „hart“ sind, und einen Release blockieren, welche als Zielwert gelten und welche zunächst nur beobachtet werden. Die strukturierte Definition von Qualitätskriterien, Risiken und Freigabekriterien gehört zu den Kernaufgaben eines professionellen Testmanagements. Entsprechende Methoden vermittelt unsere Schulung „Testmanagement in Softwareprojekten“.

3. Ein belastbares Testset ist wichtiger als eine beeindruckende Einzelmetrik

Die Qualität einer Evaluation steht und fällt mit den Testdaten. Ein kleines Set aus einfachen Standardfragen führt schnell zu guten Ergebnissen, sagt aber wenig über den produktiven Betrieb aus. Ein belastbares Testset bildet typische Aufgaben, kritische Randfälle und bekannte Fehlermuster ab. Die systematische Ableitung von Testfällen aus Anforderungen, Risiken und Nutzungsszenarien ist eine Schlüsselkompetenz imLLM-Testing. Praktische Techniken dazu vermittelt die Schulung „Testfallerstellung verständlich und praxisbewährt“.

In der Praxis lohnt sich eine Mischung aus vier Quellen:

• Reale, bereinigte Nutzeranfragen aus Pilotbetrieb oder Support, sofern Datenschutz und Nutzungsrechte geklärt sind.
• Von Fachexpertinnen und Fachexperten kuratierte Fälle mit Referenzantworten oder klaren Bewertungskriterien.
• Gezielt konstruierte Negativ- und Grenzfälle, etwa mehrdeutige Anfragen, fehlende Informationen oder widersprüchliche Quellen.
• Synthetische Varianten zur breiteren Abdeckung, die anschließend stichprobenartig auf Realismus und mögliche Verzerrungen geprüft werden.

Wichtig ist die Kennzeichnung der Fälle. Welche Sprache, Nutzerrolle, Risikoklasse und Funktion wird geprüft? Welcher Fehler ist hier besonders kritisch? Ohne solche Metadaten bleibt später unklar, ob sich eine Verbesserung wirklich über alle relevanten Gruppen erstreckt oder nur den Durchschnittswert hebt.

Auch das Testset selbst braucht Pflege. Produktionsfehler sollten als Regressionstest zurückfließen. Veraltete Referenzen müssen ersetzt werden. Und wenn sich Produktumfang oder Zielgruppe ändern, muss die Abdeckung mitwachsen. Ein Eval-Datensatz ist kein einmal erstelltes Abnahmeprotokoll, sondern ein lebendes Qualitätsartefakt.

4. LLM-Evaluation braucht mehrere Prüfmethoden

Keine einzelne Metrik kann die Qualität eines LLM-Features vollständig abbilden. N-Gramm-Metriken wie BLEU oder ROUGE können bei eng begrenzten Aufgaben nützlich sein, etwa wenn die Nähe zu einer Referenzformulierung zählt. Für offene Dialoge oder fachliche Assistenzsysteme sind sie allein jedoch zu grob. Eine andere Formulierung ist nicht automatisch schlechter, und sprachliche Ähnlichkeit garantiert keine sachliche Richtigkeit.

In der Praxis bewährt sich ein Mix aus deterministischen Checks, modellgestützter Bewertung und menschlichem Urteil.

Deterministische Checks

Sie prüfen alles, was eindeutig prüfbar ist: JSON-Schema, Pflichtfelder, verbotene Begriffe, Zitierformat, Linkstruktur, Längenlimits, reguläre Ausdrücke oder die erfolgreiche Ausführung generierten Codes. Diese Tests sind günstig, reproduzierbar und hervorragend für CI-Pipelines geeignet.

LLM-as-a-Judge

Ein separates Modell bewertet Antworten anhand einer Rubrik. Das skaliert besser als ausschließlich manuelle Reviews und eignet sich für Kriterien wie Relevanz, Tonalität oder Vollständigkeit. Allerdings ist auch der Judge ein Modell. Seine Urteile können schwanken oder systematische Präferenzen enthalten. Deshalb sollten Teams klare Bewertungsanweisungen, paarweise Vergleiche, wiederholte Läufe und regelmäßige Kalibrierung gegen menschliche Bewertungen einsetzen.

Human Evaluation

Menschen bleiben besonders dort wichtig, wo Fachwissen, rechtliche Einordnung oder reale Auswirkungen zählen. Gute Reviews basieren nicht auf „gefällt mir“, sondern auf einer kurzen, verständlichen Rubrik. Idealerweise bewerten mehrere Personen zumindest einen Teil der Fälle. Abweichende Urteile sind kein Störfaktor, sondern ein Signal: Vielleicht ist das Kriterium unklar oder die Aufgabe selbst mehrdeutig. Gerade bei kritischen Entscheidungen zeigt sich der Wert eines Human-in-the-Loop-Ansatzes: Menschen übernehmen die Aufsicht, prüfen Ergebnisse und greifen ein, wenn Kontext, Risiko oder Verantwortung dies erfordern.

Red Teaming und Sicherheitstests

Hier versucht das Testteam bewusst, Schutzmechanismen zu umgehen. Dazu gehören Prompt Injection, Datenabfluss, Rollenwechsel, verschleierte Anweisungen, schädliche Tool-Aufrufe und Manipulationen über externe Inhalte. Bei agentischen Systemen reicht es nicht, nur die letzte Antwort zu prüfen. Auch Tool-Auswahl, Berechtigungen, Zwischenzustände und Abbruchregeln gehören in den Testumfang.

5. Halluzinationen sind kein einzelner Prozentwert

Im Alltag wird oft von „der Halluzinationsrate“ gesprochen. Das klingt präzise, ist aber ohne Definition wenig aussagekräftig. Zählt jede ungestützte Aussage? Nur überprüfbare Tatsachenbehauptungen? Wird eine teilweise richtige Antwort als Fehler gewertet? Und gegen welche Quelle wird geprüft?

Für Retrieval-Augmented Generation bietet sich eine Trennung an: Erstens, konnte das System die passenden Dokumente finden? Zweitens, hat es die gefundenen Inhalte korrekt genutzt? Drittens, hat die Antwort zusätzliche Behauptungen ergänzt, die nicht belegt sind? Diese Aufteilung zeigt, ob das Problem im Retrieval, im Prompt, im Modell oder in der Darstellung liegt.

Wie sich Retrieval, Antwortqualität und Betrieb systematisch bewerten lassen, zeigt unser Whitepaper RAG-Architektur für Enterprise AI: Unternehmenswissen sicher und produktiv nutzbar machen.

RAG-Architektur für Enterprise AI: Unternehmenswissen sicher und produktiv nutzbar machen

Ein sinnvolles Fehlerschema unterscheidet außerdem die Schwere. Eine erfundene Produktbezeichnung ist ärgerlich. Eine falsche Frist, eine fehlerhafte Compliance-Aussage oder eine unzutreffende medizinische Empfehlung kann gravierende Folgen haben. Ein guter Qualitätsbericht zeigt deshalb nicht nur Häufigkeiten, sondern auch Risikoklassen und konkrete Fehlermuster.

6. Fairness testen, ohne sich in Scheinsicherheit zu wiegen

Bias lässt sich nicht mit einem einzigen Test abhaken. Schon die Frage, was als fair gilt, hängt vom Anwendungskontext, der betroffenen Population und rechtlichen Vorgaben ab. Technische Kennzahlen helfen, ersetzen aber keine fachliche und rechtliche Bewertung.

QA- und AI-Testing-Teams sollten zunächst dokumentieren, für wen das System gedacht ist und welche Gruppen durch Fehler besonders belastet werden könnten. Danach lassen sich Testfälle paarweise variieren: Bleibt die fachliche Antwort gleich, wenn irrelevante personenbezogene Merkmale verändert werden? Verändert sich die Ablehnungs-, Eskalations- oder Empfehlungsrate? Funktioniert das System auch bei unterschiedlichen Sprachstilen, Dialekten oder Eingabequalitäten?

Der sensible Punkt ist die Datengrundlage. Geschützte Merkmale dürfen nicht beiläufig gesammelt oder zweckentfremdet werden. Fairness-Tests benötigen deshalb eine abgestimmte Governance mit Datenschutz, Legal und Fachbereich. Transparenz ist wichtiger als das Versprechen, Verzerrungen vollständig beseitigt zu haben.

7. Der EU AI Act macht Qualität zur Governance-Aufgabe

Der EU AI Act verfolgt einen risikobasierten Ansatz. Für Hochrisiko-KI nennt er unter anderem Anforderungen an Risikomanagement, Daten und Daten-Governance, technische Dokumentation, Aufzeichnungen, Transparenz, menschliche Aufsicht sowie Genauigkeit, Robustheit und Cybersicherheit. Welche Pflichten konkret greifen, hängt von Rolle, System und Einsatzgebiet ab. Eine pauschale Aussage für „alle KI“ wäre daher unseriös.

Für Produkt- und QA-Teams hat das eine praktische Konsequenz: Testergebnisse müssen nachvollziehbar werden. Welche Modell- und Promptversion wurde geprüft? Mit welchem Datensatz? Nach welchen Kriterien? Wer hat Abweichungen freigegeben? Welche bekannten Restrisiken bleiben bestehen? Ohne Versionierung und belastbare Evidenz entsteht zwar Aktivität, aber kein prüfbarer Nachweis.

Auch nach dem Rollout endet die Verantwortung nicht. Betreiber von Hochrisiko-Systemen müssen den Betrieb beobachten und relevante Vorfälle adressieren. Damit rücken Monitoring, Eskalationswege und Zuständigkeiten näher an klassische RegTech- und Kontrollprozesse. QA liefert dabei nicht nur Fehlerlisten, sondern Evidenz für technische und organisatorische Kontrollen.

8. Tooling: Erst das Verfahren, dann die Plattform

Der Markt für LLM-Evaluation und Observability entwickelt sich schnell.  Eine Plattform kann Datensätze verwalten, Experimente vergleichen, Traces speichern, automatisierte Evaluatoren ausführen und Produktionssignale überwachen. Sie nimmt dem Team jedoch nicht die Entscheidung ab, was im jeweiligen Produkt als ausreichend gut gilt.

OpenAI Evals bietet ein Framework für eigene Evaluationen und Benchmark-Workflows. LangSmith unterstützt Offline- und Online-Evaluationen, Datensätze, unterschiedliche Evaluatortypen und Feedbackschleifen. Für klassische ML- und Monitoring-Szenarien kommen je nach Architektur beispielsweise MLflow oder Evidently infrage. SHAP und LIME adressieren Erklärbarkeit bei geeigneten Modelltypen, während Fairness-Werkzeuge bei der Analyse gruppenspezifischer Unterschiede unterstützen können.

Die Auswahl sollte an fünf Fragen hängen: Passt das Tool zur vorhandenen Modell- und Cloud-Landschaft? Lassen sich sensible Daten angemessen schützen? Sind Runs, Versionen und Bewertungen reproduzierbar? Können Verantwortliche für fachliche Reviews ohne unnötige Hürden mitarbeiten? Und lassen sich Ergebnisse in CI/CD, Ticketing und Governance-Prozesse integrieren? Wie Unternehmen den Einsatz von KI durch klare Regeln, Verantwortlichkeiten und Kontrollmechanismen steuern können, erläutern wir in unserem Beitrag zur KI Governance.

9. Von der Entwicklung bis zum Betrieb: ein pragmatischer Ablauf

Ein funktionierendes AI-Testing-Setup muss nicht mit hunderten Metriken starten. Ein kleiner, sauberer Prozess ist wertvoller als ein ambitioniertes Dashboard ohne klare Entscheidungen.

1. Risiko und Zweck klären: Was tut das Feature, wer nutzt es und welcher Fehler wäre besonders kritisch?
2. Qualitätskriterien definieren: Wenige, verständliche Dimensionen festlegen und harte Release-Kriterien markieren.
3. Testset aufbauen: Typische Fälle, Randfälle und kritische Negativbeispiele mit Metadaten versehen.
4. Bewertungen kombinieren: Deterministische Checks automatisieren, modellgestützte Scores kalibrieren und Fachreviews für kritische Fälle einplanen.
5. Regressionen in CI/CD prüfen: Modell-, Prompt-, Retrieval- oder Policy-Änderungen nur gegen eine stabile Basis vergleichen.
6. Produktion beobachten: Qualitäts-, Sicherheits- und Betriebsindikatoren überwachen, Stichproben reviewen und Fehler in das Testset zurückführen.
7. Entscheidungen dokumentieren: Versionen, Schwellenwerte, Ausnahmen, Freigaben und Restrisiken nachvollziehbar halten.

Dieser Ablauf verbindet Engineering und Governance. Das ist entscheidend, denn ein Testbericht ohne Release-Entscheidung bleibt Papier. Eine Governance-Vorgabe ohne automatisierbare Evidenz bleibt dagegen schnell Theorie.

10. Drei typische Praxissituationen im AI Testing

Kundenservice: hilfreiche Antwort, falsche Zusage

Ein LLM formuliert freundlich und überzeugend, verspricht aber eine Leistung, die in den Vertragsunterlagen nicht vorgesehen ist. Ein reiner Tonalitätsscore würde den Fehler übersehen. Benötigt werden Groundedness-Prüfung, Tests gegen verbindliche Quellen, Regeln für unklare Fälle und eine Eskalation an Menschen, wenn die Evidenz nicht reicht.

RegTech: richtige Regel, veralteter Stand

Das System nennt eine formal passende Vorschrift, greift jedoch auf eine ältere Fassung zurück. Hier muss die LLM-Evaluation Aktualität, Quellenrang, Gültigkeitszeitraum und Zitierbarkeit abdecken. Zusätzlich sollte das System offen anzeigen, wenn die hinterlegte Wissensbasis keine belastbare Antwort ermöglicht.

Softwareentwicklung: Code läuft, öffnet aber ein Sicherheitsloch

Generierter Code besteht Funktionstests, verwendet jedoch eine unsichere Bibliothek oder umgeht eine Berechtigungsprüfung. Deshalb gehören statische Analyse, Dependency-Checks, Secret Scanning und Security-Testfälle neben die LLM-Bewertung. AI Testing ist in diesem Szenario ein zusätzlicher Layer, kein Ersatz für Secure Software Development.

Was in der Praxis schwierig bleibt

Die größte Herausforderung ist selten eine fehlende Metrik. Schwieriger sind uneinheitliche Erwartungen, unklare Verantwortlichkeiten und fehlende Zeit für ein repräsentatives Testset. Hinzu kommt: Ein Score wirkt objektiv, obwohl seine Aussage stark von Datensatz, Rubrik, Judge-Modell und Schwellenwert abhängt.

Auch Reproduzierbarkeit bleibt begrenzt. Teams können Parameter fixieren, Modellversionen dokumentieren und mehrere Läufe durchführen. Vollständig deterministisch wird ein generatives System dadurch nicht. Qualitätsmanagement muss mit Bandbreiten, Konfidenz und beobachtbaren Trends umgehen können.

Und schließlich gibt es Zielkonflikte. Strengere Guardrails können hilfreiche Antworten blockieren. Mehr Kontext kann die Qualität verbessern, erhöht aber Kosten und Datenschutzrisiken. Menschliche Reviews erhöhen Verlässlichkeit, begrenzen aber Skalierung. Diese Spannungen lassen sich nicht wegautomatisieren. Sie müssen sichtbar gemacht und bewusst entschieden werden.

Der nächste sinnvolle Schritt

AI Testing wird dann wirksam, wenn es nicht als Spezialdisziplin am Rand läuft. QA, Engineering, Security, Fachbereich, Legal und RegTech brauchen ein gemeinsames Qualitätsbild. Alle müssen wissen, welche Fehler kritisch sind, welche Evidenz für eine Freigabe genügt und was nach dem Go-live beobachtet wird.

Starten Sie nicht mit der Frage nach dem perfekten Tool. Nehmen Sie einen konkreten Use Case, definieren Sie fünf bis zehn kritische Tests und führen Sie jede relevante Änderung dagegen aus. Dokumentieren Sie Abweichungen. Ergänzen Sie reale Fehler. Nach wenigen Iterationen entsteht etwas, das deutlich wertvoller ist als eine allgemeine Checkliste: ein eigenes, belastbares Qualitätssystem für Ihr KI-Produkt. Wer die dafür notwendigen Kompetenzen im Software Testing gezielt ausbauen möchte, findet in unserem umfangreichen Seminarangebot passende Qualifizierungsangebote für Softwaretester:innen, Testmanager:innen und QA-Verantwortliche.

Testing- und KI-Kompetenzen gezielt weiterentwickeln

Welche Qualifizierung passt zu Ihnen oder Ihrem Team? Wir beraten Sie gerne bei der Auswahl der passenden Qualifizierungen für Ihren individuellen Weiterbildungsbedarf.

Jetzt Kontakt aufnehmen

FAQ - Häufig gestellte Fragen zu AI Testing

Quellen und weiterführende Hinweise

• Europäische Kommission: Leitlinien und Informationen zu Hochrisiko-KI-Systemen
• EU AI Act Service Desk: Pflichten von Anbietern von Hochrisiko-KI-Systemen, Artikel 16
• EU AI Act Service Desk: Pflichten von Betreibern von Hochrisiko-KI-Systemen, Artikel 26
• NIST: Generative AI Profile zum AI Risk Management Framework
• LangSmith: Dokumentation zu Offline- und Online-Evaluationen
• OpenAI Evals: Open-Source-Framework für LLM-Evaluationen

War dieser Artikel hilfreich für Sie?

Geschrieben von

René Kosel

René Kosel verantwortet bei Cegos Integrata als Produktmanager die Bereiche Software-Engineering & Testing sowie IT-Strategie und -Management. Zuvor betreute er die Themenbereiche Produktmanagement, agile Methoden und Change Management.Als ausgebildeter Fachinformatiker für Anwendungsentwicklung und seiner Arbeitserfahrung im Vertrieb der überbetrieblichen Aus- und Weiterbildung verbindet er technisches Know-how mit dem Wissen, was Organisationen antreibt. So entwickelt er Produkte und Lernlösungen, die neben einer hohen Praxisnähe auch aktuelle und zukünftige Herausforderungen abdecken.