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. 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 — aber mit zwei Unterschieden, die LLM-Governance schwieriger machen als HTTP-Filterung: Request-Semantik zählt (ein Prompt ist nicht nur Payload, er trägt Absicht), und Antworten können über viele Sekunden streamen, was das saubere Request/Response-Modell der meisten Policy-Engines aufbricht.

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 Designbeschränkung, die darüber entscheidet, ob das Muster skaliert: Der Proxy muss die Wire-Protokolle der Anbieter exakt sprechen. Gleiche Routes. Gleiche Header. Gleiches Authentifizierungsschema. Gleiche Antwort-Formate. Gleiche Fehlerseman­tik. Gleiche 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.

Kompatibilitäts-Checkliste. Wenn Ihre Governance-Schicht über einen Base-URL-Wechsel — und optional ein CA-Zertifikats-Trust-Update — hinaus Anwendungsänderungen verlangt, scheitert Ihr Rollout an der Engineering-Organisation, nicht am Policy-Team. Prüfen Sie diese Beschränkung, bevor Sie die Policy-Engine bauen.

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 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 zu diesem Muster. Erstens: 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 man das Streaming-Erlebnis, das die Architektur überhaupt rechtfertigt. Zweitens: Der Proxy prüft nicht nur — er ist der Autor des SSE-Streams, den der Client erhält. Das heißt, der Proxy kann eigene Events einschleusen (z. B. ein synthetisches policy-Event vor dem ersten content_delta), um Entscheidungen an Clients zu kommunizieren, 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. Verfügbar: vollständiger Prompt, System-Message, Modellparameter, Aufrufer-Identität. Kann: blockieren, Freigabe verlangen, mit Redigierung erlauben. Latenz-Budget: großzügig (der Nutzer wartet ohnehin auf eine Antwort).
• In-Stream. Verfügbar: ein Chunk auf einmal, akkumulierender Kontext. Kann: redigieren, umschreiben, Stream beenden. Latenz-Budget: knapp (Verarbeitung pro Chunk darf den Stream nicht ins Stocken bringen).
• Post-Stream. Verfügbar: vollständige Antwort, vollständiger Audit-Kontext. Kann: Audit emittieren, nachträgliche Incidents erzeugen, Evaluation. Latenz-Budget: 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 in Produktion funktioniert: blockierende Entscheidungen gehören in Pre-Stream, Inhaltsmodifikation gehört in In-Stream, Audit und nachträgliche Analyse gehören in Post-Stream. Die Policy-Engine ist in allen drei Stufen dieselbe — was sich ändert, ist, 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):

• Atomarität pro Aufruf. Jede LLM-Interaktion ist ein Audit-Datensatz. Nicht hier ein Request-Log und dort ein Response-Log.
• Append-Only-Speicher. Audit-Events werden geschrieben, niemals aktualisiert. Es gibt keine Edit-Operation im Schema.
• Manipulationssicherheit. Jedes Event enthält einen Hash des Vorgängers — jede nachträgliche Änderung zerbricht die Kette mechanisch nachweisbar.
• Entscheidungs-Kontext. Der Datensatz enthält, welche Policy-Version galt, wie die Entscheidung lautete und welcher Mensch (falls überhaupt) eine Ausnahme freigegeben hat.
• Replay-Fähigkeit. Aus einem Audit-Datensatz lässt sich die ursprüngliche Entscheidung deterministisch rekonstruieren — auch für blockierte Anfragen, denn gerade diese sind der Compliance-Beweis.

Die Schema-Skizze:

Die Kombination aus previous_event_hash und event_hash ist die Kette, die diesen Trail manipulationssicher macht. Eine nächtliche Integritätsprüfung läuft die Kette von einem bekannten Anker vorwärts ab; jede Unterbrechung erzeugt automatisch einen Incident. Das ist die Eigenschaft, mit der ein externer Auditor argumentieren kann — nicht "wir haben Logs", sondern "wir haben Logs, die mathematisch nicht still verändert werden können".

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 mindestens 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 je Anbieter-Aufruf. Der Proxy ist notwendig, aber nicht hinreichend.
• Browserbasierte KI-Nutzung. Wenn Ihre Nutzer in das Web-UI eines Anbieters einfügen, sieht kein API-Proxy diese Interaktionen. Sie brauchen 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 grundsätzlich feindlich zum Design. 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.