# Guardrails im laufenden Betrieb > Schutzprüfungen mit messbarer Wirkung, begrenzter Latenz, kontrolliertem Fehlerverhalten und eigenem Überlastschutz betreiben. Track: [LLM Production Ops](https://physar.tech/learn/llm-production-ops) Kanonische Fassung: https://physar.tech/learn/llm-production-ops/guardrail-runtime-ops Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## Guardrails im laufenden Betrieb ### Der Betriebsblick auf Schutzprüfungen Ob eine Anwendung Eingaben und Ausgaben prüfen soll und welche Angriffe es gibt, ist eine Sicherheitsfrage — sie gehört in den Sicherheitsteil des `llmops`-Pfads. Dieses Modul nimmt an, dass die Prüfungen existieren, und stellt die Betriebsfragen: Wo sitzen sie im Pfad? Was kosten sie an Latenz und Geld? Was passiert, wenn sie ausfallen? Und wie oft liegen sie falsch? Der entscheidende Perspektivwechsel: Eine Guardrail ist im Betrieb eine **weitere Abhängigkeit im heißen Pfad** — mit eigener Verfügbarkeit, eigener Latenz und einer eigenen, messbaren Fehlerrate in beide Richtungen. > **Merksatz:** Jede Prüfung, die du in den Anfragepfad legst, ist ein Dienst, der ausfallen kann. Sie braucht Timeout, Fallback-Verhalten und Überwachung wie jeder andere. ### Platzierung: nicht alles muss synchron sein Die teuerste Platzierung ist die synchrone vor beziehungsweise nach jeder Anfrage. Sie ist nötig, wenn die Prüfung eine Auslieferung **verhindern** soll. Prüfungen, die nur der Beobachtung oder späteren Auswertung dienen, gehören dagegen asynchron neben den Pfad — dort kosten sie keine Nutzerlatenz. | | | | --- | --- | | Synchron vor dem Modellaufruf | Kann den Aufruf verhindern und spart im Trefferfall Kosten; erhöht die Vorlaufzeit aller Anfragen. | | Synchron nach der Generierung | Kann Auslieferung verhindern; kollidiert mit Streaming und verlängert die Gesamtdauer. | | Asynchron neben dem Pfad | Keine Nutzerlatenz, aber ohne Sperrwirkung — nur Erkennung und Reaktion im Nachgang. | > **Trade-off:** Eine blockierende Prüfung nach der Generierung ist der Hauptgrund, warum Streaming manchmal nicht möglich ist. Das ist eine bewusste Produktentscheidung, kein technisches Versehen. ### Fail-open oder fail-closed Wenn die Prüfung selbst nicht antwortet — Timeout, Ausfall, Überlast — muss vorher entschieden sein, was gilt. **Fail-closed** lehnt die Anfrage ab: Der Schutz bleibt, die Verfügbarkeit sinkt. **Fail-open** lässt durch: Der Dienst bleibt verfügbar, der Schutz entfällt genau dann, wenn niemand hinsieht. Prüfung antwortet nicht → **Vorher festgelegte Politik greift** → Ablehnen oder durchlassen und markieren → Ereignis in Telemetrie und Alarm → Nachträgliche Auswertung der durchgelassenen Anfragen Die Wahl folgt dem Schadensvergleich: Was ist schlimmer — eine abgelehnte legitime Anfrage oder eine ungeprüft ausgelieferte? Bei rechtlich oder sicherheitskritisch bindenden Prüfungen ist fail-closed die einzige verteidigbare Antwort; bei weichen Qualitätsfiltern kann fail-open richtig sein. In jedem Fall gilt: Der Ausfall muss **sichtbar** sein, und durchgelassene Anfragen müssen markiert und im Nachgang auswertbar bleiben. > **Merksatz:** Ein stilles fail-open ist der gefährlichste Zustand: Der Schutz ist weg, und die Statistik sieht besser aus als je zuvor. ### Schwellen und die zwei Fehlerarten Jede Prüfung mit einer Schwelle hat zwei Fehler: Sie blockiert Legitimes (Fehlalarm) oder lässt Problematisches durch (Übersehen). Beide lassen sich nicht gleichzeitig minimieren — die Schwelle verschiebt nur, welchen Fehler du häufiger machst. Betrieblich brauchst du deshalb beide Raten als laufende Kennzahlen, nicht nur eine Blockierquote. Die Blockierquote allein ist mehrdeutig: Ein Anstieg kann eine Angriffswelle oder ein Modell-Update bedeuten, das plötzlich anders formuliert. Ohne Stichprobenprüfung der Blockierungen kannst du die beiden Fälle nicht unterscheiden. > **Merksatz:** Eine Schwelle ohne gemessene Fehlalarmrate ist geraten. Und Fehlalarme sind teuer: Sie treffen legitime Nutzer und untergraben das Vertrauen in die Prüfung. ### Missbrauchswellen beantworten Wenn ein Angreifer systematisch probiert, ist die einzelne Anfrage oft unauffällig — das Muster liegt in der **Wiederholung**: viele Varianten desselben Versuchs aus derselben Quelle in kurzer Zeit. Die wirksamen Betriebsmittel sind deshalb nicht schärfere Inhaltsfilter, sondern Begrenzung und Erkennung auf Identitätsebene: Kontingente, Verlangsamung wiederholter Verstöße, Sperren. Wichtig ist die Trennung der Antwort: Eine Welle rechtfertigt eine schärfere Politik für die **auffällige Identität**, nicht eine global schärfere Schwelle für alle — sonst zahlt die gesamte Nutzerschaft mit Fehlalarmen für das Verhalten weniger. > **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Szenarien selbst — und siehst pro Option, **warum** sie trägt oder nicht. ### Praxisachse: GUARDRAIL-PLACEMENT ### Betriebsprobe: GUARDRAIL-PLACEMENT Ein Chat-Feature streamt Antworten. Es gibt zwei Prüfungen: eine, die verbotene Anfragen ablehnen **muss**, bevor überhaupt generiert wird, und eine zweite, die die Tonalität der Antwort für ein Qualitäts-Dashboard bewertet. Aktuell laufen beide synchron; die zweite blockiert die Auslieferung, bis die vollständige Antwort vorliegt — Streaming ist dadurch faktisch abgeschaltet. **Anforderungen** - Wie platzierst du die beiden Prüfungen? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Die ablehnende Prüfung synchron vor den Modellaufruf, die Tonalitätsbewertung asynchron neben den Pfad — dann kann gestreamt werden. Richtig. Nur eine Prüfung, die eine Auslieferung verhindern soll, muss im blockierenden Pfad liegen. Eine reine Beobachtungsmetrik gehört daneben, wo sie keine Nutzerlatenz kostet. - Plausibler Fehlweg: Beide Prüfungen synchron lassen, aber parallelisieren. Parallelität hilft der ersten Prüfung nicht — sie muss vor der Generierung fertig sein — und die zweite blockiert weiterhin die Auslieferung, weil sie die vollständige Antwort braucht. Streaming bliebe unmöglich. - Plausibler Fehlweg: Beide Prüfungen asynchron machen und bei einem Treffer die bereits gestreamte Antwort widerrufen. Ein Widerruf nach dem Lesen ist keine Sperre: Der Nutzer hat den Inhalt gesehen. Für eine Prüfung, die eine Auslieferung verhindern muss, ist das keine zulässige Platzierung. - Plausibler Fehlweg: Die Tonalitätsbewertung auf eine Stichprobe der Anfragen begrenzen, aber synchron lassen. Das senkt die Kosten, lässt aber einen Teil der Nutzer weiterhin ohne Streaming und mit voller Wartezeit — mit dem zusätzlichen Nachteil, dass dieselbe Funktion für verschiedene Nutzer unterschiedlich schnell wirkt. **Merksatz:** Die Platzierung folgt der Wirkung: Nur was eine Auslieferung verhindern soll, gehört in den blockierenden Pfad. Alles, was misst statt entscheidet, gehört daneben — sonst zahlen alle Nutzer Latenz für ein Dashboard. **+** Streaming wird wieder möglich, und die sperrende Prüfung behält ihre volle Wirkung. **−** Die asynchrone Bewertung liegt zeitversetzt vor und kann im Einzelfall nichts mehr verhindern; sie taugt für Trends und Nacharbeit, nicht für Sofortreaktion. ### Betriebsprobe: POLICY-ROLLOUT Eine strengere Guardrail-Version soll Missbrauch besser erkennen, könnte aber legitime Supportanfragen blockieren. **Anforderungen** - Ordne die Schritte vom Artefakt bis zur Freigabe. - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: 1. Policy, Schwellen und Abhängigkeiten als unveränderliche Version festhalten. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 2. Version gegen kuratierte positive und negative Fälle im Schatten auswerten. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 3. Kleine repräsentative Population mit klaren Stop-Grenzen exponieren. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 4. Schutz-, Fehlalarm-, Latenz- und Ausfall-SLIs mit der Kontrolle vergleichen. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 5. Nur bei bestandenem Gate stufenweise ausweiten, sonst auf die alte Version zurückschalten. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. **Merksatz:** Guardrail-Policies sind verhaltenswirksame Produktionsartefakte und benötigen denselben kontrollierten Releasepfad wie andere Konfiguration. **+** Fehlalarme und Schutzregressionen treffen zunächst nur eine begrenzte Population. **−** Parallele Auswertung und gelabelte Testfälle kosten Laufzeit und Pflege. ### Praxisachse: FILTER-THRESHOLD ### Betriebsprobe: FILTER-THRESHOLD Die Blockierquote eures Eingabefilters ist über Nacht von 0,8 % auf 3,1 % gestiegen. Zeitgleich wurde eine neue Produktoberfläche ausgerollt, die Nutzern längere Freitexteingaben erlaubt. Das Sicherheitsteam schlägt vor, die Schwelle vorsorglich weiter zu verschärfen. Support meldet erste Beschwerden über abgelehnte harmlose Anfragen. **Anforderungen** - Was tust du zuerst? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Eine Stichprobe der Blockierungen manuell klassifizieren, um Fehlalarme von echten Treffern zu trennen — erst dieses Verhältnis rechtfertigt eine Schwellenänderung in die eine oder andere Richtung. Richtig. Die Blockierquote allein ist mehrdeutig: Sie kann auf mehr Angriffe oder auf veränderte legitime Eingaben zurückgehen. Ohne die Aufteilung optimierst du eine Zahl, deren Bedeutung du nicht kennst. - Plausibler Fehlweg: Die Schwelle verschärfen, wie vorgeschlagen — bei einem Anstieg ist Vorsicht die sichere Richtung — ohne getrennte Fehler- oder Überlastbehandlung auf den gesamten Verkehr ausgerollt und unabhängig von Fehlalarmrate, Policy-Version und Serviceklasse als sicherer Default festgeschrieben. „Sicher“ ist hier nur eine Richtung des Fehlers. Wenn der Anstieg von legitimen längeren Eingaben stammt, vervielfacht die Verschärfung genau die Fehlalarme, über die der Support bereits berichtet. - Plausibler Fehlweg: Die Schwelle lockern, weil bereits Beschwerden über Fehlalarme vorliegen. Ebenso vorschnell, nur in die andere Richtung. Ein paar Beschwerden sind keine Fehlalarmrate — es könnten trotzdem überwiegend echte Treffer sein. - Plausibler Fehlweg: Die neue Oberfläche zurückrollen, da sie zeitlich mit dem Anstieg zusammenfällt. Zeitliche Nähe ist ein Hinweis, keine Ursache. Ein Rückbau einer Produktfunktion aufgrund einer noch uninterpretierten Metrik ist ein unverhältnismäßig teurer erster Schritt. **Merksatz:** Eine aggregierte Trefferquote ohne Aufteilung in richtige und falsche Treffer ist nicht interpretierbar. Bei jeder Schwellenentscheidung müssen beide Fehlerarten gemessen sein — sonst verschiebst du das Problem blind von der einen in die andere. **+** Die Schwellenentscheidung wird begründet statt geraten, und die Ursache des Anstiegs wird benannt. **−** Klassifizieren kostet Menschenzeit und verzögert die Reaktion um Stunden; in dieser Zeit läuft die aktuelle Schwelle unverändert weiter. ### Betriebsprobe: GUARDRAIL-TIMEOUT Der synchrone Eingabefilter hängt gelegentlich. Das Gateway besitzt ein Gesamtbudget von zwei Sekunden, die Schutzprüfung aber kein engeres Timeout. **Anforderungen** - Markiere die Konfigurationszeile, die eine unbegrenzte Teiloperation zulässt. - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Konfigurationsbefund. `timeout_ms: 0` lässt die Guardrail-Abhängigkeit ohne eigenes Endbudget laufen. Jede synchrone Teiloperation braucht ein begrenztes Budget innerhalb der äußeren Deadline; die Fail-Policy entscheidet danach über die Reaktion. **Merksatz:** Eine Schutzkomponente im heißen Pfad ist eine normale verteilte Abhängigkeit: Deadline, Kapazität, Fehlerzustand und Fallback müssen explizit sein. **+** Hängende Filter verbrauchen nicht unbegrenzt Request- und Worker-Kapazität. **−** Ein enges Timeout erhöht die Zahl der Fälle, in denen die gewählte Fail-Policy greift. ### Praxisachse: GUARDRAIL-SLI ### Betriebsprobe: GUARDRAIL-SLI Ein Eingabefilter blockiert seit einer Policy-Änderung deutlich mehr Requests. Das Dashboard zeigt nur die Gesamtzahl geblockter Anfragen; Support meldet zugleich mehr Beschwerden legitimer Nutzer. **Anforderungen** - Welche Instrumentierung macht die Änderung entscheidbar? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Plausibler Fehlweg: Nur die globale Blockzahl weiterführen und jeden Anstieg grundsätzlich als erfolgreich verhinderte Angriffe werten. Die Blockzahl trennt Angriffe nicht von Fehlalarmen. Mehr Blocks können eine schlechter kalibrierte Policy bedeuten. - Tragfähiger Ansatz: Entscheidung, Policy-Version, Regelklasse und kontrolliert erhobene Review-Labels korrelieren. Damit werden Blockrate und Fehlalarmrate pro Version prüfbar, ohne unbeschränkte Nutzerdaten als Metriklabel zu verwenden. - Plausibler Fehlweg: Vollständige Prompts als hochkardinale Metriklabels speichern und direkt nach einzelnen Nutzern gruppieren. Freitext und Nutzerkennungen erzeugen Kardinalität sowie Datenschutzrisiken. Solche Details gehören nicht in Metriklabels. - Plausibler Fehlweg: Den Filter aus dem Trace entfernen, damit Beschwerden und Blockentscheidungen nicht mehr zusammengeführt werden. Ohne Korrelation sinkt die Erklärbarkeit weiter. Das löst weder Kalibrierung noch Datenschutz durch ein bewusstes Datenschema. **Merksatz:** Ein Guardrail benötigt SLIs für Schutzwirkung, Fehlalarme, Latenz und Verfügbarkeit; die reine Blockmenge misst keine Qualität. **+** Policy-Versionen lassen sich anhand von Wirkung und Kollateralschaden vergleichen. **−** Verlässliche Fehlalarm-Labels erfordern Stichproben und menschliche Bewertung. ### Praxisachse: FAIL-OPEN-CLOSED ### Betriebsprobe: FAIL-OPEN-CLOSED Die verpflichtende Eingabeprüfung eines Kundenassistenten läuft in einem eigenen Dienst. Bei einer Überlastspitze antwortet sie 20 Minuten lang nicht. Der Aufrufer hat kein definiertes Verhalten für diesen Fall: Er behandelt die Zeitüberschreitung als „keine Beanstandung“ und liefert aus. Aufgefallen ist es erst bei einer späteren Auswertung — die Ablehnungsquote war in diesem Zeitraum auf null gefallen. **Anforderungen** - Welche Regelung führst du ein? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Das Ausfallverhalten ausdrücklich festlegen — bei einer verpflichtenden Prüfung fail-closed —, den Ausfall als eigenes Ereignis alarmieren und den Zustand in der Telemetrie sichtbar machen. Richtig. Eine Prüfung, deren Ergebnis bindend ist, darf ihren eigenen Ausfall nicht in ein stilles „unbedenklich“ übersetzen. Der Alarm auf den Ausfallzustand ist dabei genauso wichtig wie die Politik selbst. - Plausibler Fehlweg: Fail-open beibehalten, aber die durchgelassenen Anfragen markieren und im Nachgang prüfen. Für weiche Qualitätsfilter wäre das vertretbar. Bei einer verpflichtenden Prüfung ist nachträgliche Auswertung kein Ersatz: Der Inhalt ist bereits beim Kunden, und die Nacharbeit kann das nicht rückgängig machen. - Plausibler Fehlweg: Die Prüfung in den Anwendungsprozess einbetten, dann kann sie nicht separat ausfallen. Das verlagert das Ausfallrisiko, statt es zu behandeln: Eine eingebettete Prüfung kann ebenso überlasten oder fehlschlagen — dann fehlt weiterhin eine definierte Antwort auf diesen Fall. - Plausibler Fehlweg: Ein längeres Timeout setzen, damit die Prüfung auch unter Last noch antwortet. Bei 20 Minuten Ausfall hilft kein Timeout-Wert; er verwandelt den Fall nur in eine sehr lange Wartezeit. Und die Grundsatzfrage — was gilt, wenn keine Antwort kommt — bleibt unbeantwortet. **Merksatz:** Das Verhalten bei Ausfall einer Kontrolle ist selbst eine Kontrollentscheidung und muss vorher explizit getroffen werden. Ein nicht entschiedener Fall entscheidet sich im Zweifel zugunsten der Verfügbarkeit — also gegen den Schutz. **+** Der Schutz bleibt auch im Störfall wirksam, und der Ausfall wird sichtbar statt still. **−** Fail-closed macht die Prüfung zu einem gemeinsamen Ausfallpunkt: Ihre Verfügbarkeit begrenzt ab jetzt die Verfügbarkeit des gesamten Features und braucht entsprechende Betriebsansprüche. ### Praxisachse: ABUSE-SURGE ### Betriebsprobe: ABUSE-SURGE Innerhalb einer Stunde treffen tausende Anfragen ein, die systematisch Varianten desselben Umgehungsversuchs durchprobieren. Sie stammen aus einer Handvoll authentifizierter Konten. Jede einzelne Anfrage ist für sich unauffällig; das Muster ist die Wiederholung. Der Filter blockiert einen Teil, der Rest verbraucht Kapazität und Kosten. **Anforderungen** - Wie reagierst du im laufenden Betrieb? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Auf Identitätsebene reagieren: die auffälligen Konten drosseln, mit zunehmender Verzögerung bei wiederholten Verstößen belegen und bei Fortsetzung sperren — die globale Filterschwelle unverändert lassen. Richtig. Das Signal liegt im Verhalten einer bekannten Identität, nicht im Inhalt einer einzelnen Anfrage. Eine gezielte Reaktion trifft die Verursacher und lässt alle anderen Nutzer unberührt. - Plausibler Fehlweg: Die Filterschwelle global verschärfen, bis die Welle abklingt — ohne getrennte Fehler- oder Überlastbehandlung auf den gesamten Verkehr ausgerollt und unabhängig von Fehlalarmrate, Policy-Version und Serviceklasse als sicherer Default festgeschrieben. Damit zahlt die gesamte Nutzerschaft mit Fehlalarmen für das Verhalten weniger Konten — und der Angreifer probiert einfach weiter unterhalb der neuen Schwelle. - Plausibler Fehlweg: Die betroffene Funktion vorübergehend über den Kill-Switch abschalten. Angemessen, wenn tatsächlich Schaden entsteht oder die Filter versagen. Hier hält der Schutz im Kern; das Feature für alle abzuschalten ist eine deutliche Übersteuerung, solange eine gezielte Maßnahme möglich ist. - Plausibler Fehlweg: Die Anfragen unauffällig ins Leere laufen lassen, damit der Angreifer keine Rückmeldung über die Wirksamkeit bekommt. Verlockend, aber betrieblich schlecht: Ihr bezahlt die Anfragen weiterhin, das Verhalten wird nicht gebremst, und ihr verliert die klare Unterscheidung zwischen abgelehnt und fehlgeschlagen in der eigenen Telemetrie. **Merksatz:** Reagiere auf der Ebene, auf der das Signal liegt. Missbrauch zeigt sich als Muster über Anfragen einer Identität hinweg — dort ist die Gegenmaßnahme zielgenau, während inhaltliche Schwellen alle Nutzer treffen. **+** Zielgenaue Wirkung ohne Kollateralschaden bei legitimen Nutzern und sofortige Kostenbremse. **−** Es setzt belastbare Identitäten voraus; bei anonymem Zugang oder leicht erzeugbaren Konten verlagert sich der Missbrauch nur auf neue Identitäten und erzwingt zusätzliche Hürden bei der Registrierung. ## Quellen - OWASP LLM01 Prompt Injection — https://genai.owasp.org/llmrisk/llm01-prompt-injection/ - OWASP LLM10 Unbounded Consumption — https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ - NIST AI RMF Core — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ - Google SRE Book, Addressing Cascading Failures — https://sre.google/sre-book/addressing-cascading-failures/ - Google SRE Workbook, Managing Load — https://sre.google/workbook/managing-load/