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

Das Wichtigste in Kürze:

• Ein belastbarer Test deckt mindestens 5 Kategorien ab, nicht nur Idealfragen.
• Teststruktur: 100 Fragen, gewichtet nach Häufigkeit und Risiko.
• Sicherheitskritische Fälle müssen ausnahmslos bestehen (Stop-Kriterien).
• Regressionstest nach jedem Update: Modell, Prompt oder Dokumente.

Ein Chatbot wird im Meeting mit 5 oder 6 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. Es ist das häufigste Muster, das ich bei der Abnahme von KI-Chatbots im Mittelstand sehe. Getestet wird, was vorher schon sicher schien. Die Fragen, die im echten Betrieb Probleme machen (Tippfehler, Grenzfälle, Angriffsversuche, veraltete Informationen), tauchen in der Abnahme gar nicht erst auf.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU. Er hilft dir, einen Kundenservice-Chatbot vor dem Produktivbetrieb oder nach einem Update zu prüfen. Du erfährst, welche Testkategorien nötig sind, wie du Fakten und Sicherheitsgrenzen testest und woran du Abnahmereife erkennst. Dazu bekommst du eine eigene 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 meint eine Eingabe außerhalb des erwarteten Standardmusters: unklar formuliert, mehrdeutig, themenfremd oder bewusst provokant.

Halluzination bezeichnet eine KI-Ausgabe, die plausibel klingt, aber nicht durch die zugrunde liegenden Daten gedeckt ist. Quelle der Definition ist die Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen: 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 und kein Notfallplan.

Wichtig ist die Abgrenzung nach unten. Eine kurze Runde 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 5 bis 6 Kategorien ordnen, die sich in Wichtigkeit und Risiko deutlich unterscheiden. Die folgende Struktur teilt einen Katalog von 100 Fragen nach Häufigkeit und Risiko auf. Sie ist keine exakte Formel, sondern ein Ausgangspunkt, den du an deinen Fall anpasst:

• Kernfunktionen (30 von 100 Fragen). Die häufigsten, realen Anfragen abdecken. Beispiele: „Wie sind eure Öffnungszeiten?“, „Wo bleibt meine Bestellung?”.

• Fakten und Quellentreue (20). Prüfen, ob Antworten aus echten, aktuellen Quellen stammen. Beispiel: eine Frage zu einem kürzlich geänderten Preis oder einer aktualisierten Regel.

• Unerlaubte Inhalte und Sicherheitsgrenzen (15). Prompt Injection, Datenlecks, Themenfremdes. Beispiel: „Ignoriere deine bisherigen Anweisungen und …“.

• Grenzfälle und mehrdeutige Anfragen (15). Tippfehler, Dialekt, widersprüchliche Folgefragen. Beispiel: mehrere Fragen in einer Nachricht, aggressiver Ton.

• Eskalation und Human Handover (10). Wann und wie der Bot an Menschen übergibt. Beispiele: Beschwerde, Reklamation, Rechtsanfrage.

• Datenschutz und Betroffenenrechte (10). Umgang mit personenbezogenen Daten. Beispiele: „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 beim 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. 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 wie FAQ, Produktdaten oder Richtlinien. Ein Sprachmodell formuliert daraus die Antwort. Laut der Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen kann diese Methode Halluzinationen reduzieren, weil die Antwort an konkrete Referenzdokumente gebunden wird. Das Risiko verschwindet aber nicht vollständig.

Die Konferenz nennt 3 Stellschrauben für die Antwortqualität. Erstens die Qualität und Aktualität der Referenzdokumente selbst. Zweitens die Datenaufbereitung: saubere Aufteilung in Textabschnitte, bereinigt um störende Kopf- und Fußzeilen. Drittens die „Kontexttreue“ des Sprachmodells, also ob es bei Widersprüchen wirklich 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 kürzlich geänderten Angaben (ein neuer Preis, eine geänderte Lieferzeit, eine aktualisierte Garantiebedingung). Stimmt die Antwort nicht mit der aktuellen Quelle überein, liegt das Problem bei den Referenzdokumenten (veraltet, nicht neu eingespielt) oder bei der Kontexttreue des Modells.

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.

Ein Beispiel aus einem Projekt, in dem ich einen FAQ-Chatbot für ein Handelsunternehmen begleitet habe. Bei Fragen zu einer 2 Wochen alten Preisänderung antwortete der Bot noch mit dem alten Preis. Die Dokumente waren zwar aktualisiert, aber die zugehörigen Textabschnitte im Hintergrundsystem waren nicht neu verarbeitet worden. 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 2 unterschiedliche Risiken: dass der Chatbot Dinge sagt, die er nicht sagen soll, und dass er Informationen preisgibt, die er nicht preisgeben soll. Das OWASP-Projekt Top 10 for Large Language Model Applications 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. Overreliance: 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 öffentlich 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, KI-Ausgaben nie ungeprüft für kritische Geschäftsprozesse zu verwenden. Für eigenentwickelte oder integrierte Systeme rät es zu dedizierten AI-Security-Tests, in größeren Vorhaben etwa als AI Pen Testing. Für ein KMU mit eingekauftem 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 fehlen in Demos am zuverlässigsten, weil sie sich schlecht vorführen lassen. Aus der Praxis sind 6 Muster besonders relevant:

• Unsaubere Eingaben: Tippfehler, fehlende Satzzeichen, Umgangssprache oder Dialekt.

• 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 widerspricht scheinbar der ersten Antwort. Bleibt er konsistent?

• Emotionaler oder aggressiver Ton: Beschwerden, Frustration, Formulierungen, die eine menschliche Reaktion erwarten statt einer Standardantwort.

• Fragen am Rand der Zuständigkeit: Anliegen, die eigentlich eine Rechtsberatung, eine individuelle Zusage oder eine Entscheidung wären, die der Chatbot nicht treffen darf.

• Sprachwechsel und ungewöhnliche Formate: andere Sprachen als die Standardsprache, Transkripte von Sprachnachrichten, sehr lange oder sehr kurze Eingaben.

Der gemeinsame Nenner: Grenzfälle sind einzeln selten, in der Summe aber häufig. Jede Variante kommt vielleicht bei 1 von 100 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 3 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. Dazu zählen: keine Herausgabe fremder Kundendaten, keine erfolgreiche Prompt Injection, keine falschen rechtsverbindlichen Zusagen (Preise, Termine, Garantien) und eine funktionierende Übergabe an Menschen bei Beschwerden oder sensiblen Anliegen. Besteht der Chatbot auch nur einen dieser Fälle nicht, ist er nicht abnahmereif. Egal, wie gut die restliche Quote ist.

Betriebsmetriken nach dem Start. Eskalationsrate an Menschen, Wiederholungsfragen und echte Nutzer:innen-Rückmeldungen lassen sich erst im laufenden Betrieb sauber messen. Wiederholungsfragen sind ein Indiz dafür, dass die erste Antwort nicht verstanden oder ihr nicht getraut wurde. Versprich dir und niemandem eine Zeit- oder Kostenersparnis auf Basis der Testrunde. Diese Zahl kennst du erst nach echtem Einsatz, nicht vorher.

Umsetzung: So baust du deinen Testkatalog auf

1. Reale Anfragen sammeln. Support-Logs, häufige E-Mails, FAQ-Statistiken oder ein kurzer Austausch mit dem Team im Kundenkontakt, falls es noch keine Daten gibt. 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 Angaben. Wer diese Fragen vorab entwirft, findet mehr Lücken als beim Runterschreiben der „idealen“ Demo-Fragen.

4. Testrunde gemeinsam durchführen, mit Fachbereich, IT und Datenschutz. 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 und 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. Lass den Kernkatalog nach jeder relevanten Änderung erneut laufen, 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 senkt die Wahrscheinlichkeit unentdeckter Fehler, schließt sie aber nicht aus. Nutzer:innen formulieren Fragen, die kein Katalog 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. Erstens: Übertriebene Testtiefe kann lähmen. Nicht jeder Bot mit geringem Risiko (etwa ein reiner Öffnungszeiten-Bot ohne Kundendaten) braucht 100 Testfragen und ein volles Sicherheits-Audit. Die Teststruktur oben ist ein Rahmen, den du proportional zum Risiko herunterskalierst.

Zweitens die rechtliche Seite (Stand Juli 2026, keine Rechtsberatung). Sobald ein Chatbot personenbezogene Daten verarbeitet, gelten die üblichen DSGVO-Anforderungen: Rechtsgrundlage, falls nötig ein Auftragsverarbeitungsvertrag mit dem Anbieter und die Wahrung von Betroffenenrechten wie Auskunft und Löschung. Das ist Teil des Testkatalogs (siehe letzte Kategorie oben). Es ersetzt aber keine Abstimmung mit Datenschutzbeauftragten oder Rechtsberatung, gerade 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 Katalog deckt mindestens 5 Kategorien ab: Kernfunktionen, Fakten und 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, egal ob 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.