Guardrails (AI)

Evals, die in Production laufen — bevor die Antwort den Nutzer erreicht. Wenn ein Eval einen Fehler erkennt, kann die Antwort abgefangen, neu generiert oder korrigiert werden, bevor sie gesendet wird.

Der Begriff stammt aus der AI-Engineering-Praxis und wurde von Teresa Torres klar von regulären AI Evals abgegrenzt: Evals messen, ob ein Fehler passiert ist. Guardrails verhindern, dass ein Fehler beim Nutzer ankommt.

Wann es sich lohnt

Nicht jeder Eval sollte ein Guardrail werden. Jeder zusätzliche LLM-Call in der Response-Pipeline kostet Latenz und Geld. Die Abwägung:

• Hoher Schaden durch Fehler → Guardrail sinnvoll (z.B. der Coach schlägt eine Suggestivfrage vor, die der Student dann in echten Interviews anwenden würde)
• Niedriger Schaden, hoher Durchsatz → besser als nachgelagerter Eval auf einer Stichprobe der Traces

Teresa Torres’ Beispiel: Wenn der Eval erkennt, dass der Interview Coach eine allgemeine Frage vorschlägt, kann ein weiterer LLM-Call die Frage ersetzen, bevor der Feedback-Text an den Studenten gesendet wird. Das ist ein Guardrail.

Technisch

Guardrails sind keine besondere Infrastruktur — es sind dieselben Eval-Logiken, die man in der Pipeline vor dem Response-Schritt ausführt. Code-basierte Evals (String-Matching) sind besonders geeignet, weil sie schnell und günstig sind. LLM-as-Judge-Guardrails sind teurer, aber manchmal nötig.

Verbindungen

• AI Evals — Guardrails sind eine Teilmenge davon, nur mit anderem Ausführungszeitpunkt
• Error Mode Analysis — identifiziert, welche Fehlermodi kritisch genug für Guardrails sind
• Teresa Torres — hat die Unterscheidung Eval vs. Guardrail im Interview-Coach-Kontext erklärt

Quellen

• YouTube: “AI Evals & Discovery - All Things Product with Teresa & Petra” (Teresa Torres + Petra Wille, 2025-09)