Der Vokabular-Konflikt: Wenn ein Sicherheitsklassifikator Ihre gesamte Domain markiert

Ein allgemeiner Sicherheitsklassifikator birgt eine versteckte Annahme: Die Rede über Angreifer:innen, Exploits und Geldwäsche gilt als selten und verdächtig. Wendet man ihn auf ein Sicherheits- und Compliance-Produkt an, kehrt sich diese Annahme um. Über einen Produktionszeitraum von 17 Tagen bis zum 10. April 2026 flaggte die Mistral-Moderations-API (mistral-moderation-latest, damals aufgelöst auf mistral-moderation-2603) in unserer Anwendung 15 Nachrichten als schädlich. Jede davon war ein falsch positiver Alarm. Die Präzision lag bei null. Nicht beeinträchtigt, nicht verrauscht: null von fünfzehn.

Dieses Ergebnis ist eine konkrete Messung unseres eigenen Traffics und benennt einen Fehlerzustand, der erst sichtbar wird, wenn man die Flags einzeln liest. Wir nennen es den Vokabular-Konflikt: In einem spezialisierten Bereich wird das Gefahrenvokabular des Klassifikators zum Arbeitsvokabular der Domain. Das Signal, das selten sein sollte, wird zur Grundrate.

Die Flags

Von den 15 Flags entfielen 14 auf die Kategorie dangerous_and_criminal_content und 1 auf violence_and_threats. Beim erneuten Lesen zeigte sich sofort das Muster. Es handelte sich durchweg um legitime GRC-Diskussionen:

• Reverse Engineering der Dienste eines Cloud-Anbieters im Kontext von geistigen Eigentumsverpflichtungen. Die ISO/IEC 27001:2022, Anhang A, Kontrollziel A.5.32 lautet wörtlich „Rechte an geistigem Eigentum“; wer an diesem Kontrollziel arbeitet, muss über Reverse Engineering sprechen, um es zu begründen.
• Eine Risikobewertung auf Spanisch, in der „amenazas“ (Bedrohungen) das übliche Wort für die Dinge ist, die jedes Risikoregister auflistet.
• Arbeit im Bereich Anti-Geldwäsche, in der „blanqueo“ (Geldwäsche) das Thema ist – nicht das Geständnis.
• Erfahrungen aus Red-Teaming und Penetrationstests.
• DAST, dynamisches Scannen einer Anwendung auf Schwachstellen.

Keines dieser Themen ist strafrechtlich relevant. Es ist das tägliche Vokabular von Infosec-Profis, Compliance-Beauftragten und Auditor:innen. Der Klassifikator ist nicht defekt. Bei allgemeinem Web-Traffic ist eine Nachricht über das Reverse Engineering der Systeme eines Anbieters ein plausibel schwaches Gefahrensignal – und ein allgemeiner Klassifikator ist darauf ausgelegt, es so zu behandeln. Unsere Nutzer:innen sind jedoch genau die Gruppe, für die dieses Signal das Gegenteil bedeutet. Wir hätten diesen Fehler von jedem allgemeinen Klassifikator erwarten müssen, der auf dieselbe Weise eingesetzt wird, denn er ergibt sich aus dem generischen Rahmen und nicht aus der Implementierung eines bestimmten Anbieters. Unser Fehler bestand darin, eine allgemeine Vorannahme als domänenbewusst zu behandeln.

Überblockierung ist keine sichere Standardlösung

Der Reflex ist, falsch positive Ergebnisse als harmlosen Teil des Präzision-Recall-Kompromisses zu betrachten. Eine echte Bedrohung zu übersehen, führt zu einem Sicherheitsloch; zu viel zu blockieren, führt bestenfalls zu Rauschen. Im Live-Betrieb hatte das Rauschen jedoch Konsequenzen – und es lohnt sich, die sekundären Kosten konkret zu benennen, denn dort lag der eigentliche Schaden:

1. Alarmmüdigkeit untergrub das Netz. Jedes bestätigte Ereignis wurde an unser Sicherheitspostfach gesendet. Fünfzehn aufeinanderfolgende Fehlalarme trainierten das Team darauf, Moderationswarnungen nur noch flüchtig zu prüfen. Ein Sicherheitsnetz, das alle ignorieren lernen, ist kein Sicherheitsnetz.
2. Ein Problem mit dem Recht auf Löschung. Flaggte Threads wurden gegen Löschung gesperrt, um Beweise nicht zu vernichten. Das ist bei tatsächlichem Missbrauch sinnvoll. Bei einem falsch positiven Ergebnis bedeutete es jedoch, dass Nutzer:innen ihre eigenen Compliance-Gespräche nicht löschen konnten – ein Risiko im Sinne von Artikel 17 der DSGVO (Recht auf Löschung). Dieses Recht umfasst unter bestimmten Bedingungen und Ausnahmen auch die selektive Löschung, nicht nur das Schließen eines Kontos.
3. Eine nicht haltbare Beschuldigung. Harmlose Nutzer:innen-Nachrichten landeten in einem Speicher, dessen Semantik „gefährlicher und strafrechtlich relevanter Inhalt“ lautete. Das ist eine Behauptung über eine Person, die wir nicht untermauern konnten.

Unser Problem war nicht die Trefferquote (Recall), sondern die Präzision – und ihr Versagen war alles andere als kosmetisch.

Warum die naheliegenden Lösungen nicht funktionieren

Zwei Lösungen drängen sich auf – und beide sind falsch.

Den Klassifikator anpassen. Das geht nicht. Der Moderations-Endpoint ist ein fester Klassifikator. Seine API akzeptiert eine Modellkennung und einen Eingabetext und gibt Kategorie-Scores zurück. Es gibt kein System-Prompt, kein Anweisungsfeld, keine Möglichkeit, ihm mitzuteilen: „Das ist ein Compliance-Produkt.“ Ein fester Klassifikator liefert Ihnen einen Drehknopf ohne Beschriftung.

Laute Kategorien deaktivieren. Die Deaktivierung von dangerous_and_criminal_content und violence_and_threats würde alle falsch positiven Ergebnisse beseitigen. Gleichzeitig würden damit aber auch die einzigen Kategorien gelöscht, in denen sich eine echte Bedrohung in unserer Domain überhaupt jemals zeigen würde. Das ist keine Kalibrierung, sondern das Abschalten des Netzes und die Bezeichnung der Stille als Erfolg.

Die zweistufige Lösung

Der schnelle Klassifikator bleibt als erste Stufe erhalten; er läuft weiterhin auf jeder Nachricht. Wenn er etwas flaggt, wird die Nachricht an eine zweite Instanz weitergeleitet: ein kleines Chat-Modell (Mistral Small), dem ein System-Prompt vorgegeben wird, der die legitimen Infosec- und Compliance-Themen beschreibt, über die unsere Nutzer:innen tatsächlich sprechen. Das Modell gibt eines von zwei Urteilen zurück: CONFIRMED oder FALSE_POSITIVE.

Nur CONFIRMED-Ereignisse durchlaufen den Pfad für Warnungen und Sperren. FALSE_POSITIVE-Ereignisse landen in einem separaten, unterdrückten Speicher, der für Audits und Drift-Erkennung vorgehalten wird – mit null nutzerseitigen Konsequenzen: keine E-Mails, keine Löschsperre, keine strafrechtliche Beschuldigung. Das Modell wird täglich etwa einmal für eine flaggte Nachricht aktiv und die zusätzlichen Kosten sind vernachlässigbar. Zudem scheitert es im Zweifel im geschlossenen Modus: Falls das Modell einen Fehler macht, eine Zeitüberschreitung auftritt oder ein unklares Urteil zurückgibt, wird die Nachricht als CONFIRMED behandelt. Der schlimmste Fall ist der alte, verrauschte Baseline-Zustand – niemals ein stillschweigend durchgelassener Bedrohung.

Nach der Bereitstellung am 10. April 2026 reduzierte diese Lösung unsere falsch positive Rate bei diesen Flags von 15 von 15 auf null – ohne dass eine einzige Kategorie deaktiviert werden musste.

Der Haken: Wir haben das Risiko verlagert, nicht beseitigt

Hier kommt der Teil, den es zu verinnerlichen gilt, denn er lässt sich über Moderation hinaus verallgemeinern. Ein nachsichtiger zweiter Schritt löscht kein Risiko. Er verschiebt es: von einem Fehlerzustand, den man sehen kann, zu einem, den man nicht sehen kann.

Vorher war der Fehlerzustand die Überblockierung – und er war laut: Jeder falsch positive Alarm läutete die Glocke. Danach ist der dominante Fehlerzustand, dass das Modell zu nachsichtig ist und etwas durchwinkt, das es eigentlich hätte bestätigen sollen. Dieser Fehler ist konstruktionsbedingt still. Er schreibt sich in einen Speicher, über den niemand benachrichtigt wird.

Wir erlebten live, wie desorientierend dieses stille Regime ist. Am 14. April 2026 – vier Tage nach der Lösung – brachen die Moderations-Alarm-E-Mails plötzlich vollständig ab. Von außen ist ein plötzlicher Nullwert nicht von einem defekten Pipeline-Prozess, einem Ausfall oder einem fehlenden Trigger zu unterscheiden. Erst der Blick in die zugrundeliegenden Daten ermöglichte es uns, „gesund und ruhig“ von „still und dunkel“ zu unterscheiden. Nachdem wir Lesezugriff auf den unterdrückten Speicher hatten, prüften wir jedes Urteil von Mistral Small, das seit der Bereitstellung am 10. April 2026 gesammelt worden war: 40 unterdrückte Zeilen, und nach unserer Einschätzung war keine davon eine echte, fälschlich durchgelassene Bedrohung. Der bestätigte Pfad stimmte über denselben Zeitraum exakt überein: 23 bestätigte Ereignisse entsprachen 23 Alarm-E-Mails. Das Netz war intakt. Aber der einzige Weg, das zu wissen, bestand darin, das zu prüfen, was still geworden war.

Der zweite Schritt benötigt daher seine eigene Bewertung, nach eigenem Zeitplan. Der unterdrückte Speicher wird nun monatlich stichprobenartig auf übermäßige Nachsicht des Modells überprüft, und eine günstige tägliche Zählung der bestätigten Tabelle überwacht, ob die Pipeline „dunkel“ wird. Die Lehre lautet nicht „Fügen Sie einen LLM-Richter hinzu“. Sie lautet: Wenn Sie ein sichtbares Problem mit einer leiseren Komponente beheben, planen Sie die Prüfung der leisen Komponente ein – oder Sie haben ein Problem, das Sie messen können, gegen eines eingetauscht, das Sie nicht messen können.

Eine portable Checkliste

Wenn Sie einen allgemeinen Klassifikator über einen spezialisierten Korpus laufen lassen – medizinisch, juristisch, sicherheitsrelevant, finanziell oder compliance-relevant –, bevor Sie dessen Ausgabe vertrauen:

• Prüfen Sie auf einen Vokabular-Konflikt. Listen Sie das normale Arbeitsvokabular Ihrer Domain auf. Wenn diese Wörter mit den Gefahrenkategorien des Klassifikators überlappen, ist die Präzision bei Ihrem Traffic eine offene Frage – keine Selbstverständlichkeit. Messen Sie sie.
• Lesen Sie die Flags, zählen Sie sie nicht nur. Eine Präzisionszahl verbirgt das Muster; die einzelnen falsch positiven Ergebnisse offenbaren es. Fünfzehn Flags sagten uns nichts, bis wir fünfzehn Flags lasen.
• Bewerten Sie Überblockierung ehrlich. Verfolgen Sie, welche Konsequenzen ein falsch positives Ergebnis downstream auslöst. Alarmlistigkeit, eine Löschsperre, die mit einem gesetzlichen Löschrecht kollidiert, eine Beschuldigung, die Sie nicht untermauern können. Überblockierung ist selten kostenlos.
• Wenn der Klassifikator feststeht, umhüllen Sie ihn, bekämpfen Sie ihn nicht. Wenn Sie das Modell nicht anweisen können, fügen Sie ihm eine domänenbewusste Stufe hinzu, statt Kategorien pauschal zu deaktivieren.
• Scheitern Sie im geschlossenen Modus bei der Umhüllung. Ein Fehler des Modells sollte eskalieren, niemals unterdrücken, sodass ein Ausfall der Umhüllung das Netz nicht stillschweigend öffnen kann.
• Geben Sie der leisen Stufe ihre eigene Prüfung. Jede Komponente, die stillschweigend unterdrückt, benötigt eine geplante Überprüfung dessen, was sie unterdrückt hat, sowie eine Lebensfähigkeitsprüfung, die „gesund und ruhig“ von „dunkel“ unterscheidet.

Grenzen

Dies ist ein Produkt, eine Domain und eine kleine Stichprobe: 15 Flags über einen einzigen 17-Tage-Zeitraum bis zum 10. April 2026, plus 40 unterdrückte Zeilen in den folgenden Wochen. Es handelt sich um ein punktuelles Ergebnis für den Alias mistral-moderation-latest in der Auflösung während dieses Zeitraums, gemessen an unserem eigenen Traffic. Es ist kein allgemeiner Anspruch über die Qualität dieses Klassifikators außerhalb unserer Domain. Die eigene Fehlerquote des Modells wird durch die fail-closed-Vorgabe begrenzt, ist aber nicht null – genau deshalb wird sie geprüft, statt blind vertraut zu werden. Worin wir uns sicher sind, ist der Mechanismus: Wenn Gefahrenvokabular und Domänen-Vokabular dieselben Wörter sind, ist die Präzision eines allgemeinen Klassifikators eine Messung, die Sie vornehmen müssen – keine Eigenschaft, die Sie annehmen können.