KI-Sicherheit mit Guardrails: Welche Kontrollen wirklich zählen

Für die KI-Sicherheit lassen sich Guardrails an 5 Stellen einordnen: bei eingehenden Anfragen, abgerufenen Inhalten, Modellvorschlägen, Tool-Aktionen und ausgehenden Antworten. Ein Inhaltsfilter kann eine unzulässige Antwort abfangen. Ob ein Kunde einen Datensatz sehen darf oder eine Erstattung freigeben kann, muss weiterhin die Anwendung entscheiden. Kleine Teams sollten zuerst diese Berechtigungen klären, bevor sie weitere Klassifikatoren ergänzen.

KI-Sicherheit: Was leisten Guardrails?

Guardrails sorgen dafür, dass eine schriftliche Richtlinie tatsächlich bestimmt, was eine KI-Anwendung entgegennehmen, offenlegen oder ausführen darf. Ein großes Sprachmodell, kurz LLM, erzeugt Antworten und schlägt Aktionen vor. Guardrails prüfen die Ein- und Ausgaben oder setzen der umgebenden Software Grenzen.

Ein Museum veranschaulicht das Prinzip: Am Eingang werden Eintrittskarten kontrolliert, für einzelne Räume gelten Zugangsregeln, und ein Restaurator benötigt eine Erlaubnis, um ein Exponat zu bewegen. Eine gültige Eintrittskarte berechtigt nicht zu jeder Handlung im Gebäude. Genauso wenig belegt eine unbedenkliche Kundennachricht, wem eine Bestellung gehört.

Drei Elemente machen einen Guardrail wirksam: eine Regel, eine Prüfung und eine Konsequenz. „Keine Kundendaten offenlegen“ ist eine Regel. Den Eigentümer des angefragten Datensatzes mit dem authentifizierten Kunden abzugleichen, ist die Prüfung. Den Datenbankzugriff zu verweigern, ist die Konsequenz. Ein Protokolleintrag ohne Durchsetzung hält den Fehler lediglich fest, nachdem er passiert ist.

Manche Prüfungen sind deterministisch: Bei gleicher Regel und gleichen Eingaben liefern sie dieselbe Entscheidung. Dazu zählen etwa die Prüfung erlaubter Tool-Namen und erforderlicher Felder. Andere verwenden Klassifikatoren, also Modelle, die einschätzen, ob ein Inhalt gegen eine Richtlinie verstößt. Themenerkennung und die Einstufung schädlicher Inhalte gehören dazu. Eine menschliche Freigabe ergänzt diese Kontrollen um eine Beurteilung, bevor eine grundsätzlich zulässige, aber folgenreiche Aktion ausgeführt wird.

KI-Guardrails bezeichnet diese breite Gruppe von Schutzmechanismen. Guardrails AI ist dagegen ein bestimmtes Framework innerhalb dieser Kategorie. Wer Kategorie und Produkt verwechselt, lässt womöglich wichtige Kontrollstellen ohne klare Zuständigkeit.

KI-Guardrails am Beispiel: Eine Erstattung von der Anfrage bis zur Antwort

Eine Erstattungsanfrage benötigt zu verschiedenen Zeitpunkten unterschiedliche Prüfungen, selbst wenn sie ganz alltäglich formuliert ist. Als hypothetisches Beispiel dient diese Kundennachricht: „Bitte erstatten Sie meine letzte Bestellung und schicken Sie die Bestätigung an meine neue E-Mail-Adresse.“ Angenommen, die Richtlinie verlangt vor jeder Erstattung eine Freigabe und erlaubt Bestätigungen nur an eine verifizierte Adresse im Kundenkonto.

Die Anfrage durchläuft folgenden Weg: Eingabeprüfungen → eingegrenzter Kontext → Modellvorschlag → autorisierte, freigegebene Aktion → Ausgabeprüfungen. Bei jedem späteren Tool-Aufruf werden die jeweils relevanten Prüfungen erneut durchgeführt.

Vor dem Modell: Identität prüfen, Inhalte filtern, Daten begrenzen

Die Identität des Kunden muss aus der authentifizierten Sitzung stammen, nicht aus einem Namen oder einer Kontokennung, die im Chat eingegeben wurde. Größen- und Ratenlimits für Anfragen sollten bereits vor rechenintensiven Verarbeitungsschritten greifen.

Anschließend wird die Nachricht auf verbotene Inhalte, fachfremde Themen und unnötige sensible Daten geprüft. Ein Themenfilter kann einen Supportassistenten davon abhalten, Ratschläge außerhalb seines Aufgabenbereichs zu geben. Ein Filter für personenbezogene Daten kann eine eingefügte Telefonnummer entfernen, wenn sie für die Aufgabe nicht gebraucht wird. PII steht für „personally identifiable information“, also personenbezogene Informationen wie eine E-Mail-Adresse oder Telefonnummer.

Informationen, die der Ablauf tatsächlich benötigt, dürfen nicht ersatzlos entfernt werden. Verifizierte Kontodaten bleiben in der Anwendung; das Modell erhält nur den nötigen Kontext. Auch das Maskieren von Text vor einem Modellaufruf entfernt keine Kopien, die bereits in Anfrageprotokollen gespeichert wurden. Datenminimierung muss deshalb schon bei der Erfassung und Protokollierung ansetzen.

Vor dem Datenabruf: Den Zugriff auf zulässige Datensätze begrenzen

Die Bestellung wird mit einer Abfrage abgerufen, die auf das Konto des Kunden beschränkt ist. Diese Einschränkung muss greifen, bevor private Inhalte das Modell erreichen. Als primäre Trennung zwischen den Datensätzen verschiedener Kunden kommt ein Ausgabefilter zu spät.

Abgerufene Dokumente, Webseiten und Tool-Ergebnisse sind zusätzliche Eingaben. Ein Hilfeartikel kann eine Anweisung enthalten, die versucht, die Regeln der Anwendung außer Kraft zu setzen. Dieser Angriff heißt indirekte Prompt Injection. Abgerufene Texte sind zu prüfendes Material, keine Erlaubnis, den Ablauf zu ändern.

Das Modell benötigt möglicherweise die Rückgaberichtlinie und die Information, ob die Bestellung dafür infrage kommt. Die Transaktionen aller Kunden braucht es nicht. Deshalb gilt: den Datenabruf eingrenzen, unnötige Felder weglassen und das ausgewählte Material auf relevante Inhaltsrisiken prüfen.

Beim Modell: Den Vorschlag klar begrenzen

Das Modell sollte einen strukturierten Vorschlag mit bekannten Feldern liefern, etwa für die gewünschte Aktion und die Bestellkennung. Bevor der Vorschlag ausgewertet wird, muss seine Struktur validiert werden.

JSON, das einem Schema entspricht, belegt lediglich eine zulässige Datenstruktur. Auch eine erfundene Bestellkennung kann eine gültige Zeichenfolge sein. Das Modell darf weder die Kundenidentität noch die Erstattungsberechtigung oder seinen eigenen Freigabestatus dadurch festlegen, dass es ein Feld ausfüllt.

In diesem Beispiel kann das Modell eine Erstattung vorschlagen und den Wunsch nach einer Adressänderung erkennen. Ob eine der beiden Aktionen zulässig ist, entscheidet die Anwendung.

Vor der Tool-Ausführung: Berechtigung und Freigabe prüfen

Ein Tool ist eine Anwendungsfunktion, deren Aufruf das Modell anfordern kann. Bevor eine Erstattungsfunktion ausgeführt wird, sind ihr Name, ihre Argumente, die Zuordnung der Bestellung zum Kunden, der aktuelle Bestellstatus und die fachlichen Voraussetzungen zu prüfen. Unerwartete Felder werden abgewiesen. Dieselben Prüfungen müssen auch in dem Dienst greifen, der die Aktion tatsächlich ausführt.

Die menschliche Freigabe gehört hinter den konkreten Vorschlag und vor die tatsächliche Zustandsänderung. Die prüfende Person muss Bestellung, geplante Erstattung, Ziel und Begründung sehen. Die Freigabe gilt genau für diese Aktion. Ändern sich die Argumente, berechtigt die bisherige Freigabe nicht mehr zur Ausführung.

Die neue E-Mail-Adresse ist eine eigenständige Berechtigungsfrage. In diesem Beispiel führt die Anwendung den Kunden durch die Kontoverifizierung und verwendet bis zu deren Abschluss die bereits verifizierte Adresse. Ein Inhaltsfilter kann nicht feststellen, wem ein E-Mail-Konto gehört.

Vor der Ausgabe: Ergebnisse und offengelegte Informationen prüfen

Tool-Ergebnisse müssen geprüft werden, bevor sie wieder in den Modellkontext gelangen. Dazu gehören die Begrenzung der zurückgegebenen Felder, die Validierung ihrer Struktur und ein ausdrücklich geregelter Umgang mit fehlgeschlagenen oder unklaren Vorgängen.

Danach wird die Antwort an den Kunden auf verbotene Inhalte, sensible Informationen, unbelegte Aussagen und die vorgeschriebene Antwortstruktur geprüft. „Ihre Erstattung ist abgeschlossen“ darf nur auf einem bestätigten Tool-Ergebnis beruhen. Steht die Freigabe noch aus, muss die Antwort das auch sagen.

Ein- und Ausgabeprüfungen können ähnliche Klassifikatoren verwenden, erfüllen aber unterschiedliche Aufgaben: Die erste entscheidet, was verarbeitet wird, die letzte, was den Kunden erreicht. Keine von beiden kann eine bereits ausgeführte unbefugte Aktion rückgängig machen.

Guardrail-Tools im Vergleich: Was die Dokumentation abdeckt

Entscheidend bei der Tool-Auswahl sind die Kontrollstelle, die sich damit absichern lässt, und die Regeln, die das Team dauerhaft pflegen kann. Die folgende Übersicht wurde am 17. Oktober 2026 anhand der aktuellen Anbieterdokumentation geprüft. Sie vergleicht den dokumentierten Funktionsumfang, keine gemessene Erkennungsgenauigkeit.

Die Quellen und Grenzen der einzelnen Implementierungen folgen unten. Die Spalte „Was in eigener Verantwortung bleibt“ beschreibt die architektonische Konsequenz des dokumentierten Umfangs. Sie behauptet nicht, dass ein Framework eigene Kontrollen verhindern würde.

Was ist Guardrails AI?

Guardrails AI ist ein Python-Framework, das Validatoren für Modelleingaben und -ausgaben kombiniert und strukturierte Daten erzeugt. Die Einführung beschreibt das Framework und seine Sammlung von Validatoren.

Ein Validator prüft einen Wert anhand eines Kriteriums und meldet, ob die Prüfung bestanden wurde. Die konfigurierte on_fail-Richtlinie legt die Fehlerbehandlung fest. Die Dokumentation enthält Beispiele für toxische Sprache und PII; eigene Validatoren sind ebenfalls möglich. Grundlagen der Validatoren.

Das Framework passt, wenn sich explizite Validierungsregeln in eine bestehende Python-Anwendung einfügen sollen. Die Grenze liegt in der Abdeckung: Die bloße Einbindung legt noch nicht fest, welche Prüfungen auf jedem Pfad laufen oder was ein fehlgeschlagener Check verhindert. Diese Entscheidungen müssen zusammen mit der Anwendung implementiert und getestet werden.

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrails bietet programmierbare Kontrollen in mehreren Phasen einer LLM-Interaktion. Zu den dokumentierten Rail-Typen gehören Input-, Retrieval-, Dialog-, Execution- und Output-Rails.

Input-Rails können Inhaltssicherheit, Jailbreaks, Themen und PII abdecken. Retrieval-Rails prüfen den Kontext, Dialog-Rails begrenzen den Gesprächsverlauf. Execution-Rails können Tool-Eingaben und -Ergebnisse validieren; Output-Rails können Antworten filtern, bearbeiten oder blockieren.

Das Framework eignet sich, wenn der Interaktionsablauf gezielt gesteuert werden soll. Die Grenze liegt in der Umsetzung der Richtlinien: Execution-Rails bieten einen Ansatzpunkt für Aktionsprüfungen. Die Zuordnung zum Kunden und die Geschäftsregeln muss jedoch der eigene Code liefern. Diese Berechtigungen müssen zusätzlich im zugrunde liegenden Dienst durchgesetzt werden.

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails bietet konfigurierbare Inhaltsfilter, gesperrte Themen, Wortfilter, Filter für sensible Informationen, kontextbezogene Quellenprüfungen und Automated Reasoning-Prüfungen. Die Filter für sensible Informationen können unterstützte PII und benutzerdefinierte Muster blockieren oder maskieren. Automated Reasoning-Prüfungen gleichen Antworten mit logischen Regeln ab. Überblick über die Schutzmechanismen.

Die ApplyGuardrail API prüft Text unabhängig vom Aufruf eines Foundation-Modells. Sie lässt sich vor dem Datenabruf oder vor der Auslieferung einer Antwort einsetzen.

Das passt zu Anwendungen, die verwaltete Richtlinienprüfungen benötigen. Die Grenze liegt in der Annahme, jede Prüfung erfasse jeden Inhalt: Die Funktionen haben jeweils einen bestimmten Geltungsbereich; laut Übersicht sind Reasoning-Inhaltsblöcke ausgenommen. Auch eine bestandene Inhaltsprüfung berechtigt noch nicht zur Erstattung.

Welche Sicherheitskontrollen bieten die Modellanbieter?

OpenAI moderation klassifiziert schädliche Inhalte in unterstützten Text- und Bildeingaben und liefert Kennzeichnungen, Kategorien und Bewertungswerte zurück. Die Moderationsdokumentation weist auch darauf hin, dass eine Ablehnung, die schädliche Inhalte thematisiert, eine Kennzeichnung auslösen kann.

Diese Ergebnisse dienen als Signale für Richtlinienentscheidungen. Ein Supportgespräch, in dem eine beleidigende Nachricht zitiert wird, kann eine andere Behandlung erfordern als die Aufforderung, eine solche Nachricht zu erzeugen. Moderation hilft bei Entscheidungen über Inhalte, liefert aber keine Zugriffsregeln für Bestellungen.

Google Gemini stellt Sicherheitseinstellungen bereit, die Schadenskategorien mit Sperrschwellen verbinden. Der aktuelle Leitfaden zu den Sicherheitseinstellungen behandelt unter anderem Belästigung, Hassrede, sexuelle Inhalte, gefährliche Inhalte und Jailbreaks.

Google unterscheidet zwischen der Wahrscheinlichkeit unsicherer Inhalte und der Schwere eines möglichen Schadens. Daraus ergibt sich eine praktische Grenze: Ein niedriger Klassifikatorwert belegt nicht, dass eine Aktion nur geringe Folgen hätte. Die Kontrollen der Anbieter sind nützliche Bausteine. Berechtigungen, einen begrenzten Datenzugriff und Fehlerbehandlung braucht die Anwendung weiterhin.

Guardrails für KI-Agenten: Was die Architektur leisten muss

Ein Agent braucht eine wirksam durchgesetzte Grenze zwischen dem Vorschlag einer Aktion und ihrer Ausführung. Ob diese Grenze über Framework-Hooks oder gewöhnlichen Dienstcode umgesetzt wird: Sie muss auf einer vertrauenswürdigen Identität und dem aktuellen Anwendungszustand beruhen.

Eine explizite Liste legt die erlaubten Tools fest. Bei jedem Aufruf werden zusätzlich die Argumente und die Zielressource geprüft. Nur weil „Erstatten“ erlaubt ist, kommt nicht jede Bestellung für eine Erstattung infrage. Eine universell einsetzbare Shell oder ein uneingeschränktes Netzwerk-Tool erweitert den möglichen Aktionsradius zudem weit über eine eng begrenzte Geschäftsfunktion hinaus.

Eine Freigabe muss als überprüfbarer, verbindlicher Datensatz vorliegen, nicht bloß als „Ja“ im Gespräch. Zu speichern ist, was von wem und für welche konkreten Aktionsdetails freigegeben wurde. Vor der Ausführung muss der Zustand erneut geprüft werden: Während die prüfende Person entscheidet, könnte eine Bestellung bereits erstattet worden sein.

Der ausführende Dienst sollte einen Idempotenzschlüssel durchsetzen. Diese stabile Vorgangskennung sorgt dafür, dass Wiederholungen das bestehende Ergebnis zurückgeben, statt eine weitere Erstattung auszulösen. Zugangsdaten sollten nur eng begrenzte Rechte gewähren; das Modell darf den Prüf- und Durchsetzungspfad nicht kontrollieren. Der Agent darf keinen zweiten Endpunkt wählen können, der die Prüfung umgeht.

Unser Praxisleitfaden zu Guardrails und Schadensbegrenzung für KI-Agenten im Produktivbetrieb vertieft die umgebende Architektur. Für diese Anfrage ist die entscheidende Frage einfach: Welcher Dienst verweigert die Ausführung, wenn das Modell die falsche Aktion vorschlägt?

Welche Grenzen vor dem Produktivstart geklärt sein müssen

Funktionsnamen klingen oft umfassender, als es ihre Einsatzbedingungen erlauben. Deshalb muss klar sein, welchen Geltungsbereich genau die Prüfung hat, die zum Einsatz kommen soll.

AWS dokumentiert kontextbezogene Quellenprüfungen beispielsweise für Zusammenfassungen, Umformulierungen und die Beantwortung von Fragen mit einer Referenzquelle und einer Anfrage. Dialogbasierte Frage-Antwort-Szenarien und Chatbots sind dabei ausdrücklich ausgenommen. Die dokumentierten Höchstwerte betragen 100.000 Zeichen für die Quelle, 1.000 für die Anfrage und 5.000 für die Antwort. Das sind Zeichengrenzen dieser Funktion, keine allgemeinen Kontextgrenzen des Modells. Sie bedeuten auch nicht, dass andere Bedrock-Schutzmechanismen nicht mit Chatbots verwendet werden dürfen. Dokumentation zu kontextbezogenen Quellenprüfungen.

Eine Quellenprüfung untersucht, ob eine Antwort auf der bereitgestellten Quelle beruht. Ist schon die Quelle veraltet oder falsch, belegt die Übereinstimmung keine sachliche Richtigkeit. Im Erstattungsbeispiel muss der aktuelle Bestellstatus aus dem maßgeblichen Dienst kommen.

Streaming verändert den Zeitpunkt der Durchsetzung. AWS weist darauf hin, dass die Relevanzentscheidung einer kontextbezogenen Quellenprüfung erst eintreffen kann, nachdem eine Antwort bereits gestreamt wurde. Allgemein gilt: Verlangt eine Richtlinie die Prüfung der vollständigen Antwort vor ihrer Offenlegung, muss diese bis zum Bestehen der Prüfung gepuffert werden. Bereits angezeigter Text lässt sich durch eine spätere Ablehnung nicht zurückholen.

Für Zeitüberschreitungen braucht es ein festgelegtes Verhalten. Scheitert eine erforderliche Berechtigungs- oder Freigabeprüfung, muss die Zustandsänderung gestoppt werden. Als Ausweg dienen ein ausstehender Status oder die Übergabe an den menschlichen Support. Für risikoärmere Antworten ist ausdrücklich festzulegen, welche eingeschränkte Ersatzlösung zulässig ist. Eine ausgefallene Prüfkomponente darf nicht stillschweigend zur Erlaubnis werden, fortzufahren.

Zusätzliche Latenz und fälschlich blockierte Anfragen müssen anhand der eigenen Arbeitslast gemessen werden. Kein Anbieterwert ersetzt die Erkenntnis, ob berechtigte Kunden die konkrete Supportaufgabe tatsächlich abschließen können.

Mit diesen Kontrollen kann ein kleines Team beginnen

Am Anfang stehen sechs Kontrollen, die sich erklären, praktisch prüfen und einer verantwortlichen Person zuordnen lassen. Dafür muss nicht jedes Framework aus der Tabelle eingeführt werden.

1. 1

   Identität und Datenzugriff

   Beim Datenabruf und bei Tools wird der authentifizierte Kundenkontext verwendet. Tests müssen belegen, dass ein Kunde keine Bestellung eines anderen Kunden lesen kann, auch wenn das Modell dies anfordert.

2. 2

   Eingaberichtlinien und Datenminimierung

   Die unterstützte Aufgabe wird klar definiert, relevante Inhaltsrisiken werden geprüft und unnötige sensible Felder entfernt. Für Anfragen außerhalb des Aufgabenbereichs wird eine sichere Antwort festgelegt.

3. 3

   Verbindliche Vorgaben für die Ausgabe

   Pflichtfelder, Offenlegungsregeln und Aussagen über abgeschlossene Aktionen werden validiert. Fehlt der Antwort eine verlässliche Grundlage, muss sie Unsicherheit benennen oder an den Support verweisen.

4. 4

   Begrenzte Aktionen und Freigaben

   Bereitgestellt werden eng zugeschnittene Tools für Geschäftsvorgänge. Vor der Ausführung werden Identität, Argumente und aktueller Zustand geprüft. Aktionen, die laut Richtlinie als folgenreich gelten, benötigen eine Freigabe.

5. 5

   Fehlerverhalten und Betriebsgrenzen

   Für Anfragen, Tool-Aufrufe, Wiederholungen und Ausführungszeiten werden zum Ablauf passende Grenzen gesetzt. Es wird festgelegt, was beim Ausfall einer erforderlichen Prüfung oder eines nachgelagerten Dienstes geschieht. Überarbeitete Vorschläge und Wiederholungsversuche werden erneut validiert.

6. 6

   Regressionstests und nachvollziehbare Protokolle

   Regelversionen, Entscheidungen, Tool-Ergebnisse und Freigabereferenzen werden protokolliert, ohne unnötige sensible Daten zu kopieren. Bekannte unbefugte Offenlegungen und Aktionen müssen eine Veröffentlichung blockieren.

Entwicklungsteams sollten jetzt handeln, wenn eine Kundenfunktion private Datensätze liest oder Zustände verändern kann. Zuerst müssen die Berechtigungen in den Diensten umgesetzt werden. Betriebsteams brauchen klare Zuständigkeiten für Eskalationen, zu Unrecht blockierte Anfragen und nicht verfügbare Prüfungen. Eine Warteschlange ohne verantwortliche Person ist ein unvollständiger Arbeitsablauf.

Mit dem Kauf eines weiteren Guardrail-Produkts sollte gewartet werden, bis die fehlende Kontrollstelle benannt ist. Ein Assistent für öffentliche Dokumente ohne schreibende Tools braucht keinen Freigabeablauf für Erstattungen. Relevante Inhaltsprüfungen, einen vertrauenswürdigen Datenabruf und ein klares Ersatzverfahren benötigt er trotzdem. Zusätzliche Aktionskontrollen werden nötig, sobald seine Fähigkeiten erweitert werden.

Die Anwendung mit Promptfoo testen

Promptfoo ist ein Tool für Evaluation und Red Teaming. Es hilft dabei, normales Verhalten und gezielt angreifende Anfragen zu testen. Die Dokumentation zu Agententests beschreibt Prüfungen von Rollenbeschränkungen sowie unbefugten Objekt- und Funktionszugriffen.

Tests sollten an der Schnittstelle zur Anwendung ansetzen und repräsentative Identitäten sowie vorbereitete Testdaten verwenden. Wer nur das Modell testet, lässt die Zugriffsberechtigungen beim Datenabruf, den Freigabeablauf und die Tool-Dienste aus, mit denen Kunden tatsächlich interagieren.

Für den hypothetischen Erstattungsablauf eignen sich zunächst diese Fälle:

• Eine erstattungsfähige Bestellung: Der Vorschlag erreicht die Freigabeprüfung; die Ausführung wartet auf die Freigabe.
• Die Bestellung eines anderen Kunden: Sowohl beim Datenabruf als auch bei der Ausführung wird der Zugriff verweigert.
• Eine geänderte Bestätigungsadresse: Die Anwendung verlangt das separate Verifizierungsverfahren.
• Versteckte Anweisungen in abgerufenen Inhalten: Sie können weder Berechtigungen erteilen noch die Freigaberichtlinie ändern.
• Ein nach der Freigabe geänderter Vorschlag: Die bisherige Freigabe berechtigt nicht zur Ausführung mit den neuen Argumenten.
• Der Ausfall einer Prüfkomponente oder eine wiederholte Anfrage: Erforderliche Prüfungen werden nicht umgangen, und derselbe Vorgang wird nicht doppelt ausgeführt.

Dies sind vorgeschlagene Testfälle, keine berichteten Testergebnisse. Neben der abschließenden Antwort müssen auch die tatsächlichen Auswirkungen und der gespeicherte Zustand untersucht werden. „Das kann ich nicht tun“ ist keine Entwarnung, wenn das Tool es bereits getan hat.

Der Schnellstart von Promptfoo führt durch die Konfiguration des Testziels, Angriffskategorien, Testausführung und Berichtsauswertung. Unser Promptfoo-Testbericht behandelt den Evaluationsablauf ausführlicher. Normale Kundenanfragen sollten neben Angriffsfällen im Testbestand bleiben, damit strengere Filter nicht unbemerkt die eigentliche Aufgabe beeinträchtigen.

Welche Erwartungen an Guardrails sind überzogen?

Ein Guardrail-Produkt ist kein universeller Sicherheitsschalter. Sein Nutzen hängt davon ab, was es prüft, wo es eingesetzt wird und was seine Entscheidung verhindert.

Ein längerer System-Prompt kann eine Richtlinie formulieren, aber keine Datenbankberechtigungen durchsetzen. Ein zweites Modell kann eine Antwort kritisch prüfen; die Übereinstimmung zweier Modelle beweist jedoch nicht deren Richtigkeit. Mehr Klassifikatoren können außerdem die Zahl fälschlicher Blockierungen und den Betriebsaufwand erhöhen, ohne die fehlende Kontrolle vor einer Aktion zu ergänzen.

Der beste Ausgangspunkt ist eine kleine Zahl expliziter Kontrollen für konkrete Fehlerfälle. Eine zusätzliche Prüfung sollte eine nachgewiesene Lücke schließen. Ob sie das Ergebnis verbessert, muss gemessen werden.

KI ohne Guardrails: Welche Kontrollen fehlen tatsächlich?

Bei einer Kundenfunktion ist entscheidend, welche Kontrollen fehlen. Eine Anwendung kann die Inhaltsfilter des Anbieters nutzen und trotzdem keine kundenspezifischen Berechtigungen, Ausgabevalidierung oder verbindliche Freigabeprüfung haben. Das Etikett „abgesichert“ verdeckt diese Lücken.

Umgekehrt kann eine Anwendung mit deterministischen Zugriffskontrollen weiterhin Inhaltsprüfungen benötigen. Unbedenkliche Inhalte und autorisiertes Verhalten sind eigenständige Anforderungen. Kein Etikett beantwortet beide Fragen.

Häufige Fragen

Welche Arten von KI-Guardrails gibt es?

Für die Implementierung lassen sich Eingabeprüfungen, Prüfungen abgerufener Kontexte, Ausgabeprüfungen, Kontrollen der Tool-Ausführung und menschliche Freigaben unterscheiden. Themen- und PII-Filter können an mehreren dieser Stellen greifen.

Wie lassen sich KI-Guardrails umsetzen?

Zuerst wird ein Ergebnis benannt, das nicht eintreten darf. Vor der betreffenden Offenlegung oder Aktion wird eine Prüfung eingebaut, das Verhalten bei einem Fehlschlag festgelegt und die vollständige Anwendung getestet. Eine Person übernimmt die Pflege der Richtlinie und die Bearbeitung von Eskalationen.

Was macht Guardrails AI?

Guardrails AI kombiniert Validatoren zu Guards für Ein- und Ausgaben und unterstützt die Erzeugung strukturierter Daten. Welche Risiken geprüft und wie Fehler behandelt werden, bestimmen die Konfiguration und der Anwendungscode.

Gibt es KI ohne Guardrails?

Anwendungen unterscheiden sich in ihren Kontrollen. Vor dem Einsatz müssen die konkreten Kontrollstellen geprüft werden, statt sich auf ein Etikett zu verlassen: Der Inhaltsschutz eines Modells stellt weder die Kundenberechtigung noch eine menschliche Freigabe sicher.

Was sind die 3 wichtigsten Sicherheitsrisiken bei KI?

Für dieses Kundensupport-Beispiel bieten sich Prompt Injection, unbefugte Datenoffenlegung und unbefugte Aktionen als Ausgangspunkt an. Das ist eine praktische Priorisierung für diesen Ablauf, keine allgemeingültige Rangliste von KI-Risiken.

Der nächste konkrete Schritt

Eine reale Kundenanfrage wird vom Anmelden bis zur abschließenden Antwort nachgezeichnet. An jeder Kontrollstelle werden Regel, durchsetzende Komponente, Fehlerreaktion und verantwortliche Person festgehalten. Unbefugtes Lesen eines Datensatzes und eine Aktion ohne Freigabe müssen zu Tests werden, deren Fehlschlag eine Veröffentlichung blockiert, bevor die Berechtigungen des Agenten erweitert werden.

Praktische Leitfäden zur KI-Implementierung gibt es im Newsletter.