Enterprise-Gateway-Layer 2026: LiteLLM, Portkey, Cloudflare, Kong, AWS Strands & Privacy Router

4. Juni 202610 min readDeep Dive

TL;DR: „Wer einen Enterprise-Gateway vor seine Agenten setzen will, kombiniert heute LiteLLM (Multi-Provider) + Portkey (Governance) + Privacy Router (DSGVO-Routing). Cloudflare ist der schnellste Edge-Start, Kong die Wahl für regulierte Sektoren, AWS Strands für reine AWS-Stacks."

— Till Freitag

Warum überhaupt einen Enterprise-Gateway?

Sobald mehr als ein Team LLMs produktiv nutzt, brauchst du vier Dinge an einer Stelle:

Auth & RBAC – wer darf welches Modell mit welchem Budget nutzen?
Observability & Logging – wer hat wann was gefragt, was kostete es, was kam zurück?
Routing nach Modell/Vendor – Failover, Cost-Optimierung, PII-Awareness.
Rate-Limiting & Quotas – pro Team, pro Modell, pro Tageszeit.

Microsoft Scout wurde als integrierter Enterprise-Gateway angekündigt – ist aber noch nicht verfügbar. Wer Mitte 2026 produktiv loslegen muss, kombiniert die folgenden Bausteine.

Entscheidungs-Flowchart: Welcher Gateway passt zu dir?

Start: Brauchst du einen LLM-Gateway?
  │
  ├─ DSGVO-Strict / On-Premise-Pflicht?
  │     │
  │     ├─ Ja  →  Self-Hosted OpenClaw + Privacy Router
  │     │         (lokale Modelle, kein Hyperscaler)
  │     │
  │     └─ Nein → weiter ↓
  │
  ├─ Reiner AWS-Stack mit Compliance-Pflicht?
  │     │
  │     ├─ Ja  →  AWS Strands / Bedrock AgentCore
  │     │         (IAM, CloudTrail, Bedrock-Modelle)
  │     │
  │     └─ Nein → weiter ↓
  │
  ├─ Regulierte Branche (Bank, Pharma, Behörde)?
  │     │
  │     ├─ Ja  →  Kong AI Gateway (Self-hosted oder Konnect EU)
  │     │         (mTLS, OAuth/OIDC, Audit-Trails, Plugin-Ökosystem)
  │     │
  │     └─ Nein → weiter ↓
  │
  ├─ Brauchst du PII-Redaction & Prompt-Governance?
  │     │
  │     ├─ Ja  →  Portkey AI Gateway (vor LiteLLM)
  │     │         (Guardrails, Prompt-Versionierung, A/B-Tests)
  │     │
  │     └─ Nein → weiter ↓
  │
  ├─ Hohe Volumina mit Cache-Potenzial & globaler Edge?
  │     │
  │     ├─ Ja  →  Cloudflare AI Gateway
  │     │         (DNS-Entry, 5 Min., sofort Logs & Cost-Caps)
  │     │
  │     └─ Nein → weiter ↓
  │
  └─ Default: Multi-Provider mit Quoten & Spend-Tracking
        │
        └─→  LiteLLM Proxy (+ optional Portkey für Governance)
             (OpenAI-kompatibel, 100+ Provider, Docker in 10 Min.)

Deployment-Decision: Self-Hosted vs. VPC vs. Managed vs. Hybrid vs. Air-Gapped

Bevor du dich für ein Produkt entscheidest, klär das Deployment-Modell. Es bestimmt Datenresidenz, Governance-Aufwand und Betriebskomplexität stärker als die Feature-Liste.

Start: Wo dürfen Prompts & Logs liegen?
  │
  ├─ Keine Daten dürfen das Rechenzentrum verlassen (Behörde, Klinik, Defense)?
  │     │
  │     └─ Ja → Air-Gapped (on-prem, kein Internet)
  │            Kandidaten: OpenClaw + Ollama/vLLM, Kong AI Gateway, LiteLLM
  │            Betrieb: hoch (Updates manuell, eigenes Monitoring)
  │
  ├─ Daten müssen in eigener Cloud-Tenant bleiben (Bank, Versicherung, Pharma)?
  │     │
  │     └─ Ja → VPC / Private Cloud (EU-Region, Customer-Managed Keys)
  │            Kandidaten: AWS Strands/Bedrock AgentCore, Kong (Self-hosted in VPC),
  │                        LiteLLM/Portkey in eigenem EKS/AKS/GKE
  │            Betrieb: mittel (Hyperscaler nimmt Infra-Last ab)
  │
  ├─ DSGVO-konform, aber Mischung aus sensiblen & generischen Prompts?
  │     │
  │     └─ Ja → Hybrid (Managed-Control-Plane + Self-hosted Data-Plane)
  │            Kandidaten: Portkey Hybrid, LiteLLM + Privacy Router,
  │                        Cloudflare AI Gateway mit EU-R2 + lokalem Fallback
  │            Betrieb: mittel (zwei Ebenen, klare Routing-Policies nötig)
  │
  ├─ Standard-SaaS, EU-Hosting reicht, Time-to-Value zählt?
  │     │
  │     └─ Ja → Managed (SaaS / Edge)
  │            Kandidaten: Portkey Cloud (EU), Cloudflare AI Gateway,
  │                        AWS Bedrock (Frankfurt)
  │            Betrieb: niedrig (DPA + Konfiguration, kein Infra-Betrieb)
  │
  └─ Volle Kontrolle, IaC-Pipelines, eigenes SRE-Team vorhanden?
        │
        └─ Ja → Self-Hosted (Docker/K8s im eigenen Cluster)
               Kandidaten: LiteLLM, Portkey OSS, Kong, OpenClaw + Ollama
               Betrieb: hoch (Updates, HA, Secrets-Rotation in eigener Hand)

Kriterien-Matrix:

Modell	Datenresidenz	Governance	Betriebskomplexität	Time-to-Value
Air-Gapped	100 % on-prem, kein Internet	Maximal (kein Drittlandtransfer, kein DPA nötig)	Sehr hoch (Updates, Monitoring, HA selbst)	Wochen
Self-Hosted	Eigener Cluster (EU/on-prem)	Hoch (volle Auditierbarkeit, eigene Keys)	Hoch (SRE-Team, IaC, Patch-Management)	Tage
VPC / Private Cloud	Eigener Hyperscaler-Tenant (EU-Region)	Hoch (CMK, IAM, CloudTrail/Audit-Logs)	Mittel (Infra vom Hyperscaler, Config selbst)	Tage
Hybrid	Sensible Pfade lokal, Rest Managed	Hoch (Routing-Policies + Audit auf beiden Ebenen)	Mittel (zwei Ebenen, klare Klassifizierung nötig)	Tage bis Wochen
Managed (SaaS/Edge)	Anbieter-Region (EU wählbar)	Mittel (DPA + Anbieter-Zertifizierungen)	Niedrig (nur Config & Keys)	Stunden

💡 Faustregel: Je strenger die Datenresidenz, desto höher die Betriebskomplexität. Hybrid ist der pragmatische Mittelweg, wenn nicht alle Prompts gleich sensibel sind – PII/Geheimnisse lokal, generische Cloud.

💡 Stack-Empfehlung Till Freitag: LiteLLM als Multi-Provider-Frontdoor + Portkey als Governance-Layer + Privacy Router für DSGVO-kritische Pfade. Sobald Microsoft Scout GA ist, lässt sich die Konfiguration mit überschaubarem Aufwand migrieren – Skills und MCP-Configs bleiben gleich.

Die sechs Alternativen im Detail – mit Enterprise-Workflows

LiteLLM Proxy – Die OpenAI-kompatible Multi-Provider-Frontdoor

Setup: ~10 Min. (docker run litellm/litellm oder pip install litellm). Hosting: self-hosted, EU-Hosting möglich. 100+ LLMs unter einer einheitlichen OpenAI-API.