Guardrails, Berechtigungen und Human-in-the-Loop

2024 wurde der Chatbot eines Autohändlers dazu überredet, einem Verkauf eines Trucks für einen Dollar zuzustimmen. Das sei „rechtlich bindend", scherzte der Kunde und machte einen Screenshot der Antwort. Der Bot hatte keine Bremsen. **ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → konnte alles sagen, und (in einer gefährlicheren Variante) hätte er alles *tun* kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.**

Stellen Sie sich nun denselben Agent vor, verbunden mit Ihrer E-Mail, Ihrem Kalender und der Firmenkreditkarte. Ein Agent, der in der realen Welt handeln kann, braucht Grenzen, die er nicht überschreiten kann. In dieser Lektion geht es um diese Grenzen: was erlaubt ist, wann ein Mensch gefragt werden muss und wie man den Schaden begrenzt.

Warum Agents Bremsen brauchen

Ein Chatbot redet nur. Ein Agent (eine KI, die mit Tools Aktionen ausführen kann, etwa eine E-Mail senden oder eine APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → aufrufen) tut tatsächlich Dinge. Das ist der ganze Sinn, und gleichzeitig das ganze Risiko.

Drei Fehlermodi treten ständig auf:

• Falsche Aktion. Der Agent erstattet 5.000 $ statt 50 $.
• Richtige Aktion, falscher Adressat. Er mailt den Entwurf an die gesamte Firma statt an eine Person.
• Runaway Loops. Er wiederholt eine fehlschlagende Aufgabe 400 Mal, und jeder Versuch kostet Geld.

GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen → sind der Weg, den Nutzen zu behalten und die Katastrophe zu entfernen. Es gibt drei zentrale Werkzeuge: Berechtigungen (was der Agent tun *darf*), Approvals (wann ein Mensch zuerst zustimmen muss) und Limits (harte Obergrenzen, die er nicht überschreiten kann).

Berechtigungen: die Tool-Allow-List

Das erste Guardrail ist die Entscheidung, welche Tools der Agent überhaupt anfassen darf. Das ist eine Tool-Allow-List: eine explizite Liste der ihm verfügbaren Aktionen. Was nicht auf der Liste steht, existiert für den Agent einfach nicht.

Denken Sie an den Keycard für einen neuen Praktikanten. Sie geben ihm nicht Zugang zu jedem Raum im Gebäude. Sie geben ihm die drei Türen, die er braucht.

Ein Support-Agent bekommt vielleicht:

• search_knowledge_base (nur lesend, sicher)
• create_draft_reply (erzeugt Text, sendet nichts)
• escalate_to_human (gibt ab)

Beachten Sie, was *nicht* dabei ist: kein send_email, kein issue_refund, kein delete_account. Der Agent kann Arbeit vorbereiten, aber alles Irreversible übernimmt eine Person oder ein strengeres System.

Eine nützliche Gewohnheit: sortieren Sie jedes Tool in read (sicher, Dinge nachschauen), write (verändert etwas, riskanter) und irreversibel (gibt Geld aus, sendet Nachrichten, löscht Daten). Read-Tools können meist frei laufen. Write- und irreversible Tools verdienen zusätzliche Prüfung.

Das Tool scopen, nicht nur benennen

Einem Agent ein send_email-Tool zu geben, ist noch keine ausreichende Kontrolle. *Scopen* Sie es. Beispiel: schränken Sie das Tool so ein, dass es nur an Adressen innerhalb Ihrer eigenen Firmendomain mailen kann, oder nur auf Threads antwortet, die der Nutzer gestartet hat. Das Tool selbst erzwingt die Regel, also kann der Agent sie nicht brechen, egal was er „entscheidet".

Human-in-the-Loop: der Approval-Schritt

Bei riskanten Aktionen ist die sicherste Bremse ein Mensch. Human-in-the-Loop (oft zu HITL verkürzt) bedeutet, dass der Agent vor einer sensiblen Aktion pausiert und wartet, bis eine Person zustimmt oder ablehnt.

Das Muster ist einfach:

1. Der Agent entscheidet, dass er eine Aktion ausführen will (diese Erstattung senden).
2. Statt sie auszuführen, *schlägt* der Agent sie vor und pausiert.
3. Ein Mensch sieht den Vorschlag und klickt zustimmen oder ablehnen.
4. Erst nach der Zustimmung läuft die Aktion.

Sie brauchen nicht für alles eine Zustimmung. Das würde den Agent so langsam machen wie die Arbeit selbst zu erledigen. Genehmigen Sie nur die Aktionen, die irreversibel oder teuer sind. Das Sichere lassen Sie laufen.

Hier eine herstellerneutrale Skizze, wie ein Approval Gate in einem Tool-Call-Loop aussieht. Die Logik ist dieselbe, ob Sie das OpenAI Agents SDK, das Claude Agent SDK oder Googles ADK nutzen:

# Tools that always require a human to approve before running
NEEDS_APPROVAL = {"send_email", "issue_refund", "delete_record"}

def run_tool(name, args):
    if name in NEEDS_APPROVAL:
        # Pause and ask a person
        if not human_approves(name, args):
            return {"status": "rejected", "reason": "Human declined."}
    return execute(name, args)

# The agent loop
while not done:
    action = agent.next_action()          # model proposes a tool call
    result = run_tool(action.name, action.args)
    agent.observe(result)                 # feed the outcome back in

Der Kerngedanke: das Modell *schlägt vor*, Ihr Code *entscheidet*, ob es ausgeführt wird. Der Agent hat nie direkt die Hand am gefährlichen Knopf.

Approvals leicht prüfbar machen

Eine Approval-Anfrage, die nur „Aktion genehmigen?" sagt, ist nutzlos. Der Mensch kann sie nicht beurteilen. Zeigen Sie das volle Detail:

Agent will eine E-Mail senden An: jane@acme.com Betreff: Ihre Erstattung von 50,00 $ Text: Hallo Jane, wir haben Ihre Erstattung bearbeitet... [Genehmigen] [Ablehnen] [Bearbeiten]

Geben Sie dem Prüfer genug Kontext, um einen Fehler in zwei Sekunden zu erkennen. Eine Option „Bearbeiten" ist ein Plus: der Mensch korrigiert den Betrag von 500 $ auf 50 $ und genehmigt dann.

Limits: Obergrenzen, die der Agent nicht überschreiten kann

Approvals setzen voraus, dass ein Mensch aufmerksam ist. Limits funktionieren auch, wenn niemand hinschaut. Sie sind harte Obergrenzen, die Ihr Code erzwingt, nicht das Urteil des Modells.

Übliche Limits:

• Ausgabenlimit. Der Agent darf höchstens 100 $ pro Tag ausgeben. Versuch 101 schlägt automatisch fehl.
• Rate Limit. Nicht mehr als 20 E-Mails pro Stunde, damit ein Runaway Loop nicht spammt.
• Step-Budget. Nach 15 Aktionen an einer einzelnen Aufgabe stoppen, damit er nicht endlos loopt.
• Datengrenze. Er darf die Support-Datenbank lesen, aber niemals die Payroll-Datenbank.

Ein Ausgabenlimit ist in der Praxis nur eine laufende Summe, die Ihr Code vor jeder Ausgabe prüft:

DAILY_CAP = 100.00

def issue_refund(amount):
    if spent_today() + amount > DAILY_CAP:
        return {"status": "blocked", "reason": "Daily cap reached."}
    charge(amount)
    return {"status": "ok"}

Weil das in Ihrem Code läuft, kann der Agent sich nicht daran vorbeireden. Kein geschickter Prompt macht die Zahl höher. Genau das macht Limits stärker als Anweisungen.

Anweisungen sind keine Guardrails

„Gib niemals mehr als 100 $ aus" in den System-Prompt zu schreiben, ist ein *Vorschlag*, keine Garantie. Modelle können verwirrt sein, gejailbreakt werden oder sich einfach irren. Echte Guardrails leben im umgebenden Code und in den Tools, wo das Modell kein Stimmrecht hat. Nutzen Sie den Prompt zur Verhaltenssteuerung, aber erzwingen Sie die harten Regeln außerhalb des Modells.

Für einen solide gemachten, kostenlosen Überblick, wie diese Kontrollen in ein größeres Safety-Bild passen, ist das NIST AI Risk Management Framework lesbar und herstellerneutral.

Alles zusammen: ein Refund-Agent

Entwerfen wir einen realistischen Agent und legen alle drei Guardrails übereinander.

Aufgabe: Erstattungsanfragen von Kunden in einem Support-Inbox bearbeiten.

Berechtigungen (Allow-List):

• look_up_order (read, sicher)
• check_refund_policy (read, sicher)
• draft_refund (write, bereitet vor, führt nicht aus)
• issue_refund (irreversibel)

Approvals:

• Erstattungen unter 50 $, die der Policy entsprechen: automatisch genehmigt, der Agent führt sie aus.
• Erstattungen ab 50 $ oder alles außerhalb der Policy: pausiert für einen Menschen.

Limits:

• Tageslimit von 2.000 $ über alle Erstattungen.
• Maximal 30 Erstattungsaktionen pro Stunde.
• Nach 10 Schritten an einem Fall stoppen und eskalieren.

Verfolgen wir eine Anfrage. Ein Kunde will 200 $ für eine verspätete Bestellung zurück. Der Agent schaut die Bestellung nach (sicher), prüft die Policy (sicher) und entwirft die Erstattung. Weil 200 $ die 50-$-Schwelle überschreitet, pausiert er. Ein Support-Mitarbeiter sieht den vollständigen Vorschlag, bestätigt, dass die Bestellung tatsächlich verspätet war, und klickt genehmigen. Die Erstattung läuft und wird gegen das Tageslimit von 2.000 $ gerechnet.

Würde ein Bug den Agent dazu bringen, 50 Erstattungen in einer Minute zu versuchen, stoppt ihn das Rate Limit bei 30. Würde eine Prompt Injection (eine versteckte Anweisung in einer Kundennachricht, die den Agent kapern will) ihn anweisen, 10.000 $ zu erstatten, blockiert das Tageslimit sie und der Approval-Schritt fängt sie ab. Die Schichten stützen sich gegenseitig.

Diese Schichtung ist die eigentliche Lektion. Kein einzelnes Guardrail reicht. Berechtigungen verkleinern das Möglich, Approvals fangen Urteilsfehler ab, und Limits begrenzen den schlimmsten Fall. Zusammen lassen sie einen Agent größtenteils eigenständig laufen und machen eine Katastrophe nahezu unmöglich.

Die Bremsen über die Zeit justieren

Streng anfangen, dann lockern. Starten Sie mit Approval auf fast allem. Beobachten Sie die Vorschläge eine Woche lang. Die Aktionen, die Menschen jedes Mal ohne Änderung genehmigen, sind Kandidaten für Auto-Approval. Die, die Menschen häufig bearbeiten oder ablehnen, bleiben gated.

Das gibt Ihnen Daten statt Vermutungen. Sie lernen, *wo* der Agent vertrauenswürdig ist, und lassen ihn dort frei laufen, während bei den wirklich riskanten Entscheidungen ein Mensch bleibt.

Für anbieterspezifische Wege, diese Kontrollen zu verdrahten (native Approval-Hooks, Tool-Permission-Einstellungen und Budget-Features), siehe die Deep-Dive-Blöcke zum OpenAI Agents SDK, zum Claude Agent SDK und zu Googles ADK. Die Konzepte hier übertragen sich direkt; nur die Syntax ändert sich.

Key Takeaways

• Nutzen Sie eine Tool-Allow-List. Der Agent kann nur Tools nutzen, die Sie explizit freigeben. Sortieren Sie jedes Tool in read, write und irreversibel, und scopen Sie die riskanten eng.
• Setzen Sie bei irreversiblen oder teuren Aktionen einen Menschen in den Loop. Das Modell schlägt vor, Ihr Code entscheidet, ob es läuft. Zeigen Sie Prüfern das volle Detail, damit die Zustimmung Sekunden dauert.
• Erzwingen Sie harte Limits im Code, nicht im Prompt. Ausgabenlimits, Rate Limits und Step-Budgets stoppen Runaway Loops und Jailbreaks, auch wenn niemand hinschaut.
• Schichten Sie die Guardrails. Berechtigungen, Approvals und Limits fangen jeweils ab, was die anderen verpassen. Eine einzelne Bremse reicht nicht.
• Streng starten und mit Daten lockern. Beim Launch alles gaten, dann die Aktionen auto-genehmigen, die Menschen ohnehin immer durchwinken.