ChatGPT · Guardrails: Berechtigungen, Review und Kosten

Ein Agent, der eine E-Mail senden, einen Pull Request mergen oder Geld bewegen kann, ist nur so sicher wie die Gates, die Sie vor diese Aktionen setzen. Das Modell generiert nicht mehr nur Text. Es handelt, und eine selbstbewusste Halluzination wird zu einer realen Konsequenz. Diese Lektion behandelt die Kontrollschicht: entscheiden, was ein Agent anfassen darf, wann ein Mensch zustimmen muss, was nie unbeaufsichtigt laufen sollte und wie Sie verhindern, dass eine auß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 → Kontrolle geratene Loop Ihr Budget verbrennt.

Die drei Failure Modes, gegen die Sie sich absichern

Jedes GuardrailGuardrailRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →, das Sie bauen, lässt sich einem davon zuordnen:

1. Falsche Aktion ausgeführt. Der Agent tut etwas, das er nicht tun sollte (löscht einen Datensatz, mailt den falschen Kunden an).
2. Richtige Aktion, falscher Scope. Der Agent tut das Richtige, aber mit zu großer Reichweite (erstattet die ganze Bestellung statt einer einzelnen Position).
3. Kosten außer Kontrolle. Eine Loop, ein Retry-Sturm oder ein riesiger Tool-Output, der wieder in den Context wandert und Ihre TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →-Rechnung nach oben treibt.

Berechtigungen adressieren #1 und #2. Human Review fängt den besonders riskanten Rand von beidem ab. Kostenkontrollen 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 →ümmern sich um #3. Behandeln Sie das als getrennte Systeme, nicht als eine große „Sei vorsichtig“-Anweisung.

Berechtigungen: die Tools scopen, nicht den Prompt

Der größte Einzelfehler ist, Sicherheit in den Prompt zu legen („lösche nie etwas, ohne zu fragen“). Prompts sind Vorschläge. Berechtigungen leben in Code und Konfiguration, wo das Modell sich nicht daran vorbeireden kann.

In ChatGPT (dem Produkt)

Wenn Sie mit Custom GPTs und GPT Actions bauen, definieren Sie über das OpenAPI-SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → genau, welche 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 →-Endpunkte die Action ansprechen darf. Das GPT kann keinen Endpunkt aufrufen, den Sie nicht exponiert haben. Nutzen Sie OAuth in der Auth-Konfiguration der Action, damit jeder Nutzer mit seinen eigenen Berechtigungen handelt und nicht mit einem gemeinsamen Key. Den Auth-Flow finden Sie in der Actions-Dokumentation.

Connectors (Google Drive, SharePoint, GitHub und andere) erben die Berechtigungen des verbundenen Accounts. Wenn Sie einen Read-only-Service-Account verbinden, erhält der Agent Read-only-Zugriff. Richten Sie den dahinterliegenden Account nach dem Least-Privilege-Prinzip ein, bevor Sie ihn verbinden.

Der ChatGPT Agent browst, führt Code aus und nutzt Connectors in einer Sandbox-Umgebung, und er hält vor folgenreichen Schritten inne und fragt nach, etwa beim Absenden eines Formulars oder einem Kauf. Behandeln Sie diese eingebaute Bestätigung als Untergrenze, nicht als Ihre ganze Strategie.

In der API (wo Sie alles kontrollieren)

Mit der Responses API und dem Agents SDK sind Berechtigungen einfach Code um Ihre Tool-Funktionen herum. Das Modell schlägt einen Call vor; Ihr Code entscheidet, ob er ausgeführt wird.

ALLOWED_REFUND_CEILING = 100_00  # cents

def issue_refund(order_id: str, amount_cents: int) -> dict:
    if amount_cents > ALLOWED_REFUND_CEILING:
        return {
            "status": "needs_review",
            "reason": f"Amount {amount_cents} exceeds auto-approve ceiling",
        }
    result = payments.refund(order_id, amount_cents)
    return {"status": "done", "refund_id": result.id}

Das Modell sieht die Payment-Credentials nie und kann das Limit nicht anheben. Die Regel wird dort durchgesetzt, wo es zählt.

Das Review-Gate: ein konkretes Beispiel

Hier ist das Muster, das eingangs versprochen wurde: ein Agent entwirft eine Aktion, aber ein Mensch gibt sie frei, bevor sie ausgeführt wird. Das ist ein zweistufiges Tool. Phase eins liefert einen Vorschlag zurück. Ein Mensch (oder ein separater Approval-Schritt) bestätigt. Phase zwei führt aus.

Stellen Sie sich einen Support-Agenten vor, der Rückerstattungsanfragen bearbeitet. Er soll die mühsame Arbeit übernehmen (Bestellung nachschauen, Policy lesen, Rückerstattung entwerfen), aber oberhalb eines Schwellenwerts nie eigenständig Geld bewegen.

from openai import OpenAI
client = OpenAI()

PENDING = {}  # in production, use a real datastore

def propose_refund(order_id: str, amount_cents: int, reason: str) -> dict:
    token = f"refund_{order_id}"
    PENDING[token] = {"order_id": order_id, "amount_cents": amount_cents}
    return {
        "status": "awaiting_approval",
        "approval_token": token,
        "summary": f"Refund ${amount_cents/100:.2f} on {order_id}: {reason}",
    }

def commit_refund(approval_token: str) -> dict:
    job = PENDING.pop(approval_token, None)
    if not job:
        return {"status": "error", "reason": "unknown or already-used token"}
    receipt = payments.refund(job["order_id"], job["amount_cents"])
    return {"status": "done", "refund_id": receipt.id}

Der Agent kann propose_refund beliebig aufrufen. Er kann commit_refund physisch nicht ohne ein gültiges Token aufrufen, und dieses Token entsteht in Ihrem System erst, nachdem ein Mensch auf Freigeben geklickt hat. Die Aufgabe des Modells endet bei „das würde ich jetzt tun“. Das „Ja“ gehört einem Menschen.

Das ist das Denkmodell für jede folgenreiche Automatisierung: Vorschlag durch die KI, Ausführung durch den Menschen, wobei der Commit-Schritt hinter einem Token liegt, das das Modell nicht fälschen kann.

Wo der Mensch hingehört

Nicht jede Aktion verdient dasselbe Gate. Sortieren Sie Ihre Tools in drei Kategorien:

• Auto: read-only oder trivial umkehrbar (Bestellung nachschauen, Text entwerfen, Dokumente durchsuchen). Kein Gate.
• Review: folgenreich, aber Routine (Kunden-E-Mail senden, Ticket anlegen, Rückerstattung unter einem Limit). Mensch gibt frei, idealerweise gesammelt.
• Nie unbeaufsichtigt: irreversibel oder mit großem Blast Radius (Produktionsdaten löschen, Geld über einem Limit überweisen, an alle Nutzer publizieren, Berechtigungen ändern). Immer ein Mensch, immer geloggt.

Machen Sie diese Kategorien in Ihrem Design-Dokument explizit. „In welcher Kategorie ist dieses Tool?“ ist die erste Frage bei jeder neuen Fähigkeit, die Sie hinzufügen.

Was nie unbeaufsichtigt automatisiert werden sollte

Einige Kategorien gehören in die dritte Schublade, egal wie gut Ihr Agent ist:

• Irreversible Löschungen von Kunden- oder Produktionsdaten.
• Ausgehende Finanztransaktionen über einem kleinen, festen Limit.
• Identity- und Access-Änderungen (Rollen vergeben, Credentials anderer rotieren, Sharing-Einstellungen ändern).
• Öffentliche oder Massenkommunikation (öffentlich posten, eine ganze Liste anmailen, alles, was man nicht zurückholen kann).
• Rechtliche oder Compliance-Verpflichtungen (unterschreiben, AGB zustimmen, regulatorische Meldungen).

Der Test: *Wenn der Agent das einmal falsch macht, kann ich es rückgängig machen, bevor jemandem Schaden entsteht?* Wenn die Antwort nein ist, führt ein Mensch es aus. Scheduled Tasks machen das noch deutlicher, denn ein Scheduled Task in ChatGPT läuft, während Sie nicht hinschauen. Alles, was nach Zeitplan läuft, sollte einen Entwurf oder eine Benachrichtigung produzieren und keine irreversible Aktion ins Leere abfeuern.

Kosten im Griff behalten

Agenten loopen. Das ist ihre Stärke und ihr finanzielles Risiko. Ein einzelner fehllaufender Run kann ein Tool fünfzig Mal aufrufen, jedes aufgeblähte Ergebnis wieder in den Context schieben und still eine Rechnung erzeugen, die weit über einem normalen Chat liegt. Kostenkontrolle ist ein Guardrail, kein Nachgedanke.

Die Loop begrenzen

Das wichtigste Limit ist die maximale Anzahl Schritte, die ein Agent gehen darf. Im Agents SDK setzen Sie ein Turn-Limit, damit ein feststeckender Agent stoppt statt endlos zu kreisen.

from agents import Agent, Runner

agent = Agent(name="support", instructions=SYSTEM_PROMPT, tools=[propose_refund])

result = Runner.run_sync(agent, "Refund order 8842, item was defective", max_turns=8)

Wenn der Agent in acht Turns nicht fertig wird, hält er an. Dieser eine Parameter ist der Unterschied zwischen einer begrenzten Aufgabe und einer Loop außer Kontrolle.

Kontrollieren, was zurück in den Context wandert

Token-Kosten kumulieren, weil jedes Tool-Ergebnis dem Context hinzugefügt und beim nächsten Call mitgesendet wird. Ein 20.000-Token-API-Dump, aus dem das Modell nur ein Feld brauchte, kostet Sie in jedem weiteren Turn. Kürzen und fassen Sie Tool-Outputs zusammen, bevor Sie sie zurückgeben.

def search_logs(query: str) -> dict:
    rows = db.search(query, limit=2000)
    return {"matched": len(rows), "top": rows[:5]}  # not all 2000

Geben Sie die Anzahl und eine Stichprobe zurück, nicht den ganzen Heuhaufen. Das Modell braucht den Rohdump selten, und Ihr Geldbeutel schon gar nicht.

Das Modell passend wählen und die günstigen Hebel nutzen

Sie brauchen nicht für jeden Schritt Ihr leistungsfähigstes Modell. Klassifikation und Extraktion an ein kleineres, günstigeres Modell zu routen und das Frontier-Modell für echtes Reasoning zu reservieren, ist einer der wirkungsvollsten Kostenhebel überhaupt. Die aktuelle Modellpalette und die Preise pro Token finden Sie auf der OpenAI Pricing Page, da sich die genauen Modelle und Zahlen über die Zeit ändern.

Zwei weitere Hebel:

• Prompt Caching senkt die Kosten für den wiederkehrenden, statischen Teil Ihres Prompts (System-Instruktionen, Tool-Definitionen), wenn derselbe Prefix erneut auftritt. Halten Sie stabile Inhalte vorne, damit sie gecacht werden.
• Structured Outputs halten Antworten knapp und parsebar, was die Re-Prompt-und-Retry-Zyklen vermeidet, die Ihre Ausgaben still verdoppeln. Sie definieren das Schema und das Modell liefert genau diese Form.

Ausgaben beobachten, nicht entdecken

Setzen Sie in den Billing-Einstellungen Ihres OpenAI-Accounts ein hartes monatliches Usage Limit, damit ein Bug das Budget nicht leeren kann. Nutzen Sie API-Keys pro Umgebung (einer für Dev, einer für Prod), damit Sie Ausgaben zuordnen und den lauten Key widerrufen können. Und dann beobachten Sie das Usage Dashboard. Ein Kostenausschlag in einem Graph ist eine Frühwarnung; eine überraschende Rechnung ist ein Postmortem.

Die Schichten zusammenbringen

Ein gut abgesicherter Agent hat alle drei Systeme gleichzeitig am Laufen:

1. Berechtigungen entscheiden, welche Tools existieren und welchen Scope jedes hat, durchgesetzt im Code.
2. Review-Gates sitzen vor den folgenreichen Tools, mit einer Trennung von Propose und Commit, damit ein Mensch jedes irreversible „Ja“ verantwortet.
3. Kostenkontrollen begrenzen die Loop, kürzen das, was zurück in den Context wandert, routen an das passende Modell und alarmieren bei Ausgaben.

Nichts davon lebt im Prompt. Der Prompt formt Verhalten; die Guardrails setzen Grenzen durch. Wenn Sie eine neue Fähigkeit hinzufügen, stellen Sie alle drei Fragen in dieser Reihenfolge: *Was kann das anfassen? Wer gibt es frei? Was kostet es, wenn es loopt?*

Key Takeaways

• Setzen Sie Berechtigungen im Code durch, nicht im Prompt. Nutzen Sie GPT-Actions-Schemas, Connector-Accounts nach Least Privilege und Checks auf Tool-Ebene, die das Modell nicht übergehen kann.
• Nutzen Sie für folgenreiche Aktionen ein Propose-then-Commit-Gate. Der Agent liefert einen Vorschlag plus Token; erst die Freigabe eines Menschen löst den Commit-Schritt aus.
• Führen Sie eine explizite „Nie unbeaufsichtigt“-Liste: irreversible Löschungen, Geld über einem festen Limit, Access-Änderungen, Massenkommunikation und rechtliche Verpflichtungen.
• Begrenzen Sie die Schrittzahl jedes Agenten mit max_turns (oder dem Äquivalent) und kürzen Sie Tool-Outputs, damit aufgeblähte Ergebnisse nicht in jeder Loop erneut in den Context wandern.
• Setzen Sie ein hartes Billing-Limit, nutzen Sie getrennte Keys pro Umgebung und routen Sie günstige Schritte an günstigere Modelle. Beobachten Sie das Usage Dashboard, damit ein Ausschlag eine Warnung ist und keine Rechnung.