Das Drop-in-Proxy-Muster für LLM-Governance: Architektur, Kompatibilität und Fehlermodi

TL;DR. Der schwierigste Teil von LLM-Governance ist nicht die Policy-Engine. Es ist, sich zwischen Anwendung und Anbieter zu schieben, ohne etwas zu zerbrechen. Dieser Beitrag erklärt das transparente Proxy-Muster, das skaliert, warum API-Protokoll-Kompatibilität die alles entscheidende Designbeschränkung ist, wie Streaming das Durchsetzungsfenster verändert und welche Produktions-Fehlermodi nicht im Architekturdiagramm auftauchen.

Inhalt

1. Warum direkte LLM-Integration beim ersten Audit scheitert
2. Das transparente Governance-Proxy-Muster
3. API-Kompatibilität ist die Designbeschränkung
4. Streaming und das Durchsetzungsfenster
5. Wo Policy tatsächlich läuft
6. Der Audit-Trail, den jede Aufsicht inzwischen verlangt
7. Lehren aus dem Produktiveinsatz und Trade-offs
8. Wann dieses Muster für Sie falsch ist

1. Warum direkte LLM-Integration beim ersten Audit scheitert

Die meisten Unternehmen rollen LLM-Zugriffe so aus, wie sie jede neue SaaS-API ausrollen: jedes Team holt sich einen API-Key, integriert das SDK des Anbieters direkt in seine Anwendung und liefert es aus. Das funktioniert genau bis zum ersten Audit, dem ersten PII-Vorfall oder der ersten Sicherheitsprüfung eines KI-nahen Systems. Dann stellt jemand aus Compliance vier Fragen, und niemand im Engineering hat die Antworten:

• Welche Prompts haben in den letzten drei Monaten unser Netzwerk verlassen, und was stand darin?
• Wie stellen wir sicher, dass Kundendaten, Zugangsdaten und geistiges Eigentum nicht in der Trainings-Pipeline oder im Log eines externen Anbieters landen?
• Wenn ein Modell vertrauliche Informationen zurückgibt, die nicht sichtbar sein dürfen, gibt es eine Kontrolle, die verhindert, dass die Antwort den Nutzer erreicht?
• Welche Policy galt für einen bestimmten LLM-Aufruf, wer hat sie freigegeben, und kann diese Entscheidung deterministisch reproduziert werden?

Teams, die direkt integriert haben, können diese Fragen nicht beantworten, denn die Integration ist die Lücke. Der Anbieter sieht den Prompt, bevor irgendeine interne Kontrolle läuft, und die Antwort erreicht die Anwendung, bevor irgendeine interne Validierung stattfindet. Logging auf Anwendungsebene erfasst, woran sich der Entwickler erinnert hat, selten das, was der Auditor braucht.

Das Muster, das dieses Problem löst, ohne jede Anwendung umzuschreiben, ist ein transparenter Governance-Proxy: er sitzt zwischen Anwendung und Anbieter, spricht das Protokoll des Anbieters und wendet Policy im laufenden Datenstrom an. Der Rest dieses Artikels beschreibt, wie dieses Muster im Produktivbetrieb tatsächlich funktioniert.

2. Das transparente Governance-Proxy-Muster

Die Architektur ist leicht zu zeichnen und überraschend subtil zu bauen:

Die Anwendung benutzt ihr bestehendes SDK weiter. Keine Imports ändern sich. Keine Client-Bibliothek wird ersetzt. Geändert wird ausschließlich die Base-URL: Statt auf den öffentlichen Endpunkt des Anbieters zeigt sie auf den Proxy. Der Proxy spricht dasselbe Wire-Protokoll, das das SDK erwartet, wendet Policy beim Durchgang an und leitet die Anfrage weiter oder blockiert sie.

Konzeptionell ähnelt das einem Enterprise-Web-Proxy oder API-Gateway. Zwei Dinge machen LLM-Governance jedoch schwieriger als reine HTTP-Filterung. Ein Prompt trägt Absicht, nicht bloß eine Payload, also muss der Proxy über die Request-Semantik nachdenken. Und Antworten streamen über viele Sekunden, was das saubere Request/Response-Modell aufbricht, das die meisten Policy-Engines voraussetzen.

3. API-Kompatibilität ist die Designbeschränkung

Der Grund, warum die meisten "AI-Security-Plattform"-Rollouts steckenbleiben, ist, dass sie verlangen, dass Teams ihre Anwendungen umbauen, um mit einer proprietären Governance-API zu sprechen. Aus Sicht der Engineering-Organisation ist das nicht akzeptabel: Jede LLM-nutzende Anwendung muss neu getestet, deployed und validiert werden. Hochskaliert auf das ganze Unternehmen ist das ein Quartale dauerndes Projekt, bevor irgendeine Policy tatsächlich greift.

Die Beschränkung, die über die Skalierbarkeit entscheidet: Der Proxy muss das Wire-Protokoll jedes Anbieters exakt sprechen. Routes, Header und Authentifizierungsschema müssen übereinstimmen, ebenso die Antwortformate, die Fehlersemantik und die Abfolge der Streaming-Events. Die Anwendung darf nicht erkennen können, ob sie mit dem echten Anbieter oder dem Proxy spricht.

In der Praxis heißt das: Eine einzige Änderung der Base-URL reicht aus.

Vorher: direkte Integration

Nachher: über den Governance-Proxy

Der Anwendungscode ändert sich nicht. Das SDK muss nichts vom Proxy wissen. Das Anfrage-Format des Anbieters bleibt durchgängig erhalten. Was sich ändert, geschieht zwischen den beiden Requests auf der Leitung.

Ein lohnender Test, bevor Sie überhaupt etwas bauen: Verlangt Ihre Governance-Schicht mehr als einen Base-URL-Wechsel (und, optional, ein CA-Zertifikats-Trust-Update), scheitert der Rollout an der Engineering-Organisation, nicht am Policy-Team. Prüfen Sie diese Kompatibilität zuerst.

4. Streaming und das Durchsetzungsfenster

Die meisten modernen LLM-Endpunkte unterstützen Server-Sent Events (SSE). Der Client öffnet eine HTTP-Verbindung, der Server hält sie offen, und Tokens treffen über viele Sekunden hinweg als benannte Events ein. Das ist es, was LLM-Anwendungen reaktiv wirken lässt, und zugleich das, was naive Policy-Durchsetzung unmöglich macht.

Das klassische API-Gateway-Modell setzt voraus: gesamten Request empfangen, entscheiden, weiterleiten, gesamte Response empfangen, entscheiden, zurückgeben. Streaming bricht beide Hälften. Der Request-Body kann zu Beginn vollständig empfangen werden (Policy auf den Prompt ist also unkompliziert), aber die Antwort trifft Token für Token über eine Verbindung ein, die 30 Sekunden oder länger offen bleiben kann. Wenn man die ganze Antwort gesehen hat, hat der Nutzer das meiste davon längst gesehen.

Das Durchsetzungsfenster hat daher zwei klar getrennte Phasen. Pre-Stream, bevor die Anfrage an den Anbieter weitergeleitet wird, hat der Proxy den vollständigen Prompt zur Verfügung und kann jede blockierende Policy ausführen. In-Stream, während die Antwort ausgeliefert wird, puffert der Proxy jeden Chunk und prüft ihn, bevor er ihn an den Client weitergibt. Wenn ein Chunk gegen eine Policy verstößt, kann der Proxy ihn umschreiben, redigieren oder den Stream beenden.

Das Wire-Level-Muster sieht so aus:

Zwei Designhinweise. In-Stream-Chunk-Prüfung ist durch Latenz begrenzt: jede Arbeit pro Chunk muss in der Größenordnung von Millisekunden fertig sein, sonst zerstört sie das Streaming-Erlebnis, das die Architektur überhaupt rechtfertigt. Und der Proxy prüft den Stream nicht bloß, er schreibt ihn: Er ist der Autor des SSE-Streams, den der Client erhält, und kann deshalb eigene Events einschleusen (etwa ein synthetisches policy-Event vor dem ersten content_delta), um Entscheidungen an Clients zu melden, die darauf vorbereitet sind.

5. Wo Policy tatsächlich läuft

Ein nützliches mentales Modell: Der Proxy hat drei Policy-Entscheidungspunkte, jeder mit anderen Trade-offs.

• Pre-Stream. Bevor irgendetwas weitergeleitet wird, hat der Proxy den vollständigen Prompt, die System-Message, die Modellparameter und die Aufrufer-Identität vorliegen und kann blockieren, eine Freigabe verlangen oder mit Redigierung durchlassen. Das Latenz-Budget ist großzügig, denn der Nutzer wartet ohnehin auf eine Antwort.
• In-Stream. Jetzt sieht der Proxy einen Chunk nach dem anderen vor akkumulierendem Kontext und kann redigieren, umschreiben oder den Stream beenden. Das Budget ist knapp: die Verarbeitung pro Chunk darf den Stream nicht ins Stocken bringen.
• Post-Stream. Mit der vollständigen Antwort und dem gesamten Audit-Kontext kann der Proxy Audit-Datensätze emittieren, nachträglich Incidents eröffnen oder Evaluationen fahren. Diese Arbeit läuft asynchron, entkoppelt von der nutzersichtbaren Latenz.

Ein häufiger Fehler ist es, alles in Pre-Stream zu legen, weil sich dieser Punkt am leichtesten beherrschen lässt. Das Ergebnis ist ein Proxy, der offensichtliche Lecks in Prompts fängt, aber alles übersieht, was das Modell selbst produziert. Der gegenteilige Fehler, alles in In-Stream, ist noch schlimmer, weil der Proxy dann zum alleinigen Latenzpunkt jeder LLM-Interaktion im Unternehmen wird.

Die Aufteilung, die sich in Produktion bewährt, ist schnell gesagt: blockieren in Pre-Stream, Inhalte anpassen in In-Stream, Audit und nachträgliche Analyse in Post-Stream. Die Policy-Engine ist in allen drei Stufen dieselbe; es ändert sich nur, was sie tun darf.

6. Der Audit-Trail, den jede Aufsicht inzwischen verlangt

Steht der Proxy einmal, ist der Audit-Trail fast ein Nebenprodukt, aber nur, wenn man ihn von Anfang an richtig entwirft. Die Eigenschaften, die für Aufsichtsbehörden zählen (und für das eigene zukünftige Ich, das in acht Monaten einen Vorfall rekonstruiert):

• Jede LLM-Interaktion wird zu einem einzigen Audit-Datensatz, nicht hier ein Request-Log und dort ein Response-Log.
• Audit-Events sind append-only: einmal geschrieben, nie aktualisiert, ohne jede Edit-Operation im Schema.
• Jedes Event enthält einen Hash seines Vorgängers, sodass jede nachträgliche Änderung die Kette nachweisbar zerbricht.
• Der Datensatz hält fest, welche Policy-Version galt, wie entschieden wurde und welcher Mensch, falls überhaupt, eine Ausnahme freigegeben hat.
• Aus einem einzigen Datensatz lässt sich die ursprüngliche Entscheidung deterministisch rekonstruieren, blockierte Anfragen eingeschlossen, und gerade die wiegen als Compliance-Beweis am schwersten.

Die Schema-Skizze:

Die Kombination aus previous_event_hash und event_hash bildet die Kette, die den Trail manipulationssicher macht. Eine nächtliche Integritätsprüfung läuft sie von einem bekannten Anker vorwärts ab, und jede Unterbrechung eröffnet automatisch einen Incident. Das gibt einem externen Auditor eine Aussage, mit der er tatsächlich argumentieren kann: Die Logs lassen sich nicht still verändern, ohne dass die Kette es zeigt.

7. Lehren aus dem Produktiveinsatz und Trade-offs

Ein paar Dinge lernt man erst, nachdem man dieses Muster eine Weile produktiv betrieben hat.

Latenz ist nicht umsonst

Jede Stufe der Durchsetzung kostet Millisekunden. Bei Pre-Stream-Policy fängt das die User Experience auf. Der Roundtrip zu einem gehosteten LLM wird ohnehin in Sekunden gemessen. Bei In-Stream-Chunk-Prüfung übersetzt sich jede Millisekunde in spürbar langsamere Antworten. Aggressiv profilieren und budgetieren. Die Versuchung, "noch eine Prüfung" pro Chunk hinzuzufügen, ist die häufigste Ursache für "der Proxy macht unsere App langsam".

Fail-Closed ist die einzig richtige Voreinstellung

Wenn der PII-Scanner nicht erreichbar ist, muss die Anfrage blockiert werden. Wenn das Policy-Bundle nicht geladen werden kann, muss die Anfrage blockiert werden. Wenn die Audit-Senke unten ist, muss die Anfrage blockiert werden, oder zumindest die Antwort gepuffert, bis Audit wieder verfügbar ist. Fail-Open wirkt nutzerfreundlicher, bis zum Tag, an dem ein Scanner-Ausfall genau auf den Prompt fällt, der am dringendsten zu blockieren gewesen wäre.

Policy-Authoring ist ein eigenes Problem

Der Proxy setzt Policy durch. Er entscheidet nicht, welche Policy gelten soll. Behandeln Sie Policy wie Code: versionsverwaltet, von zwei unabhängigen Reviewern freigegeben, signiert und über dieselbe Pipeline ausgerollt wie jede andere Produktionsänderung. Eine Policy-Engine ohne Governance über die Policy-Autoren ist Theater.

Multi-Tenancy hebt die Anforderungen an Isolation

Bedient der Proxy mehr als eine Organisationseinheit, müssen Audit-Kette, Policy-Bundle und Redigierungs-Tokens alle mandantengescoped sein. Ein Row-Level-Filter reicht nicht: gewünscht ist Schema-Level-Isolation, abgesichert durch Row-Level-Enforcement, damit auch ein ehrlicher Fehler in einer Query keine Mandanten­grenze überlesen kann.

8. Wann dieses Muster für Sie falsch ist

Das transparente Proxy-Muster ist die richtige Antwort für die größte Klasse von LLM-Governance-Problemen, aber nicht für alle. Einige Fälle, in denen Sie nach einem anderen Ansatz suchen sollten:

• Agentische Workflows, die viele Werkzeuge orchestrieren. Ein Agent, der mit zehn Tools über mehrere Anbieter spricht, braucht Governance auf der Agent-Ebene, nicht bei jedem einzelnen Anbieter-Aufruf. Der Proxy ist hier notwendig, aber nicht hinreichend.
• Browserbasierte KI-Nutzung. Fügen Ihre Nutzer in das Web-UI eines Anbieters ein, sieht kein API-Proxy diese Interaktionen. Nötig ist eine andere Kontrollfläche, typischerweise Session-Instrumentierung oder Browser-Policy.
• Private Modell-Deployments innerhalb Ihres Perimeters. Verlässt das Modell Ihr Netzwerk nie, ändert sich die Form des Datenleck-Problems. Ein transparenter Proxy hilft weiterhin für Governance und Audit, löst aber kein Vertraulichkeitsproblem, das es nicht mehr gibt.
• Hard-Realtime-Anwendungen. Hat Ihre Anwendung Latenzanforderungen unter 100 ms, ist In-Stream-Policy dem Design grundsätzlich abträglich. Pre-Stream und Post-Stream können funktionieren, In-Stream meist nicht.

Zu wissen, wann das Muster nicht anzuwenden ist, ist Teil davon, es gut anzuwenden. Die Teams, die den größten Nutzen aus einem Governance-Proxy ziehen, behandeln ihn als eine Schicht in einer Defense-in-Depth-Architektur, nicht als alleinige Antwort auf jede KI-Risikofrage.