Wie man einen Kanzlei-Bot testet, bevor er live geht

Würdigung — der Reflex „einfach live schalten" ist verständlich, aber gefährlich#

Einen Bot zu bauen ist heute schnell gemacht — ein paar Zeilen, ein Modell-Aufruf, fertig. Genau das ist die Falle: Weil der Bau so leicht aussieht, wird die Prüfung übersprungen. Bei einem Spielzeug-Bot ist das egal. Bei einem Bot auf einer Kanzlei-Website nicht — er spricht im Namen der Kanzlei, und was er sagt, fällt auf sie zurück.

Die Sorge ist berechtigt: Ein Sprachmodell ist nicht deterministisch. Es kann auf dieselbe Frage zweimal unterschiedlich formulieren, und es kann — ohne Schutzmaßnahmen — Dinge behaupten, die nicht stimmen, oder in eine Rechtsberatung abrutschen, die ihm verboten ist. Daraus den Schluss zu ziehen „testen lohnt sich nicht, das Ergebnis schwankt ja ohnehin" ist aber falsch. Man testet einen Bot anders als ein klassisches Programm — nicht gar nicht.

Die meisten Schichten sind gar nicht das Sprachmodell#

Der erste wichtige Befund: Ein gut gebauter Bot besteht zum größten Teil aus ganz normalem, deterministischem Code rund um den eigentlichen Modell-Aufruf. Und dieser Code ist exakt so testbar wie jeder andere — mit denselben automatischen Tests, die bei uns vor jedem Push laufen.

Bei unserem Concierge gibt es genau solche Schichten, und jede hat ihre eigenen Tests. Die Wissens-Zusammenstellung — der Block aus FAQ, Leistungsdaten und Artikel-Metadaten, aus dem der Bot antwortet — ist eine reine Funktion: Gleiche Eingabe, gleicher Block. Das lässt sich Wort für Wort prüfen. Die Schutz-Schichten vor dem Modell-Aufruf — Eingabe-Längenprüfung, eine Heuristik gegen Prompt-Injection, eine Heuristik gegen offensichtliche Verbots-Themen wie konkrete Steuerberatung — sind ebenfalls reine Logik und werden mit konkreten Beispiel-Eingaben getestet. Wie diese gestaffelte Verteidigung insgesamt aufgebaut ist, zeigt der Insight zum grounded-only Concierge.

Schon hier liegt ein großer Teil der Qualitätssicherung — und nichts davon ist „KI-Magie", sondern handfest prüfbarer Code.

Das wichtigste Test-Ziel: keine Fehlalarme bei echten Fragen#

Bei den Schutz-Schichten gibt es ein Qualitätsziel, das oft übersehen wird. Eine Verbots-Heuristik, die jede zweite legitime Frage fälschlich abblockt, ist nutzlos — der Bot würde Mandanten abweisen, die nur wissen wollen, was die Kanzlei anbietet. Das Ziel ist deshalb nicht „blockt möglichst viel", sondern „blockt das Offensichtliche, ohne eine einzige legitime Frage zu erwischen".

Genau das ist ein Test, den man schreiben kann: eine Sammlung echter, harmloser FA²-Fragen, die alle durchgehen müssen, und eine Sammlung klar verbotener Fragen, die alle hängenbleiben müssen. Erst wenn beide Listen sauber durchlaufen, ist die Heuristik richtig eingestellt — bewusst eng, hohe Treffsicherheit, keine Fehlalarme. Die eigentliche inhaltliche Grenze bleibt dabei der System-Prompt; die Heuristik fängt nur die billigen, offensichtlichen Fälle ab, bevor das Modell überhaupt antwortet.

Die eine nicht-deterministische Schicht — und wie man sie bewertet#

Bleibt die Schicht, die sich nicht Wort für Wort festnageln lässt: die eigentliche Antwort des Modells. Hier prüft man nicht auf exakten Wortlaut, sondern auf Verhalten. Man stellt dem Bot eine Sammlung repräsentativer Fragen und bewertet die Antworten gegen klare Kriterien: Bleibt er im erlaubten Rahmen, also grounded — stützt er sich nur auf das vorgegebene Wissen, statt zu erfinden? Verweigert er bei einer Rechts- oder Steuerfrage sauber und eskaliert an den Menschen? Verlinkt er den passenden eigenen Inhalt, statt einen zu erfinden, den es nicht gibt? Bleibt der Ton sachlich und im Namen der Kanzlei angemessen?

Diese Prüfung ist halb automatisierbar, halb Handarbeit. Ein Teil — etwa „enthält die Antwort nur Links, die wirklich existieren?" — lässt sich automatisch gegenprüfen. Bei uns sichert ein eigener Reality-Check ab, dass die Inhalte, auf die der Bot verweist, real auflösbar sind und keine veralteten Preise auftauchen. Der wertende Teil — „klingt das angemessen, eskaliert es richtig?" — bleibt eine bewusste menschliche Abnahme an einer festen Fragen-Liste, die man bei jeder Änderung erneut durchgeht. Dieselbe Disziplin, mit der eine ganze Bau-Pipeline Fehler vor dem Live-Gang abfängt, trägt also auch den Bot.

Warum das laufend bleibt, nicht einmalig#

Ein Bot ist nicht nach der ersten Abnahme fertig. Sein Wissen ändert sich — neue Leistungen, neue Inhalte, angepasste Preise. Jede dieser Änderungen kann das Verhalten verschieben. Deshalb gehört die Prüf-Liste nicht in eine einmalige Abnahme, sondern in die laufende Routine: Bei jeder Wissens-Änderung läuft sie erneut, die automatischen Schichten ohnehin bei jedem Code-Stand. Der Insight zur RAG-Architektur ohne Vektor-Datenbank zeigt, warum gerade ein wissensgetriebener Bot bei jeder Inhalts-Änderung neu betrachtet werden will.

Was Kanzleien davon haben#

• Vertrauen statt Hoffnung: Ein abgenommener Bot ist nachprüfbar im Rahmen geblieben — keine bösen Überraschungen im Namen der Kanzlei.
• Der größte Teil ist normaler Code: Wissens-Aufbau und Schutz-Schichten sind handfest testbar — viel Qualität entsteht, bevor das Modell überhaupt antwortet.
• Keine Fehlalarme: Eine sauber eingestellte Schutz-Schicht weist legitime Mandanten-Fragen nicht ab, sondern fängt nur das Offensichtliche.
• Laufende Verlässlichkeit: Eine feste Prüf-Liste bei jeder Wissens-Änderung hält den Bot über Monate stabil, statt ihn einzufrieren.

Für eine nüchterne Abnahme-Strategie Ihres Bots — oder die Vorab-Frage, ob ein Bot überhaupt der richtige Schritt ist — empfehlen wir ein Gespräch in der KI-Werkstatt oder den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Ein Sprachmodell ist nicht deterministisch — daraus folgt aber nicht, dass man einen Bot nicht testen kann, sondern dass man ihn anders testet als ein klassisches Programm. Der größte Teil eines gut gebauten Bots ist deterministischer Code rund um den Modell-Aufruf: Die Wissens-Zusammenstellung und die Schutz-Schichten gegen Injection und Verbots-Themen sind reine Logik und exakt so testbar wie jeder andere Code. Das wichtigste Ziel dabei ist, dass keine legitime Mandanten-Frage fälschlich abgeblockt wird. Die eine nicht-deterministische Schicht — die Modell-Antwort selbst — bewertet man nicht auf Wortlaut, sondern auf Verhalten: bleibt der Bot grounded, eskaliert er bei Rechtsfragen sauber, verlinkt er nur Existierendes. Ein Teil davon läuft automatisch, der wertende Teil bleibt menschliche Abnahme an einer festen Fragen-Liste — und die wird bei jeder Wissens-Änderung erneut durchlaufen, nicht einmalig vor dem Start.

Quellen#

• Anthropic — Tests entwickeln und auswerten — abgerufen 2026-06-13
• Anthropic — Evaluierungs-Werkzeug (Konsole) — abgerufen 2026-06-13
• Anthropic — Building effective agents — abgerufen 2026-06-13

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung, keine Rechtsberatung. Die beschriebene Prüf-Strategie bildet die Eigenpraxis beim FA²-Concierge ab; Umfang und Tiefe einer Bot-Abnahme hängen vom konkreten Anwendungsfall ab.