Guardrails für LLM-Anwendungen: Ein- und Ausgaben absichern

Guardrails für LLM-Anwendungen sind Schutzschichten rund um das Sprachmodell: Sie prüfen, was hineingeht, und kontrollieren, was herauskommt. Kein einzelner Mechanismus ist lückenlos, aber mehrere Schichten zusammen machen eine Anwendung deutlich robuster gegen Fehler, Missbrauch und peinliche Antworten.

Warum der Systemprompt allein nicht reicht

Anweisungen wie „Sprich nur über unsere Produkte“ helfen, sind aber keine Garantie. Nutzer können versuchen, sie mit geschickten Formulierungen auszuhebeln, und Modelle halten sich nicht in jedem Fall an jede Regel. Deshalb gehören wichtige Regeln zusätzlich in Code, der unabhängig vom Modell prüft.

Schicht 1: Eingaben prüfen

• Länge begrenzen: Sehr lange Eingaben kosten Geld und werden oft für Angriffe genutzt.
• Themenfilter: Ein kleines, günstiges Modell oder ein Klassifizierer entscheidet, ob die Anfrage zum Einsatzzweck passt.
• Prompt Injection erkennen: Auffällige Muster wie „Ignoriere alle vorherigen Anweisungen“ markieren. Der Prompt-Injection-Prüfer zeigt typische Muster.
• Personenbezogene Daten: wo nötig vor dem Senden maskieren.

Schicht 2: Kontext trennen

Inhalte aus Dokumenten, Webseiten oder E-Mails sollten im Prompt klar als Daten gekennzeichnet werden, etwa in eigenen Abschnitten mit XML-Tags. Dazu gehört die Anweisung, Befehle in diesen Abschnitten nicht zu befolgen. Das senkt das Risiko indirekter Prompt Injection, beseitigt es aber nicht. Hintergründe stehen unter Prompt Injection.

Schicht 3: Ausgaben prüfen

• Format validieren: JSON gegen ein Schema prüfen, bevor es weiterverarbeitet wird.
• Inhalt prüfen: verbotene Begriffe, interne Informationen, Links auf fremde Seiten, Preise oder Zusagen, die das Modell nicht machen darf.
• Belege prüfen: Bei RAG kontrollieren, ob zitierte Quellen tatsächlich in den Auszügen vorkommen.
• Moderation: Viele Anbieter bieten Moderationsschnittstellen oder eingebaute Sicherheitsfilter für schädliche Inhalte.

Schicht 4: Handlungen begrenzen

Besonders wichtig sind Guardrails, wenn das Modell Werkzeuge nutzt. Ein Agent, der E-Mails senden oder Daten ändern kann, braucht:

1. möglichst geringe Rechte für jedes Werkzeug
2. Bestätigung durch einen Menschen vor folgenreichen Aktionen
3. Obergrenzen für Schritte, Kosten und Anzahl der Aktionen
4. ein Protokoll aller Werkzeugaufrufe

Mehr dazu im Ratgeber KI-Agenten absichern.

Was tun, wenn ein Guardrail anschlägt?

Ein Beispiel: Ein Händler betreibt einen Produktberater. Eingangs prüft ein günstiges Modell, ob die Frage zum Sortiment gehört. Ausgangs prüft eine Regel, ob die Antwort Preise nennt, die nicht aus dem Produktkatalog stammen, und ob Rabattversprechen enthalten sind. Schlägt eine Regel an, wird die Antwort durch einen festen Text mit Verweis auf den Kundenservice ersetzt.

Eine blockierte Anfrage sollte nicht einfach mit einem Fehler enden. Besser ist eine freundliche, feste Antwort, etwa der Hinweis auf das Thema der Anwendung oder die Weiterleitung an einen Menschen. Protokollieren Sie jeden Treffer, um Fehlalarme zu erkennen und Regeln nachzuschärfen; siehe LLM-Observability.

Abwägung: Sicherheit gegen Nutzbarkeit

Zu strenge Filter blockieren harmlose Anfragen und frustrieren Nutzer. Jede zusätzliche Prüfung kostet außerdem Zeit und gegebenenfalls Tokens. Testen Sie Guardrails deshalb mit einem Datensatz aus erlaubten und unerwünschten Anfragen und messen Sie beide Fehlerarten, wie in LLM-Anwendungen testen beschrieben.