Phillip Pham, Azure- und Plattformberater bei Pexon Consulting | 10 Min. Lesezeit | 15.09.2026
TL;DR: llm guardrails checkliste in sieben Punkten
Eine LLM Guardrails Checkliste 2026 prüft Policy vor dem Token, nicht den Modell-Filter danach. TrueFoundry trennt Input, Output, Tool vor dem Aufruf, Tool nach der Antwort. Google sah den Begriff guardrails 202-mal auf Pexon-URLs, ohne Klick (Position 5,1, 08.08. bis 04.09.2026). Pexon Consulting (80 Mitarbeitende, Microsoft Partner, ISO 27001) setzt den Rand in LiteLLM, blockt nicht „alles“.
| Stufe | Wann sie feuert | Typische Lücke |
|---|---|---|
| Input | vor dem Modell | Klasse fehlt |
| Output | nach dem Modell | Token schon raus |
| Tool davor | vor dem Tool-Call | zu breite Rechte |
| Tool danach | nach dem Tool | ungeprüfte Antwort |
Das Problem: die Checkliste hängt hinter dem Call
Die kurze Antwort: die meisten Listen prüfen den Text, den das Modell schon gesehen hat. Das ist Output. Das Token ist weg.
Ein CISO schickt uns eine Folie mit „PII, Toxicity, Jailbreak“. Alles sitzt im Anbieter-Filter. Der Prompt mit der Stückliste ist längst unterwegs. Die Folie ist grün. Das Haus nicht.
In 28 Tagen bis Anfang September 2026 zählte Google 202 Impressionen auf guardrails bei uns und 0 Klicks. Die SERP kennt den Term. Eine Checkliste, die den Rand meint, fehlte. Dieser Text ist die Liste. Der Hub bleibt LiteLLM.
Wir raten aktuell davon ab, Tracing mit Guardrails zu verwechseln. Tracing erklärt, was passiert ist. Guardrails entscheiden, ob es passiert. Den Observability-Pfad beschreibt Langfuse-Tracing, nicht dieser Artikel.
Die vier Stufen, bevor Sie Häkchen setzen
Die kurze Antwort: TrueFoundry beschreibt 2026 vier Stufen. Dieselbe Trennung gilt am LiteLLM-Rand.
- Input. Klasse, Cap, Block, bevor Tokens das Modell erreichen.
- Output. Filter auf die Antwort. Nützlich, zu spät für Geheimnisse im Prompt.
- Tool davor. MCP Pre: darf der Call das Tool mit diesen Argumenten treffen?
- Tool danach. MCP Post: darf die Tool-Antwort zurück ins Modell?
Quelle: TrueFoundry, Architecture of Governed AI Usage, 2026. Pexon schreibt daraus keine eigene KPI. Pexon schreibt die Treppe am Gateway.
# Monitor vor Enforce. Kein Versprechen, alles zu blocken.
guardrails:
- name: klasse-fachdaten
mode: monitor
on: pre_call
action: log
- name: block-personalakte
mode: enforce
on: pre_call
action: block
- name: tool-write
mode: enforce
on: pre_mcp
action: block
Das ist die Form. Die Namen sind Beispiele. Lauffähig wird es erst mit Ihren Callbacks. Monitor vor Enforce ist der sichere Rollout. Wer am ersten Tag nur blockt, erzeugt Schatten-Prompts im privaten Tab.
Checkliste: sieben Punkte, die der Rand tragen muss
Die kurze Antwort: wenn ein Punkt fehlt, ist die Liste Deko.
- Klasse schriftlich. Was das Haus nicht verlassen darf. Ein Satz im Wiki reicht nicht, wenn niemand ihn am Gateway prüft.
- Cap am Key. Budget und Rate pro Team. Ohne Cap ist Policy eine Meinung.
- Block-Liste klein. Drei Dinge, die nie durch dürfen. Eine Liste mit 80 Mustern liest niemand.
- Klärfall. Wer entscheidet, wenn der Score in der Mitte liegt. Sonst landet der Call im Chat der GF.
- Ein Log. Allow und Block in einem Export. App, Team, Modell.
- Tool-Rechte getrennt. Lesen ist nicht Schreiben. Pre und Post sind zwei Häkchen.
- Owner. Wer die Policy ändert. Ohne Owner bleibt die YAML eine Demo.
Personenbezogene Filter bleiben ein eigenes Thema. Diese Liste klont sie nicht. Schatten-Prompts, die die Liste umgehen, stehen auf der Schatten-KI-Seite.
Was die Checkliste bewusst nicht ist
Die kurze Antwort: kein zweiter Gateway-Artikel, kein Tracing-Leitfaden, kein Versprechen.
Sie ist keine Kaufseite für „gateway guardrails“. Das Exact-Match bleibt die Spoke, sobald sie live ist. Heute zeigt der nächste Schritt auf den Hub.
Sie ist keine Anleitung, LiteLLM zu installieren. Die bleibt der Enterprise-Setup-Guide.
Sie ist kein „wir blocken alles“. Klärfall und Schwelle gehören in den Check. Monitor vor Enforce.
Das funktioniert in der Praxis selten, wenn die Liste in Confluence steht und der Proxy offen ist. Dann ist die Checkliste eine Audit-Lüge.
Rollout: Monitor, dann Enforce, dann Tool-Rechte
Die kurze Antwort: eine llm guardrails checkliste in Produktion ist eine Reihenfolge, kein Big Bang.
Woche 1: Klasse schreiben, drei Block-Fälle, Monitor auf Input. Nichts wird hart gestoppt. Das Log zeigt, was durchgelaufen wäre. Ohne dieses Log ist Enforce Politik.
Woche 2: Caps auf Virtual Keys. Ein Team bekommt Budget und Rate. Ein zweites Team bleibt offen, als Kontrast. Wenn niemand den Unterschied merkt, war das Cap Kosmetik.
Woche 3: ein Block, der wirklich weh tut. Personalakte, Kundenliste, was bei Ihnen der rote Eimer ist. Klärfall benennen. Eine Person, die den Call freigibt oder zurückweist.
Woche 4: Tool davor und danach. Lesen darf mehr als Schreiben. Pre blockt den zu breiten Aufruf. Post prüft, was zurückkommt. Wer Tools erst nach dem Modell filtert, hat Stufe 2 mit anderem Namen.
TrueFoundry liefert die vier Stufen als Architektur. Pexon liefert sie als Treppe am Gateway. Wir erfinden keine Block-Quote. Wir versprechen nicht, alles zu stoppen. 8×5 auf der App-Schicht, nicht rund um die Uhr.
Zwei Dinge, die den Rollout töten. Eine Liste mit 80 Mustern am Tag 1. Ein Block ohne Klärfall. Beides erzeugt den privaten Tab, den die Checkliste verhindern sollte.
Der Plattform-Check in 45 Minuten setzt den ersten roten Eimer und den Owner. Ohne die beiden Punkte bleibt YAML eine Demo. Mit ihnen wird aus der Liste ein Rand.
Zwei Sätze zur Abgrenzung, damit die Checkliste nicht den Hub frisst. Der LiteLLM-Hub bleibt die Fläche für Keys, Spend und Fallbacks. Die Implementierung hängt den Proxy in zwei bis vier Wochen. Diese URL bleibt die Liste: Stufe, Häkchen, Reihenfolge. Ein Personenbezugs-Filter bekommt keine zweite Anleitung hier. Tracing bekommt keinen zweiten Leitfaden. Wer beides sucht, folgt den Sibling-Links und bleibt auf dieser Seite bei Policy vor dem Token.
Google hat guardrails 202-mal gesehen und nicht geklickt. Das ist kein Ruhm. Es ist der Grund, warum die Liste den Rand beim Namen nennt und nicht „KI-Sicherheit“ schreibt. Position 5,1 ohne Klick heißt: die SERP zeigt etwas, das die Frage nicht beantwortet. Wir beantworten sie mit sieben Punkten und vier Stufen. Den Rest trägt der Proxy.
Häufig gestellte Fragen
Was kostet eine LLM Guardrails Checkliste in der Umsetzung?
Die Liste kostet Workshop-Zeit. Der Rand kostet Scope am Gateway. Pexon nennt keinen Listenpreis und keine 4.000-Euro-Pauschale. Einstieg ist der Plattform-Check in 45 Minuten. Token bleiben beim Anbieter.
LLM Guardrails Checkliste vs Modell-Filter: reicht der Anbieter?
Kommt drauf an. Reicht, wenn nur die Antwort geprüft werden soll und der Prompt keine Fachdaten trägt. Reicht nicht, sobald Klasse vor dem Token sitzen muss. TrueFoundry trennt die Stufen genau deshalb.
Ist das dieselbe Liste wie PII-Filter?
Nein. Ein Personenbezugs-Filter maskiert Felder. Diese Checkliste prüft Klasse, Cap, Block, Log und Tool-Rechte. Beides kann zusammenlaufen. Eins ersetzt das andere nicht.
Blocken Sie alles, was die Liste rot macht?
Nein. Monitor vor Enforce. Ein harter Block ohne Klärfall erzeugt den nächsten privaten Tab. Der Check setzt die Schwelle, nicht das Marketing.
Wo steht der nächste Schritt nach der Liste?
Auf dem LiteLLM-Hub. Dort sitzt der Rand. Die Implementierung hängt Virtual Keys, Budgets und Fallbacks. Diese URL bleibt die Checkliste.
Die Liste bleibt spitz. Sieben Punkte, vier Stufen, Monitor vor Enforce. Wir versprechen nicht, alles zu blocken. Tracing bleibt der andere Text. Personenbezug bleibt das andere Thema. Nach 45 Minuten stehen der rote Eimer und der Owner. Ohne die beiden Namen bleibt YAML eine Demo, mit ihnen wird Policy ein Rand auf dem Request-Pfad. 8×5 auf der App-Schicht, Token beim Anbieter, Endpreis nach Scope. Impressionen ohne Klick waren der Anlass, nicht die KPI. Die KPI wäre ein Block, den wir nicht erfinden. Der nächste Schritt ist der Proxy, nicht eine längere Folie. Caps ohne Klasse bleiben Kosmetik. Klasse ohne Log bleibt Behauptung. Beides zusammen ist die Checkliste in Produktion, nicht die Folie im Wiki und nicht der Filter hinter dem Modell. Input zuerst, Output danach, Tools in der dritten und vierten Stufe.
Nächster Schritt
LiteLLM-Implementierung klären



