AI Gateway: Definition, Funktionen und Abgrenzung 2026

Ein AI Gateway ist eine zentrale Zwischenstation zwischen den eigenen Anwendungen und Sprachmodellen (Large Language Models, kurz LLMs, die Modelle hinter ChatGPT, Claude oder Gemini). Statt dass jede Anwendung direkt mit jedem Modell-Anbieter spricht, geht jede Anfrage erst durch den Gateway. Der prüft, wer fragt (Login und Zugriffskontrolle), wie oft gefragt werden darf (Nutzungsgrenzen), welche Anwendung welche Kosten verursacht (Kostenzuordnung), was der Anfrage- und Antworttext enthalten darf (Inhalts-Filter, oft „Guardrails" genannt) und an welches Modell die Anfrage geht (Modell-Auswahl und Ersatz-Route bei Ausfall).

Was ist ein AI Gateway?

Ein AI Gateway ist die Kontrollstelle vor dem Sprachmodell. Anwendungen sprechen nur mit dem Gateway und wissen weder, welcher Anbieter dahintersteht, noch besitzen sie dessen Zugangsschlüssel. Hinter dem Gateway können viele verschiedene Modelle stehen: von Anbietern gehostete Modelle (OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock), im eigenen Haus betriebene offene Modelle und intern angepasste (feingetunte) Varianten. Der Gateway leitet jede Anfrage an das passende Modell weiter und liefert die Antwort zurück.

Der Begriff hat sich 2024/2025 als eigene Kategorie etabliert, weil produktive LLM-Landschaften mehrere Anwendungen und mehrere Provider parallel betreiben. Ohne Vermittlungsschicht entstehen Keys, Logs, Rate-Limits, Content-Filter und Kostenzuordnung pro Anwendung neu. Databricks führt den Mosaic AI Gateway als Bestandteil des Model-Serving-Stacks; Open-Source-Projekte wie LiteLLM und Kong AI Gateway sowie kommerzielle Angebote wie Portkey und Azure API Management for AI besetzen dieselbe Position.

Sechs Funktionen tragen einen produktiven Gateway. Auth und Key-Management ersetzen dezentrale Provider-Keys durch Gateway-Tokens pro App oder Team. Rate-Limits greifen pro Nutzer, App oder Kostenstelle und schützen vor Runaway-Kosten. Kostenzuordnung verknüpft Token-Verbrauch mit Metadaten (App-ID, Team, Umgebung) und macht LLM-Kosten pro Anwendungsfall sichtbar. Guardrails filtern PII, prüfen gegen Themen-Blocklisten und wenden Content-Moderation auf Prompts und Antworten an. Semantic Caching erkennt semantisch identische Anfragen und liefert eine gespeicherte Antwort, was Kosten und Latenz senkt. Modell-Routing und Fallback verteilen zwischen Modellen (starkes Modell für komplexe, günstiges für einfache Aufrufe) oder leiten bei Provider-Ausfall auf einen definierten Ersatz um.

Zusätzlich schreibt der Gateway einen strukturierten Audit-Trail: Prompt, Antwort, Modell, Token-Verbrauch, Latenz und App-Metadaten laufen in eine Observability-Plattform. Dieser Trail deckt Anforderungen aus EU AI Act (Aufzeichnungspflichten in Artikel 12) und ISO 42001 auf der Zugriffs-Ebene ab, ohne dass jede Anwendung eigenes Logging bauen muss.

Abgrenzung zu API-Gateway, Model Serving und Agent Routing

Der Begriff wird häufig mit angrenzenden Komponenten vermischt. Die folgende Tabelle ordnet die Unterschiede ein:

Komponente	Ebene im Stack	Kern-Funktion
AI Gateway	Vermittlung vor der Modell-Inferenz	Auth, Rate-Limits, Kostenzuordnung, Guardrails, Multi-Provider-Routing für LLM-Aufrufe
API-Gateway (klassisch)	Netzwerk-/App-Ebene	Schützt beliebige HTTP-APIs; kennt weder Token-Kosten noch Prompt-Semantik
Model Serving	Inferenz-Ebene	Hostet die Modell-Inferenz selbst (Endpoints, Skalierung, GPU-Zuweisung)
Agent Routing	Kontrollfluss in Multi-Agent-Systemen	Verteilt zwischen spezialisierten Agenten oder Rollen, nicht zwischen Modell-Providern
LLMOps	Betriebs-Rahmen	Umfasst Eval, Deployment, Drift, Governance für den gesamten LLM-Lifecycle

Ein klassisches API-Gateway (Kong, NGINX, Azure APIM) kann HTTP-APIs schützen und routen, versteht aber keine Prompts, keine Token-Semantik und keine LLM-spezifischen Kostenmodelle. Model Serving liegt eine Ebene tiefer und stellt die eigentliche Inferenz bereit; der AI Gateway ruft Serving-Endpoints oder Provider-APIs auf. Agent Routing arbeitet auf semantischer Ebene innerhalb eines Multi-Agenten-Systems und entscheidet, welcher Agent den nächsten Schritt macht. Der AI Gateway sitzt unter dieser Entscheidung und stellt die Modell-Aufrufe bereit, die der gewählte Agent auslöst. LLMOps schließlich ist der übergeordnete Betriebs-Rahmen; der Gateway ist eine Komponente darin.

Beispiel: drei GenAI-Anwendungen mit gemeinsamem Gateway

Ein Unternehmen betreibt einen internen Wissensassistenten, eine Vertragsanalyse und einen Support-Copilot. Ohne Gateway pflegt jedes Team eigene OpenAI- und Anthropic-Keys, eigene Rate-Limits und eigenes Prompt-Logging. Die Modellrechnung erscheint als Sammelposten, ohne Zuordnung zu Anwendung oder Kostenstelle. Ein Modellwechsel bedeutet, dass jede Anwendung einzeln angepasst wird.

Mit AI Gateway laufen alle drei Anwendungen gegen einen gemeinsamen Endpoint. Der Gateway prüft das App-Token, wendet einen PII-Filter auf Prompts vor externem Provider-Aufruf an, schreibt Prompt und Antwort mit App-ID und Team-Metadaten in ein Audit-Log und ordnet Token-Verbrauch der Kostenstelle zu. Fällt ein Provider aus, greift die konfigurierte Fallback-Route zum Ersatzmodell. Ein Modellwechsel für die Vertragsanalyse wird als Routing-Regel am Gateway umgestellt, ohne dass Code in der Anwendung geändert wird.