KI-Governance und Audit für Enterprise-LLMs: Virtuelle Schlüssel, RBAC und Compliance-konforme Protokolle

Wenn LLMs von der Pilotphase in den produktiven Einsatz über verschiedene Teams hinweg übergehen, ist Governance keine Option mehr. Irgendwann stellt sich die Frage, wer welches Modell mit welchem Budget und auf Basis welcher Daten aufrufen darf – und ob jeder Aufruf für ein Audit rekonstruiert werden kann. Dieser Beitrag beschreibt die Steuerungsebene, die diese Fragen beantwortet: virtuelle Schlüssel zur Entkopplung von Zugriffen und Anbieter-Anmeldedaten, RBAC und Policy-as-Code, Budgets und Quoten als Governance-Instrumente, Compliance-konforme Audit-Logs, Datenresidenz sowie die Zuordnung dieser Gateway-Kontrollen zu Verpflichtungen wie dem EU AI Act – verstanden als Unterstützung bei der Erfüllung, nicht als Compliance-Garantie.

Quartalsende bei Northwind. Mei, die Plattform-Leiterin, erhielt eine Frage vom Sicherheits- und Compliance-Team, die sie nicht beantworten konnte: Welche Teams hatten im letzten Quartal Kundendaten an welche Modellanbieter gesendet, und konnte sie die entsprechenden Aufzeichnungen vorlegen? Sie konnte es nicht. Jeder Dienst rief die Modellanbieter über einen gemeinsamen API-Schlüssel auf, der vor Jahren in einer Konfigurationsdatei hinterlegt worden war. Es gab keine Zuordnung pro Team, keine Aufzeichnung darüber, welche Anfragen Kundendaten enthielten, keine Möglichkeit, den Zugriff eines einzelnen Teams zu widerrufen, ohne den Schlüssel für alle zu ändern, und keinen Audit-Trail, der über die undurchsichtigen Abrechnungen der Anbieter hinausging. Die LLM-Nutzung war von einem Prototyp auf ein Dutzend produktive Dienste angewachsen, doch die Governance war nicht mitgewachsen.

Es war zwar nichts schiefgelaufen – kein Sicherheitsvorfall, keine bemerkten Budgetüberschreitungen. Aber „wir können die Frage nicht beantworten“ ist ein eigenes Ergebnis, und genau das macht aus einem Routine-Audit ein langwieriges Projekt. Dieser Beitrag beschreibt die Steuerungsebene, mit der diese Fragen beantwortet werden können, bevor sie überhaupt gestellt werden.

Was das AI Gateway von TrueFoundry hier bietet

Alles, was in diesem Beitrag beschrieben wird – virtuelle Schlüssel, RBAC, Budgets, Ratenbegrenzungen, Audit-Logs, Residenzregeln und Leitplanken als durchgesetzte Richtlinien – ist etwas, das das AI Gateway von TrueFoundry als Konfiguration in einer zentralen Steuerungsebene abbildet. Zugriffskontrolle definiert, wer (Benutzer, Teams, virtuelle Konten) welche Anbieterkonten und Modelle aufrufen darf; Persönliche Zugriffstoken und Token für virtuelle Konten sind die Art und Weise, wie sich Anwendungen am Gateway authentifizieren, anstatt direkte Anbieterschlüssel zu verwenden; Konfigurationen für Ratenbegrenzungen und Budgets gelten pro Benutzer, Team, virtuellem Konto, Modell oder jedem benutzerdefinierten Metadaten-Schlüssel; und Leitplanken – einschließlich Cedar und OPA als Policy-as-Code an der MCP-Tool-Schnittstelle – laufen als durchgesetzte Regeln an vier Lifecycle-Hooks.

Jede Anfrage durchläuft denselben Pfad: Authentifizierung, Identifizierung des Aufrufers, Prüfung der Zugriffsrichtlinie und der schlüsselbasierten Budgets, Auswertung der Ratenbegrenzungsregeln (die erste Übereinstimmung zählt), Ausführung der Eingabe-Leitplanken, Weiterleitung an einen Anbieter, Erstellung eines Audit-konformen Traces und schließlich Ausführung der Ausgabe-Leitplanken. Dieselbe Ansicht dient als Nachweis für Auditoren: Wer hat was wann aufgerufen, basierend auf welcher Richtlinie und mit welchen Ergebnissen der Leitplanken. Anfrage-Traces und OpenTelemetry-Export lassen Sie die Daten in Ihrem SIEM landen, anstatt in einem Anbieter-Dashboard, das Sie nicht abfragen können.

‍

‍

Der Anwendungscode unterscheidet sich nicht von einem herkömmlichen OpenAI-Aufruf – die Governance liegt im Bearer-Token und im Metadaten-Header, nicht in der Client-Logik. Ein Personal Access Token wird einer Person zugeordnet; ein Virtual Account Token einer nicht-menschlichen Identität für Produktionsdienste. Der X-TFY-METADATA -Header enthält die strukturierten Felder (Team, Projekt, Kostenstelle, Umgebung), mit denen Richtlinien, Budgets und Audit-Logs abgeglichen werden:

Aufruf des Gateways mit Identitäts- und Audit-Metadaten (Python, OpenAI-kompatibel)

from openai import OpenAI

client = OpenAI(
    base_url="https://<your-truefoundry-gateway-url>",   # your gateway endpoint
    api_key="<your-virtual-account-token>",              # VAT for production; PAT in dev
)

resp = client.chat.completions.create(
    model="openai-main/gpt-5.5",
    messages=[{"role": "user", "content": "Summarize this document."}],
    extra_headers={
        # Structured identity for audit, attribution, and policy matching.
        "X-TFY-METADATA": '{"team":"support-ai","project":"helpdesk","cost_center":"cc-203","environment":"production"}',
    },
)
print(resp.choices[0].message.content)

1. Warum Governance in der Produktion unverzichtbar wird

Ein einzelner Prototyp, der ein Modell mit einem Schlüssel aufruft, benötigt keine Governance. Ein Dutzend Dienste in verschiedenen Teams, die mehrere Anbieter mit Daten unterschiedlicher Sensibilität aufrufen, benötigen jedoch eine Control Plane – denn die Fehlerquellen sind längst keine Theorie mehr. Ein gemeinsam genutzter Schlüssel bedeutet keine Nutzungszuordnung; Sie können der Finanzabteilung also nicht sagen, welches Team die Kosten verursacht, oder der Sicherheitsabteilung, welches Team auf Kundendaten zugegriffen hat. Ohne Ausgabenlimits kann ein einziger außer Kontrolle geratener Agent (denken Sie an die stille Eskalation aus dem Routing-Beitrag) das Budget sprengen, bevor es jemand bemerkt. Ohne Audit-Trail können Sie bei einem Vorfall oder für einen Wirtschaftsprüfer nicht rekonstruieren, was passiert ist. Und ohne Zugriffskontrolle entsteht Schatten-KI: Teams binden Modelle ein, ohne dass dies jemand nachverfolgt.

Neben dem operativen Druck wächst auch der regulatorische Druck. Der EU AI Act führt schrittweise Verpflichtungen zu Aufzeichnungspflichten, Transparenz und menschlicher Aufsicht ein (Abschnitt 7), und branchenspezifische Regelungen – wie SOC 2, HIPAA oder Finanzvorschriften – fordern schon lange Zugriffskontrollen und Audits. Der gemeinsame Nenner ist, dass sie alle voraussetzen, dass Sie Meis Frage beantworten können. Governance ist die Arbeit, die genau das ermöglicht.

‍