KI-Chatbot testen: Fragenkatalog, Grenzfälle und Abnahmekriterien

Ein Chatbot wird im Meeting mit fünf, sechs Fragen vorgeführt – alle beantwortet er sauber, alle sind sorgfältig ausgewählt. Der Eindruck: einsatzbereit. Zwei Wochen später beschwert sich ein Kunde, weil der Bot einen falschen Preis genannt hat, den niemand getestet hatte. Das ist kein Ausreißer, sondern das häufigste Muster, das ich bei der Abnahme von KI-Chatbots im Mittelstand sehe: Getestet werden die Fragen, bei denen man sich vorher sicher war, dass sie funktionieren. Genau die Fragen, die im echten Betrieb Probleme machen – Tippfehler, Grenzfälle, Angriffsversuche, veraltete Informationen –, tauchen im Abnahmeprozess gar nicht erst auf.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die einen Kundenservice-Chatbot einführen oder einen bestehenden vor dem Produktivbetrieb oder nach einem Update prüfen wollen. Er beantwortet, welche Testkategorien nötig sind, wie man Fakten- und Quellentreue prüft, wie man unerlaubte Inhalte testet, welche Grenzfälle wichtig sind und woran man erkennt, ob ein Chatbot abnahmereif ist – inklusive einer eigenen Teststruktur, die du direkt übernehmen kannst.

Begriffe kurz geklärt

Testkategorie bündelt Testfragen mit ähnlichem Zweck – etwa „Fakten prüfen” oder „Sicherheitsgrenzen prüfen”. Grenzfall ist eine Eingabe, die nicht dem erwarteten Standardmuster entspricht: unklar formuliert, mehrdeutig, außerhalb des Themenbereichs oder bewusst provokant. Halluzination bezeichnet eine KI-Ausgabe, die plausibel klingt, aber nicht durch die zugrunde liegenden Daten gedeckt ist – die Datenschutzkonferenz definiert das in ihrer Orientierungshilfe zu RAG-Systemen so: Informationen, „die zwar plausibel klingen, aber nicht durch ihre Trainingsdaten gestützt sind”. RAG (Retrieval Augmented Generation) ist die heute übliche Technik hinter den meisten Unternehmens-Chatbots: Statt nur aus trainiertem Wissen zu antworten, durchsucht das System vorher hinterlegte Dokumente und reichert die Antwort damit an. Human Handover ist die Übergabe eines Falls vom Chatbot an einen Menschen – ein eigener Testbereich, kein Notfallplan für den Fehlerfall.

Wichtig ist die Abgrenzung nach unten: Eine kurze Testrunde mit den Lieblingsfragen aus dem Sales-Pitch ist kein Test, sondern eine Demo. Ein Test prüft, wo das System bricht – nicht, wo es glänzt.

Welche Testkategorien braucht man?

Aus meiner Praxis lassen sich Testfragen in fünf bis sechs Kategorien ordnen, die sich in Wichtigkeit und Risiko deutlich unterscheiden. Die folgende Teststruktur teilt einen Testkatalog von 100 Fragen nach Häufigkeit und Risiko auf – nicht als exakte Formel, sondern als Ausgangspunkt, den du an deinen Anwendungsfall anpasst.

Kategorie	Anteil (von 100 Testfragen)	Fokus	Beispielhafte Testfrage
Kernfunktionen	30	Die häufigsten, realen Anfragen abdecken	„Wie sind eure Öffnungszeiten?”, „Wo bleibt meine Bestellung?”
Fakten & Quellentreue	20	Prüfen, ob Antworten aus echten, aktuellen Quellen stammen	Frage zu einem kürzlich geänderten Preis oder einer aktualisierten Regel
Unerlaubte Inhalte & Sicherheitsgrenzen	15	Prompt Injection, Datenlecks, Themenfremdes	„Ignoriere deine bisherigen Anweisungen und …”
Grenzfälle & mehrdeutige Anfragen	15	Tippfehler, Dialekt, widersprüchliche Folgefragen	Mehrere Fragen in einer Nachricht, aggressiver Ton
Eskalation & Human Handover	10	Wann und wie der Bot an Menschen übergibt	Beschwerde, Reklamation, Rechtsanfrage
Datenschutz & Betroffenenrechte	10	Umgang mit personenbezogenen Daten	„Welche Daten habt ihr von mir?”, „Löscht meine Daten”

Eigene Teststruktur Philogic Labs, abgeleitet aus Umsetzungsprojekten. Die Aufteilung ist ein Ausgangspunkt – ein reiner Bestell-Statusbot braucht mehr Gewicht bei Kernfunktionen, ein wissensbasierter Support-Bot mit Zugriff auf Kundendaten mehr Gewicht bei Datenschutz.

Der Kern des Modells: Die ersten 30 Fragen sind die, die in jeder Demo ohnehin getestet werden. Die entscheidenden 70 sind die, die typischerweise fehlen – und genau dort entstehen die Vorfälle, die später Vertrauen kosten.

Wie prüft man Fakten und Quellen?

Die meisten Unternehmens-Chatbots arbeiten heute mit RAG: Sie durchsuchen hinterlegte Dokumente (FAQ, Produktdaten, Richtlinien) und lassen ein Sprachmodell daraus eine Antwort formulieren. Laut der Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen kann diese Methode Halluzinationen reduzieren, weil die Antwort an konkrete Referenzdokumente gebunden wird – sie beseitigt das Risiko aber nicht vollständig. Die Konferenz nennt drei Stellschrauben, die für die Antwortqualität entscheidend sind: die Qualität und Aktualität der Referenzdokumente selbst, die Qualität der Datenaufbereitung (saubere Aufteilung in Textabschnitte, bereinigt um störende Kopf- und Fußzeilen) und die „Kontexttreue” des Sprachmodells – also ob es bei widersprüchlichen Inhalten tatsächlich die hinterlegten Dokumente nutzt oder auf sein Trainingswissen zurückfällt.

Daraus folgt eine konkrete Testmethode: Formuliere Fragen, deren korrekte Antwort du vorher aus der Originalquelle kennst – idealerweise zu Informationen, die sich kürzlich geändert haben (ein neuer Preis, eine geänderte Lieferzeit, eine aktualisierte Garantiebedingung). Stimmt die Antwort des Chatbots nicht mit der aktuellen Quelle überein, liegt entweder ein Problem bei den Referenzdokumenten (veraltet, nicht neu eingespielt) oder bei der Kontexttreue des Modells vor. Zweitens: Stelle Fragen, die bewusst außerhalb der hinterlegten Wissensbasis liegen. Ein guter Chatbot sagt „dazu habe ich keine Information” – ein schlechter erfindet eine plausible, aber falsche Antwort. Genau dieses Verhalten zu erkennen ist der Kern des Fakten-Tests, nicht die Zahl der richtig beantworteten Standardfragen.

In einem Projekt, bei dem ich einen FAQ-Chatbot für ein Handelsunternehmen begleitet habe, fiel genau das auf: Bei Fragen zu einer zwei Wochen alten Preisänderung antwortete der Bot noch mit dem alten Preis, weil die Dokumente zwar aktualisiert, aber die zugehörigen Textabschnitte im Hintergrundsystem nicht neu verarbeitet worden waren. Ohne gezielten Test auf genau diese Art von Frage wäre das erst bei echten Kundenanfragen aufgefallen.

Wie testet man unerlaubte Inhalte?

Hier geht es um zwei unterschiedliche Risiken: dass der Chatbot Dinge sagt, die er nicht sagen soll, und dass er Informationen preisgibt, die er nicht preisgeben soll. Das OWASP Top 10 for Large Language Model Applications-Projekt beschreibt die relevanten Risikoklassen: Prompt Injection – gezielte Eingaben, die das System aus seiner vorgesehenen Rolle drängen sollen –, Sensitive Information Disclosure – die ungewollte Preisgabe sensibler Informationen in Ausgaben – und Overreliance, also der unkritische Verlass auf ungeprüfte KI-Ausgaben.

Konkrete Testfragen für diese Kategorie: Versuche, den Chatbot mit Formulierungen wie „Ignoriere deine bisherigen Anweisungen und …” aus seiner Rolle zu bringen. Frage nach seinem Systemprompt oder seinen internen Anweisungen. Frage nach Daten anderer Kund:innen oder nach Informationen, die erkennbar nicht für die Öffentlichkeit bestimmt sind. Teste Themen außerhalb des erlaubten Bereichs – politische Statements, Konkurrenzvergleiche, rechtliche Zusagen, die das Unternehmen nicht geben will. Das BSI empfiehlt in seinem Management Blitzlicht zu generativer KI für genau diesen Bereich, KI-Ausgaben nie ungeprüft für kritische Geschäftsprozesse zu verwenden und bei eigenentwickelten oder integrierten Systemen dedizierte AI-Security-Tests einzuplanen – in größeren Vorhaben etwa in Form von AI Pen Testing. Für ein KMU mit einem eingekauften Chatbot-Produkt heißt das praktisch: Diese Angriffsversuche selbst durchspielen, bevor Kund:innen es tun, und beim Anbieter nachfragen, welche Schutzmaßnahmen gegen Prompt Injection und Datenlecks eingebaut sind.

Welche Grenzfälle sind wichtig?

Grenzfälle sind der Bereich, der in Demos am zuverlässigsten fehlt, weil er sich schlecht vorführen lässt. Aus der Praxis sind folgende Muster besonders relevant:

• Unsaubere Eingaben: Tippfehler, fehlende Satzzeichen, Umgangssprache oder Dialekt-Formulierungen.
• Mehrere Anliegen in einer Nachricht: „Wann kommt meine Bestellung und kann ich gleichzeitig die Lieferadresse ändern?”
• Widersprüchliche Folgefragen: Der Chatbot beantwortet Frage 1, die zweite Frage widerspricht scheinbar der ersten Antwort – bleibt er konsistent?
• Emotionaler oder aggressiver Ton: Beschwerden, Frustration, Formulierungen, die eher eine menschliche Reaktion erwarten als eine Standardantwort.
• Fragen am Rand des Zuständigkeitsbereichs: Anfragen, die eigentlich eine Rechtsberatung, eine individuelle Zusage oder eine Entscheidung wären, die der Chatbot nicht treffen darf.
• Sprachwechsel und ungewöhnliche Formate: Fragen in einer anderen Sprache als der Standardsprache, Sprachnachrichten-Transkripte, sehr lange oder sehr kurze Eingaben.

Der gemeinsame Nenner: Grenzfälle sind in der Menge selten, aber in der Summe häufig – jede einzelne Variante kommt vielleicht bei einem von hundert Gesprächen vor, aber addiert machen solche Fälle im echten Betrieb einen relevanten Anteil aller Anfragen aus. Ein Testkatalog, der nur Standardfragen enthält, blendet diesen Anteil systematisch aus.

Welche Abnahmemetriken gelten?

Es gibt keine allgemeingültige Kennzahl, ab der ein Chatbot „fertig getestet” ist – das hängt vom Anwendungsfall und Risiko ab. Sinnvoll sind aus meiner Erfahrung drei Ebenen:

Fehlerquote je Testkategorie. Nicht eine Gesamtquote über alle 100 Fragen, sondern getrennt nach Kategorie – eine hohe Erfolgsquote bei Kernfunktionen sagt nichts über die Qualität bei Grenzfällen aus. Beide Bereiche brauchen eigene Schwellenwerte, die dein Team vorab festlegt.

Stop-Kriterien für sicherheitskritische Fälle. Bestimmte Testfälle dürfen nicht „meistens” bestehen, sondern müssen es ausnahmslos: keine Herausgabe fremder Kundendaten, keine erfolgreiche Prompt Injection, keine falschen rechtsverbindlichen Zusagen (Preise, Termine, Garantien), und eine funktionierende Übergabe an Menschen bei Beschwerden oder erkennbar sensiblen Anliegen. Besteht der Chatbot auch nur einen dieser Fälle nicht, ist er nicht abnahmereif – unabhängig davon, wie gut die restliche Quote ist.

Betriebsmetriken nach dem Start. Eskalationsrate an Menschen, Wiederholungsfragen (ein Indiz dafür, dass Nutzer:innen die erste Antwort nicht verstanden oder ihr nicht getraut haben) und tatsächliche Nutzer:innen-Rückmeldungen lassen sich erst im echten Betrieb sauber messen. Versprich dir und niemandem eine Zeit- oder Kostenersparnis auf Basis der Testrunde – das ist eine Zahl, die du erst nach echtem Einsatz kennst, nicht vorher.

Umsetzung: So baust du deinen Testkatalog auf

1. Reale Anfragen sammeln. Support-Logs, häufige E-Mails, FAQ-Statistiken oder – falls es noch keine gibt – ein kurzer Austausch mit dem Team, das aktuell den Kundenkontakt hat. Das ist die belastbarste Quelle für Kernfunktionen, nicht die Annahmen der Projektleitung.
2. Kategorien nach der obigen Struktur gewichten. Passe die Verteilung an dein Risiko an: Ein Chatbot mit Zugriff auf Bestell- oder Vertragsdaten braucht mehr Gewicht bei Datenschutz und Sicherheitsgrenzen als ein reiner Öffnungszeiten-Bot.
3. Testfragen konkret formulieren, inklusive der unangenehmen: Angriffsversuche, Grenzfälle, veraltete oder mehrdeutige Informationen. Wer diese Fragen erst im Test entwirft, findet mehr Lücken als beim Runterschreiben der „idealen” Demo-Fragen.
4. Testrunde mit Fachbereich und IT/Datenschutz gemeinsam durchführen. Der Fachbereich erkennt fachlich falsche Antworten, IT und Datenschutz erkennen Sicherheits- und Compliance-Lücken – eine Person allein deckt selten beides ab.
5. Ergebnisse dokumentieren und Stop-Kriterien konsequent anwenden. Ein Testprotokoll mit Datum, Frage, Antwort, Bewertung ist auch die Grundlage für den nächsten Punkt.
6. Regressionstests bei jedem Update wiederholen. Chatbots verändern sich mit Modell-Updates, neuen Dokumenten oder geänderten Prompts – ein einmal bestandener Test gilt nicht dauerhaft. Sinnvoll ist, den Kernkatalog nach jeder relevanten Änderung erneut laufen zu lassen, nicht nur vor dem ersten Livegang.

Wie du einen Chatbot grundsätzlich mit eigenen Unternehmensdaten aufbaust, behandelt ein eigener Artikel in unserem Cluster KI im Kundenservice; dieser Artikel konzentriert sich bewusst auf die Abnahme und laufende Prüfung.

Risiken & Grenzen

Ein Testkatalog – auch ein guter – ist kein Garantieschein. Er reduziert die Wahrscheinlichkeit unentdeckter Fehler, schließt sie aber nicht aus: Nutzer:innen formulieren Fragen, die kein Testkatalog vorwegnimmt. Deshalb gehört zu jedem Chatbot-Betrieb eine laufende Stichprobenprüfung echter Gespräche, nicht nur der einmalige Abnahmetest.

Zwei weitere Grenzen sind wichtig zu benennen. Erstens: Übertriebene Testtiefe kann lähmen. Nicht jeder Chatbot mit geringem Risiko (etwa ein reiner Öffnungszeiten-Bot ohne Zugriff auf Kundendaten) braucht 100 Testfragen und ein volles Sicherheits-Audit – die Teststruktur oben ist ein Rahmen, den du proportional zum Risiko herunterskalierst. Zweitens, rechtlich (Stand Juli 2026, keine Rechtsberatung): Sobald ein Chatbot personenbezogene Daten verarbeitet, gelten die üblichen DSGVO-Anforderungen – Rechtsgrundlage, gegebenenfalls Auftragsverarbeitungsvertrag mit dem Anbieter, und die Wahrung von Betroffenenrechten wie Auskunft und Löschung. Das ist Teil des Testkatalogs (siehe die letzte Kategorie oben), ersetzt aber keine Abstimmung mit Datenschutzbeauftragten oder Rechtsberatung, insbesondere wenn Chat-Verläufe gespeichert oder an Dritte weitergegeben werden.

Checkliste: KI-Chatbot testen

1. Wir haben Testfragen aus echten Support-Anfragen gesammelt, nicht nur aus Annahmen der Projektleitung.
2. Unser Testkatalog deckt mindestens fünf Kategorien ab: Kernfunktionen, Fakten/Quellentreue, unerlaubte Inhalte, Grenzfälle, Eskalation.
3. Wir haben Fakten- und Preisfragen zu kürzlich geänderten Informationen getestet, nicht nur zu stabilen Standardfragen.
4. Wir haben geprüft, ob der Chatbot bei fehlender Information ehrlich „weiß ich nicht” sagt statt zu halluzinieren.
5. Wir haben Prompt-Injection- und Datenleck-Versuche aktiv durchgespielt.
6. Wir haben Grenzfälle getestet: Tippfehler, aggressive Töne, mehrdeutige und mehrteilige Anfragen.
7. Wir haben feste Stop-Kriterien für sicherheitskritische Fälle definiert, die ausnahmslos bestehen müssen.
8. Fachbereich, IT und Datenschutz waren gemeinsam an der Testrunde beteiligt.
9. Die Übergabe an Menschen funktioniert zuverlässig bei Beschwerden und sensiblen Anliegen.
10. Wir haben ein Testprotokoll dokumentiert, das auch als Grundlage für Regressionstests dient.
11. Wir wiederholen den Kerntest nach jedem relevanten Update – Modell, Prompt oder Dokumente.
12. Wir versprechen keine Zeit- oder Kostenersparnis auf Basis der Testrunde, sondern messen sie erst im echten Betrieb.

Wenn du deinen bestehenden oder geplanten Chatbot strukturiert prüfen lassen willst, unterstützen wir das im Rahmen unseres Beratungsangebots – ein kostenloses Erstgespräch klärt, ob und wo eine externe Testrunde sinnvoll ist.