Guar­drails

Ein Gesprächssystem soll bestimmte Dinge nicht tun. Nicht über das Wetter reden, wenn es für Ter­min­ver­schie­bungen 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 (externe Seite, openai.github.io) prüfen und validieren, was der Nutzer eingibt und was der Agent ausgibt.

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 aus­ein­an­der­ge­nommen.

Manche Anbieter zählen feiner. NVIDIA nennt für NeMo Guardrails (externe Seite, docs.nvidia.com) in einem einzigen Satz fünf Stationen, die an verschiedenen Stellen eines Durchlaufs greifen: Eingang, Abruf, Dialog, Ausführung und Ausgang.

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 (externe Seite, docs.nvidia.com): Eingaben der Nutzer und Antworten des Modells, die unsicher, am Thema vorbei, böswillig oder regelwidrig sind, lassen sich damit sperren, ändern oder prüfen.

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. Wer nur protokolliert, was gesperrt wurde, sieht die geänderten Fälle nie. Ein Fall des Änderns am Eingang ist das Ersetzen von Namen vor dem Versand, beschrieben in Nutzung und Anpassung von LLMs, Kapitel 07.

Bemerkenswert ist auch, was in der Aufzählung neben „unsicher“ steht. Am Thema vorbei, englisch off-topic, 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 (externe Seite, developers.openai.com) sagt es geradeheraus: Wird eine erzeugte Antwort gestreamt, kommen die Werte der Moderation erst, wenn die ganze Ausgabe vorliegt.

Ton prüft diese Schnittstelle laut derselben Seite gar nicht, sie ordnet kein Audio ein.

Was im Gespräch geprüft wird, ist also die Abschrift dessen, was gesagt wurde.

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.

Der Werkzeugkasten von OpenAI für Echtzeit-Agenten geht den zweiten Weg. Die Prüfung der Ausgabe (externe Seite, openai.github.io) läuft dort in Abständen über den bis dahin gesammelten Text und die Abschrift. Schlägt sie an, meldet sie ein Ereignis, und die Anwendung entscheidet, was daraus folgt. Welche Prüfungen es dort gibt, sagt ein Satz der Doku für Echtzeit-Agenten (externe Seite, openai.github.io): Prüfungen am Ausgang für die Antworten des Agenten und Prüfungen am Eingang für die Aufrufe von Funktions-Tools.

Eine Prüfung dessen, was der Anrufer sagt, steht in dieser Aufzählung 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. Manche Anbieter prüfen zusätzlich auf ihrer Seite, für jede Anwendung auf demselben Modell gleich; davon handelt die zweite Tiefe.

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 (externe Seite, huggingface.co) beschreibt es in einem Satz: Llama Guard ist ein Schutzmodell für Ein- und Ausgaben mit sieben Milliarden Parametern, gebaut auf Llama 2.

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: Es stuft laut Modellkarte (externe Seite, huggingface.co) sowohl ein, was in ein Sprachmodell hineingeht (Prompt-Klassifikation), als auch, was herauskommt (Antwort-Klassifikation).

Dieselbe Mechanik am Eingang und am Ausgang, mit demselben Modell.

Was dabei wirklich entschieden wird

Die Modellkarte legt offen, was hinter dem Urteil steckt, und der Satz ist die wichtigste Zeile dieses Kapitels: Wer das Modell nutzt, trifft die Ja-oder-Nein-Entscheidung (externe Seite, huggingface.co) selbst, indem er an die Wahr­schein­lich­keits­werte eine Schwelle seiner Wahl anlegt.

Das Modell liefert eine Wahr­schein­lich­keit, 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 Wahr­schein­lich­keit 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. Dieselbe Mechanik mit einer Frage, die man je Anfrage selbst stellt, steckt in den Ent­schei­dungs­mo­dellen aus KI jenseits der Sprachmodelle, Kapitel 15.

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. Laut der Systemkarte zu GPT-5 (externe Seite, arxiv.org) bringen alle Modelle der Reihe zusätzlich Safe Completions mit, OpenAIs damals neuesten Ansatz im Sicher­heits­trai­ning gegen unzulässige Inhalte.

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, solange er die Gewichte nicht verändert. Was außen herum liegt, gilt nur in dieser Anwendung und lässt sich in einer Stunde ändern.

Eine dritte Schicht liegt beim Anbieter. Anthropic führt bei sechs seiner Modelle Sicher­heits­klas­si­fi­zierer (externe Seite, platform.claude.com), die eine Anfrage ablehnen können. Die Anwendung erhält dann eine gewöhnliche Antwort mit dem Stoppgrund refusal. Diese Schicht gilt in jeder Anwendung auf demselben Modell, und als Ausweg nennt die Seite ein anderes Modell: Dieselbe Anfrage an ein anderes Claude-Modell bringe meist doch eine Antwort.

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.

Bei offenen Gewichten lässt sich die innere Schicht herausrechnen

Bei einem Modell mit offenen Gewichten hält die Trennung nur, solange niemand die Gewichte verändert. Arditi und Kollegen haben das Ablehnen in offenen Chatmodellen untersucht und eine einfache Struktur (externe Seite, arxiv.org) gefunden: In 13 verbreiteten offenen Chatmodellen mit bis zu 72 Milliarden Parametern hängt das Ablehnen an einem eindimensionalen Unterraum.

Für jedes Modell gibt es also eine einzelne Richtung im Inneren. Wird sie aus den Zwi­schen­er­geb­nissen entfernt, lehnt das Modell schädliche Anfragen nicht mehr ab; wird sie hinzugefügt, lehnt es sogar harmlose ab. Die Arbeit baut daraus ein Verfahren, das das Ablehnen abschaltet und die übrigen Fähigkeiten kaum berührt. Es setzt Zugriff auf die Gewichte voraus.

Unter dem Namen Abliteration steht seit Juni 2024 eine Anleitung auf Hugging Face (externe Seite, huggingface.co), mit Code. Die Richtung wird dort einmal fest aus den Gewichten herausgerechnet, und heraus kommt ein neues Modell, das sich weitergeben lässt. Am 05.10.2026 fand die Modellsuche von Hugging Face (externe Seite, huggingface.co) 8.343 Modelle mit dem Wort im Namen.

Für den Bau heißt das: Die innere Schicht eines offenen Modells hat der in der Hand, der die Gewichte weitergibt. Wer ein offenes Modell aus fremder Hand einsetzt, prüft außen, was er sicher wissen will. Für die Prüfungen um das Modell herum ist das ein eigener Grund. Wie sich ein solches Modell bis zu seinem Ursprung zurückverfolgen lässt, steht in Nutzung und Anpassung von LLMs, Kapitel 02.

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 diese Wartezeit 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: Ein leichtes Modell (externe Seite, platform.claude.com) wie Claude Haiku 5.5 sieht die Eingabe des Nutzers durch, bevor sie das eigentliche Gespräch erreicht.

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 jenseits der Sprachmodelle, Kapitel 10.

Für Haiku 5.5 nennt dieselbe Seite (externe Seite, platform.claude.com) eine Eigenheit. Das Modell gehört zu denen mit Sicher­heits­klas­si­fi­zie­rern und kann schon die Prüfanfrage ablehnen. Eine solche Ablehnung soll die Anwendung als Urteil „schädlich“ werten.

Ü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. Der Werkzeugkasten von OpenAI startet die Prüfung der Eingabe deshalb im Standard gleichzeitig mit dem Agenten. Die Doku (externe Seite, openai.github.io) nennt beide Seiten: Läuft die Prüfung blockierend, startet das teure Modell garantiert nicht. Läuft sie parallel, kann das teure Modell schon begonnen haben, bevor die Prüfung fertig ist.

Läuft die Prüfung nebenher, kann der Agent beim Anschlagen schon Tokens verbraucht und Tools ausgeführt haben. Wer das ausschließen will, lässt die Prüfung vorher laufen und nimmt die Wartezeit in Kauf.

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

Prüfungen am Agenten greifen am Anfang und am Ende der Kette

Die Dokumentation des Agenten-Werkzeugkastens (externe Seite, openai.github.io) sagt beides ausdrücklich: Die Prüfung am Eingang läuft nur für den ersten Agenten der Kette. Die Prüfung am Ausgang läuft nur für den Agenten, der die endgültige Ausgabe erzeugt.

Das Wort, auf das es ankommt, ist beide Male nur. Wer drei Agenten hin­ter­ein­an­der­schaltet, prüft so die Eingabe des ersten und die Ausgabe des letzten. Was der zweite an den dritten weiterreicht, sehen diese beiden Prüfungen nicht.

Für die Strecke dazwischen verweist dieselbe Seite auf die Prüfung am Tool (externe Seite, openai.github.io): Wer in einem Ablauf mit Manager-Agenten, Übergaben oder beauftragten Spezialisten vor oder nach jedem Aufruf eines eigenen Funktions-Tools prüfen will, soll Tool-Guardrails einsetzen, statt sich allein auf die Prüfungen am Agenten zu verlassen.

Sie hängt am Tool selbst und läuft bei jedem seiner Aufrufe, gleich welcher Agent ihn auslöst. Ihre Lücken nennt die Seite gleich mit. Die Übergabe an einen anderen Agenten läuft über einen eigenen Weg, und dort greift keine Prüfung am Tool. Dasselbe gilt für die Tools, die der Anbieter selbst betreibt, etwa Websuche, Dateisuche und Codeausführung.

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, braucht die Strecke dazwischen eigene Prüfungen an den Tools. Wer sich auf die beiden Prüfungen am Agenten verlässt, 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: Die Eingangsprüfung am Tool (externe Seite, openai.github.io) läuft, bevor das Tool ausgeführt wird, und kann den Aufruf überspringen, seine Ausgabe durch eine Nachricht ersetzen oder einen Abbruch auslösen.

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 lassen sich verbinden. Der Werkzeugkasten legt die Reihenfolge (externe Seite, openai.github.io) fest: Braucht ein Funktions-Tool eine Freigabe, läuft die Eingangsprüfung im Normalfall nach der Freigabe und unmittelbar vor der Ausführung.

Auf Wunsch prüft die Regel zusätzlich vor der Rückfrage. Dann sieht niemand eine Rückfrage zu einem Aufruf, den die Regel ohnehin abweist, und nach der Zustimmung wird trotzdem noch einmal geprüft. Beim Bau bleibt die Frage, was eine Regel bekommt und was eine Rückfrage.

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 auf­ein­an­der­fol­genden Sätzen der Moderations-Dokumentation (externe Seite, developers.openai.com). Zuerst, was geprüft wird: Bei Anfragen mit Tool Calls erfasst die Moderation die Argumente der Aufrufe und die Ausgaben der Tools, sofern sie im Gesprächsinhalt stehen.

Und unmittelbar danach, was ausgenommen bleibt: Namen, Beschreibungen und Schemata der Tools sowie die Schemata für das Antwortformat.

Wer Agenten und Harness, Kapitel 02 gelesen hat, erkennt die Aufzählung. Name, Beschreibung und Schema eines Tools liefert bei einem fremden Server dessen Betreiber, und die dortige Spezifikation führt solche Beschreibungen als fremden Text im eigenen Kontextfenster, als unver­trau­ens­würdig. 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 (externe Seite, platform.claude.com) fasst beide Fälle in einem Satz zusammen: Jailbreak und Prompt Injection sind Versuche, Claude dazu zu bringen, seine Richtlinien oder die Anweisungen des Betreibers zu übergehen.

Der Unterschied liegt darin, wer angreift, und danach teilt die Seite ein. Beim Jailbreak und bei der direkten Prompt Injection ist es der Mensch im Gespräch, der die Vorgaben umgehen will. Bei der indirekten 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: die Antworten anpassen und Nutzer, die wiederholt versuchen, die Guardrails der Anwendung zu umgehen, bremsen oder sperren (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: Claude ausdrücklich sagen, dass Inhalte aus Tools, Dokumenten oder Suchen nicht vertrauenswürdige Daten (externe Seite, platform.claude.com) sind und weder den Systemprompt noch die ursprüngliche Bitte des Nutzers je außer Kraft setzen dürfen.

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.

Was die veröffentlichten Zahlen messen

Alles bisher Beschriebene ist Mechanik. Zahlen zur Wirksamkeit stehen in den Begleitdokumenten, die die Hersteller zu ihren Modellen veröffentlichen. OpenAIs Begleitdokument zu GPT-5 (externe Seite, arxiv.org) vom August 2025 misst in Tabelle 5 Anfragen mit bekannten Jailbreaks. Über vier Modelle und vier Kategorien waren 93,4 bis 99,9 Prozent der Antworten unbedenklich. Tabelle 7 misst eingeschleuste Anweisungen in Webseiten, Tool-Ausgaben und Code. Das denkende Modell widerstand ihnen in 97 bis 99 Prozent der Fälle.

Gemessen ist dabei das Modell mit seinem Training, auf den Prüfsätzen des Herstellers. Die Prüfungen, die ein Betreiber um das Modell legt, kommen in diesen Tabellen nicht vor. Auch die eigene Abwehr legt OpenAI nur zum Teil offen: Es gebe weitere Schutzmaßnahmen (externe Seite, arxiv.org), die wegen der gegnerischen Natur von Prompt Injections nicht alle beschrieben werden.

Für die Schicht außen herum nennt keine Quelle dieses Kapitels eine Trefferquote oder eine Rate falscher Alarme. Bei einem Guardrail mit Schwelle, wie ihn die zweite Tiefe beschreibt, hängt jede solche Quote an der Schwelle, die der Betreiber wählt.

Wer die Quote für die eigene Anwendung wissen 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. Ob er richtig lag, zeigt erst der Testlauf. Wie sich das prüfen lässt, steht in Kapitel 10.