KI-Guardrails im Vergleich: NeMo Guardrails, Llama Guard, Guardrails AI, LLM Guard und Presidio

Eine KI-Anwendung im Betrieb messbar halten? Managed LLMOps beobachtet Tracing, Fehler, Kosten und Latenz einer KI-Anwendung (etwa mit Langfuse), nutzt Evaluationen und dokumentiert Änderungen an Prompt, Modell, Provider und Retrieval mit Rückfallweg. Ab 1.990 € netto im Monat (Stand Oktober 2026). Managed LLMOps ansehen

Guardrails sind Prüf- und Steuerregeln um ein Sprachmodell herum: Sie kontrollieren Eingaben, Ausgaben, abgerufene Inhalte und Werkzeugaufrufe gegen eine Richtlinie. Sie sind eine Schicht neben Rechten und Architektur, kein Ersatz dafür. Der Vergleich von NeMo Guardrails, Llama Guard, Guardrails AI, LLM Guard und Presidio nach Lizenz, Pflegestand, Deutsch, Latenz und Integration steht unten. Stand Oktober 2026. Vier Befunde sind für die Auswahl relevant: LLM Guard ist archiviert, Guardrails AI wurde im September von Harvey übernommen, Llama Guard 4 ist an eine Lizenz mit EU-Klausel gebunden, und NeMo Guardrails sendet standardmäßig Telemetrie.

Inhaltsverzeichnis

• Was Guardrails sind und was nicht
• Die Werkzeuge im Überblick
• Vier Befunde zu Pflegestand, Lizenz und ausgehenden Verbindungen
• Deutsch, Latenz und Integration
• Entscheidungshilfe
• Policy als Code
• Guardrails testen
• Betrieb und Monitoring mit Langfuse
• Unser Vorgehen bei WZ-IT
• Stand und Methodik
• Weiterführende Guides

Was Guardrails sind und was nicht

Die Grenze zieht NVIDIA in den Sicherheitsrichtlinien von NeMo Guardrails selbst: Das Modell gilt als Browser unter vollständiger Kontrolle des Benutzers, seine Ausgaben als nicht vertrauenswürdig, und jeder aufgerufene Dienst wird im Kontext des Benutzers aufgerufen. Laut Runtime-Security-FAQ garantiert keine einzelne Rail Schutz gegen jeden Angriff. Filter allein tragen nicht (Schutz vor Prompt Injection), die tragenden Maßnahmen beschreiben KI-Agenten: Rechte und Freigaben und RAG mit Berechtigungen.

Die Werkzeuge im Überblick

Generative Klassifikatoren wie Llama Guard 3-8B und 4-12B sind Sprachmodelle mit 8 bis 12 Milliarden Parametern; kleinere Varianten wie Llama Guard 3-1B oder Qwen3Guard-Gen-0.6B existieren. Jeder Aufruf ist ein zusätzlicher Modelllauf.

NeMo Guardrails in Kürze

NeMo Guardrails legt Rails zwischen Anwendung und Modell. Eingabe-Rails können eine Anfrage ablehnen oder verändern, etwa um Personendaten zu maskieren. Dialog-Rails steuern in Colang, welche Aktion oder Antwort folgt. Retrieval-Rails prüfen abgerufene Abschnitte, Ausführungs-Rails die Ein- und Ausgaben von Werkzeugen, Ausgabe-Rails die Antwort des Modells. Eine Konfiguration ohne Rails reicht Anfragen unverändert an das Modell durch. Colang 1.0 ist der Standard, Colang 2.0 optional (README).

Vier Befunde zu Pflegestand, Lizenz und ausgehenden Verbindungen

LLM Guard ist archiviert

Das README des Repositories nennt das Projekt und die zugehörigen Hugging-Face-Modelle als nicht mehr entwickelt oder gepflegt. Die Beispielpipeline für Open WebUI hängt an dieser Bibliothek.

Guardrails AI wurde von Harvey übernommen

Harvey kündigte die Übernahme am 9. September 2026 an. Die Ankündigung von Harvey enthält keine Aussage zur Weiterentwicklung des Open-Source-Frameworks. Das Repository steht weiter unter Apache-2.0 und hatte am 27.10.2026 einen Push. Das Hub-Installationsverfahren (guardrails hub install) mit der privaten Validator-Registry und die gehostete Remote-Inferenz waren laut Ankündigung des Projekts vom 6. Juli 2026 zum 25. August 2026 zur Abschaltung vorgesehen (die README nennt einen „planned cutoff“); für die gehostete Inferenz nennt derselbe Text zugleich den 6. August 2026. Ob die Abschaltung vollzogen wurde, geht aus den Primärquellen nicht hervor, das Issue ist am 28.10.2026 noch offen. Laut Migrationsanleitung sind Validatoren eigenständige PyPI-Pakete (pip install guardrails-ai-<name>, zum Zeitpunkt der Ankündigung 50 von 64), Modelle laufen lokal (use_local=True) oder an einem eigenen Endpunkt. guardrails configure aktiviert anonyme Metriken standardmäßig, --disable-metrics schaltet sie ab (Quelltext).

Llama Guard 4 und die EU-Klausel

Der Ordner von Llama Guard 4 enthält die Llama 4 Community License und die Nutzungsrichtlinie. Diese gewährt für multimodale Modelle aus Llama 4 die Rechte nach Abschnitt 1(a) nicht an Personen mit Wohnsitz und Unternehmen mit Hauptniederlassung in der EU; ausgenommen sind Endnutzer eines Produkts oder Dienstes, in das ein solches Modell eingebunden ist. Llama Guard 4 ist laut Modellkarte nativ multimodal. Ob die Klausel den Betrieb als Guard-Modell erfasst, bewertet die Rechtsabteilung vor dem Einsatz (LLM-Lizenzen). Dieselbe Nutzungsrichtlinie liegt auch dem Textklassifikator Prompt Guard 2 (mDeBERTa-Basis) bei, der kein multimodales Modell ist.

NeMo Guardrails sendet Telemetrie

Die README beschreibt einen anonymen Ping an NVIDIA beim Start und danach periodisch. Die Nutzlast enthält keine Prompts, Antworten, Modellnamen, Endpunkte oder IP-Adressen, der Ping ist aber eine ausgehende Verbindung. Abschalten lässt er sich vor dem Start mit NEMO_GUARDRAILS_NO_USAGE_STATS=1 oder DO_NOT_TRACK=1. Die Dokumentation nennt außerdem: NIM-Container brauchen zum Download einen NGC-Schlüssel, und Beispiele nutzen den gehosteten NVIDIA-Endpunkt (NVIDIA Build), der laut README nur für Evaluation und Tests gedacht ist, ohne vertrauliche Daten oder Personendaten. Für die Egress-Liste siehe DSGVO-konforme KI, Frage 5.

Deutsch, Latenz und Integration

Deutsch

Meta evaluiert Prompt Guard 2 auf Deutsch, das 22M-Modell mit größerer Lücke. Llama Guard 3 unterstützt Deutsch. Presidio enthält in der Standardkonfiguration Erkenner und Modelle für Englisch. Für Deutsch kommen ein deutsches NLP-Modell für Namen und die deutschen Erkenner hinzu, etwa für Steuer-ID, Personalausweis und Versicherungsnummern. Die Beispielpipeline in den Open-WebUI-Pipelines setzt language auf en und listet US-Entitäten, sie muss angepasst werden.

Latenz

NVIDIA schreibt in der FAQ, dass es keine einsatzunabhängige p50, p95 oder Durchsatzzahl gibt. Meta nennt für Prompt Guard 2 auf einer A100 bei 512 Token 92,4 ms (86M) und 19,3 ms (22M) je Klassifikation. Hebel laut FAQ: parallele Rails (rails.input.parallel, rails.output.parallel), spekulative Generierung in IORails, die Eingabeprüfung parallel zur Antwort laufen lässt und die Antwort bei Blockade verwirft, und beim Streaming stream_first: False, das Ausgaben vor der Auslieferung prüft, aber Latenz kostet.

Integration mit LiteLLM und Open WebUI

LiteLLM führt Guardrails in der config.yaml mit den Modi pre_call, during_call, post_call und logging_only aus, mit Presidio, Guardrails AI und weiteren Anbietern. Die Generic Guardrail API (Beta) bindet einen eigenen Dienst an, der BLOCKED, NONE oder GUARDRAIL_INTERVENED antwortet. Zuordnung je API-Schlüssel, tag-basierte Modi, modellbezogene Guardrails, dynamische Parameter je Aufruf und das Sperren der Guardrail-Änderung je Team erfordern laut Dokumentation eine Enterprise-Lizenz. In Open WebUI setzen Filter Functions die Regeln mit inlet, request, stream und outlet um. Laut Dokumentation gehört Durchsetzung in request, weil es vor jedem Modellaufruf läuft, auch in Werkzeugschleifen. Eine Exception in inlet oder im ersten request-Aufruf eines Turns bricht den Turn ab, in outlet wird sie in der Regel nur protokolliert. Ein Filter läuft als Python-Code auf dem Server und kann nur von Administratoren angelegt werden. Das Pipelines-Projekt rät für einfache Filter selbst von Pipelines ab.

Entscheidungshilfe

Regel: ein Baustein je Aufgabe, jeder mit Testfällen und Messwert. Vor der Aufnahme werden sechs Punkte geprüft:

1. Lizenz: Code, Modellgewichte und Nutzungsrichtlinie, nicht nur das Repository-Label.
2. Pflegestand: letzte Version, Archivierung, Eigentümer des Projekts.
3. Selbstbetrieb und ausgehende Verbindungen: Läuft alles auf eigener Infrastruktur? Telemetrie, Modell-Downloads, gehostete Endpunkte, eingetragen in die Egress-Liste.
4. Deutsch: eigene Testfälle, nicht Herstellerangaben.
5. Latenz: p50 und p95 der eigenen Konfiguration auf realem Verkehr, auch beim Streaming.
6. Ausfallverhalten: Entscheidung, ob eine ausgefallene Prüfung öffnet oder schließt, getestet mit Timeout und Fehlern.

Policy als Code

Die Richtlinie liegt als Text vor, die Regeln als Konfiguration im Repository, die Testfälle daneben. Pflegeaufwand entsteht bei Schwellen und Regeln (Fehlalarme), bei den Testfällen (neue Angriffsmuster, neue Datenquellen) und bei den Abhängigkeiten (Modell- und Bibliotheksversionen, Projektstatus). NeMo Guardrails trennt dafür config.yml (Modelle, aktive Rails), Colang-Dateien (Abläufe) und actions.py (eigene Prüfungen), LiteLLM die config.yaml. Ein mögliches Layout, die Struktur von config folgt der README von NeMo Guardrails:

guardrails/
  POLICY.md           Richtlinie in Textform, mit Version
  config/config.yml   Modelle, aktive Rails, Schwellen
  config/*.co         Colang-Flows für Themen und Abläufe
  config/actions.py   eigene Prüfungen
  tests/cases.jsonl   Angriffs-, Legitim- und deutsche Fälle mit erwartetem Ergebnis

Auszug aus der Dokumentation für die Maskierung von Personendaten:

rails:
  config:
    sensitive_data_detection:
      input:
        entities:
          - PERSON
          - EMAIL_ADDRESS
  input:
    flows:
      - mask sensitive data on input

Die NVIDIA-FAQ empfiehlt, Bibliothek, Konfiguration, Prompts, eigene Aktionen und externe Modellversionen zusammen zu versionieren und erst nach einem Regressionstest freizugeben, mit gestufter Einführung und Rückfall.

Guardrails testen

Getestet wird die Konfiguration, nicht das Werkzeug: Angriffsfälle direkt und indirekt (Anweisungen in Dokumenten und Werkzeugausgaben), legitime Fälle mit Fachbegriffen und Code, Personendaten-Fälle und deutsche Fälle. Gemessen werden Blockrate der Angriffe und Fehlblockrate legitimer Fälle je Kategorie, mit vorab vereinbarten Schwellen, als Gate bei jeder Änderung an Modell, Bibliothek, Konfiguration und Prompt. NeMo Guardrails bietet dafür check() und nemoguardrails evaluate, garak (Apache-2.0) scannt gezielt auf Schwachstellen, und Langfuse-Datasets halten das Testset versioniert.

Der Zielkonflikt zeigt eine Untersuchung der eingebauten Guardrails dreier Cloud-Plattformen (Unit 42, 2. Juni 2025) mit 1.000 harmlosen und 123 bösartigen Prompts, bei maximal strenger Einstellung der Filter (Prozentwerte wie in der Studie angegeben):

Ähnliche Erkennungsraten (91 und 92 Prozent) gehen mit sehr unterschiedlichen Fehlblockraten einher (0,6 und 13,1 Prozent). Die Erkennungsrate allein sagt wenig, beide Werte gehören in dieselbe Messung. Rundung: 114 von 123 sind rechnerisch 92,7 %, die Studie gibt „approximately 92 %“ an. Für Plattform 3 nennt der Fließtext der Studie an anderer Stelle 14,0 % fälschlich blockierte harmlose Prompts, Tabelle 1 und die Rechnung (131 von 1.000) ergeben 13,1 %. Ein Regressionstest der eigenen Konfiguration ist kein Penetrationstest.

Betrieb und Monitoring mit Langfuse

Jede Rail-Entscheidung sollte mit Regelname, Version, Ergebnis (bei NeMo PASSED, MODIFIED oder BLOCKED) und Dauer protokolliert werden; Konfigurationsversion und Entscheidungsgrund ergänzt laut NVIDIA-FAQ die Anwendung. Langfuse zerlegt die Latenz der Prüfungen im Trace; die Dokumentation empfiehlt, damit zu bewerten, ob die Prüfung die Wartezeit wert ist. Scores und Annotation Queues stützen die Stichprobenprüfung auf Fehlalarme. Personendaten in Traces lassen sich mit Masking schwärzen. Ausfälle der Prüfung selbst (Timeout, Fehler) werden als eigenes Ereignis protokolliert.

Unser Vorgehen bei WZ-IT

Managed LLMOps beobachtet Tracing, Fehler, Latenz und Kosten einer Anwendung, nutzt Evaluationen, um Veränderungen der Qualität sichtbar zu machen, und dokumentiert Änderungen an Prompt, Modell, Provider und Retrieval mit Rückfallweg. Essential umfasst eine Anwendung mit vereinbarten Trace- und Eval-Mengen und Bearbeitung nach bestem Bemühen in den vereinbarten Servicezeiten, ab 1.990 € netto im Monat. Die tragenden Maßnahmen, Berechtigungen vor der Suche und ein enger Werkzeugkatalog mit Freigaben, sind in Schutz vor Prompt Injection beschrieben. Preise netto, Stand Oktober 2026.

Stand und Methodik

• Stand: 28.10.2026. Lizenzen, Versionen und Pflegestand aus den LICENSE-Dateien, READMEs, Releases und Modellkarten der Repositories, die Quellen sind an diesem Tag abgerufen.
• Nicht gemessen: Es gibt keine eigenen Benchmarks. Latenzwerte stammen von Herstellern (Meta), die Raten der Unit-42-Studie betreffen Cloud-Plattformen (Auswertung vor dem 10.03.2025), nicht die hier verglichenen Werkzeuge, und stammen von einem Anbieter von Sicherheitsprodukten.
• Lizenzen: Die Llama-Lizenzen sind je Modell zu lesen. Die Modellseite von Llama Guard 3-8B nennt die Llama 3.1 Community License, der Ordner im Repository enthält Lizenztexte anderer Llama-Versionen. Die Anwendbarkeit der EU-Klausel auf Llama Guard 4 ist eine Rechtsfrage und hier nicht entschieden. Der Artikel ist keine Rechtsberatung.
• Guardrails AI: Die Aussagen zu Hub und Inferenz folgen der Ankündigung des Projekts (Stichtage dort uneinheitlich: 6. und 25. August 2026), ob die Abschaltung vollzogen wurde, ist nicht belegt. In der Ankündigung von Harvey findet sich keine Aussage zu den Plänen für das Framework.

Weiterführende Guides

• Schutz vor Prompt Injection - warum Filter allein nicht tragen
• KI-Agenten: Rechte und Freigaben - Identität, Werkzeugkatalog, Freigaben
• RAG-Qualität messen - Testset, Regressionstest, Langfuse
• Was ist LiteLLM? - das Gateway, in dem Guardrails laufen können
• LLM-Lizenzen für die kommerzielle Nutzung - Llama-, Qwen- und weitere Lizenzen

Eine KI-Anwendung im Betrieb messbar halten? Managed LLMOps macht Qualität, Kosten und Latenz einer KI-Anwendung sichtbar und dokumentiert Änderungen mit Rückfallweg. Managed LLMOps · LLM-Hosting