Warum unser LLM Gateway vor dem Modell filtert

„Wir lassen das Modell antworten und filtern dann raus, was raus muss.“ Diese Annahme klingt sauber, ist aber eine Sackgasse. Wer erst am Ausgang filtert, sieht das Problem erst, wenn das Modell schon Token-Budget verbraucht hat. Und wenn die Antwort etwas Sensibles enthält, steht es zu diesem Zeitpunkt bereits im Log.

Unser LLM Gateway prüft deshalb an drei Stellen, nicht an einer.

Vor dem Modell. Prompts werden auf personenbezogene Daten, Geschäftsgeheimnisse, Zugangsdaten und Policy-Verstöße geprüft, bevor der API-Call losgeht. Ein Mitarbeiter, der versehentlich einen Kundennamen mit Bankverbindung in den Prompt einfügt, bekommt die Warnung vorher. Das Modell sieht den Vorgang nie.

Im Tool-Call. Will das Modell eine Aktion auslösen (Datei lesen, Ticket schließen, E-Mail senden), wird die Aktion gegen die Policy geprüft. Schreiboperationen sind per Default Human in the Loop. Leseoperationen werden gegen ihre Quelle geprüft: welcher Mandant, welche Klasse.

Nach dem Modell. Die Antwort wird noch einmal auf dieselben Dinge geprüft wie die Eingabe, als Sicherheitsnetz und nicht als erste Instanz. Schlägt etwas durch, wird blockiert und alarmiert.

Das kostet in der Praxis 15 bis 25 Millisekunden Latenz pro Anfrage, je nach Prüftiefe. Am Token-Budget ändert es nichts, eher im Gegenteil: unsinnige Anfragen werden abgefangen, bevor sie das Modell erreichen.

In sechs Monaten Betrieb über drei Mandate hat das Gateway 148 Mal einen Prompt mit personenbezogenen Daten abgefangen, bevor er das Modell erreichte. Drei Mal hätte ein Modell ein produktives Ticket geschlossen, ohne dass es bestätigt war. Human in the Loop hat es verhindert. Kein Geschäftsgeheimnis ist über den Ausgabefilter durchgerutscht.

Die meisten der 148 Fälle waren nicht böswillig. Menschen kopieren Daten in Prompts, weil es schnell geht. Die Prüfung vor dem Modell ist die Erinnerung, die das Modell selbst nicht hat.

Wer ein eigenes Gateway baut oder eines einsetzt, sollte vier Dinge prüfen: Filtert es vor dem Modell, nicht nur danach? Sieht es Tool-Calls, nicht nur Chat-Text? Ist jede Aktion auditiert, auch die abgewiesenen? Lassen sich die Regeln getrennt pro Mandant, Team und Anwendungsfall pflegen?