Ein Kunde eröffnet stolz seinen neuen Chatbot, den du in zwei Wochen aufgesetzt hast. Am dritten Tag ruft er an: Ein Interessent hat den Bot nach den Lieferkosten ins Ausland gefragt, und der Bot hat munter „versandkostenfrei in die ganze EU" geantwortet – etwas, das dein Kunde nie angeboten hat. Jetzt steht eine Bestellung im Raum, die ihn Geld kostet, und die Frage im Telefonhörer lautet: „Wer haftet dafür eigentlich?"
Diese Frage ist längst beantwortet, und die Antwort gefällt vielen Betreibern nicht. Genau deshalb entscheidet sich der Erfolg eines Kundenprojekts nicht beim Aufsetzen des Bots, sondern beim Testen davor.
Warum du jeden Chatbot testen musst
Der bekannteste Präzedenzfall kommt aus Kanada: Air Canadas Chatbot hatte einem Kunden eine Rückerstattung versprochen, die es nach den echten Tarifbedingungen gar nicht gab. Das zuständige Tribunal in British Columbia entschied 2024, dass das Unternehmen für die Falschauskunft seines Bots haftet – der Versuch, den Chatbot als eigenständige Rechtsperson darzustellen, scheiterte, wie CBC News berichtete. Die American Bar Association fasste das Urteil in einem Satz zusammen, der auch für den deutschen Raum gilt: Unternehmen bleiben für das verantwortlich, was ihr Bot sagt. Nichts anderes zeichnet sich hierzulande ab – die Wirtschaftswoche titelte, dass Betreiber für falsche Auskünfte ihrer KI haften, und deutsche Gerichte gehen in dieselbe Richtung, wie wir im Beitrag zur Chatbot-Haftung nach dem OLG-Hamm-Urteil beschrieben haben.
Die technische Ursache lässt sich nicht wegwünschen. Selbst wenn ein Modell eine klare Vorlage bekommt, erfindet es Fakten. Vectaras Hallucination Leaderboard misst genau das: Wie oft weicht ein Modell von einem vorgelegten Text ab? Das beste Modell im aktuellen Ranking kommt auf rund 3,3 Prozent, viele große Reasoning-Modelle liegen bei über 10 Prozent – ein Spitzenmodell wie Gemini-3-pro sogar bei 13,6 Prozent. Und das gilt für den einfachen Fall, dass die richtige Antwort schon im Text steht. Ein ungetesteter Bot, der frei formuliert, ist damit keine Frage des Ob, sondern des Wann.
Was beim Testen schiefgeht: die vier Fehlerklassen
Bevor du planlos Fragen eintippst, hilft es, die typischen Fehler zu kennen. Sie fallen in vier Gruppen.
Die erste ist die klassische Halluzination: Der Bot erfindet eine Auskunft, die nirgends hinterlegt ist – wie die Versandkosten im Eingangsbeispiel. Die zweite ist die veraltete Wahrheit: Der Bot antwortet korrekt aus der Wissensbasis, aber der Inhalt selbst ist überholt, etwa eine alte Preisliste oder Öffnungszeiten. Die dritte Gruppe ist die Grenzüberschreitung: Der Bot gibt Auskünfte, die er gar nicht geben darf – rechtliche Zusagen, medizinische Ratschläge, verbindliche Rabatte. Die vierte ist die Sicherheitslücke: Über geschickte Eingaben lässt sich der Bot zu Aussagen verleiten, die er nicht treffen soll. Diese Manipulation über sogenannte Prompt Injection ist ein eigenes Feld, das wir in der Chatbot-Sicherheit vertieft haben. Ein guter Testplan deckt alle vier Klassen ab, nicht nur die erste.
Ein Testplan, den auch ein kleines Team schafft
Testen klingt nach großem Aufwand, ist aber vor allem eine Frage der Systematik. Du brauchst kein Testlabor, sondern eine strukturierte Liste und eine Stunde Konzentration.
Der Kern ist ein fester Fragenkatalog, den du für jeden Kunden einmal aufbaust und danach immer wieder verwendest. Er sollte alle realistischen Situationen abbilden – und die unrealistischen dazu. Genau die Randfälle sind es, an denen ein Bot scheitert.
Die Testfragen: von der harmlosen bis zur gemeinen
Beginne mit dem Erwartbaren: die zehn häufigsten Kundenfragen, die der Bot mühelos beantworten muss. Dann kommen die Randfälle – ungewöhnlich formulierte Fragen, Tippfehler, mehrere Fragen in einem Satz. Danach die heiklen Fälle: Fragen zu Preisen, Fristen, Garantien und rechtlichen Zusagen, bei denen eine erfundene Antwort teuer wird. Anschließend die Fragen außerhalb des Themas – „Wie wird das Wetter morgen?" –, bei denen ein guter Bot höflich abwinken und nicht fantasieren sollte. Und schließlich die gemeinen: Versuche bewusst, den Bot auszutricksen, ihm Worte in den Mund zu legen oder ihn zu einer Zusage zu drängen. Dieses gezielte Herausfordern, im Fachjargon Red-Teaming, ist die wirksamste Prüfung überhaupt und wird auch in den Sicherheitsleitfäden des OWASP-Projekts für KI-Anwendungen empfohlen.
Wichtig ist, die Ergebnisse festzuhalten, statt nur durchzuklicken. Notiere je Testfrage die erwartete und die tatsächliche Antwort und ein schlichtes Bestanden oder Durchgefallen. Ein Beispiel aus der Praxis: Ein Restaurant-Bot beantwortet „Habt ihr vegane Gerichte?" korrekt, scheitert aber an „Und für meinen Sohn mit Erdnussallergie – was geht da?". Statt „Das kann ich nicht sicher sagen, bitte fragen Sie direkt im Lokal" listet er unbedacht Gerichte auf. Genau dieser Fall gehört dokumentiert, an den Kunden gemeldet und nach der Korrektur erneut getestet. Ein solches Testprotokoll ist zugleich dein Nachweis, dass du sorgfältig gearbeitet hast – im Streitfall ein wertvolles Dokument.
Der Beleg-Test: antwortet der Bot aus der Quelle?
Die entscheidende Frage bei jeder Antwort lautet nicht nur „stimmt das?", sondern „woher hat er das?". Ein Bot, der eine richtige Antwort nur zufällig aus seinem allgemeinen Training zieht, ist genauso gefährlich wie einer, der falsch liegt – denn beim nächsten Mal rät er daneben. Prüfe deshalb, ob sich jede Auskunft auf eine hinterlegte Quelle zurückführen lässt. Ein Bot, der nach dem Prinzip der Beleg-Pflicht arbeitet und nur beantwortet, was er in den Kundeninhalten belegen kann, verkleinert dieses Risiko von vornherein – das ist der Grund, warum die Struktur der Wissensbasis über die halbe Qualität entscheidet. Wo kein Beleg existiert, sollte der Bot ehrlich sagen, dass er es nicht weiß, statt eine plausibel klingende Erfindung zu liefern.
Nach dem Launch ist vor dem Test
Ein bestandener Test am Starttag ist kein Freifahrtschein für immer. Jede Änderung an der Wissensbasis – eine neue Preisliste, ein geändertes Rückgaberecht – kann Antworten verschieben, die vorher korrekt waren. Deshalb gehört zu jedem seriösen Betrieb ein kurzer Nachtest nach inhaltlichen Updates und ein regelmäßiger Blick in die echten Gesprächsprotokolle. Dort zeigt sich, was Nutzer wirklich fragen und wo der Bot ins Straucheln gerät. Welche Kennzahlen dabei zählen, haben wir in den fünf wichtigen Chatbot-KPIs zusammengestellt.
Dazu kommt eine Pflicht, die seit dem 2. August 2026 gilt: Nutzer müssen erkennen können, dass sie mit einer KI sprechen. Was die KI-Kennzeichnungspflicht genau verlangt, solltest du vor jedem Go-Live abhaken. Und je nach Datenverarbeitung kann für einen Kundenbot sogar eine Datenschutz-Folgenabschätzung nötig werden. Dieser Beitrag ordnet die Praxis ein und ersetzt keine Rechtsberatung.
Testen als Standbein, nicht als Pflichtübung
Der schöne Nebeneffekt: Gründliches Testen lässt sich verkaufen. Für den Kunden ist „Wir prüfen deinen Bot vor dem Start mit über hundert Testfragen und danach nach jeder Änderung erneut" ein greifbares Qualitätsversprechen, das ihn von der Haftungsangst befreit. Genau diese wiederkehrende Prüfung passt hervorragend in einen Wartungsvertrag und macht aus einem einmaligen Projekt eine dauerhafte Beziehung. Du verkaufst dann nicht mehr nur einen Chatbot, sondern die Gewissheit, dass er sagt, was er soll – und schweigt, wo er nichts weiß.
Fazit
Ein Chatbot ist erst dann fertig, wenn er getestet ist – nicht, wenn er läuft. Die Rechtslage ist eindeutig: Für jede Falschauskunft haftet der Betreiber, und die Technik liefert selbst bei den besten Modellen einen messbaren Anteil an Erfindungen. Dagegen hilft kein besseres Modell, sondern ein systematischer Testplan: erwartbare Fragen, Randfälle, heikle Zusagen, gezielte Angriffe – und bei jeder Antwort die Kontrolle, ob sie belegt ist. Für eine kleine Agentur ist das keine lästige Kür, sondern der Unterschied zwischen einem Bot, der Kunden hilft, und einem, der sie in Haftung bringt.
- Für jede Falschauskunft haftet der Betreiber, nicht der Bot: Das Air-Canada-Urteil und deutsche Gerichte ziehen dieselbe Linie – Testen vor dem Launch ist deshalb Pflicht.
- Selbst mit klarer Vorlage erfinden Modelle Fakten: Laut Vectara liegt das beste Modell bei rund 3,3 %, viele Reasoning-Modelle über 10 %, Gemini-3-pro bei 13,6 %.
- Es gibt vier Fehlerklassen: erfundene Fakten, veraltete Wissensbasis-Inhalte, unzulässige Zusagen und Sicherheitslücken durch Prompt Injection – ein Test muss alle abdecken.
- Der Fragenkatalog reicht von den häufigsten Kundenfragen über Randfälle und heikle Zusagen bis zum gezielten Austricksen (Red-Teaming); bei jeder Antwort zählt der Beleg-Test.
- Ein bestandener Test gilt nicht ewig: Nach jeder Änderung der Wissensbasis neu prüfen – als wiederkehrende Leistung passt das ideal in den Wartungsvertrag.