Was ein AI Gateway technisch ist

Ein AI Gateway ist eine zentrale Vermittlungsschicht zwischen den eigenen Anwendungen und den genutzten Modellen. Statt dass jede Anwendung direkt mit der API eines Anbieters spricht, geht jeder Aufruf über das Gateway. Das Gateway leitet ihn an das passende Modell weiter, protokolliert den Vorgang, prüft Berechtigungen, zählt Verbrauch und kann bei Bedarf Antworten zwischenspeichern.

Architektonisch ist das Muster vergleichbar mit einem klassischen API-Gateway, nur mit zusätzlicher Logik, die für LLM-Aufrufe relevant ist: Token-Buchhaltung, Modell-Routing, Prompt- und Antwort-Caching, Streaming-Unterstützung, Anbieter-Abstraktion. Der Begriff „LLM Router" wird häufig im selben Sinn benutzt und betont die Routing-Funktion — die zentrale Frage, welcher Aufruf bei welchem Modell landet.

Wichtig ist: Ein AI Gateway ist keine eigene KI. Es ist Infrastruktur. Die inhaltliche Qualität der Anwendung entsteht weiterhin im Modell und in der Anwendungslogik. Was das Gateway leistet, ist Beherrschbarkeit jenseits der einzelnen Anwendung.

Drei Probleme, die ein AI Gateway tatsächlich löst

In Pitches wird einem AI Gateway gerne alles Mögliche zugeschrieben. In der Praxis sind drei Klassen von Problemen, die diese Schicht tatsächlich entschärft.

Erstens Anbieter-Lock-in. Wenn jede Anwendung direkt mit einem bestimmten Modellanbieter spricht, ist der Wechsel zu einem anderen Anbieter eine Migration in jeder einzelnen Anwendung. Mit einem Gateway dazwischen wird dieser Wechsel zu einer Konfigurationsänderung — vorausgesetzt, die Anwendungen reden wirklich mit dem Gateway, nicht durchgriffen. Welche Trade-offs zwischen Anbietern zu beachten sind, haben wir im Beitrag zur LLM-Auswahl für Unternehmen ausgeführt.

Zweitens Multi-Modell-Routing. Sobald ein Unternehmen mehr als ein Modell sinnvoll nutzt — kleines Modell für Routine, großes Modell für anspruchsvolle Aufgaben, Reasoning-Modell für mehrstufige Analyse — wird das Gateway zu dem Ort, an dem die Routing-Logik sinnvoll lebt. Diese Disziplin überschneidet sich direkt mit dem Modell-Tiering aus dem Beitrag zur LLM-Kostenoptimierung und wird im Reasoning-Kontext besonders wirksam, wo der Kostenunterschied zwischen Modellklassen am größten ist.

Drittens Beobachtbarkeit, Berechtigungen und Kostensteuerung quer über Anwendungen. Eine Statistik pro Anwendung sagt wenig; eine zentrale Sicht auf den gesamten Modellverbrauch zeigt, wo Geld entsteht, welche Teams welche Modelle nutzen und welche Aufrufmuster sich verschieben. Genauso lassen sich Berechtigungen — wer darf welches Modell mit welchen Kontingenten nutzen — sauber durchsetzen, wenn sie an einer einzigen Stelle sitzen.

Wann sich ein AI Gateway lohnt

Ein AI Gateway ist kein Selbstzweck. Drei Konstellationen sprechen ehrlich für die Investition.

Die erste ist mehrere produktive LLM-Anwendungen im Haus. Sobald zwei oder mehr Anwendungen Modelle aufrufen — und sei es nur eine produktive plus mehrere im Aufbau — entsteht ein Bedarf an gemeinsamer Sicht und gemeinsamer Steuerung. Mit einer einzigen Anwendung ist ein Gateway selten gerechtfertigt.

Die zweite ist absehbarer Modell- oder Anbieterwechsel. Wenn klar ist, dass die heutige Modellwahl in zwölf Monaten nicht mehr die richtige sein wird — wegen Preis, Qualität, Hosting-Anforderungen oder neuen Modellklassen — sollte der Wechsel keine Migration in jeder Anwendung sein. Ein Gateway hält diese Option offen.

Die dritte ist Compliance- und Berechtigungs-Anforderungen über mehrere Teams hinweg. Wenn unterschiedliche Bereiche unterschiedliche Modelle, Limits oder Datenflusswege nutzen sollen, ist eine zentrale Durchsetzung pragmatischer als dieselbe Logik in jeder Anwendung neu zu bauen.

In allen anderen Fällen ist ein Gateway zu früh. Eine erste Anwendung sollte sauber und ohne unnötige Zwischenschicht gebaut werden — der Aufwand für ein Gateway zahlt sich erst aus, wenn er auf mehrere Konsumenten verteilt werden kann.

Was im Gateway sitzen sollte — und was nicht

Ein verbreiteter Fehler ist, einem Gateway Aufgaben zuzuweisen, die nicht in eine generische Vermittlungsschicht gehören. Vier Funktionen sitzen dort gut.

Modell-Routing: Welche Anwendung darf welches Modell ansprechen, wann wird automatisch auf ein günstigeres Modell ausgewichen, wann auf einen Fallback bei Anbieter-Ausfall. Authentifizierung und Berechtigungen: Welche Anwendung — oder welcher Nutzer hinter der Anwendung — darf wie viele Aufrufe pro Zeit machen, welche Modelle sind freigeschaltet, welche Inhalte sind ausgeschlossen. Beobachtbarkeit: Vollständige Aufrufe-Logs, Token-Verbrauch, Latenz, Cache-Treffer, Fehlerquoten, Aufschlüsselung nach Anwendung und Modell. Caching: Wo dieselben Anfragen wiederkehren — etwa stabile System-Prompts, oft gestellte Fragen — kann das Gateway Antworten zwischenspeichern, mit klarer Cache-Invalidierungslogik.

Was dort schlecht aufgehoben ist, sind fachliche Logik, Wissensanbindung und anwendungsspezifische Sicherheit. RAG-Logik, Tool-Use-Definitionen, Agent-Steuerung und Anwendungsverhalten gehören in die jeweilige Anwendung — nicht in das Gateway. Ein Gateway, das diese Aufgaben übernimmt, wird zu einem Monolithen, der schwer zu pflegen ist und in dem alle Anwendungen voneinander abhängen.

Eine sinnvolle Faustregel: Was sich in jeder Anwendung gleich anfühlen sollte (Routing, Auth, Logging, Caching), gehört in das Gateway. Was sich pro Anwendung unterscheidet (Wissen, Werkzeuge, Geschäftslogik), gehört in die Anwendung.

Architekturmuster: zentral, dezentral, hybrid

In der Praxis sind drei Muster verbreitet. Welches passt, hängt am Reifegrad und der organisatorischen Struktur.

Zentrales Gateway: Eine Instanz, die alle LLM-Aufrufe im Unternehmen entgegennimmt. Maximale Beobachtbarkeit, einfachste Steuerung — aber ein neuer Single Point of Failure. Wenn das Gateway ausfällt, fallen alle KI-Anwendungen aus. Hochverfügbarkeit ist hier Pflicht, nicht Komfort.

Dezentrales Modell mit gemeinsamer Bibliothek: Jede Anwendung betreibt ihre eigene Vermittlungslogik, geteilte Funktionen kommen aus einer internen Bibliothek. Robust gegen Ausfälle, dafür schwächer in zentralen Auswertungen — und mit dem Risiko, dass die Bibliothek über Anwendungen hinweg auseinanderläuft.

Hybride Architektur: Ein zentrales Gateway für die meisten Aufrufe, mit klar definierten Ausnahmen für Anwendungen mit besonderen Anforderungen — etwa Echtzeit-Aufrufe ohne Gateway-Latenz oder isolierte Bereiche mit eigenem Datenfluss. Dieses Muster ist in den meisten reiferen Setups die ehrlichste Antwort.

Welche Variante passt, hängt eng mit der Frage zusammen, wo die genutzten Modelle laufen. Die Diskussion aus On-Premises vs. Cloud-LLMs verschiebt sich beim Gateway-Thema nicht — sie wird nur an einer Stelle verankert, statt in jeder Anwendung neu beantwortet zu werden.

Build vs. Buy: eigenes Gateway oder kommerzielle Lösung

Mit Portkey, Cloudflare AI Gateway, Helicone, OpenRouter und einer wachsenden Zahl anderer Anbieter ist die Frage „selbst bauen oder einkaufen" auch hier real. Die ehrliche Antwort hängt am Reifegrad des Programms und an den eigenen Anforderungen.

Kommerzielle Gateways sind sinnvoll, wenn die eigenen Anforderungen sich gut mit einem Standardprodukt decken. Sie liefern in Tagen statt Wochen funktionsfähige Beobachtbarkeit, Routing und Caching — und nehmen die Last der Wartung ab. Die Trade-offs sind dieselben wie in jedem Build-vs.-Buy-Vergleich: Lock-in an einen Gateway-Anbieter, eingeschränkte Anpassbarkeit, möglicher zusätzlicher Datenfluss zu einem dritten Anbieter — der genau geprüft sein sollte, wenn sensible Inhalte verarbeitet werden.

Eigenes Gateway ist sinnvoll, wenn besondere Anforderungen bestehen — etwa eigene Hosting-Vorgaben, sehr spezielle Routing-Logik, tief integrierte interne Auth-Systeme oder regulatorische Anforderungen, die ein externer Anbieter nicht erfüllen kann. Eigenbau bedeutet allerdings auch eigenen Lebenszyklus: Modell-Anbindungen, Authentifizierung, Logging, Performance — alles im Haus zu pflegen.

Eine pragmatische Mischung ist häufig der schnellste Weg: Ein kommerzielles Gateway für den ersten Schritt, mit der bewussten Architekturentscheidung, dass Anwendungen es so ansprechen, dass eine spätere Migration ohne Anwendungsumbau möglich bleibt.

Beobachtbarkeit, Caching und Kostensteuerung im Detail

Ein gut gebautes Gateway zeigt im Alltag drei Vorteile, die jeden für sich die Investition rechtfertigen können — gemeinsam aber den eigentlichen Wert ausmachen.

Beobachtbarkeit auf Anwendungsebene: Token-Verbrauch pro Anwendung, pro Use Case, pro Nutzergruppe. Welche Modelle werden tatsächlich genutzt, welche Aufrufmuster verschieben sich, wo entstehen Ausreißer. Diese Sicht ist die Grundlage jeder ernsthaften Optimierung — die Disziplin überschneidet sich direkt mit LLM-Monitoring und Observability, mit dem Unterschied, dass das Gateway die zentrale Datenquelle dafür liefert.

Caching mit klarer Invalidierungslogik. Stabile System-Prompts, wiederkehrende Anfragen und identische Embedding-Aufrufe lassen sich zwischenspeichern — mit klarem Verständnis, wann eine zwischengespeicherte Antwort ungültig wird. Caching ist im Gateway besonders wirksam, weil es über Anwendungen hinweg greifen kann.

Limits und Budgets. Pro Anwendung, pro Nutzergruppe, pro Zeitraum lassen sich harte Grenzen setzen — als Schutz gegen Ausreißer, als Budget- Disziplin und als Sicherheitsnetz gegen Schleifen in agentischen Setups, wie wir sie im Beitrag zur LLM-Kostenoptimierung beschrieben haben.

Typische Fehler in den ersten Gateway-Projekten

Der häufigste Fehler ist, ein Gateway zu früh aufzusetzen. Eine einzelne Anwendung mit einer einzigen Modellanbindung braucht keine Vermittlungsschicht — das Gateway wird hier zur Komplexität ohne Gegenwert.

Der zweite Fehler ist, dem Gateway zu viel zu geben. Wer fachliche Logik, Wissensanbindung oder agentische Orchestrierung dort einbaut, baut einen Monolithen, an dem mit der Zeit alle Anwendungen hängen. Eine klare Trennung zwischen Vermittlungsschicht und Anwendungslogik ist Pflicht.

Der dritte Fehler ist, das Gateway als Single Point of Failure zu unterschätzen. Wenn alle KI-Anwendungen darüber laufen, gehört Hochverfügbarkeit in die erste Version — nicht in eine spätere Härtungsphase.

Der vierte Fehler ist, Caching unkontrolliert zu aktivieren. Ein Cache, der Inhalte zwischen Mandanten oder Berechtigungsstufen mischt, ist ein ernsthaftes Problem. Cache-Schlüssel müssen die relevanten Sicherheitsdimensionen einschließen — Nutzer, Mandant, Berechtigungsbereich.

Der fünfte Fehler ist, das Gateway gegen die Anwendungs-Teams einzuführen. Eine zentrale Schicht, die Geschwindigkeit aus den Teams herausnimmt, wird umgangen — entweder offen oder still durch direkte Aufrufe. Das Gateway muss als Werkzeug für die Teams gestaltet sein, nicht als Kontrollinstrument gegen sie.

Wie das Gateway in eine breitere KI-Plattform passt

Ein AI Gateway ist eine von mehreren Schichten in einer reifen KI-Architektur. Es sitzt nicht allein da, sondern zwischen den Anwendungen und den Modellen. Andere Schichten — die Werkzeug-Anbindung, die Wissensschicht, die Beobachtungsschicht — haben ihre eigenen Verantwortungen.

Die Werkzeug-Anbindung wird in vielen Setups über das Model Context Protocol standardisiert — ein Standard für die Verbindung zwischen Anwendungen und Tools, während das Gateway den Weg zu den Modellen vereinheitlicht. Beide Schichten ergänzen sich, lösen aber unterschiedliche Probleme. Wer beide bewusst aufbaut, bekommt eine Plattform, die mit dem Programm wächst.

Diese Plattform-Sicht ist eng mit der Frage verbunden, welche Rollen ein wachsendes KI-Team im Unternehmen braucht — eine Plattform-Verantwortung gehört spätestens in der zweiten Phase ausdrücklich besetzt, nicht in der ersten.

Wann externe Unterstützung sinnvoll ist

Für eine erste Anwendung mit klar geschnittenem Modellbedarf ist ein Gateway verfrüht — und externe Unterstützung dafür ohnehin nicht nötig. Sobald aber zwei oder mehr produktive Anwendungen laufen, ein Modell- oder Anbieterwechsel absehbar ist oder mehrere Teams parallel KI-Werkzeuge bauen, lohnt sich ein gezielter Blick von außen — auf Schnitt, Architektur, Build-vs-Buy und Beobachtbarkeit.

Wir arbeiten mit Unternehmen, die KI nicht als einzelnen Use Case, sondern als wachsendes Portfolio verstehen. Wenn das zu Ihrer Situation passt, sprechen Sie uns an — am besten bevor das Gateway-Thema entweder zu früh oder zu spät angegangen wird. Den passenden Rahmen dafür bieten wir über AI Engineering und unser AI Consulting.