Guardrails für produktive AI-Agents: was nie beim Kunden ankommen darf

Ein AI-Agent, der im Testbetrieb überzeugt, ist noch lange nicht bereit für den Kunden. Im Demo-Modus sind Fehler eine Anekdote. In der Produktion sind sie eine falsche Auskunft an einen zahlenden Kunden, eine ungewollte Zusage oder eine Aktion im falschen Datensatz. Guardrails sind die technischen und organisatorischen Grenzen, die dafür sorgen, dass bestimmte Ausgaben und Aktionen das System gar nicht erst verlassen.

Der häufigste Denkfehler dabei: Guardrails werden als eine einzige Schutzschicht verstanden, die man dem Agenten am Ende überstülpt. In der Praxis zeigt sich, dass wirksamer Schutz aus mehreren Ebenen besteht, die jeweils eine bestimmte Klasse von Fehlverhalten adressieren. Wer die Klassen nicht kennt, baut den falschen Filter.

Kategorien von Fehlverhalten kennen statt pauschal absichern

Bevor ein Team Filter baut, sollte es benennen, wovor es sich schützt. Bewährt hat sich eine Einteilung in fünf Kategorien:

• Inhaltlich falsch: erfundene Fakten, falsche Zahlen, nicht existierende Produkte oder Regelungen.
• Unzulässig: Aussagen mit rechtlicher Wirkung, etwa verbindliche Zusagen, Preisnachlässe, Rechts- oder Gesundheitsauskünfte außerhalb des erlaubten Rahmens, Weitergabe personenbezogener Daten.
• Außerhalb des Auftrags: der Agent äußert sich zu Themen, für die er nicht gedacht ist, vom Wettbewerbervergleich bis zur politischen Einschätzung.
• Schädliche Aktionen: der falsche Werkzeugaufruf, also löschen statt lesen, an alle senden statt an einen, buchen statt reservieren.
• Ton und Marke: fachlich korrekt, aber im Stil unpassend, unhöflich oder nicht markenkonform.

Jede Kategorie verlangt einen anderen Mechanismus. Erfundene Fakten bekämpft man mit Quellenbindung und Prüfungen, schädliche Aktionen mit Berechtigungsgrenzen. Ein einziger Filter für alles existiert nicht.

Eingabe- und Ausgabe-Filter

Die erste Verteidigungslinie liegt vor dem Modell. Eingabe-Filter erkennen Anfragen, die der Agent gar nicht erst inhaltlich verarbeiten soll: offensichtliche Versuche, die Systemanweisung auszuhebeln, Themen außerhalb des Auftrags, oder Eingaben mit sensiblen Daten, die besonderen Regeln unterliegen. Solche Fälle werden abgewiesen oder auf einen definierten Pfad gelenkt, bevor das Modell antwortet.

Die zweite Linie liegt hinter dem Modell. Ausgabe-Filter prüfen jede Antwort, bevor sie den Kunden erreicht. Hier gilt eine klare Reihenfolge: deterministische Prüfungen zuerst, modellbasierte danach. Ob eine Antwort verbotene Begriffe, konkrete Preiszusagen, interne Bezeichnungen oder Kundendaten enthält, lässt sich mit gewöhnlichem Code prüfen, zuverlässig und in Millisekunden. Für weichere Kriterien wie Ton, Themenbezug oder implizite Zusagen hat sich ein zweites, kleines Modell als Prüfer bewährt. Entscheidend ist, dass diese Filter außerhalb des Agenten laufen: Eine Anweisung im Prompt, bestimmte Dinge nicht zu sagen, ist eine Bitte, kein Guardrail.

Berechtigungsgrenzen für Werkzeuge

Sobald ein Agent handeln kann, verschiebt sich das Risiko von der Aussage zur Aktion. Hier gilt dasselbe Prinzip wie bei jedem technischen System: so wenig Rechte wie möglich. Konkret bedeutet das:

• Der Agent erhält nur die Werkzeuge, die seine Aufgabe tatsächlich erfordert.
• Lesende und schreibende Zugriffe sind getrennte Werkzeuge mit getrennten Rechten.
• Zugangsdaten sind auf den Anwendungsfall beschränkt, nicht auf das ganze System.
• Harte Limits liegen im Werkzeug selbst: maximale Beträge, maximale Anzahl betroffener Datensätze, erlaubte Empfängerkreise.

Der wichtigste Punkt: Diese Grenzen werden serverseitig durchgesetzt, im Werkzeug oder in der Schicht davor. Was das Modell nicht aufrufen kann, kann es auch unter keiner noch so geschickten Eingabe tun. Für Aktionen mit Außenwirkung, etwa Versand, Buchung oder Löschung, kommt eine Freigabepflicht dazu: Der Agent schlägt vor, ein Mensch gibt frei.

Eskalation an Menschen als geplanter Pfad

Guardrails, die nur blockieren, erzeugen Sackgassen. Ein produktiver Agent braucht deshalb einen sauber gestalteten Eskalationspfad: Wenn eine Anfrage außerhalb des Auftrags liegt, die Unsicherheit hoch ist oder ein Filter anschlägt, übergibt das System an einen Menschen, und zwar mit vollständigem Kontext, also bisherigem Verlauf, erkanntem Anliegen und dem Grund der Eskalation. Eine Übergabe, bei der der Kunde alles wiederholen muss, ist keine Eskalation, sondern ein Abbruch mit Umweg.

Die Eskalationsrate ist zugleich eine wertvolle Betriebsmetrik. Steigt sie, hat sich entweder das Nutzerverhalten verschoben oder ein Filter greift zu breit. Sinkt sie gegen null, ist das selten ein Qualitätsbeweis, sondern häufiger ein Zeichen, dass Fälle durchrutschen, die eigentlich eskaliert gehören.

Die Grenzen von Guardrails

Zur Ehrlichkeit gehört: Guardrails senken Risiko, sie beseitigen es nicht. Modellbasierte Filter sind selbst fehlbar, und wer gezielt versucht, ein System zu überlisten, entwickelt seine Methoden weiter. Deterministische Prüfungen erfassen nur, was man vorhergesehen hat. Und kein Filter repariert einen Agenten, dessen Auftrag zu breit geschnitten ist. Ein System, das alles können soll, lässt sich nicht sinnvoll begrenzen.

Daraus folgt eine nüchterne Betriebshaltung: mehrere Schichten kombinieren, Vorfälle systematisch auswerten, Filter und Prüffälle laufend nachschärfen und für den Restfall einen Incident-Prozess haben. Guardrails sind kein Zustand, den man einmal herstellt, sondern eine Praxis, die man pflegt.

Fazit

Wer einen AI-Agent produktiv setzt, sollte die Frage, was nie beim Kunden ankommen darf, schriftlich beantworten können, und zwar pro Kategorie: falsche Inhalte, unzulässige Aussagen, themenfremde Antworten, schädliche Aktionen, unpassender Ton. Darauf bauen die Mechanismen auf, also Eingabe- und Ausgabe-Filter, serverseitige Berechtigungsgrenzen, Freigabepflicht für wirkende Aktionen und ein Eskalationspfad, der den Menschen mit Kontext übernimmt. Perfekt wird das nie. Aber es ist der Unterschied zwischen einem kontrollierten Restrisiko und einem Blindflug mit Kundenkontakt.