Warum unser LLM Gateway vor dem Modell filtert — nicht danach
Eine Architektur-Notiz: Output-Filterung allein reicht nicht. Wir filtern Eingaben, Tool-Calls und Modellantworten in drei Stufen. Was das in der Praxis kostet und was es verhindert.
Die häufige Annahme
„Wir lassen das Modell antworten und filtern dann raus, was raus muss." Klingt sauber, ist aber eine Sackgasse. Wer am Ausgang filtert, sieht erst, wenn das Modell schon teures Token-Budget verbrannt hat — und wenn das Modell etwas Sensibles in der Antwort verarbeitet hat, ist es bereits in den Logs.
Was wir stattdessen tun
Unser LLM Gateway filtert in drei Stufen:
Vor dem Modell — Eingabe-Filter. Wir prüfen Prompts auf PII, Geschäftsgeheimnisse, Secrets, Policy-Verstöße. Ein Mitarbeiter, der versehentlich einen Kundennamen plus Bankverbindung in den Prompt klebt, bekommt vor dem API-Call eine Warnung. Das Modell sieht den Vorgang nie.
Im Tool-Call — Aktions-Filter. Wenn das Modell ein Tool aufrufen will (Datei lesen, Ticket schließen, E-Mail senden), prüfen wir die Aktion gegen Policy. Schreiboperationen sind per Default human-in-the-loop. Leseoperationen werden auf Quelle (welcher Mandant, welche Klasse) geprüft.
Nach dem Modell — Antwort-Filter. Nur als Sicherheitsnetz, nicht als primäre Schicht. Wir prüfen Ausgaben auf das Gleiche wie Eingaben — und wenn etwas durchschlüpft, blockieren wir und alarmieren.
Was das kostet
In der Praxis: 15–25 ms Latenz pro Anfrage, je nach Tiefe der Eingabeprüfung. Token-Budget verringert sich um 0% (wir sparen sogar, weil unsinnige Anfragen abgefangen werden, bevor sie das Modell erreichen).
Was es verhindert hat
Innerhalb von sechs Monaten Betrieb bei drei Mandaten:
- 148 Mal wurde ein Prompt mit PII abgefangen — vor dem Versand ans Modell.
- 3 Mal hätte ein Modell ein produktives Ticket geschlossen, ohne dass es bestätigt war. Human-in-the-loop hat es verhindert.
- 0 Mal ist ein Geschäftsgeheimnis durchgerutscht (Output-Filter als Sicherheitsnetz).
Die meisten dieser 148 Fälle waren nicht böswillig — Menschen kopieren Daten in Prompts, weil es schnell geht. Die Filter sind die Erinnerung, die das Modell selbst nicht hat.
Konkrete Lehre
Wenn Sie ein eigenes Gateway bauen oder eines einsetzen, fragen Sie:
- Filtert es vor dem Modell — nicht nur danach?
- Sieht das Gateway Tool-Calls, nicht nur Chat-Text?
- Ist jede Aktion auditiert, auch die abgewiesenen?
- Können Sie Filter pro Mandant / pro Team / pro Use-Case getrennt pflegen?
Wenn die Antwort viermal Ja ist, sind Sie weiter als 90% der Stacks da draußen.