Guardrails

Ein Gesprächssystem soll bestimmte Dinge nicht tun. Nicht über das Wetter reden, wenn es für Terminverschiebungen gebaut ist. Keine Auskunft geben, für die niemand geradesteht. Die Vorkehrungen dafür heißen Guardrails, auf Deutsch Leitplanken, und sie liegen um das Modell herum.

Drei Stellen, an denen geprüft wird

Der Werkzeugkasten von OpenAI für Agenten beschreibt die ersten beiden in einem Satz:

Guardrails enable you to do checks and validations of user input and agent output. (externe Seite, openai.github.io)

Am Eingang wird geprüft, was hereinkommt, bevor das Modell es sieht. Am Ausgang wird geprüft, was hinausgeht, bevor jemand es hört. Die dritte Stelle ist der Tool Call, also der Moment, in dem das System etwas tut statt etwas zu sagen. Sie hängt eng an Kapitel 06 und wird in der dritten Tiefe dieses Kapitels auseinandergenommen.

Manche Anbieter zählen feiner. NVIDIA nennt fünf Stationen, und zwar in einem einzigen Satz:

Input, retrieval, dialog, execution, and output rails run at different stages of an LLM interaction. (externe Seite, docs.nvidia.com)

Dazwischen liegen der Abruf von Unterlagen und die Gesprächsführung selbst. Wer mit den drei groben Stellen anfängt, hat die Sache verstanden; die feinere Einteilung wird interessant, sobald eine Anwendung wirklich gebaut wird.

Sperren, ändern, prüfen

Was ein Guardrail mit einem Befund anstellt, steht bei demselben Anbieter:

Use it to block, alter, or validate unsafe, off-topic, malicious, or policy-violating user inputs and model responses. (externe Seite, docs.nvidia.com)

Drei Verben, und das mittlere ist das überraschende. Ein Guardrail hat also drei Möglichkeiten, und der Abbruch ist eine davon. Er kann eine Eingabe entschärfen oder eine Antwort umschreiben, und der Anrufer merkt davon nichts. Das ist bequem und hat einen Preis: Wer nur protokolliert, was gesperrt wurde, sieht die geänderten Fälle nie.

Bemerkenswert ist auch, was in der Aufzählung neben „unsafe“ steht. Off-topic, also am Thema vorbei, hat mit Sicherheit wenig zu tun. In einer Sprachanwendung ist es trotzdem der häufigere Fall: Die meisten Gespräche, die schieflaufen, laufen einfach woandershin.

Warum das im Gespräch später kommt

Eine Prüfung der Ausgabe hat ein Zeitproblem, das im Chatfenster niemandem auffällt. Die Dokumentation der Moderations-Schnittstelle sagt es geradeheraus:

If you stream a generated response, moderation scores arrive after the full generated output is available. (externe Seite, developers.openai.com)

Am Bildschirm ist das verschmerzbar. Der Text läuft ein, und wenn die Prüfung danach anschlägt, lässt er sich ausblenden oder ersetzen, bevor jemand ihn zu Ende gelesen hat.

Im Gespräch gibt es dieses Zeitfenster nicht. Die Antwort wird gesprochen, während sie entsteht, das ist die Bedingung, unter der Kapitel 03 überhaupt funktioniert. Was das Modell erzeugt hat, ist gehört, bevor die Prüfung ihr Urteil hat.

Daraus folgt eine Bauentscheidung, die es am Bildschirm so nicht braucht: Entweder wird auf die vollständige Antwort gewartet, dann kostet die Prüfung Wartezeit. Oder es wird während des Sprechens geprüft, dann greift die Prüfung erst beim nächsten Stück. Beides ist vertretbar, und ein drittes gibt es nicht.

Weshalb dasselbe Modell sich verschieden verhält

Guardrails gehören zur Anwendung. Sie stehen in deren Programm, sie werden von deren Betreiber eingestellt, und sie lassen sich ändern, ohne die Gewichte anzufassen. Das Modell selbst weiß von ihnen nichts.

Deshalb sagt die Auskunft „wir benutzen Modell X“ wenig darüber, was ein System tut. Zwei Anwendungen auf derselben Grundlage können sich sehr verschieden verhalten, und der Unterschied liegt in dem, was drumherum gebaut wurde. Für die Einordnung eines Angebots ist das die nützlichere Frage.

Wer prüfen will, ob ein Satz gefährlich ist, braucht etwas, das Sprache versteht. Deshalb ist ein Guardrail häufig selbst ein Sprachmodell.

Ein Modell, das nur einstuft

Meta hat für diesen Zweck ein eigenes veröffentlicht. Die Modellkarte beschreibt es in einem Satz:

Llama-Guard is a 7B parameter Llama 2-based input-output safeguard model. (externe Seite, huggingface.co)

Sieben Milliarden Parameter sind nach heutigen Maßstäben wenig: Ein Prüfmodell soll schnell und billig sein. Es beantwortet eine einzelne Frage, und zwar an beiden Enden:

It can be used for classifying content in both LLM inputs (prompt classification) and in LLM responses (response classification). (externe Seite, huggingface.co)

Dieselbe Mechanik am Eingang und am Ausgang, mit demselben Modell. Das ist der Grund, warum diese Bauform sich durchgesetzt hat.

Was dabei wirklich entschieden wird

Die Modellkarte legt offen, was hinter dem Urteil steckt, und der Satz ist die wichtigste Zeile dieses Kapitels:

Model users can then make binary decisions by applying a desired threshold to the probability scores. (externe Seite, huggingface.co)

Das Modell liefert eine Wahrscheinlichkeit, also eine Zahl zwischen null und eins. Ein Ja oder Nein entsteht erst eine Stufe später: Wer das Modell einsetzt, legt die Schwelle fest, ab der etwas als unsicher gilt. Dieselbe Seite beschreibt weiter oben, woher die Zahl kommt: aus der Wahrscheinlichkeit des ersten Tokens, das das Modell erzeugt.

Damit ist gesagt, was „sicher“ in diesem Zusammenhang bedeutet. Es ist eine Einstellung, die jemand vorgenommen hat, und wer sie ändert, ändert das Verhalten des Systems, ohne eine Zeile am Modell zu ändern. Wer eine Schwelle tief legt, blockt mehr Harmloses. Wer sie hoch legt, lässt mehr durch. Eine Einstellung, die beides zugleich verbessert, gibt es nicht.

Wer die Zahlen dahinter kennt, liest auch die Werbung anders. Die Aussage „das System hat Guardrails“ beschreibt eine Bauform. Über die Schwelle, an der sie eingestellt ist, sagt sie nichts.

Die zweite Schicht sitzt weiter innen

Neben den Prüfungen um das Modell herum gibt es Vorkehrungen im Modell selbst, angelegt beim Training. OpenAI nennt seine so:

All of the GPT-5 models additionally feature safe-completions, our latest approach to safety training to prevent disallowed content. (externe Seite, arxiv.org)

Die zwei Schichten haben verschiedene Eigenschaften, und beim Bauen zählt der Unterschied. Was im Training steckt, gilt überall, wo das Modell läuft, und lässt sich vom Betreiber nicht anpassen. Was außen herum liegt, gilt nur in dieser Anwendung und lässt sich in einer Stunde ändern.

Für eine Sprachanwendung heißt das: Die Schulung des Modells deckt ab, was allgemein unerwünscht ist. Alles, was mit dem eigenen Anwendungsfall zu tun hat, muss außen gebaut werden. Kein Modell weiß von sich aus, dass es über Preise keine Auskunft geben soll.

Was eine Prüfung im Gespräch kostet

Jede Prüfung ist ein eigener Aufruf, und ein Aufruf dauert. In Kapitel 05 steht, wie ein Anbieter diesen Preis selbst beziffert: Wer vor der Antwort etwas prüfen will, bezahlt dafür mit Wartezeit. Für Guardrails gilt dieselbe Rechnung, und sie fällt an jeder der drei Stellen erneut an.

Anthropic beschreibt den üblichen Ausweg:

Use a lightweight model like Claude Haiku 4.5 to pre-screen user input before it reaches your main conversation. (externe Seite, platform.claude.com)

Ein kleines Modell vor dem großen. Das ist dieselbe Überlegung wie bei Llama Guard und dieselbe wie in Grundkurs, Kapitel 10: Für eine einfache Frage genügt ein einfaches Modell, und der Zeitgewinn ist der eigentliche Grund. Was diese Modellklasse ausmacht, steht in KI-Wissen, Kapitel 10.

Übrig bleibt trotzdem eine Entscheidung, die niemandem abgenommen wird. Drei Prüfungen hintereinander sind drei Aufrufe, und in einem Gespräch, dessen Antwort nach etwa einer Sekunde anfangen soll, ist das viel. Wer alles prüfen will, baut ein langsames System. Wer nichts prüft, baut ein schnelles, für das niemand geradestehen möchte.

Die drei Stellen aus der Übersicht sind eine Vereinfachung. In einer wirklichen Anwendung stehen mehrere Agenten hintereinander, und dann greift eine Prüfung an genau einer Stelle jeder Kette.

Wo ein Guardrail greift, und wo die Kette blank ist

Die Dokumentation des Agenten-Werkzeugkastens sagt beides ausdrücklich:

Input guardrails run only for the first agent in the chain. (externe Seite, openai.github.io)

Output guardrails run only for the agent that produces the final output. (externe Seite, openai.github.io)

Das Wort, auf das es ankommt, ist beide Male only. Wer drei Agenten hintereinanderschaltet, prüft die Eingabe des ersten und die Ausgabe des letzten. Was der zweite an den dritten weiterreicht, läuft ungeprüft durch.

Für ein Gesprächssystem mit einem einzigen Agenten spielt das keine Rolle. Sobald ein Gespräch an einen spezialisierten Agenten weitergereicht wird, was Agenten und Harness, Kapitel 01 beschreibt, sind die Zwischenstrecken offen. Wer das übersieht, hat eine Prüfung eingebaut und misst dabei die falsche Stelle.

Der Guardrail am Tool Call

Die dritte Station ist die interessanteste, weil dort etwas geschieht statt gesagt zu werden. Derselbe Werkzeugkasten beschreibt sie so:

Input tool guardrails run before the tool executes and can skip the call, replace the output with a message, or raise a tripwire. (externe Seite, openai.github.io)

Drei Reaktionen, und die mittlere ist die für ein Gespräch brauchbarste. Der Aufruf unterbleibt, und an seine Stelle tritt eine Nachricht, mit der das Modell weiterarbeitet. Das Gespräch läuft weiter, die Handlung findet nicht statt, und niemand muss gefragt werden. Die dritte Reaktion, im Original tripwire genannt, bricht den Lauf ab.

Hier verläuft die Grenze zu Kapitel 06. Dort geht es um die Zustimmung: Die Spezifikation verlangt vor jedem Tool Call eine ausdrückliche Einwilligung, und im Gespräch wird daraus eine Rückfrage, die einen Zug kostet. Hier entscheidet eine Regel, ohne jemanden zu fragen. Beide sitzen an derselben Stelle des Ablaufs, und die Frage, welche von beiden greift, ist eine der ersten beim Bau.

Die Faustregel dafür ergibt sich aus dem, was Kapitel 01 zwischen Antworten und Handeln zieht. Was sich zurücknehmen lässt, bekommt eine Regel. Was sich nicht zurücknehmen lässt, bekommt eine Rückfrage. Wer alles mit Rückfragen absichert, bekommt die Ermüdung, die Agenten und Harness, Kapitel 02 beschreibt.

Die Fläche, die ausgelassen wird

Der schärfste Befund dieses Kapitels steht in zwei aufeinanderfolgenden Sätzen der Moderations-Dokumentation. Zuerst, was geprüft wird:

For tool-calling requests, moderation covers tool-call arguments and tool outputs when they appear in conversation content. (externe Seite, developers.openai.com)

Und unmittelbar danach, was ausgenommen bleibt:

It doesn’t cover tool names, tool descriptions, tool schemas, or response-format schemas. (externe Seite, developers.openai.com)

Wer Agenten und Harness, Kapitel 02 gelesen hat, erkennt die Aufzählung. Genau diese vier Dinge führt die dortige Spezifikation als fremden Text im eigenen Kontextfenster, als unvertrauenswürdig und vom Server eines Dritten geliefert. Die Moderation prüft, was durch diese Tools fließt, und lässt aus, wodurch sie beschrieben sind.

Dahinter steht eine Frage der Zuständigkeit. Eine Moderations-Schnittstelle prüft Gesprächsinhalte, und eine Tool-Beschreibung gehört einer anderen Ebene an. Für den Bauenden bleibt die Folge dieselbe. Wer Tools von fremden Servern einbindet, hat eine Fläche im Kontextfenster, die keine der drei Stationen abdeckt, und muss sie eigens behandeln.

Zwei Angreiferbilder in einem System

Anthropics Anleitung zu dem Thema fasst beide Fälle in einem Satz zusammen:

Jailbreaking and prompt injection are attempts to make Claude ignore its guidelines or your instructions. (externe Seite, platform.claude.com)

Der Unterschied liegt darin, wer angreift. Beim Jailbreak ist es der Mensch im Gespräch, der die Vorgaben umgehen will. Bei der Prompt Injection kommt der Angriff aus einem Text, den das System selbst hereingeholt hat, und der Anrufer ist dabei das Opfer.

Für den ersten Fall empfiehlt die Seite eine Antwort, die im Sprachkanal Aufmerksamkeit verdient:

Adjust responses and consider throttling or banning users who repeatedly attempt to circumvent your application’s guardrails. (externe Seite, platform.claude.com)

Am Bildschirm ist ein Konto die Handhabe dafür. Am Telefon steht dafür die Rufnummer zur Verfügung, und die lässt sich fälschen. Was Kapitel 04 über den Anruf als Ereignis sagt, gilt hier weiter: Der Anbieter meldet den eingehenden Anruf, und die Anwendung entscheidet über zwei Endpunkte, ob sie ihn annimmt. Eine Sperre gegen wiederholte Versuche sitzt also vor dem Gespräch, an der Stelle, an der über die Annahme entschieden wird.

Für den zweiten Fall lautet die Empfehlung so:

Tell Claude explicitly that content returned from tools, documents, or searches is untrusted data and must never override the system prompt or the user’s original request. (externe Seite, platform.claude.com)

Das ist eine Anweisung an das Modell, und Agenten und Harness, Kapitel 01 hält dagegen, warum keine bessere Formulierung dieses Problem löst. Beides steht nebeneinander und beides stimmt: Der Hinweis im Systemprompt senkt die Trefferquote eines Angriffs. Was ihn wirklich verschließt, liegt eine Schicht tiefer, in den Rechten des Tools.

Wozu es keine Zahl gibt

Alles bisher Beschriebene ist Mechanik. Wie gut Guardrails halten, steht in keiner der geprüften Quellen. Keine nennt eine Trefferquote, keine eine Rate falscher Alarme, keine eine Umgehungsquote.

Die Zahlen dazu gibt es. Sie stehen in den Begleitdokumenten, die die Anbieter zu ihren Modellen veröffentlichen, und die sind auf dieser Seite aus einem schlichten Grund nicht zitiert: Anthropics Dokument liegt ausschließlich als PDF vor, OpenAI gibt von seinem nur die Zusammenfassung als lesbaren Text frei. Der Prüflauf dieser Seite kann in beiden Fällen nichts nachschlagen, und ohne Prüfung steht hier keine Zahl.

Damit bleibt eine Aussage stehen, die dieses Kapitel nicht auflösen kann. Beschrieben ist, woraus Guardrails gebaut sind. Wie zuverlässig sie in einer laufenden Anwendung wirken, ist hier eine offene Frage.

Wer sie für die eigene Anwendung beantworten will, kommt an der Messung nicht vorbei, und die findet im Testlauf statt. Im Betrieb ist nur zu sehen, dass ein Guardrail ausgelöst hat, nicht ob er richtig lag. Wie sich das prüfen lässt, steht in Kapitel 10.