Guardrails in der KI: Was sie kontrollieren, wo sie wirken und was sie nicht garantieren

Definition: Was ist ein Guardrail?

Ein Guardrail in der künstlichen Intelligenz ist eine Kontrolle, die eine Eingabe, eine Ausgabe oder eine Aktion eines Systems anhand einer festgelegten Richtlinie bewertet. Je nach Ergebnis lässt sie den Vorgang weiterlaufen, verändert oder blockiert ihn oder fordert eine Prüfung an. Im Deutschen werden auch Begriffe wie „Sicherheitsbarriere“, „Schutzmaßnahme“ oder „Kontrolle“ verwendet. Sie bezeichnen jedoch nicht immer genau denselben Mechanismus.

Die Definition beschreibt eine Funktion, keine einheitliche Architektur. Ein Guardrail kann eine einfache, regelbasierte Prüfung, ein mit Daten trainierter Detektor, eine Kombination verschiedener Kontrollen oder eine Stufe in einem umfassenderen Ablauf sein. Um ein konkretes Guardrail zu verstehen, sollte man fragen: Welches Objekt prüft es, an welcher Stelle greift es ein, welche Richtlinie wendet es an und was tut es, wenn es einen möglichen Verstoß erkennt?

Eine Forschungsarbeit zu Guardrails für Sprachmodelle bietet eine eng gefasste Definition: Ein Algorithmus erhält Objekte, etwa die Eingabe oder die Ausgabe eines Modells, und entscheidet, ob er darauf reagieren soll. Diese Formulierung hilft, den Begriff präziser zu fassen. Sie bedeutet aber weder, dass alle Kontrollen gleich funktionieren, noch ist sie ein Beleg dafür, dass ein bestimmtes Guardrail wirksam ist.

Wo Guardrails eingreifen können

Eine Eingabekontrolle prüft Informationen, bevor sie das Modell oder einen anderen Teil des Systems erreichen. Sie kann nach unzulässigen Inhalten, Daten, die nicht verarbeitet werden sollen, oder Anweisungen suchen, die einer Richtlinie widersprechen. Ihr Nutzen hängt davon ab, was sie tatsächlich erkennen kann und ob es eine sichere Alternative gibt, wenn sie eine Anfrage stoppt. Eine Eingabekontrolle prüft nicht automatisch alles, was anschließend geschieht.

Während einer Interaktion können weitere Prüfungen stattfinden. Ein System könnte beispielsweise prüfen, ob ein Tool auf zulässige Weise aufgerufen wird oder ob eine menschliche Bestätigung erforderlich ist. Die für diesen Beitrag bereitgestellte Dokumentation von Microsoft Learn beschreibt Kontrollen als Festlegungen dazu, welche Risiken erkannt werden sollen und an welchen Stellen Prüfungen stattfinden. Das verfügbare Fragment beschreibt weder eine universelle Architektur noch belegt es, dass alle Systeme diesem Muster folgen.

Eine Ausgabekontrolle prüft eine Antwort, bevor sie angezeigt oder verwendet wird. Sie kann feststellen, ob die Antwort Material enthält, das gegen eine Richtlinie verstößt, Informationen preisgibt, die nicht offengelegt werden sollten, oder eine bestimmte Formatbedingung erfüllt. Dass eine Antwort diese Prüfung besteht, sagt nur etwas über das Ergebnis dieser einen Prüfung aus. Es bestätigt weder die Richtigkeit des Inhalts noch, dass im System keine weiteren Risiken bestehen.

Eine Anwendung kann Kontrollen an mehreren Stellen enthalten. Die Bewertung einer Eingabe ersetzt nicht die Prüfung einer Antwort; beides ist wiederum nicht dasselbe wie eine Begrenzung der Aktionen, die ein Agent ausführen kann. Die Abdeckung lässt sich am besten als Menge von Kontrollen mit klar umrissenen Zuständigkeiten beschreiben und nicht als einzelne Barriere, die sämtliche Risiken lösen könnte.

Wie Guardrails implementiert werden können

Eine regelbasierte Kontrolle prüft ausdrücklich festgelegte Bedingungen. Sie kann beispielsweise feststellen, ob eine Anfrage eine Kennung in einem bestimmten Format enthält oder ob eine Aktion auf einer Zulassungsliste steht. Ein Vorteil ist, dass sich das Kriterium bei einer klar formulierten Regel meist leicht nachvollziehen lässt. Auch die Grenzen sind konkret: Eine zu eng gefasste Bedingung deckt möglicherweise nicht alle Varianten ab; eine zu weit gefasste Regel kann zulässige Fälle blockieren.

Eine Kontrolle auf Basis maschinellen Lernens verwendet ein Modell, um Inhalte entsprechend seinem Training und seiner Konfiguration zu klassifizieren, zu erkennen oder zu bewerten. Sie kann dabei helfen, Muster zu erkennen, die sich nicht mit einer einzigen festen Bedingung beschreiben lassen. Aber auch ihr Ergebnis kann falsch sein. Die Leistung muss im jeweiligen Anwendungskontext gemessen werden. Die Bezeichnung „KI-basiert“ verrät für sich genommen weder die Genauigkeit noch die verwendeten Evaluationsdaten oder das Verhalten bei neuen Fällen.

Eine sekundäre Quelle von DataCamp weist darauf hin, dass einige aktuelle Implementierungen deterministische Regeln und maschinelles Lernen kombinieren. Das ist eine Beschreibung bestimmter Implementierungen, keine allgemeingültige Regel. Die für diesen Beitrag verfügbaren Unterlagen ermöglichen keinen detaillierten Vergleich dieser Ansätze und rechtfertigen keine pauschale Aussage, welcher davon grundsätzlich besser ist. Entscheidend ist in jedem Fall, die konkreten Kriterien zu kennen, sie zu testen und zu prüfen, wie mit unterschiedlichen Ergebnissen einzelner Komponenten umgegangen wird.

Es gibt außerdem Projekte und Dienste, die ausdrücklich als Guardrail-Werkzeuge bezeichnet werden, sowie Forschung zu Methoden, mit denen Kontrollen integriert werden können. Die Existenz einer Bibliothek, einer API oder einer Forschungsarbeit belegt, dass eine Implementierung oder Forschungsrichtung existiert. Sie reicht nicht aus, um zu folgern, dass alle Risiken abgedeckt sind, die Lösung in anderen Kontexten gleich funktioniert oder unabhängig evaluiert wurde.

Beispiel: Kundenservice

Angenommen, ein Assistent formuliert eine Antwort zu einer Rückgabe. Die Servicerichtlinie nennt konkrete Voraussetzungen für eine Rückgabe, untersagt nicht genehmigte Ausnahmen und verlangt, bestimmte Fälle an eine Person weiterzuleiten. Ein Ausgabeguardrail könnte prüfen, ob die Antwort diesen Bedingungen widerspricht, bevor sie angezeigt wird.

Entdeckt die Prüfung möglicherweise nicht genehmigte Zusagen, könnte das System die Antwort blockieren, das Modell um eine neue, auf freigegebenen Informationen beruhende Fassung bitten oder die Anfrage weiterleiten. Welche Option angemessen ist, hängt von der Gestaltung und dem Risiko ab. Bei einer mehrdeutigen Formulierung kann eine automatische Überarbeitung zum Beispiel sinnvoll sein; ein Fall mit finanziellen Folgen könnte dagegen eine menschliche Prüfung erfordern.

Diese Kontrolle stellt nicht zwangsläufig fest, ob die Rückgaberichtlinie fair ist, ob die abgefragten Daten aktuell sind oder ob die Antwort die Frage korrekt löst. Das sind andere Aufgaben. Um die Rolle des Guardrails nicht zu überhöhen, sollte man es als Prüfung von Antworten anhand der Serviceregeln beschreiben und nicht als Garantie für einen durchgehend korrekten Kundenservice.

Beispiel: Ein Agent verwendet Tools

Ein Agent kann Aktionen über Tools vorschlagen, etwa ein internes System abfragen, einen Datensatz ändern oder eine Nachricht senden. In diesem Szenario bleibt die externe Aktion unkontrolliert, wenn nur der Text geprüft wird, den der Agent einer Person anzeigt. Eine Kontrolle vor der Ausführung kann prüfen, ob der Vorgang zulässig ist, ob die nutzende Person dazu berechtigt ist und ob eine Bestätigung erforderlich ist.

Ein Software-Agent schlägt beispielsweise vor, den Status eines Tickets zu ändern. Ein Guardrail könnte die Aktion und ihre Parameter mit den Regeln des Arbeitsablaufs abgleichen und sie stoppen, wenn die erforderlichen Berechtigungen fehlen. Die Berechtigungsprüfung entscheidet, ob der Vorgang autorisiert ist. Ein Guardrail kann eine Richtlinie durchsetzen oder überprüfen, sollte aber nicht mit dem Identitäts- und Autorisierungsmechanismus verwechselt werden, den das System benötigt.

Wichtig ist auch, dass sich die Entscheidung nachvollziehen lässt. Eine Meldung wie „Die Aktion ist sicher“ ersetzt nicht die Prüfung, welches Tool mit welchen Parametern und unter welchen Zugangsdaten aufgerufen wird. Bei folgenreichen Vorgängen kann eine Richtlinie eine ausdrückliche Bestätigung oder eine menschliche Prüfung verlangen. Das ist ein Gestaltungsbeispiel und keine Fähigkeit, die jedes Guardrail-Tool bietet.

Beispiel: Inhaltserzeugung

Für ein Tool, das Texte für eine Organisation erstellt, könnte eine redaktionelle Richtlinie untersagen, personenbezogene Daten offenzulegen, bestimmte Hinweise in der Antwort verlangen oder unbelegte Aussagen auf Grundlage der bereitgestellten Informationen einschränken. Ein Guardrail kann je nach Kontrollziel die Eingabe, die Ausgabe oder beides prüfen.

Eine Eingabeprüfung kann dem System ermöglichen, schon zu Beginn eine Anfrage zu erkennen, die nicht bearbeitet werden soll oder eine anonymisierte Fassung erfordert. Eine Ausgabekontrolle kann Formulierungen finden, die gegen eine redaktionelle Regel verstoßen, bevor der Text veröffentlicht wird. Das sind unterschiedliche Kontrollen: Die Prüfung nur der Anfrage stellt nicht sicher, dass die spätere Antwort der Richtlinie entspricht. Die Prüfung nur der Antwort verhindert umgekehrt nicht, dass Daten verarbeitet wurden, die hätten ausgeschlossen werden müssen.

Die Kriterien müssen sich testen lassen. Eine Richtlinie wie „problematische Inhalte vermeiden“ ist zu unbestimmt, um genau zu erklären, was kontrolliert wird. Klar abgegrenzte Regeln – etwa ein bestimmtes Datenfeld nicht in den endgültigen Text aufzunehmen – lassen sich leichter bewerten. Auch sie lösen jedoch nicht automatisch jedes redaktionelle oder sachliche Risiko.

Verwandte Begriffe, die auseinandergehalten werden sollten

Moderation bezeichnet üblicherweise die Bewertung von Inhalten anhand einer Richtlinie und eine darauf folgende Entscheidung, etwa ob Inhalte zugelassen, eingeschränkt oder eskaliert werden. Moderation kann als Guardrail implementiert werden, die Begriffe sind aber nicht genau gleichbedeutend: „Moderation“ beschreibt eine häufige Aufgabe; „Guardrail“ kann auch Ablaufkontrollen, Aktionsprüfungen oder Einschränkungen in anderen Phasen umfassen.

Alignment bezeichnet in einem weiten Sinn das Bestreben, das Verhalten eines Systems an Zielen, Präferenzen oder Beschränkungen auszurichten. Ein Guardrail ist eine konkrete Kontrolle, die eine Richtlinie an einer bestimmten Stelle durchzusetzen versucht. Das Vorhandensein einer einzelnen Kontrolle beweist weder ein allgemeines Alignment des Modells noch, dass die angewandte Richtlinie alle relevanten Ziele berücksichtigt.

Autorisierung und Berechtigungen legen fest, wer welche Operation an welcher Ressource ausführen darf. Ein Guardrail kann eine Aktion anhand dieser Grenzen prüfen, ersetzt aber nicht zwangsläufig Identitätsprüfung, Zugriffskontrolle oder Protokollierung. Verfügt das System über zu weitreichende Berechtigungen, behebt ein Textfilter dieses Problem nicht von selbst.

Prompt Injection bezeichnet eine Problemklasse, bei der Anweisungen in bereitgestellten Inhalten versuchen können, das vorgesehene Verhalten des Systems zu verändern. Ein Guardrail kann Teil einer Schutzmaßnahme sein, ist aber keine automatische Lösung und erkennt nicht notwendigerweise alle bösartigen Anweisungen. Bei einem Agenten können außerdem Berechtigungskontrollen, die Isolierung von Tools und Begrenzungen der Aktionen nötig sein.

Ein Agent schließlich ist ein System, das Schritte koordinieren oder Tools verwenden kann, um eine Aufgabe zu erledigen. Ein Guardrail kann einige dieser Aktionen einschränken, ist aber weder der Agent selbst noch eine Garantie dafür, dass der gesamte Ablauf sicher ist. Wer diese Begriffe getrennt benennt, schreibt nicht einer einzelnen Komponente die Verantwortung für die gesamte Architektur zu.

Grenzen, Fehler und Evaluation

Ein Guardrail kann nur die Richtlinie durchsetzen, die für es festgelegt wurde, und nur das erkennen, was seine Methode tatsächlich erfasst. Ist die Richtlinie unvollständig, mehrdeutig oder veraltet, kann die Kontrolle eine ungeeignete Regel konsequent anwenden. Versagt die Erkennung, kann sie einen Verstoß durchlassen oder zulässige Inhalte blockieren. Beide Fehlerarten sind relevant: Der erste kann ein Risiko entstehen lassen, der zweite eine legitime Aufgabe verhindern.

Auch der Kontext beeinflusst das Ergebnis. Eine Formulierung kann in einer Anfrage harmlos, in einer anderen aber sensibel sein. Eine Ausgabe, die für eine Person akzeptabel ist, kann einer bestimmten Richtlinie widersprechen. Außerdem können Komponenten zu unterschiedlichen Ergebnissen kommen, etwa wenn ein Detektor eine Anfrage blockiert, die eine andere Regel zulässt. Deshalb muss neben den Regeln dokumentiert werden, wer die endgültige Entscheidung trifft und wie unklare Fälle geprüft werden.

Um ein Guardrail zu evaluieren, braucht es geeignete Testfälle für den vorgesehenen Einsatzzweck, klare Kriterien und Aufmerksamkeit für die relevanten Fehler. Die Anzahl blockierter Anfragen reicht nicht aus, um die Güte einer Kontrolle zu beurteilen. Ebenso sollte geprüft werden, welche zulässigen Anfragen fälschlich blockiert und welche problematischen Fälle nicht erkannt wurden. Die für diesen Beitrag bereitgestellten Belege enthalten keine vollständigen Prüfprotokolle oder vergleichbaren Ergebnisse, anhand derer sich eine allgemeine Wirksamkeitsrate behaupten ließe.

Ein Guardrail kann daher Risiken innerhalb seines Abdeckungsbereichs verringern, aber nicht beweisen, dass das gesamte System sicher ist. Dafür müssen unter anderem das Modell, die Daten, die Tools, die Berechtigungen, die Aufsicht und die Einsatzumgebung berücksichtigt werden. Das ist eine Schlussfolgerung aus der klaren Begrenzung der Kontrolle: Einen Teil zu prüfen ist nicht dasselbe, wie sämtliche Teile zu verifizieren.

Praktische Kriterien, um ein Guardrail zu erkennen

Beginne bei der Prüfung einer Architektur mit dem kontrollierten Objekt: Eingabe, Ausgabe, Tool-Aufruf, Parameter, Daten oder Aktionsfolge. Bestimme anschließend, in welcher Phase die Kontrolle angewandt wird und welche Richtlinie aus einer Erkennung eine Entscheidung macht. Sind diese Elemente nicht dokumentiert, ist die Aussage „Wir haben Guardrails“ zu allgemein, um die Abdeckung beurteilen zu können.

Lege danach die Reaktion auf einen Verstoß und den Umgang mit Unsicherheit fest: Wird blockiert, verändert, eine Bestätigung angefordert oder an eine Person weitergeleitet? Prüfe auch, was geschieht, wenn die Kontrolle versagt oder nicht verfügbar ist. Bei folgenreichen Aktionen ist es besonders wichtig, die Entscheidung, einen Vorschlag zu generieren, von der tatsächlichen Berechtigung zur Ausführung zu trennen.

Frage schließlich, durch welche Tests die Beschreibung gestützt wird: Welche Fälle wurden in welchem Kontext und anhand welcher Kriterien geprüft, und wie wurden sowohl unberechtigte Blockierungen als auch übersehene Verstöße untersucht? Die Dokumentation einer Bibliothek, einer API oder einer Forschungsarbeit kann helfen, eine konkrete Implementierung zu verstehen. Sie ersetzt aber nicht die Evaluation des Systems, in dem diese eingesetzt wird. Die verfügbaren Belege ermöglichen es, den Begriff und einige Implementierungsformen zu beschreiben; sie begründen weder eine Sicherheitsgarantie noch einen Wirksamkeitsvergleich.

Verwandte Begriffe