LLM-Gateway: was es im Unternehmen leistet und wer es betreiben sollte
Stand: 12. Oktober 2026
Wer nach „LLM-Gateway“ sucht, stößt schnell auf LiteLLM, einen Open-Source-Proxy, den man selbst betreibt. Gemeint ist eine Zwischenschicht vor den Modell-APIs von OpenAI, Anthropic oder Mistral: Ihre Anwendungen schicken alle Anfragen an eine URL und melden sich dort mit eigenen Tokens an, die Anbieterschlüssel liegen nur noch auf dem Gateway. Budgets, Rate Limits und Fallbacks werden dort eingestellt, ebenso Maskierung und Logging. Ob man das Gateway selbst hostet oder als Dienst aus der EU bezieht, hängt vor allem davon ab, ob ein eigenes Team Betrieb und Updates übernehmen kann.
Für diese Seite haben wir am 12.10.2026 die LiteLLM-Doku, das GitHub-Repository von BerriAI und unsere eigene Gateway-Doku unter ai-docs.myra.eu gelesen. Zitate von LiteLLM stehen im Original, auf Englisch.
Typische Ausgangslage
In der Praxis sieht es vor der Einführung oft so aus, dass ein Data-Team seinen OpenAI-Key in einer .env hat, die Entwickler Claude Code über eigene Anthropic-Konten nutzen und im Ticketsystem ein weiterer Schlüssel hinterlegt ist, den keiner mehr zuordnen kann. Jede dieser Stellen hat ihre eigenen Wiederholungsversuche und ihre eigene Rechnung. Scheidet ein Entwickler aus, müsste der Schlüssel auf seinem Rechner eigentlich für alle getauscht werden.
Fragt der Datenschutzbeauftragte, welche Kundendaten im September an welchen Anbieter gegangen sind, muss man jede Anwendung einzeln durchgehen. Mit einem Gateway steht das in einem Log.
Der Weg einer Anfrage durch das Gateway
Am Beispiel des Myra-Gateways, dessen Ablauf wir am besten kennen; andere Produkte benennen die Schritte anders.
Zuerst prüft das Gateway das Token. Ein Token ist an genau ein Gateway gebunden, mit einem Token für staging lässt sich production also nicht aufrufen. Noch bevor der Body der Anfrage gelesen wird, folgen Rate Limit und Budget. Budgets gibt es pro Token, pro Gateway und pro Mandant, und es gilt jeweils das strengste. Ab 80 % Verbrauch sehen Admins einen Hinweis im Dashboard.
Welcher Anbieter das angefragte Modell bedient, legen die Routing-Regeln fest. Liefert der Anbieter einen 5xx-Fehler oder ein 429, wiederholt das Gateway die Anfrage (mit retry_count: 2 sind es insgesamt drei Versuche) und geht danach die Fallback-Kette durch. Einen 400 reicht es sofort an die Anwendung zurück, weil eine fehlerhafte Anfrage auch beim nächsten Anbieter scheitert.
Vor dem Versand laufen die Guardrails, darunter der PII Protector. Er ersetzt etwa einen Namen und eine IBAN durch Platzhalter der Form [MYRA-REDACT-…] und setzt die Originalwerte in der Antwort wieder ein, sofern target auf "both" steht. Zuletzt schreibt das Gateway einen Log-Eintrag mit Modell, Tokenzahl, Kosten und Laufzeit.
Selbst betreiben oder als Dienst beziehen
LiteLLM bezeichnet sein Gateway in der Doku als „self-hosted server“ mit einem OpenAI-kompatiblen Endpunkt für über 100 Anbieter. Laut LICENSE-Datei im Repository steht alles außerhalb des Verzeichnisses enterprise/ unter MIT-Lizenz; für enterprise/ gilt eine eigene Lizenz von BerriAI. Bei Selbstbetrieb werden nach LiteLLMs Seite zu Datenschutz und Sicherheit keine Daten und keine Telemetrie auf LiteLLM-Servern gespeichert. Wer den Code anpassen und im eigenen Cluster laufen lassen will, ist dort richtig.
Den Betrieb beschreibt LiteLLM in einem eigenen „Shared Responsibility Model“ mit dem Satz „When you self-host LiteLLM, you run the software and we build it.“ Sicherheits-Patches und das offizielle Docker-Image samt Helm-Chart kommen von LiteLLM, die Verfügbarkeit der Instanz und die Infrastruktur darunter liegen beim Kunden. In der Tabelle haben wir zusammengestellt, welche Lage eher für welchen Weg spricht.
| Ihre Lage | Eher LiteLLM im Eigenbetrieb | Eher verwalteter EU-Dienst wie Myra |
|---|---|---|
| Wer hat nachts Bereitschaft? | Ihr Plattform-Team betreibt ohnehin Kubernetes, Postgres und Redis | Niemand im Team soll für das Gateway erreichbar sein müssen |
| Wo soll der Code liegen? | Sie wollen ihn lesen und forken, Patches spielen Sie selbst ein | Ein kommerzieller Dienst ist in Ordnung; on-premises gibt es bei Myra auf Anfrage |
| Wie viele Anbieter brauchen Sie? | Möglichst viele (LiteLLM nennt über 100) | Die großen Anbieter plus Modelle, die in der EU laufen |
| Personenbezogene Daten | Sie betreiben die Presidio-Container für die Maskierung selbst | Maskierung mit deutschen Prüfsummen-Erkennern ist eingebaut und in allen Tarifen verfügbar |
| Wer prüft Admin-Änderungen? | Ihre Revision will das Audit-Log selbst in einer Oberfläche durchsehen (bei LiteLLM Enterprise-Funktion) | Auszüge aus dem Audit-Log liefert Myra per API; eine eigene Ansicht für Ihre Admins gibt es bisher nicht |
| Was fragt der Einkauf? | Einen Nachweis über Ihren eigenen Betrieb | Einen Nachweis des Betreibers: Die Myra-Infrastruktur ist BSI-C5-Typ-2-testiert |
Maskieren kann LiteLLM ebenfalls, mit Microsoft Presidio, und die Originalwerte in der Antwort zurücktauschen (Einstellung output_parse_pii). Dafür müssen Presidio Analyzer und Anonymizer als eigene Container laufen. Bei Myra ist die Erkennung Teil des Gateways. IBANs werden mit Prüfsumme geprüft, deutsche Kennungen wie Steuer-ID oder KV-Nummer ebenfalls, sobald de_recognizers am Detektor eingeschaltet ist. Eine ausführliche Gegenüberstellung finden Sie auf unserer englischen Seite zur LiteLLM-Alternative.
Umstieg in vier Schritten
Eine Anwendung, die bisher das OpenAI-SDK direkt nutzt, braucht bei Myra zwei geänderte Werte im Client, nämlich Basis-URL und Schlüssel. Gateway und Tokens samt Anbieterschlüsseln legt ein Tenant-Admin vorher in der Oberfläche an.
- Ein Gateway anlegen, zum Beispiel
production, und dort die Schlüssel der Anbieter hinterlegen. Sie liegen verschlüsselt (AES-256) im Tresor und werden nie an die Oberfläche zurückgegeben. - Pro Anwendung oder Team ein Token ausstellen, mit eigenem Ausgabendeckel und eigenem Rate Limit.
- Im Client die Basis-URL und den Schlüssel austauschen.
- Nach ein paar Tagen in den Kostenanalysen nachsehen, wer was verbraucht, und die Deckel nachziehen.
Für den dritten Schritt sieht ein Aufruf des OpenAI-kompatiblen Endpunkts so aus:
curl https://ai-api.myra.eu/v1/{tenant}/{gateway}/compat/chat/completions \
-H "Authorization: Bearer <gateway-token>" \
-H "Content-Type: application/json" \
-d '{"model": "claude-sonnet-4-6",
"messages": [{"role": "user", "content": "Hallo"}]}'
Den Anbieter leitet das Gateway aus dem Modellnamen ab, ein Wechsel von GPT zu Claude ist damit eine Änderung am model-Feld. Editoren wie Continue, Cursor oder Zed lassen sich mit derselben Basis-URL (ohne /chat/completions) anbinden.
Claude Code spricht die Messages API von Anthropic und läuft über die Route /anthropic. Eingestellt wird das mit zwei Umgebungsvariablen:
export ANTHROPIC_BASE_URL="https://ai-api.myra.eu/v1/{tenant}/{gateway}/anthropic"
export ANTHROPIC_API_KEY="<gateway-token>"
In ANTHROPIC_API_KEY steht dabei das Gateway-Token; den Anthropic-Schlüssel holt das Gateway aus seinem Tresor. Messages-Anfragen an die Compat-Route beantwortet das Gateway mit 400.
Voreinstellungen, die Sie kennen sollten
Ein paar Standardwerte bei Myra sind großzügig. Das sagen wir lieber hier als später im Audit.
| Einstellung | Ab Werk | Was das bedeutet |
|---|---|---|
log_payloads |
true |
Das Request-Log speichert Prompt und Antwort im Klartext. Abschalten pro Gateway oder pro Anfrage mit x-aig-collect-log-payload: false; Routing und Tokenzahl bleiben im Log |
rate_limit |
nicht gesetzt | Ohne eigenen Wert gibt es kein Limit |
target (PII Protector) |
"request" |
Die Anfrage wird maskiert, die Antwort aber nicht zurückübersetzt. Mit "both" stehen die echten Namen wieder im Text |
de_recognizers (PII Protector) |
false |
Die Erkenner für Steuer-ID, USt-IdNr., KV-Nr. und weitere deutsche Kennungen laufen erst nach dem Einschalten |
fail_open (PII Protector) |
true |
Fällt die Erkennung aus, geht die Anfrage unmaskiert raus. Projekte mit „PII-Schutz erforderlich“ und Mandanten mit erzwungener Maskierung lehnen sie dann ab |
| EU-Routing | aus | Eingeschaltet lehnt das Gateway Routen außerhalb der EU mit 403 data_residency_blocked ab, bevor ein Anbieter angefragt wird |
| Audit-Log | an | Admin-Änderungen und Sicherheitsereignisse werden protokolliert, bei Bedarf manipulationserkennbar per Hash-Kette |
Wer Kundendaten durch das Gateway schickt, stellt fail_open und target um, bevor die erste echte Anfrage läuft, und schaltet die deutschen Erkenner ein.
Myra-Modelle laufen auf Myras eigener EU-Infrastruktur. In bezahlten Self-Serve-Tarifen setzen sie das Zusatzpaket „EU-Gov“ voraus. Geht eine Anfrage komplett an so ein Modell, maskiert das Gateway gar nichts (die Daten verlassen Myra ja nicht).
Was die Maskierung rechtlich ist
Kurz gesagt: Pseudonymisierung. Art. 4 Nr. 5 DSGVO definiert sie, und weil das Gateway die Zuordnung kennt und zurücktauschen kann, fällt genau das darunter. Erwägungsgrund 26 hält fest, dass pseudonymisierte Daten weiter als Angaben über eine identifizierbare Person gelten. Der Anbieter sieht weniger. Eine Rechtsgrundlage brauchen Sie trotzdem, einen AVV auch. Für den Chat-Alltag haben wir das im Beitrag Datenabfluss bei KI-Nutzung verhindern durchgespielt.
Myra verwendet Kundendaten nicht zum Training von KI-Modellen. Bei externen Anbietern wie OpenAI gelten deren eigene Bedingungen.
Übrigens läuft über dasselbe Gateway auch der Chat in Myra AI Workspace. Die Entwickler mit Claude Code und die Kollegin aus der Buchhaltung, die einen Vertrag zusammenfassen lässt, hängen also an denselben Budgets und Regeln. Welche Modelle wofür taugen, steht im Ratgeber zu Claude und Gemini im Unternehmen.
Häufige Fragen
Ist LiteLLM ein LLM-Gateway?
Ja. LiteLLM beschreibt seinen AI Gateway als selbst betriebenen Server, der Anwendungen einen OpenAI-kompatiblen Endpunkt für mehr als 100 Anbieter gibt. Den Betrieb übernehmen Sie selbst. Für Single Sign-on ab sechs Nutzern und für das Audit-Log braucht es die Enterprise-Lizenz.
Kann ich Claude Code über ein Gateway laufen lassen?
Bei Myra ja, über die Anthropic-Route. Sie setzen ANTHROPIC_BASE_URL auf https://ai-api.myra.eu/v1/{tenant}/{gateway}/anthropic und tragen als Schlüssel ein Gateway-Token ein. Der echte Anthropic-Schlüssel liegt im Tresor des Gateways und kommt nie auf die Laptops.
Speichert das Gateway meine Prompts?
Im Standard ja. Das Request-Log von Myra speichert Prompt und Antwort, solange log_payloads auf true steht, und so ist es voreingestellt. Sie können das pro Gateway abschalten oder pro Anfrage mit dem Header x-aig-collect-log-payload: false. Modell und Tokenzahl stehen dann weiter im Log, ebenso die Kosten. Der Text fehlt.
Laufen die Anfragen dann automatisch in der EU?
Nein. Das hängt vom Modell ab, an das Sie routen. Myra-Modelle laufen auf Myras eigener EU-Infrastruktur und setzen in bezahlten Self-Serve-Tarifen das Zusatzpaket „EU-Gov“ voraus. Externe Anbieter arbeiten auf ihrer eigenen Infrastruktur. Wer das ausschließen will, schaltet das EU-Routing ein; es ist standardmäßig aus.
Quellen
- LiteLLM Doku: AI Gateway (Proxy Server), abgerufen am 12.10.2026
- LiteLLM auf GitHub: LICENSE, abgerufen am 12.10.2026
- LiteLLM: Pricing, FAQ, abgerufen am 12.10.2026
- LiteLLM Doku: Data Privacy and Security, abgerufen am 12.10.2026
- LiteLLM Doku: Shared Responsibility Model, abgerufen am 12.10.2026
- LiteLLM Doku: Enterprise, abgerufen am 12.10.2026
- LiteLLM Doku: PII Masking mit Presidio, abgerufen am 12.10.2026
- LiteLLM Doku: Audit Logs, abgerufen am 12.10.2026
- Verordnung (EU) 2016/679 (DSGVO), Art. 4 Nr. 5 und Erwägungsgrund 26, EUR-Lex, abgerufen am 12.10.2026
- Myra AI Workspace: Dokumentation, abgerufen am 12.10.2026