Der Filter, der die Arbeit blockierte
Ein Techniker fragte, was passiert, wenn zwei Reinigungsmittel gemischt werden. Der Filter stufte das als Anfrage nach gefährlichem Wissen ein und lehnte ab — allgemein vertretbar und genau falsch in einem Werk, in dem diese Frage eine Sicherheitsvorschrift ist.
Die Ablehnung
Das Werk betreibt einen Wartungsassistenten über die eigene Dokumentation, zu der Sicherheitsdatenblätter gehören. Ein Techniker fragte, was passiert, wenn ein bestimmter saurer Reiniger auf einen bestimmten chlorbasierten trifft — eine Frage mit dokumentierter Antwort und offensichtlichem betrieblichem Anlass.
Der Inhaltsfilter stufte sie als Suche nach Informationen zur Herstellung eines Gefahrstoffs ein und lehnte ab. Die Antwort stand in einem Dokument, das der Techniker gelesen haben muss, lag im Index — und der Assistent wollte sie nicht wiederholen.
Warum das kein Justierungsfehler ist
Kumar und Kollegen veröffentlichten 2025 eine Arbeit zu Guardrails, die zeigt, dass die Verringerung der einen Fehlerart die andere erhöht, dass es keine Konfiguration gibt, die beide vermeidet, und dass die Wahl ein Handel ist statt eine Frage der richtigen Einstellungen.
Diese Rahmung hat uns aufhören lassen, das als einmal zu behebenden Defekt zu behandeln. Jede Schwelle, die wir setzen, ist eine Entscheidung darüber, welchen Fehler wir bevorzugen — und ein Filter, der nie legitime Arbeit blockiert, lässt etwas durch, das wir lieber aufgehalten hätten.
Was wir messen
Beide Seiten, bewusst — denn nur Ablehnungen zu messen erzeugt ein System, das nie etwas ablehnt. Wir erfassen blockierte Anfragen, die ein Prüfer als legitim einstuft, und lassen wöchentlich eine Menge gegnerischer Prompts laufen, die der Filter fangen soll.
Die erste Zahl lag anfangs bei sieben Prozent Ablehnungen, hoch genug, dass Nutzer aufhören zu fragen. Die zweite sieht sich niemand gern an, denn ein Filter, der nie etwas wirklich Schlechtes blockiert hat, ist nicht geprüft — er wurde nur nicht angegriffen.
| Einstellung | Was man bekommt |
|---|---|
| Überall streng | Blockiert legitime Arbeit. Nutzer fragen nicht mehr |
| Überall locker | Lässt durch, was Urteil braucht |
| Je Bestand und Nutzerrolle | Mehr Konfiguration, bessere Passung |
| Ablehnen plus an Menschen leiten | Langsamer, und nichts geht still verloren |
Was wir geändert haben
Der Filter wird je Deployment konfiguriert statt global. Im Werksassistenten sind Fragen zu chemischen Wechselwirkungen erwarteter Verkehr, und die Schwelle bildet das ab; in einem kundengerichteten Assistenten derselben Plattform sind sie es nicht, und sie tut es nicht.
Das klingt selbstverständlich und verlangte einzuräumen, dass eine einheitliche Sicherheitskonfiguration über alle Deployments eine Bequemlichkeit für uns war und keine Eigenschaft, die jemand wollte. Die Sicherheitsfachkraft des Werks hat die Konfiguration freigegeben — dort gehört diese Entscheidung hin.
Ablehnungen sind Defekte mit Ticket
Jede Ablehnung wird mit der Frage protokolliert, und eine Stichprobe prüft wöchentlich jemand, der beurteilen kann, ob sie hätte abgelehnt werden sollen. Die, die es nicht hätten sollen, werden zu Tickets — und das Ticket richtet sich gegen die Filterkonfiguration, nicht gegen den Nutzer.
Dieser Prozess senkte die Zahl über ein Quartal von sieben auf unter zwei Prozent. Wichtiger noch hat er die Haltung zum Filter geändert: Er ist eine Komponente mit Fehlerquote statt einer moralischen Position, und Leute melden ihn, wenn er falsch liegt.
Wo wir Überblockung hinnehmen
Bei allem, was Personaldaten berührt, und bei allem, was auf eine Rechtsauskunft hinausliefe. In beiden Fällen lehnen wir lieber eine legitime Frage ab, als eine zu beantworten, die wir nicht beantworten sollten — die Kostenasymmetrie ist deutlich, und die Ablehnung hat einen klaren nächsten Schritt: eine bestimmte Person fragen.
Die Ablehnungsnachricht nennt deren Rolle. Ein Filter, der sagt, er könne nicht helfen, bringt Nutzern bei, dass das System unzuverlässig ist; einer, der sagt, das geht an den Betriebsrat oder an die Rechtsabteilung, leistet die Weiterleitung, die die Organisation ohnehin wollte.
Der Teil, den wir zweimal falsch gemacht haben
Die Ausgabe mit derselben Konfiguration zu filtern wie die Eingabe. Eine Antwort, die ein Sicherheitsdatenblatt zitiert, enthält genau das Vokabular, nach dem ein Eingabefilter sucht — unser Ausgabefilter blockierte also richtige Antworten auf Fragen, die der Eingabefilter erlaubt hatte.
Eingabe und Ausgabe brauchen verschiedene Regeln, und die Ausgaberegel handelt vor allem davon, ob der Inhalt durch ein abgerufenes Dokument gedeckt ist, nicht davon, welche Wörter darin vorkommen. Nach der Trennung verschwand das Problem — es hatte uns zwei Wochen verwirrender Meldungen gekostet.
Was wir nicht behaupten
Wir behaupten nicht, unsere Konfiguration sei für andere richtig. Sie ist richtig für ein Werk mit einer Sicherheitsfachkraft, die sie freigegeben hat, und dieselben Einstellungen wären in einem Verbraucherprodukt nicht vertretbar.
Wir behaupten auch nicht, zwei Prozent seien eine gute Quote falscher Ablehnungen. Es ist der Punkt, an dem die messbaren Beschwerden aufhörten, was nicht dasselbe ist — und unter den verbleibenden Ablehnungen sind einige, von denen wir schlicht nichts erfahren haben, weil der Nutzer aufgegeben hat, statt sie zu melden.