Gleiche Befugnisse mit einem anderen Modell

Kurzfassung: Beim Wechsel eines KI-Modells zählt nicht nur die bessere Antwort. Erlaubte und verbotene Werkzeugzugriffe sowie ihre Entscheidungsprotokolle brauchen einen eigenen Vergleich. Open Policy Agent zeigt, wie sich Regeln und Modell trennen lassen. Ein unverändertes Regelpaket allein beweist allerdings noch keine unveränderte Kontrolle.

Ein Serviceagent darf einen Ersatzteilauftrag vorbereiten, aber keinen Preisnachlass freigeben. Nach einem Modellwechsel liefert er bessere Begründungen und findet schneller die richtige Teilenummer. Die Vorführung überzeugt. Offen bleibt, ob er weiterhin an derselben Rabattgrenze gestoppt wird – und ob das Unternehmen die Entscheidung später noch nachvollziehen kann.

Dieser gedachte Fall beschreibt eine andere Folge des Modellwechsels als verlorene Gesprächsverläufe oder schlechtere Antworten. Ausgetauscht wird ein Modell; verändert werden kann dabei auch, wie seine Ausgabe in eine ausführbare Aktion übersetzt wird. Genau dort verdient die Abnahme einen eigenen Blick.

Die Regel bleibt, ihre Eingabe kann sich ändern

Zwischen Modell und Geschäftssystem sitzt Software, die Werkzeugaufrufe übersetzt. Sie ordnet beispielsweise einen vorgeschlagenen Kunden, eine Aktion und einen Betrag einer technischen Anfrage zu. Diese Vermittlung wird hier als Modelladapter bezeichnet. Wechselt dessen Format oder Zuordnung, kann dieselbe geschäftliche Absicht mit anderen Angaben bei der Rechteprüfung ankommen.

Eine externe Regelprüfung kann etwa entscheiden, ob eine bestimmte Identität für einen bestimmten Kunden einen Nachlass dieser Höhe anfordern darf. Sie prüft die übermittelten Angaben. Ob der Adapter den richtigen Kunden, den Betrag und die handelnde Identität übergeben hat, ist eine zusätzliche Frage. Ein unverändertes Regelwerk schützt nicht vor einer falschen Übersetzung seiner Eingaben.

Open Policy Agent, kurz OPA, beschreibt eine Architektur, in der Dienste die Auswertung solcher Regeln auslagern können. Die Auswertungsinstanz kann unmittelbar neben dem jeweiligen Dienst laufen. Regelverteilung, Entscheidungsprotokolle und Statusmeldungen werden über getrennte Managementschnittstellen organisiert. Die Regeln müssen damit nicht Bestandteil einer Modellanweisung sein.

Die laufende Dokumentation, gelesen am 5. November 2026, beschreibt keine neue Produkteinführung. Sie liefert eine technische Grundlage für die Trennung. OPA stellt ausdrücklich keinen fertigen zentralen Verwaltungsdienst bereit. Ebenso wenig garantiert das Werkzeug, dass beliebige Modelladapter fachlich dieselben Eingaben erzeugen oder jede Anwendung das zurückgegebene Ergebnis tatsächlich durchsetzt.

Verglichen wird die Befugnis, nicht der Wortlaut

Für den gedachten Serviceagenten könnte die Wechselprobe vier festgelegte Fälle enthalten: Ein zulässiger Auftrag wird vorbereitet. Ein Rabatt oberhalb der Zuständigkeit wird abgelehnt oder zur Freigabe weitergeleitet. Ein fremder Kundenbestand bleibt gesperrt. Ein inzwischen entzogener Zugriff wird auch mit dem neuen Modell verweigert.

Die fachlichen Erwartungen werden vorher festgelegt. Beide Modellvarianten erhalten dieselben Testidentitäten, Daten und Regeln. Verglichen werden nicht identische Formulierungen, sondern die entscheidenden Angaben und Wirkungen: Welche Aktion wurde angefordert? Für welches Objekt? Unter welcher Identität? Welche Entscheidung kam zurück? Was wurde anschließend tatsächlich ausgeführt?

Ein Modell darf eine verbotene Aktion bereits vor dem Werkzeugaufruf verwerfen. Das kann richtig sein, prüft aber die nachgelagerte Zugriffssperre noch nicht. Deshalb braucht der ausführende Dienst zusätzlich direkte Tests, die die Regelprüfung unabhängig vom Modell erreichen. Andernfalls bleibt ausgerechnet die letzte technische Grenze in der Vorführung unberührt.

Die Forderung nach dieser Wechselprobe ist eine betriebliche Ableitung, kein von OPA nachgewiesenes Prüfverfahren für Sprachmodelle. Sie verlangt auch nicht, dass alle Modelle jede Aufgabe gleich lösen. Sie prüft enger: Bleiben die festgelegten Befugnisse trotz anderer Lösungswege erhalten?

Das Entscheidungsprotokoll ist nicht der Ausführungsbeleg

Die OPA-Dokumentation zu Decision Logs beschreibt Ereignisse mit abgefragter Regel, Eingabe, Ergebnis und Metadaten des verwendeten Regelpakets. Das Schema enthält unter anderem eine Entscheidungskennung, einen Zeitstempel und die Revision des Regelpakets. Bei aktivierter Entscheidungsprotokollierung liefert die API eine decision_id zurück.

Solche Angaben erlauben einen präziseren Vergleich als die Aussage, der Agent habe „korrekt reagiert“. Sie können zeigen, welcher Regelstand eine konkrete Anfrage erlaubt oder abgelehnt hat. Das Unternehmen sollte diese Belege über den Modellwechsel hinweg unter eigener betrieblicher Zuständigkeit verfügbar halten können – auch wenn ein Dienstleister sie betreibt.

Doch protokolliert wird zunächst eine Regelauswertung. Ein erlaubtes Ergebnis beweist nicht, dass der Auftrag danach erfolgreich gebucht wurde. Ein abgelehntes Ergebnis beweist allein noch nicht, dass kein anderer Zugriffsweg die Aktion ausführte. Für kritische Vorgänge gehört deshalb der Abgleich mit dem ausführenden Geschäftsdienst dazu. Die Verbindung zwischen dessen Vorgangskennung und der Regelentscheidung muss die Integration herstellen; sie entsteht nicht automatisch durch den Modellwechsel.

Auch fehlende Protokolle sind ein Testergebnis

Entscheidungsprotokollierung ist konfigurierbar. OPA dokumentiert Regeln zum Auslassen bestimmter Ereignisse. Bei einer eingestellten Begrenzung der Ereignisrate können darüber hinaus Ereignisse verworfen werden. Die Existenz einer Logschnittstelle ist deshalb kein Nachweis einer lückenlosen Aufzeichnung.

Zur Abnahme gehört folglich eine Prüfung, ob die benötigten Belege beim vorgesehenen Empfänger ankommen, welche Ereignisse absichtlich fehlen und wie Überlast sichtbar wird. Zugleich enthalten die Eingaben möglicherweise personenbezogene oder vertrauliche Informationen. Die Dokumentation beschreibt Maskierung und Entfernung sensibler Felder vor der Übertragung. Mehr Nachvollziehbarkeit rechtfertigt nicht, Kennwörter oder vollständige Kundeninhalte ungefiltert zu sammeln. Aufbewahrung, Zugriff und benötigte Belegdetails sind gesondert festzulegen.

Für den nächsten Modellwechsel lässt sich daraus ein begrenzter Lieferumfang machen: Der Integrator dokumentiert die Zuordnung von Identität, Objekt und Aktion, führt die vereinbarten Erlaubnis- und Ablehnungsfälle aus und weist den Eingang der erforderlichen Protokolle nach. Der Fachbereich bestimmt die erwarteten Befugnisse; IT und Betrieb prüfen Durchsetzung und Nachvollziehbarkeit. Erst dann steht neben der besseren Antwort auch fest, ob das neue Modell innerhalb derselben geschäftlichen Grenzen arbeitet.