Guardrails AI: prüfen, was das Modell zurückgibt

Guardrails AI ist ein Open-Source-Framework für Python, das prüft, was ein Modell zurückgibt, bevor eine Anwendung darauf handelt. Die Validatoren liegen in einem Hub aus 65 Paketen, jedes legt fest, was beim Fehlschlag passiert: Ausnahme, Reparatur, erneute Anfrage, Filtern oder keine Rückgabe. Das Projekt steht unter Apache-2.0, die Version 0.11.0 wurde am 14. August 2026 veröffentlicht, gesteuert wird es aus Python, JavaScript ist im README unterstützt.

Es besetzt die Schicht zwischen einem LLM-Aufruf und dem Code, der dessen Ausgabe konsumiert, und dort entscheidet sich, ob ein durchgesickertes Systemprompt, eine Zusammenfassung mit personenbezogenen Daten oder ein defektes JSON beim Nutzer ankommt. Es konkurriert mit Mustern zur Prompt-Injection-Abwehr um dieselbe Stelle wie NVIDIA NeMo Guardrails, mit dem Moderations-Endpunkt von OpenAI als gehostete Abkürzung und mit den handgeschriebenen Prüfungen, die die meisten Teams bereits haben. Die hier vertretene Position: die vollständigste Validatoren-Bibliothek des Feldes, deren Fehlermodell besser konstruiert ist als sein Betriebsmodell, bei dem der kostenlose Teil die Software ist und der teure Teil die Wiederholungen.

Was es wirklich ist

Die Arbeitseinheit ist ein Guard: eine geordnete Liste von Validatoren, die entweder auf die ausgehenden Nachrichten angewendet wird, mit on="messages", oder auf die Antwort. Die Validatoren kommen aus dem Hub und installieren als eigene PyPI-Pakete, eine Deployment führt also nur die Prüfungen aus, die es auch nutzt. Manche sind Regeln wie Regex, Länge und JSON-lesbarkeit, manche laufen als kleines lokales Modell, und manche rufen ein zweites LLM auf, um das erste zu bewerten.

• Hub. 65 Validatoren, gruppiert nach Risiko: Markenrisiko, Formatierung, Etikette, Jailbreaking, Datenabfluss, Code-Exploits und Faktizität.
• Paketierung. Jeder Validator ist ein eigenes Paket, das nach guardrails configure installiert wird, etwa guardrails-ai-regex-match oder guardrails-ai-detect-pii.
• Zwei Richtungen. Guards laufen auf den Nachrichten vor dem Aufruf und auf der Modellausgabe danach, und dasselbe Guard-Objekt kann beides.
• Strukturierte Generierung. Guard.for_pydantic steuert das Modell gegen eine Pydantic-Klasse und prüft das geparste Objekt, per Function Calling wo das Modell es kann und über Prompt-Vorlagen wo nicht.
• Lizenz und Version. Apache-2.0, Python 3.10 bis 3.13, Version 0.11.0 vom 14. August 2026, mit rund 7.500 Sternen auf GitHub.
• Servermodus. guardrails start startet einen Flask-Dienst, der jeden Guard hinter einer OpenAI-kompatiblen Basis-URL ausliefert, ein bestehender Client ändert damit nur eine Zeichenkette.

So funktioniert es

Die Validierung ist standardmäßig synchron: die Rohausgabe hinein, jeder Validator der Reihe nach, jeder Fehler wird an guard.history.last.failed_validations angehängt, und die on-fail-Aktion dieses Validators entscheidet, was den Guard verlässt. Die Aktion wird pro Validator statt pro Guard gesetzt, ein Guard kann also bei personenbezogenen Daten eine Ausnahme werfen und bei einem Formatfehler nur protokollieren. reask baut einen Prompt mit dem gescheiterten Kriterium neu auf und fragt das Modell erneut, bis zur Grenze num_reasks.

Da Fehler unabhängig davon protokolliert werden, ob sie den Ablauf stoppen, liefert auch ein Guard auf noop eine Prüfspur, und noop ist ohnehin die Voreinstellung. Bei Aufrufen an einen Anbieter wiederholt das Framework Verbindungsfehler, Ratenlimits und Zeitüberschreitungen mit exponentiellem Backoff bis zu einer Wartezeit von sechzig Sekunden, ein Anbieterausfall erscheint damit als Latenz im Guard und nicht als sofortige Ausnahme.

Wenn ein Validator fehlschlägt

Acht Aktionen stehen zur Verfügung, und sie sind die eigentliche Schnittstelle dieses Tools, mehr als die Validatorenliste. Die Dokumentationstabelle markiert, welche davon gegen eine Streaming-Ausgabe funktionieren, und diese Spalte entscheidet mehr Architekturfragen als die Feature-Liste.

Der mutige Teil: reask ist die beworbene Funktion und die, die man sorgfältig budgetieren muss, denn jeder reask ist eine zweite vollständige Generierung zum selben Satz wie die erste, und er multipliziert sich mit der Fehlerrate statt mit dem Traffic. Die Dokumentation selbst weist komplexe Fälle von reask weg und empfiehlt einen ansatzbasierten Ansatz, sobald die Fälle wachsen, weil eine Ausnahme einem Handler erlaubt, je nach gescheitertem Validator zu verzweigen, statt das still zurückgegebene Ergebnis von reask zu interpretieren.

Erste Schritte

Die Installation besteht aus dem Kernpaket und den Validatoren, die der Guard braucht, danach richtet guardrails configure die Zugangsdaten ein. Ein Guard entsteht im Code, nicht in einer Konfigurationsdatei, dadurch steht die Fehleraktion neben der Prüfung, zu der sie gehört.

# pip install guardrails-ai guardrails-ai-detect-pii
from guardrails import Guard, OnFailAction
from guardrails_ai.detect_pii import DetectPII

guard = Guard().use(
    DetectPII(pii_entities="pii", on_fail=OnFailAction.FIX)
)

result = guard.validate(
    "Hello, my name is John Doe and my email is john.doe@example.com"
)

print(result.validation_passed)   # True once the scrub lands
print(result.validated_output)    # <PERSON> and <EMAIL_ADDRESS>

Für Aufrufer ohne Python bedient guardrails start jeden Guard an einer Basis-URL der Form localhost:8000/guards/<name>/openai/v1/, ein bestehender OpenAI-Client zeigt darauf hin, ohne neues SDK. Das README nennt zusätzlich JavaScript als unterstützt, wobei das Python-Paket die Referenzimplementierung bleibt.

Kosten

Die Software ist im strengen Sinne kostenlos: Apache-2.0 deckt das Framework und jeden Hub-Validator, und zwischen Installation und Validierung steht nichts Abrechenbares. Die Rechnung entsteht woanders, bei dem, was die Validatoren unterwegs aufrufen.

• Lizenz. Apache-2.0 für Framework und Validatoren; es gibt keine bezahlte Stufe der Bibliothek selbst.
• LLM-Prüfungen. Validatoren wie llm_critic, provenance_llm und qa_relevance_llm_eval kosten pro Prüfung und Antwort einen zusätzlichen Modellaufruf.
• Reasks. Jeder reask ist eine vollständige Neugenerierung, und num_reasks legt fest, wie oft eine Antwort neu erzeugt werden darf, bevor der Guard aufgibt.
• Lokales ML. Validatoren wie detect_pii laufen mit Presidio im Prozess, ihr Preis ist Speicher und Latenz statt Tokens.
• Servermodus. Der optionale Flask-Dienst ist Infrastruktur, die das Deployment selbst betreibt, skaliert und absichert.

Der Vergleich, der zählt, ist der gegen gehostete Moderation. OpenAI führt omni-moderation-latest auf der Preisseite als kostenlos, und NeMo Guardrails steht ebenfalls unter Apache-2.0, keiner der beiden Wettbewerber verlangt also eine Lizenz für dieselbe Aufgabe. Was Guardrails verkauft, ist Abdeckung: ein Moderations-Endpunkt beantwortet eine Frage zur Inhaltspolitik, der Hub kann im selben Durchgang auch Schema, Länge, Wettbewerbernennungen, Prompt-Leakage und Provenienz erzwingen.

Wo es schwächelt

Die Schwächen sind betrieblicher Natur und zeigen sich nach der ersten Woche. Der Hub mischt eine Regex, ein BERT-Modell und einen LLM-Judge hinter einer Abstraktion, die Latenz unterscheidet sich also um Größenordnungen zwischen den Validatoren und die Dokumentation kennt keinen Latenzbudget-Wert pro Validator. Der Sprachfilter des Hubs listet nur Englisch. Die Streaming-Unterstützung endet bei noop und exception, was das Tool für Ausgabe Token für Token ausschließt, wenn die Antwort nicht vollständig gepuffert wird. Und die Abschaltung der gehosteten Inferencing im August 2026 war eine Breaking Change an einem Dienst, den einige Deployings aufgebaut hatten.

Die dritte Alternative ist die, die die meisten Teams tatsächlich ausliefern: handgeschriebene Prüfungen um den Aufruf, eine if-Abfrage für das JSON-Parsing und ein Regex für alles, was wie eine Kontonummer aussieht. Das ist billiger als alle drei Zeilen oben und scheitert konstruktiv still, und genau dieser Fehlertyp ist der Grund für diese Kategorie. Der ehrliche Vergleich ist nicht Guardrails gegen NeMo, sondern Guardrails gegen das, was ein Team nachmittags schreibt und danach vergisst zu erweitern.

Fazit

Einsetzen, wo eine schlechte Antwort Geld, Daten oder Glaubwürdigkeit kostet und wo die Aufzeichnung dessen, was fehlschlug, ebenso zählt wie der Fehler selbst. Das ist das vollständigste Validatorenkatalog unter freier Lizenz, und die Fehleraktion pro Validator ist ein besserer Entwurf als ein globaler Politikschalter. Die Kosten sind die jedes prüfenden Codes im Prozess: man betreibt ihn, man justiert ihn, und man zahlt für die Aufrufe, die die Validatoren auslösen.

1. Verwenden, wenn eine Antwort den Dienst verlässt: personenbezogene Daten in einer Support-Zusammenfassung, SQL, das ein Nutzer ausführt, strukturierte Ausgabe, die ein anderer Dienst parst.
2. Verwenden, wenn eine Prüfspur verlangt wird, denn jeder Fehler landet in guard.history, und eine handgeschriebene Prüfung zeichnet sonst wenig auf.
3. NeMo Guardrails vorziehen, wenn es um Gesprächspolitik geht, etwa wann abgelehnt oder das Thema gewechselt wird, dafür sind Colang-Rails gebaut.
4. Den kostenlosen Moderations-Endpunkt vorziehen, wenn anstößiger Inhalt das einzige Risiko ist und ein Dependency es nicht wert ist.
5. Keine Streaming-Reparaturen erwarten: nur noop und exception reagieren auf eine Teilausgabe, also puffern oder die reparierenden Tools weglassen.

Der Rat der Dokumentation, sobald ein Fall den einfachen Pfad verlässt, lautet: as usecases get more complex, we recommend switching to an exception-based approach. Ein Framework, das empfiehlt, seine Kopffunktion zu verlassen, sobald es schwierig wird, ist ehrlich darüber, wo diese Funktion hingehört.

Quellen

1. Guardrails AI auf GitHub: README, News und FAQ
2. guardrails-ai 0.11.0 auf PyPI
3. Guardrails Hub: 65 Validatoren
4. Guardrails-Dokumentation: Fehlerbehandlung und on-fail-Aktionen
5. Guardrails-Dokumentation: on-fail-Aktionen nutzen
6. Migrations-Issue 1560: Weg von der gehosteten Inferencing
7. NVIDIA NeMo Guardrails auf GitHub
8. NVIDIA NeMo Guardrails-Dokumentation
9. OpenAI-API-Preise, einschließlich Moderation