KI-Guardrails sind technische Kontrollen, die Eingaben, Ausgaben und Aktionen von LLM-Anwendungen und KI-Agenten gegen festgelegte Richtlinien prüfen. Sie erkennen Probleme wie Prompt Injection, preisgegebene personenbezogene Daten, toxische oder themenfremde Inhalte und unsichere Tool-Aufrufe und blockieren, schwärzen, korrigieren oder eskalieren die Anfrage.
Was sind KI-Guardrails?
KI-Guardrails sind die Kontrollen rund um ein großes Sprachmodell, die sein Verhalten in vertretbaren Grenzen halten. Ein Modell allein kann nicht garantieren, dass es manipulierte Anweisungen ablehnt, nie personenbezogene Daten preisgibt oder immer beim Thema bleibt. Guardrails ergänzen Prüfungen vor und nach dem Modellaufruf sowie rund um jede Aktion eines Agenten. So setzt die Anwendung Richtlinien auch dann durch, wenn das Modell es nicht tut.
Der Begriff umfasst ein breites Spektrum: einfache Regeln wie einen regulären Ausdruck für Kreditkartennummern, Klassifikationsmodelle für Toxizität, ein zweites LLM, das Antworten bewertet, Schema-Validierung für strukturierte Ausgaben und Berechtigungssysteme, die festlegen, welche Tools ein Agent nutzen darf.
Guardrails sind wichtiger geworden, seit LLM-Anwendungen nicht mehr nur Fragen beantworten, sondern handeln. Ein Chatbot mit falscher Antwort ist ein Qualitätsproblem; ein Agent, der auf Basis einer manipulierten Anweisung eine E-Mail versendet, einen Datensatz ändert oder Code ausführt, ist ein Sicherheitsvorfall. Je mehr Autonomie und Zugriff eine Anwendung hat, desto stärker müssen ihre Guardrails im Code statt im Prompt verankert und im Monitoring sichtbar sein.
Arten von KI-Guardrails
| Art | Prüft | Typische Reaktion |
|---|---|---|
| Eingabe-Guardrails | Nutzer-Prompts und abgerufene Inhalte auf Injection-Versuche, verbotene Themen, personenbezogene Daten | Blockieren, schwärzen, nachfragen |
| Ausgabe-Guardrails | Antworten auf Datenlecks, Toxizität, unbelegte Aussagen, Formatfehler | Schwärzen, neu generieren, sichere Standardantwort |
| Aktions-Guardrails | Tool-Aufrufe von Agenten gegen Allowlists, Berechtigungen und Limits | Ablehnen, menschliche Freigabe verlangen |
| Betriebliche Guardrails | Token-Budgets, Anfrageraten, Schleifenanzahl | Drosseln, Lauf abbrechen |
Ausgabeprüfungen auf Faktentreue hängen eng mit der Erkennung von Halluzinationen zusammen, Eingabeprüfungen sind die erste Verteidigungslinie gegen Prompt Injection.
So greifen Guardrails in einer Anfrage
- Die Anwendung erhält einen Prompt und führt Eingabeprüfungen aus. Ein Verstoß stoppt die Anfrage oder entfernt den problematischen Teil.
- Das Modell wird mit einem System-Prompt aufgerufen, der die Richtlinie ebenfalls nennt, sie aber nicht allein durchsetzen muss.
- Will das Modell ein Tool aufrufen, prüft ein Aktions-Guardrail Tool, Argumente und Berechtigungen.
- Die Antwort durchläuft Ausgabeprüfungen, bevor sie angezeigt oder gespeichert wird.
- Jede Entscheidung wird mit der ausgelösten Regel protokolliert, damit sie später nachvollziehbar ist.
Die Reihenfolge wirkt sich auf Kosten und Latenz aus. Günstige deterministische Prüfungen wie Mustererkennung und Schema-Validierung laufen zuerst, danach Klassifikationsmodelle und teure LLM-Bewerter nur dort, wo sie einen Mehrwert bringen. Manche Ausgabeprüfungen können parallel zur gestreamten Antwort laufen. Alles, was ein Datenleck verhindern soll, muss jedoch abgeschlossen sein, bevor der Text beim Nutzer ankommt.
Wichtig ist außerdem eine klare Reaktion pro Regel: Nicht jeder Verstoß muss zum Abbruch führen. Oft reicht es, eine Passage zu schwärzen, eine Rückfrage zu stellen oder die Anfrage zur Prüfung an einen Menschen weiterzugeben.
Beispiel: ein Support-Assistent
Eine illustrative Richtlinie für einen Kundensupport-Assistenten: Eingabeprüfungen markieren Anweisungen wie „ignoriere deine bisherigen Regeln“ in Nutzernachrichten und in abgerufenen Hilfeseiten. Ausgabeprüfungen maskieren IBANs und E-Mail-Adressen, die nicht zum Kunden gehören. Der Assistent darf get_order frei aufrufen, issue_refund erfordert dagegen ab einem beispielhaften Schwellenwert von 50 Euro die Freigabe durch eine Mitarbeiterin. Ein Token-Budget pro Konversation stoppt endlose Schleifen. Jede blockierte oder veränderte Antwort landet in einer Review-Queue.
Best Practices
- Mehrere Schichten kombinieren. Keine einzelne Prüfung ist zuverlässig; kombinieren Sie Regeln, Klassifikatoren und Berechtigungsgrenzen.
- Berechtigungen außerhalb des Modells durchsetzen. Ein Agent sollte nichts tun können, was seine Zugangsdaten nicht erlauben, egal was man ihm sagt.
- Falsch-Positive messen. Guardrails, die legitime Anfragen blockieren, schaden Nutzern; verfolgen Sie Blockierraten pro Regel und prüfen Sie Stichproben.
- Latenz im Blick behalten. Jede Prüfung, besonders ein LLM als Bewerter, verlängert die Antwortzeit.
- Guardrails mit Evals testen und mit Red-Team-Datensätzen vor jeder Prompt- oder Modelländerung prüfen.
KI-Guardrails im Betrieb überwachen
Guardrails nützen nur, wenn Sie wissen, wann und warum sie greifen. Erfassen Sie jede Prüfung als Span oder Event im Trace der Anfrage, mit Regelname, Ergebnis und Latenz. Aussagekräftige Signale sind die Verstoßrate pro Regel, Modell und Mandant, plötzliche Änderungen nach einem Release und der Anteil der Anfragen, die mit einer Ersatzantwort enden. Ein sprunghafter Anstieg erkannter Injection-Versuche kann etwa auf einen Angriff oder eine neue Dokumentquelle mit problematischen Inhalten hinweisen. Umgekehrt kann ein plötzlicher Rückgang auf null bedeuten, dass eine Prüfung nach einem Deployment gar nicht mehr ausgeführt wird.
Wie Obseria hilft
Die AI Observability von Obseria bewertet Antworten auf Halluzinationen, Toxizität, Datenlecks und Prompt Injection und leitet Verstöße in eine Review-Queue. Guardrail-Ergebnisse erscheinen im selben Trace wie LLM- und Tool-Aufrufe. Hintergründe finden Sie unter Was ist LLM Observability.
