Worin unterscheidet sich Policy-Orchestrierung von Guardrails im Modell?

Guardrails wirken auf Ein- und Ausgaben des Modells, arbeiten selbst probabilistisch und filtern Inhalte. Die Entscheidungsschicht wirkt dagegen auf Handlungen und entscheidet deterministisch, ob ein Werkzeugaufruf ausgeführt werden darf. Beide Ebenen ersetzen einander nicht: Ein Filter verhindert keine unerlaubte Überweisung, und eine Richtlinie verhindert keine unpassende Formulierung.

Lohnt sich eine eigene Entscheidungsschicht schon bei zwei Agenten?

Ja, in schlanker Form: ein Durchsetzungspunkt am Werkzeug-Gateway und eine Handvoll Richtlinien für die teuren Aktionen. Der eigentliche Aufwand entsteht nicht beim Aufbau, sondern beim Nachrüsten, wenn die Regeln bereits über Prompts, Code und mündliche Absprachen verteilt sind. Solange Sie noch alle Stellen kennen, ist die Umstellung günstig.

Welche Latenz kostet die Richtlinienprüfung?

Das hängt von Regelwerk, Attributbeschaffung und Anbindung ab und lässt sich nicht seriös pauschal beziffern. Werten Sie lokal aus — als Sidecar oder eingebettete Bibliothek — und messen Sie den p95-Wert an Ihrem eigenen Regelsatz. Teuer wird meist nicht die Auswertung selbst, sondern das Nachladen fehlender Attribute; dort helfen Zwischenspeicher mit kurzer Gültigkeit.

Fällt die Entscheidungsschicht selbst unter die KI-Verordnung?

Die Schicht ist konventionelle Software und wird nicht dadurch zum KI-System, dass sie Agenten kontrolliert. Relevant wird sie als Mittel, um Pflichten des Gesamtsystems zu erfüllen, etwa Protokollierung nach Artikel 12 und wirksame menschliche Aufsicht nach Artikel 14. Ob und in welche Risikoklasse Ihr Anwendungsfall fällt, entscheidet der Einsatzzweck, nicht die eingesetzte Technik.

Wer schreibt die Richtlinien — Fachbereich oder Plattformteam?

Beide, mit klarer Aufgabenteilung: Der Fachbereich formuliert Absicht, Schwellen und Freigaberollen, das Plattformteam überführt sie in ausführbare Regeln. Als gemeinsame Sprache dienen Testfälle nach dem Muster „diese Anfrage, diese erwartete Entscheidung“, die auch ohne Kenntnis der Richtliniensprache lesbar sind. Jede Änderung sollte von beiden Seiten mitgezeichnet werden.

Muss der Betriebsrat eingebunden werden?

Sobald Entscheidungsprotokolle Rückschlüsse auf Verhalten oder Leistung von Beschäftigten zulassen, greift in Deutschland die Mitbestimmung nach § 87 Absatz 1 Nummer 6 BetrVG. Klären Sie Zweckbindung, Auswertungsgrenzen und Löschfristen schriftlich, bevor Sie in den Wirkbetrieb gehen. In Österreich und der Schweiz gelten abweichende Regelungen, die Sie gesondert prüfen sollten.

Policy-Orchestrierung für KI-Agenten: eine Entscheidungsschicht statt Regeln in jedem Prompt

Zwei Felder: links vier einzelne Regelkarten in unterschiedlichen Winkeln ohne Verbindung untereinander; rechts eine einzige Regelkarte, die über gerade Linien mit vier Torvorrichtungen in einer Reihe verbunden ist

Eine Regel wie „Zahlungen über 5.000 Euro niemals ohne zweite Freigabe” steht in vielen Agentensystemen an drei Stellen gleichzeitig: im System-Prompt, in der Beschreibung des Werkzeugs und als Bedingung im Adapter zur Buchhaltung. Welche Fassung im Zweifel gilt, weiß niemand genau. Fragt die Interne Revision nach, folgt keine Antwort, sondern eine Suche in drei Repositorien.

Dieses Muster ist der Normalfall, sobald ein Team vom Prototyp in den Betrieb wechselt. Es trägt nicht weit: Mit jedem zusätzlichen Agenten, jedem neuen Werkzeug und jeder weiteren Fachabteilung wächst die Zahl der Orte, an denen eine Regel stehen könnte, schneller als die Zahl der Menschen, die alle diese Orte kennen.

Was Policy-Orchestrierung für KI-Agenten bedeutet

Policy-Orchestrierung bedeutet, sämtliche Richtlinien für KI-Agenten aus Prompts, Werkzeugbeschreibungen und Anwendungscode herauszulösen und in einer eigenen Entscheidungsschicht zusammenzuführen. Diese Schicht erhält vor jeder wirksamen Handlung eine strukturierte Anfrage — wer handelt, mit welchem Werkzeug, an welcher Ressource, in welchem Kontext — und antwortet mit einer verbindlichen Entscheidung: erlauben, verweigern, Freigabe anfordern oder eingeschränkt ausführen. Der Agent formuliert die Absicht, die Schicht befindet über die Zulässigkeit, und ein Durchsetzungspunkt im Aufrufpfad vollzieht das Ergebnis. Damit wird aus einer Bitte im Prompt eine Richtliniendurchsetzung, die auch dann hält, wenn das Modell die Anweisung überliest oder durch eine Prompt Injection umgelenkt wird.

Der praktische Gewinn dieser Trennung zeigt sich beim ersten Wechsel: Sie können das Modell austauschen, den Anbieter wechseln oder das Framework ersetzen, ohne Ihre Regeln neu zu schreiben. Umgekehrt ändern Sie eine Freigabegrenze an genau einer Stelle — und sie gilt sofort für jeden Agenten, dessen Aufrufe durch dieselbe Schicht gehen.

Warum Regeln im Prompt keine Durchsetzung sind

Ein Prompt ist eine Anweisung an ein probabilistisches System, kein Kontrollpunkt. Befolgt wird er meistens — und „meistens” hält bei Zahlungen, Löschungen oder beim Versand an externe Empfänger keiner Prüfung stand.

Hinzu kommt, dass Agenten laufend Inhalte lesen, die andere geschrieben haben: Tickets, E-Mails, Webseiten, Anhänge. Diese Inhalte konkurrieren im selben Kontextfenster mit Ihren Regeln. Die OWASP-Liste „Top 10 for LLM Applications” führt Prompt Injection und übermäßige Handlungsvollmacht („Excessive Agency”) nicht ohne Grund nebeneinander: Das eine wird erst durch das andere zum Schaden.

Der dritte Punkt wiegt in regulierten Häusern am schwersten — es fehlt der Nachweis. Eine Regel im Prompt hinterlässt keine Spur darüber, ob sie in einem konkreten Vorgang gegriffen hat. Sie können im Nachhinein weder zeigen, welche Fassung galt, noch wer sie zuletzt geändert hat, noch wie oft sie eine Handlung tatsächlich verhindert hat.

Viertens fehlt der Lebenszyklus: keine Tests, keine Versionierung, keine benannte Zuständigkeit, kein erprobter Weg zurück. Eine Prompt-Änderung, die eine Regel schärft, kann unbemerkt eine andere aufweichen, weil beide um dieselben Token konkurrieren.

Die Anatomie der Entscheidungsschicht

Die Zerlegung ist weder neu noch spekulativ; sie stammt aus der Zugriffssteuerung. Der OASIS-Standard XACML und der NIST-Leitfaden SP 800-162 zur attributbasierten Zugriffssteuerung beschreiben sie seit Jahren. Neu ist allein der Aufrufer: kein Mensch in einer Oberfläche, sondern ein Agent, der Werkzeuge in Serie und ohne Pause aufruft.

Durchsetzungspunkt (PEP) — sitzt im Aufrufpfad und lässt keinen Werkzeugaufruf an sich vorbei. In Agentenarchitekturen ist das typischerweise das Werkzeug-Gateway, der MCP-Server oder die Bibliothek, über die Werkzeuge registriert werden.
Entscheidungspunkt (PDP) — wertet die Richtlinien aus und liefert eine Entscheidung samt Begründung und Richtlinienkennung zurück.

Eine Entscheidung, vier mögliche Ergebnisse. Der PEP fängt ab, der PDP entscheidet, der PAP gibt die Regeln frei und der PIP liefert die Fakten, die die Anfrage selbst nicht mitbringt — und jedes Ergebnis landet im Audit-Trail.

Verwaltungspunkt (PAP) — hier werden Richtlinien geschrieben, überprüft, versioniert und freigegeben.
Informationspunkt (PIP) — ergänzt Attribute, die in der Anfrage fehlen: Rolle des Auftraggebers, Datenklasse einer Tabelle, bereits verbrauchtes Budget der laufenden Sitzung.

Ein Durchsetzungspunkt taugt nur dann etwas, wenn er sich nicht umgehen lässt. Ein Agent, der neben dem Gateway zusätzlich eine eigene HTTP-Bibliothek oder eine Shell benutzen darf, hat keine Richtliniendurchsetzung, sondern eine Empfehlung.

Kriterium	Regel im Prompt	Richtlinie in der Entscheidungsschicht
Wirkung	Bitte an das Modell	verbindliche Entscheidung im Aufrufpfad
Verhalten bei Prompt Injection	angreifbar, konkurriert mit fremden Inhalten	unberührt, da außerhalb des Kontextfensters
Nachweis	keiner	Entscheidungsprotokoll je Aufruf
Änderung	Prompt neu justieren, Wirkung unklar	versionierter Vorgang mit Prüfung und Freigabe
Test	manuelles Ausprobieren	Testfälle mit erwarteter Entscheidung in der CI
Geltung über mehrere Agenten	je Agent kopiert, läuft auseinander	einmal definiert, überall wirksam
Konflikte	letzte Formulierung gewinnt zufällig	ausdrücklich geregelter Vorrang

Was eine Agentenrichtlinie tatsächlich auswertet

Die üblichen Eingaben aus der klassischen Zugriffssteuerung — Subjekt, Aktion, Ressource — reichen bei Agenten nicht aus. Praktisch tragfähig wird eine Richtlinie erst mit diesen zusätzlichen Attributen:

Delegierte Identität: In wessen Auftrag handelt der Agent? Die wirksamen Rechte sind die Schnittmenge aus den Rechten des Agenten und denen des Auftraggebers, nie deren Vereinigung.
Auslöser des Vorgangs: Hat ein Mensch die Aufgabe gestartet, ein Zeitplan oder eine eingehende Nachricht von außen? Der dritte Fall muss am strengsten behandelt werden.
Vertrauensstufe der gelesenen Inhalte: Hat der Agent im selben Lauf nicht vertrauenswürdige Inhalte verarbeitet, bevor er eine schreibende Aktion versucht?
Zweck: Die Zweckbindung ist keine Kür, sondern in Artikel 5 DSGVO ein Grundsatz. Sie lässt sich als Attribut modellieren und auswerten.
Verbrauch und Budget: Summe der bereits angestoßenen Zahlungen, versendeten Nachrichten oder gelesenen Datensätze innerhalb einer Sitzung.

Ebenso wichtig ist, dass die Antwort nicht binär bleibt. Eine brauchbare Entscheidungsschicht kennt mindestens fünf Ergebnisse: erlauben, verweigern, Freigabe durch eine benannte Rolle anfordern, eingeschränkt erlauben (Felder maskieren, Betrag deckeln, Probelauf erzwingen) und drosseln. Genau diese Zwischenstufen fehlen im Prompt-Ansatz, und genau sie halten den Betrieb am Laufen, ohne die Kontrolle aufzugeben.

Vorrang statt Zufall

Sobald Richtlinien aus mehreren Quellen stammen — Konzernvorgabe, Fachbereich, Mandant, Projekt — brauchen Sie eine ausdrückliche Konfliktauflösung. Bewährt hat sich in der Zugriffssteuerung die Kombination aus der Grundhaltung „alles verboten, was nicht ausdrücklich erlaubt ist” und der Regel, dass ein Verbot einer Erlaubnis immer vorgeht.

Übertragen auf Agenten heißt das: Ein unbekanntes Werkzeug wird abgelehnt, nicht stillschweigend zugelassen. Jede Ausnahme bekommt einen namentlich Verantwortlichen, eine Begründung und ein Ablaufdatum. Ein Notfallzugang ohne Verfallsdatum ist keine Ausnahme, sondern eine dauerhafte Rechteerweiterung mit besserem Namen.

Policy as Code: der Lebenszyklus

Richtlinien gehören in die Versionsverwaltung und durchlaufen denselben Weg wie Anwendungscode — mit einer Ergänzung: Die fachliche Seite muss die Prüfung mitzeichnen können, ohne die Richtliniensprache selbst zu beherrschen. Testfälle in der Form „diese Anfrage, diese erwartete Entscheidung” sind dafür die gemeinsame Sprache.

Führen Sie neue Fassungen zuerst im Schattenbetrieb: Die Schicht entscheidet und protokolliert, setzt aber noch nichts durch. Wie viele legitime Aufrufe die neue Fassung blockiert hätte, lesen Sie anschließend aus Ihren eigenen Protokollen ab. Diese Zahl lässt sich nicht aus Erfahrungswerten anderer Häuser übernehmen — sie hängt vollständig von Ihrem Regelwerk und Ihren Abläufen ab.

Danach folgt die stufenweise Einführung: ein Agent, ein Mandant, eine Fachabteilung — und für jeden Schritt ein erprobter Weg zurück. Wer alle Regeln gleichzeitig scharfschaltet, lernt vor allem, wie schnell ein Fachbereich eine Umgehung findet.

Entscheidungsprotokolle sind der eigentliche Ertrag

Ein verwertbarer Protokolleintrag enthält mindestens: Zeitstempel, Agenten- und Auftraggeberidentität, Werkzeug und Operation, die entscheidungsrelevanten Attribute, das Ergebnis, die Kennung und Version der ausschlaggebenden Richtlinie sowie eine Korrelationskennung zum Vorgang. Damit lässt sich im Nachhinein rekonstruieren, warum eine Handlung zulässig war — und nicht nur, dass sie stattgefunden hat.

Regulatorisch deckt das gleich mehrere Anforderungen ab. Die KI-Verordnung (Verordnung (EU) 2024/1689) verlangt in Artikel 12 die Protokollierung bei Hochrisiko-Systemen und in Artikel 14 wirksame menschliche Aufsicht; Artikel 26 nimmt Betreiber zusätzlich in die Pflicht, die automatisch erzeugten Protokolle aufzubewahren. Die konkreten Fristen und Ausnahmen prüfen Sie am konsolidierten Text auf EUR-Lex, da sich Fassungen und nationale Vorgaben unterscheiden. Aus der DSGVO kommt die Rechenschaftspflicht nach Artikel 5 Absatz 2 hinzu, bei folgenreichen automatisierten Entscheidungen außerdem Artikel 22.

Zwei Nebenwirkungen sollten Sie früh einplanen. Erstens sind Entscheidungsprotokolle selbst personenbezogene Daten und brauchen Zugriffsbeschränkung, Zweckbindung und ein Löschkonzept. Zweitens sind sie geeignet, Verhalten und Leistung von Beschäftigten nachvollziehbar zu machen; in Deutschland löst genau das die Mitbestimmung des Betriebsrats nach § 87 Absatz 1 Nummer 6 BetrVG aus. In Österreich und der Schweiz gelten eigene Regelungen, in der Schweiz zusätzlich das revidierte Datenschutzgesetz. Den Betriebsrat erst nach der Einführung einzubinden, ist der teuerste aller möglichen Wege.

Werkzeuge: Orientierung, keine Kaufempfehlung

Für die Entscheidungsschicht müssen Sie nichts erfinden. Etabliert ist zum einen der Open Policy Agent (OPA) mit der Sprache Rego: ein CNCF-Projekt, das als Sidecar läuft oder sich als Bibliothek einbetten lässt und Entscheidungsprotokolle bereits mitbringt. Daneben steht Cedar, die quelloffene Richtliniensprache von AWS, die auch als verwalteter Dienst zu haben ist, sowie OpenFGA für beziehungsbasierte Berechtigungen nach dem Vorbild des Zanzibar-Papiers von Google. Für Infrastrukturregeln in Kubernetes sind Kyverno und OPA Gatekeeper üblich — sie lösen jedoch ein anderes Problem als die Kontrolle einzelner Werkzeugaufrufe.

Der ehrliche Vorbehalt: Keines dieser Werkzeuge wurde für Agenten entworfen. Sitzungsbudgets, Zweckbindung, das Vertrauen in die Herkunft einer Auslösung und „Freigabe anfordern” als mögliches Ergebnis modellieren Sie selbst und liefern sie über einen Informationspunkt zu. Prüfen Sie vor der Auswahl Lizenz, Projektreife und die Auswertungszeit an Ihrem eigenen Regelsatz; veröffentlichte Vergleichswerte sagen über Ihr Regelwerk wenig aus.

Latenz und Fehlerverhalten

Jeder Werkzeugaufruf wartet auf die Entscheidung, deshalb gehört der Entscheidungspunkt dicht an den Durchsetzungspunkt — als Sidecar oder eingebettete Bibliothek, nicht als eigener Dienst jenseits von zwei Netzgrenzen. Stabile Entscheidungen lassen sich kurz zwischenspeichern, sofern der Schlüssel alle entscheidungsrelevanten Attribute umfasst.

Legen Sie das Fehlerverhalten je Aktionsklasse fest, nicht global: Für schreibende und schwer umkehrbare Aktionen gilt „im Zweifel verweigern”, für rein lesende, unkritische Aufrufe kann ein anderes Verhalten vertretbar sein. Diese Festlegung ist eine Risikoentscheidung des Fachbereichs und kein Konfigurationsdetail des Plattformteams.

Der Einstieg in vier Schritten

Inventur: Alle Stellen auflisten, an denen heute eine Regel steht — Prompts, Werkzeugbeschreibungen, Code, Tickets, Absprachen. Meist ist diese Liste die überzeugendste Begründung für das Vorhaben.
Ein Durchsetzungspunkt: Werkzeugaufrufe über genau einen Pfad führen und alle Umgehungen schließen. Ohne diesen Schritt wirkt jede Richtlinie nur dort, wo sie ohnehin niemand umgehen wollte.
Fünf Richtlinien, nicht fünfzig: Beginnen Sie bei den Aktionen, bei denen ein Fehler richtig teuer wird — Geld, Löschung, Außenkommunikation, personenbezogene Daten.
Protokoll und Schattenbetrieb: Erst messen, dann durchsetzen, dann ausweiten.

Ein Anti-Muster zum Schluss: die Entscheidungsschicht selbst aus einem Sprachmodell zu bauen — ein Agent, der prüft, ob ein anderer Agent handeln darf. Das ist bequem und verschiebt das Problem nur um eine Ebene, denn dieser Prüfer ist genauso wenig deterministisch und genauso angreifbar wie der Agent, den er prüfen soll. Die Entscheidungsschicht muss langweilige, überprüfbare Software sein. Ihr Wert liegt genau darin.