Geregelte KI-Agenten: Ein Richtlinienmodell, mehrere Umsetzungsstellen zur Laufzeit.
Wie man Kosten, Modellwahl, Daten, Tools sowie MCP-Aufrufe zur Laufzeit steuert: ein Governance- Rahmenwerk, ein neutrales Richtlinienkonzept, Rückfallmechanismen, Schutzgrenzen und Nachverfolgung.
Quellen: Building Governed AI Agents: How to Control Cost, Data, Tools and Actions at Runtime
Ein Supportmitarbeiter erhält einen Rückzahlungsantrag. Die Nachricht enthält eine Kontonummer und eine Telefonnummer. Um ihn bearbeiten zu können, benötigt der Mitarbeiter ein Sprachmodell zum Lesen des Antrags, ein internes Tool zur Suche nach der Bestellung, ein CRM über MCP zum Hinzufügen einer Notiz sowie möglicherweise einen zweiten Mitarbeiter zur Prüfung besonders großer Rückzahlungen. Nichts davon ist heute noch ungewöhnlich. Die schwierige Herausforderung besteht darin, dass jeder Schritt in dieser Kette eine andere Richtlinie berührt, und jede solche Berührung eigene Fragen aufwirft.
- Ist es zulässig, dass diese Kundendaten an den ausgewählten Modellanbieter übermittelt werden?
- Liegt der Antrag noch innerhalb des Budgets?
- Darf diese Arbeitslast dieses Modell in dieser Region nutzen?
- Soll der CRM-Server das gesamte Gespräch erhalten?
- Kann das Rückzahlungstool 2.000 Dollar auszahlen, ohne dass ein Mensch es genehmigt?
Ein Richtliniedokument kann grundsätzlich solche Fragen beantworten, und ein Systemhinweis kann einen Agenten an einige Aspekte erinnern. Keines davon sorgt jedoch konsequent für Einhaltung der Vorgaben. Deshalb wird die Steuerung von Agenten zu einem Problem während des Betriebs.
Ein veröffentlichtes Framework für gesteuerte Agenten beschreibt diesen Wandel gut: Die Governance legt die Regeln fest, und ein Gateway ist einer der Orte, an denen diese Regeln auf den tatsächlichen Datenverkehr treffen. Es organisiert die Arbeit in fünf Aktivitäten – Govern, Decide, Protect, Observe und Assure. Ein nützlicher Punkt dabei ist, dass Modellaufrufe, Toolaufrufe, MCP-Aufrufe sowie Kommunikation zwischen Agenten jeweils unterschiedliche Risiken mit sich bringen. Diese Unterscheidung ermöglicht ein besseres Design, als alle Kontrollmechanismen in einen einzigen großen Hinweis oder ein einziges großes Gateway zu packen.
Lassen Sie die Richtlinie mit der Anfrage mitgehen
Das einfachste Modell ist eine Governance-Enveloppe, die eine Interaktion innerhalb des Systems begleitet. Sie enthält genügend Kontext, um vor Überschreiten einer Grenze eine Entscheidung treffen zu können:
- Identität und Nutzer,
- Arbeitslast und Agent,
- Risikostufe und Datenklassifizierung,
- aktuelle Ausgaben und Limits,
- erlaubte Anbieter und Regionen,
- erlaubte Tools und Handlungsbereiche,
- Schwellenwerte, die eine menschliche Genehmigung erfordern,
- Politikversion sowie eine Trace- oder Entscheidungs-ID.
Nicht jedes Komponente benötigt jedes Feld. Die Enveloppe dient dazu, dass immer wieder dieselben Fragen konsistent beantwortet werden können, egal wohin der Agent geht.
- Für einen Modellaufruf sind die relevanten Fakten Ausgaben, Anbieter, Region, Aufbewahrungsfrist und Löschung.
- Für ein Rückerstattungstool sind es die Identität des Benutzers, das Eigentum am Auftrag, der Betrag sowie die Genehmigungsstufe.
Daher handelt es sich bei der Architektur nicht um einen universellen Filter, sondern um ein einziges Richtlinienmodell mit mehreren Durchsetzungsstellen. In dieser Phase wird die Laufzeitsteuerung konkret, denn die wichtige Frage ist nicht, ob eine Richtlinie existiert, sondern welcher Komponente es möglich ist, die Interaktion vor jeglichen Nebeneffekten zu stoppen.
Ein kleiner, anbieterunabhängiger Entwurf
Es ist keine Steuerungsplattform erforderlich, um dieses Muster zu erkennen. Der untenstehende Python-Code ist absichtlich unparteiisch und nicht an eine bestimmte Produkt-API gebunden. Seine Aufgabe besteht darin, die Entscheidungspunkte sichtbar zu machen.
from dataclasses import dataclass
from enum import Enum
class Decision(str, Enum):
ALLOW = "allow"
BLOCK = "block"
APPROVAL = "approval"
FALLBACK = "fallback"
@dataclass(frozen=True)
class PolicyContext:
user_id: str
workload: str
risk_tier: str
data_class: str
spend_usd: float
spend_limit_usd: float
policy_version: str
def before_model_call(ctx: PolicyContext, model: str) -> Decision:
if ctx.spend_usd >= ctx.spend_limit_usd:
return Decision.BLOCK
if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
return Decision.FALLBACK
return Decision.ALLOW
def before_tool_call(
ctx: PolicyContext,
tool: str,
amount: float = 0,
) -> Decision:
if tool not in TOOL_SCOPES[ctx.workload]:
return Decision.BLOCK
if tool == "issue_refund" and amount > 500:
return Decision.APPROVAL
return Decision.ALLOW
def before_mcp_call(
ctx: PolicyContext,
server: str,
) -> Decision:
if server not in APPROVED_MCP_SERVERS:
return Decision.BLOCK
if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
return Decision.BLOCK
return Decision.ALLOW
Die Syntax ist weniger wichtig als die Liste der Dinge, die das Modell auf keinen Fall berücksichtigen darf. Es kann darüber nachdenken, was der Kunde möchte. Es kann jedoch nicht entscheiden, dass eine Rückerstattung von 2.000 Dollar jetzt den Richtlinien entspricht, oder dass ein nicht genehmigter MCP-Server in Ordnung ist, weil die Anfrage harmlos erscheint. Solche Ergebnisse sind deterministische Zustandsänderungen, die vom Laufzeitumfeld gesteuert werden.
Eine Produktionsversion sollte außerdem für jede Entscheidung Nachweise liefern: die Version der Richtlinie, den Eingabebereich, das Ergebnis, den Grund, den Ausführenden, das Zeitstempel sowie die Trace-ID. Genau diese Nachweise belegen später, welche Richtlinie tatsächlich ausgeführt wurde, anstatt lediglich zu zeigen, dass es ein Richtliniedokument gab.
Ein Modell-Gateway hilft, ist aber nicht das gesamte Design
In diesem Rahmen stellt ein LLM-Gateway eine gemeinsame Schicht für Authentifizierung, Auswahl des Modells, Kürzung des Kontexts, Ausgabenrichtlinien, Fehlerbehandlung sowie Nachweise für Entscheidungen dar. Ein aktuelles Produkt eines Anbieters von Agenten-Tools macht dies greifbar. Es ging im August 2026 in die öffentliche Beta-Version und bietet Ausgaben- sowie Geschwindigkeitsbeschränkungen, Fallback-Möglichkeiten für Modelle, Routing zu Anbietern, Schutz für sensible Daten sowie Integration von Trace-Daten. Die Einführung bei herkömmlichen Modellkunden soll unkompliziert sein: Richten Sie die base_url des Clients auf das Gateway aus, speichern Sie die Schlüssel der Anbieter zentral und legen Sie die Richtlinien an einem Ort fest.
Das ist wichtig, denn andernfalls würde die Modellverwaltung in jeden Agent kopiert werden.
agent A → custom rate logic → OpenAI
agent B → custom PII logic → Anthropic
agent C → custom fallback → Gemini
agent D → no controls → self-hosted model
Ein Gateway kann den Haufen in eine gemeinsame Schicht zusammenfassen.
agents
↓
shared model-call policy
↓
approved providers / hosts
Resistieren Sie hier einer zu einfachen Übergeneralisierung. Das Governance-Framework ist breiter gefasst als jedes einzelne Gateway-Produkt. Es behandelt ausdrücklich Tool-Aufrufe, MCP-Aufrufe sowie Interaktionen zwischen Agenten, denn das größte Risiko für einen Agenten liegt oft in den Aktionen, die er ausführen kann, und nicht im von ihm generierten Text. Die Kontrollmechanismen des öffentlichen Beta-Zustands des Gateways beziehen sich hauptsächlich auf den Datenverkehr der Modelle. Eine zusätzliche Überwachung ist weiterhin im Agent-Harness, im Tool-Runtime-Umfeld, an der MCP-Grenze oder in einem speziellen Aktion Gateway erforderlich. Diese Trennung ist sinnvoll, da ein Modell-Gateway nicht vorgeben sollte, eine Änderung in einer Produktionsdatenbank autorisieren zu können, die es nie gesehen hat.
Zuverlässigkeit zählt zur Governance
Sobald ein Gateway auf dem kritischen Pfad steht, kann eine unklare Fehlerbehandlung dazu führen, dass die Governance selbst zu Ausfällen führt. Zwei Ansätze helfen dabei.
Zunächst benötigt jede Arbeitslast eine explizite Einstellung für „Fail-Open“ oder „Fail-Closed“. Eine risikofreie Zusammenfassungsanfrage, die den Richtlinienservice nicht erreichen kann, sollte möglichst reibungslos abgewickelt werden. Eine Anfrage mit eingeschränkten Daten, die nicht nachweisen kann, dass ihre Lösch- oder Speicherungspolitik angewandt wurde, darf möglicherweise nicht in den „Fail-Open“-Modus wechseln.
Zweitens muss ein Ersatzmodell den Richtlinien entsprechen und nicht lediglich verfügbar sein. Angenommen, das primäre Modell wurde genehmigt, weil es die Daten in einer vorgeschriebenen Region gemäß einer vereinbarten Aufbewahrungsrichtlinie speichert. Ein automatischer Wechsel auf einen günstigeren oder besser verfügbaren Anbieter, der diese Bedingungen missachtet, erhöht die Widerstandsfähigkeit nicht – stattdessen wird ein Verstoß gegen die Compliance durch das Aussehen einer kontinuierlichen Funktionsfähigkeit ersetzt.
Ausgabenkontrollen folgen derselben Logik. Harte Obergrenzen helfen, doch eine Obergrenze ohne Warnungen und ohne Eskalationsweg verwandelt die Governance in einen willkürlichen Ausfall. Eine bessere Lösung ist eine sequenzielle Vorgehensweise.
usage approaches threshold
↓
alert
↓
route / reduce context / downgrade model if allowed
↓
hard block when policy requires it
↓
auditable exception path if business-approved
Aus diesem Grund steht das Modell-Routing näher der Portfolio-Verwaltung als dem Versand einfacher Anfragen an ein billiges Modell. Kosten spielen eine Rolle, genauso wie Latenz, Datenverarbeitung, Qualität, Risikostufe und Verfügbarkeit.
Der Kostenfaktor eines zentralen Steuerungsplanes
Durch die Zentralisierung der Richtlinien entfällt für jeden Agenten die Notwendigkeit, eigene Kopien mitzuführen, doch die Verantwortung konzentriert sich dort ebenfalls. Die Laufzeitsschicht steht nun im Weg des Modellverkehrs und hilft in einigen Designs bei der Autorisierung von Aktionen, weshalb sie wie jeder andere kritische Dienst konzipiert werden muss.
- Die Richtlinienprüfungen müssen schnell genug ablaufen, um die Anfragenlatenz nicht zu dominieren, und der Richtlinienservice benötigt selbst Redundanz.
- Die Preisdaten jedes Anbieters müssen aktuell bleiben und im Cache gespeichert werden; außerdem müssen Batch- und Reasoning-Tokens genau gezählt werden, damit die Ausgabenobergrenzen glaubwürdig sind.
Ein weiterer Kostenfaktor ist organisatorischer Natur. Ein zentrales Plattformteam kann sichere Standardwerte mühelos bereitstellen, doch zu umfassende Kontrollen können Produktteams verlangsamen. Ein Weg von Sichtbarkeit über Kontrolle bis hin zu Sicherstellung mildert dies ab: Zunächst beobachten, die neue Richtlinie im Warn- oder Schattenmodus ausführen, messen, was passiert, und nur dort vollständig blockieren, wo das Risiko es erfordert. Diese Schicht sollte wiederholende Arbeiten beseitigen, ohne zu einer undurchsichtigen Abhängigkeit zu werden, die niemand umgehen, debuggen oder sicher ändern kann.
Sicherheitsmaßnahmen sollten keine konsequenzenbehafteten Aktionen eigenständig ausführen
Schutzmechanismen gibt es in zwei Arten. Musterregeln eignen sich für strukturierte Geheimnisse und Identifikatoren. modellbasierte Detektoren kommen mit unstrukturierten Kategorien wie unstrukturierten personenbezogenen Daten, Jailbreak-Versuchen oder Aspekten der Plausibilität zurecht. Keiner dieser Ansätze ist perfekt, und modellbasierte Überprüfungen sind probabilistisch, wodurch sowohl Falschpositive als auch Falschnegative auftreten können.
Es gilt folgende Richtlinie: Die Inhaltserkennung kann das Risiko verringern, sollte aber niemals die einzige Kontrolle sein, die zwischen einem Agenten und einer nachteiligen Nebenwirkung steht.
- Eine Rückerstattungsbeschränkung sollte lieber als Code implementiert werden als als Klassifikator.
- Jede Bereitstellung eines Systems sollte eine Autorisierungsprüfung enthalten.
- Eine hochriskante Aktion kann eine menschliche Genehmigung erfordern.
- Anmeldeinformationen sollten so eingeschränkt werden, dass ein Agent nicht über das hinausgeht, was seine Aufgabe erfordert – selbst wenn ein Schutzmechanismus etwas übersehen hat.
Das Framework setzt die Grenze auf dieselbe Weise: Konsequente Aktionen hängen von deterministischen Grenzen oder menschlicher Genehmigung ab und nicht allein von der Inhaltserkennung. Es handelt sich dabei um die Lücke zwischen dem Erkennen unsicherer Absichten und der Eindämmung unsicherer Fähigkeiten. OWAPPS Leitlinien zu übermäßiger Autonomie kommen unabhängig dazu zum selben Schluss und empfehlen eine minimale Funktionalität sowie Berechtigungen der Tools, wobei die Autorisierung in nachgelagerten Systemen durchgesetzt werden soll und nicht dem eigenen Urteilsvermögen des Modells überlassen wird. Beide Ansätze sind erforderlich.
Beobachten und sicherstellen
Das Nachverfolgen wird weitaus nützlicher, sobald Richtlinienentscheidungen Teil der Nachverfolgung sind.
- Eine abgelehnte Modellanfrage zeigt an, welche Ausgabenrichtlinie aktiviert wurde.
- Ein Löschvorgang zeigt an, welche Richtlinienversion angewendet wurde, ohne den sensiblen Wert preiszugeben.
- Die Genehmigung eines Tools ist mit der Aktion verbunden, die es kontrolliert.
Durch solche Bewertungen kann man mehr prüfen als nur die Genauigkeit des Modells. Man kann untersuchen, ob ein kleineres Modell nach einer Änderung der Routen weiterhin eine gute Qualität aufweist, ob das Weglassen von Kontextinformationen Kosten senkt, ohne die Ergebnisse zu beeinträchtigen, ob eine Löschrichtlinie zu viele falsche Positivfälle erzeugt und ob eine neue Ersatzlösung weiterhin der ursprünglichen Richtlinie entspricht.
Zusammen schließen diese Elemente den fünfteiligen Kreislauf ab. Govern legt Eigentumsverhältnisse, Risiken und Richtlinien fest; Decide steuert die Routen, kümmert sich um Eskalationen und Fallback-Lösungen; Protect sorgt an allen Grenzen für Einhaltung der Richtlinien; Observe misst das Verhalten sowie die Ergebnisse der Richtlinien; Assure bewahrt die Abfolge der Abläufe auf und prüft Änderungen. Das Einsetzen einer Regel beendet die Arbeit nicht – die Arbeit ist abgeschlossen, wenn nachgewiesen werden kann, welche Regel angewendet wurde, was sie entschieden hat, was danach geschah und ob die Kontrolle auch nach Systemänderungen weiterhin funktioniert.
Was das für die Agent-Architektur bedeutet
Was Produktionsagenten benötigen, ist eine Laufzeitsteuerungsarchitektur – unabhängig von der gewählten Gateway-Lösung. Ein zentrales Modellgateway eignet sich hervorragend zur Verwaltung von Kosten, Auswahl der Anbieter, Redaktion, Rate-Limits sowie Fallback-Mechanismen und ermöglicht die Wahl von Modellen, ohne jede Anwendung direkt anzufassen. Ein regulierter Agent benötigt dennoch die umgebenden Schichten:
- Autorisierung sowie feste Grenzen für Tool-Aktionen,
- Verschlussschutzentscheidungen bezüglich MCP-Servern sowie Regeln darüber, welche Daten abgegeben werden dürfen,
- minimierter Kontext sowie überprüfte Identität zwischen kooperierenden Agenten,
- Genehmigung oder Eindämmung bei Maßnahmen mit ernsthaften Folgen,
- eine nachvollziehbare Politikhierarchie hinter jeder Entscheidung.
Zurück bei der Rückerstattungsanfrage kann das Modell weiterhin logisch denken und der Agent weiterhin handeln. Die Architektur verlangt lediglich nicht mehr, dass das Modell das gesamte Governance-Programm in seiner Anweisung enthält. Jede wichtige Grenze erhält ihre Antwort bereits vor dem Überschreiten:
- Wer stellt die Anfrage?
- Welche Daten werden übertragen und wohin?
- Wie viel Rechenleistung ist erlaubt?
- Welche Modelle und Tools sind zulässig?
- Was ist der Plan, falls der bevorzugte Weg versagt?
- Ist eine menschliche Freigabe erforderlich?
- Welche Policy-Version hat die Anweisung gegeben?
Das ist es, was KI-Policies von gesteuerten Agenten unterscheidet.