08.08.2026•8 Min. Lesezeit

KI-Assistenten testen: woran du merkst, ob er wirklich taugt

Ob dein KI-Assistent taugt, entscheidet ein fester Satz echter Fälle, den du vorher aufschreibst und nach jeder Änderung erneut durchlaufen lässt. Zehn Fälle reichen. Bauchgefühl reicht nicht, weil jeder halbwegs gebaute Assistent drei gute Antworten hinbekommt.

Interessant wird der vierte Fall. Der schiefe. Der, zu dem in deiner Wissensbasis nichts steht.

Dieser Test kostet dich beim ersten Mal etwa eine Stunde. Danach zehn Minuten, immer wenn du etwas änderst. Wer ihn überspringt, weiß auch nach vier Wochen Nutzung nicht, ob er dem Ding eine Kundenantwort anvertrauen kann.

Warum das Bauchgefühl beim eigenen Assistenten immer täuscht

Wer einen Assistenten baut, prüft ihn mit genau den Fällen, die er beim Bauen im Kopf hatte. Das ist menschlich und trotzdem wertlos. Du hast die Constraints, also die festen Regeln für den Assistenten, für dieses Szenario geschrieben. Die Dokumente hast du für dieses Szenario ausgewählt. Und dann fragst du genau dieses Szenario ab.

In einem Workshop hat eine Teilnehmerin diesen Zustand präziser beschrieben, als ich es je hinbekommen hätte: „So habe ich eine ‚Test’-Skill aber keinen Alltags-Skill.” Der Assistent funktioniert im Demo-Fall und liegt im echten Postfach daneben. Wie du aus dem Demo-Zustand rauskommst, steht ausführlicher in Test-Skill zu Alltags-Skill.

Testen heißt deshalb: Du prüfst gegen Fälle, die du dir nicht ausgesucht hast.

Der Testsatz: zehn echte Fälle, gesammelt bevor du baust

Nimm die letzten Wochen deiner tatsächlichen Arbeit. Kundenmails, Angebotsanfragen, interne Rückfragen, was auch immer der Assistent später abdecken soll. Zehn davon kopierst du wortwörtlich in ein Dokument. Keine geglätteten Formulierungen, keine idealtypischen Anfragen.

Die Mischung entscheidet. Ich halte diese Verteilung für praktikabel:

Vier Standardfälle. Genau das, wofür der Assistent gedacht ist. Wenn er die nicht kann, hörst du hier auf.
Drei Randfälle. Anfragen, die fast in die Aufgabe passen, aber einen Sonderfall enthalten: Rabattwunsch, ungewöhnliche Frist, ein Produkt, das ihr letztes Jahr eingestellt habt.
Zwei Fälle mit Lücke. Fragen, zu denen in der Wissensbasis nichts steht.
Ein Fall mit falscher Prämisse. Eine Frage, die eine Behauptung enthält, die schlicht nicht stimmt.

Zu jedem Fall notierst du in einem Satz, wie eine brauchbare Antwort aussieht. Es geht um die Untergrenze: Was muss drinstehen, damit du die Antwort ohne Nacharbeit verwenden würdest? Ohne diese Notiz bewertest du hinterher wieder nach Gefühl, und das Gefühl ist bei selbstgebauten Dingen großzügig.

Falls dir beim Sammeln auffällt, dass du gar nicht sauber sagen kannst, was der Assistent leisten soll: Dann ist die Spezifikation dran, bevor der Test dran ist. Das Schema aus Aufgabe, Wissensdaten und Constraints steht in Aufgabe, Wissen, Constraints.

Die Frage, die er nicht beantworten können darf

Jeder Assistent braucht eine Frage, bei der die richtige Reaktion „weiß ich nicht” lautet.

Konstruiertes Beispiel, das aber jeder Handwerksbetrieb so bauen könnte: Der Assistent kennt eure Leistungen und Preise. Die Testfrage lautet „Was kostet bei euch eine Wärmepumpen-Wartung im Wartungsvertrag?” und Wartungsverträge gibt es bei euch nicht. Ein guter Assistent sagt, dass er dazu nichts hinterlegt hat, und schlägt vor, wen man fragt. Ein schlechter erfindet eine Zahl, die plausibel klingt.

Genau dieser Unterschied ist der Grund, warum ich Assistenten für Kundenkommunikation nie ohne Lückentest freigebe. Die Stanford-Studie „Hallucination-Free?” von Magesh, Surani, Dahl, Suzgun, Manning und Ho (Stanford RegLab und HAI, 2024) hat kommerzielle Rechtsrecherche-Tools geprüft, die genau so gebaut sind wie ein Assistent mit Firmenwissen: Modell plus angebundene Dokumentenbasis. Ergebnis: Lexis+ AI lieferte bei über 17 Prozent der Anfragen falsche oder falsch belegte Antworten, Westlaws AI-Assisted Research bei rund einem Drittel (Stanford HAI, RegLab, arXiv 2405.20362, peer-reviewed im Journal of Empirical Legal Studies 2025).

Das waren Produkte von LexisNexis und Thomson Reuters, gebaut von großen Teams, beworben mit dem Versprechen, Halluzinationen seien ausgeschlossen. Wenn deren Trefferquote so aussieht, ist die Erwartung an dein Wochenend-Projekt entsprechend zu kalibrieren. Eine angebundene Wissensbasis senkt das Risiko deutlich, beseitigt es aber nicht.

Erfindet er, oder fragt er nach?

Der Lückentest hat drei mögliche Ausgänge, und alle drei sagen dir etwas anderes.

Er sagt ehrlich, dass er es nicht weiß. Bestes Ergebnis. Prüf trotzdem, ob er dabei einen sinnvollen nächsten Schritt anbietet.

Er fragt nach. Auch gut, oft sogar besser. Eine Rückfrage bedeutet, dass er die Lücke erkannt hat und sie schließen will.

Er antwortet flüssig und falsch. Das ist der Fall, für den du das Constraint-Set nachschärfen musst. Meistens fehlt ein expliziter Satz in der Art von „Wenn die Information nicht in den hinterlegten Dokumenten steht, sage das und rate nicht.” Wie man solche Regeln formuliert, damit sie im Alltag greifen, steht in Constraints schreiben.

Ein Detail, das leicht untergeht: Prüf auch die Herkunft. Frag nach der Quelle für eine Aussage, und zwar bei einer Antwort, die richtig war. Wenn der Assistent dann ein Dokument nennt, das es nicht gibt, hast du zwar die richtige Antwort bekommen, aber nicht aus dem Grund, den du annimmst.

Wer testet: bitte nicht der Erbauer

Der wichtigste Satz in diesem Artikel: Lass jemand anderen testen.

Du kennst die Wissensbasis. Du formulierst deine Fragen unbewusst so, dass sie zu den hinterlegten Dokumenten passen. Ein Kollege, der die Dokumente nie gesehen hat, fragt anders, unpräziser, mit mehr Kontext im Kopf und weniger im Text. Genau so fragen später alle anderen auch.

Wenn du solo arbeitest, geht es trotzdem. Zwei Möglichkeiten: Du lässt eine befreundete Person aus einer anderen Branche zehn Fragen stellen. Oder du nimmst die Fragen, die dir echte Kunden per Mail geschickt haben, im Originalwortlaut, inklusive Tippfehler und fehlendem Kontext.

Wie oft hast du deinen Assistenten bisher mit einer Frage getestet, die du nicht selbst formuliert hast?

Sobald mehr als eine Person den Assistenten nutzt, wird das Ganze ohnehin zum Teamthema. Dazu gehört auch, wer bei Fehlern Bescheid gibt, siehe KI-Assistenten im Team teilen.

Regressionsprüfung: nach jeder Änderung an der Wissensbasis

Hier trennt sich der ordentliche vom improvisierten Aufbau. Du fügst ein Dokument hinzu, und plötzlich antwortet der Assistent auf eine Frage anders als vorher. Das neue Dokument muss dafür nicht falsch sein. Es reicht, wenn es mit einem alten kollidiert: alte Preisliste, neue Preisliste, beide in der Basis. Der Assistent zieht sich eine davon.

Deswegen läuft der Testsatz nach jeder Änderung noch einmal komplett durch. Zehn Fälle, zehn Minuten, Ergebnis in einer Tabelle mit Datum. Beim dritten Durchlauf siehst du Muster: Fall 7 kippt jedes Mal, wenn du an den Vertriebsunterlagen etwas anfasst.

Für die Tabelle reichen vier Spalten: Datum, Fall-Nummer, Bewertung, Notiz. Als Bewertung nutze ich drei Stufen, weil Schulnoten hier nur Scheingenauigkeit erzeugen. Grün heißt: geht so raus. Gelb heißt: brauchbar, aber ich musste anfassen. Rot heißt: falsch, unvollständig oder am Thema vorbei. Interessant sind die gelben Fälle, denn sie zeigen dir, welche Korrektur du immer wieder von Hand machst. Genau diese Korrektur gehört anschließend in die Constraints, damit du sie nicht ein viertes Mal tippst.

Und wenn du merkst, dass du beim Testen ständig neue Dokumente nachschiebst, ist das ein Signal. Dann war die Aufgabe zu breit geschnitten.

Welche Dokumente überhaupt in die Basis gehören und welche du besser draußen lässt, ist ein eigenes Thema, das ich in Wissensbasis: Dokumente auswählen behandle. Was nach dem Test kommt, also die laufende Pflege, steht in Wartung.

Der zugelassene Einwand: „Das ist doch Overkill für ein Nebenprojekt”

Berechtigt. Für einen Assistenten, der dir Blogüberschriften vorschlägt, ist ein zehnteiliger Testsatz mit Regressionslauf tatsächlich zu viel. Da merkst du den Mist sofort, weil du jede Ausgabe ohnehin liest.

Die Grenze verläuft an der Sichtbarkeit: Sobald der Output ohne deine Prüfung nach außen geht oder eine Entscheidung stützt, brauchst du den Testsatz. Bei allem, was nur dir Vorschläge macht, reichen drei Fälle und ein wachsames Auge.

Zur Kalibrierung hilft ein Befund aus dem Feldexperiment von Dell’Acqua, McFowland, Mollick, Lifshitz-Assaf, Kellogg, Rajendran, Krayer, Candelon und Lakhani (Harvard Business School Working Paper 24-013, 2023) mit 758 BCG-Beratern: Bei Aufgaben innerhalb der KI-Fähigkeiten erledigten die Teilnehmenden 12,2 Prozent mehr Aufgaben und arbeiteten 25,1 Prozent schneller. Bei Aufgaben außerhalb dieser Zone kamen sie mit KI 19 Prozentpunkte seltener zur richtigen Lösung als die Kontrollgruppe ohne KI (HBS Working Paper 24-013, Harvard Crimson, Organization Science 2025).

Dein Testsatz hat genau einen Zweck: herauszufinden, auf welcher Seite dieser Grenze deine Aufgabe liegt. Ohne Test rätst du.

Was du heute in einer Stunde machen kannst

Öffne dein Postfach. Kopier zehn echte Anfragen in ein Dokument, davon zwei, zu denen dein Assistent nichts wissen kann. Schreib zu jeder in einem Satz die Untergrenze einer brauchbaren Antwort. Lass sie durchlaufen und trag die Ergebnisse mit Datum ein.

Diese Datei ist ab jetzt der Maßstab. Sie ist auch der Grund, warum ein Assistent überhaupt zur wiederverwendbaren Skill statt zum Einmal-Prompt wird, und sie gehört zu jedem Assistenten, den du nach dem Guide für KI-Assistenten mit Firmenwissen baust.

Wenn du vorher wissen willst, ob dein Setup und deine Daten überhaupt tragen: Diese Vorprüfung steckt im KI-Readiness-Check. Der Testsatz sagt dir, ob der Assistent taugt. Der Check sagt dir, ob die Grundlage stimmt, auf der er steht.

Quellen

Benedikt Backhaus

Experte für KI, Automatisierung und die Zukunft der Arbeit. Ich helfe Unternehmen und Einzelpersonen dabei, die Potenziale neuer Technologien zu nutzen.

Mehr über mich →Termin buchen →