Jede KI-Codebasis erfindet dieselbe Schicht neu
Schauen Sie in eine beliebige Produktions-Codebasis, die OpenAI oder Anthropic aufruft, und Sie finden dasselbe selbstgebaute Geruest: hier ein Retry-Wrapper, dort ein Token-Zaehler, irgendwo eine Tabelle, die festhaelt, welches Team das Budget des letzten Monats verbrannt hat. Jedes Team baut diese Schicht — schlecht und unter Termindruck. Denn die Modell-API liefert Completions, und alles andere ist Ihr Problem.
Ein AI Gateway ist genau diese Schicht: einmal gebaut, als Infrastruktur betrieben. Dieser Beitrag erklaert, was ein AI Gateway wirklich ist, wie die Architektur funktioniert, welche Faehigkeiten zaehlen — und genauso ehrlich: wann Sie noch keins brauchen.
Was ist ein AI Gateway?
Ein AI Gateway ist eine Proxy-Schicht zwischen Ihrer Anwendung und den LLM-Anbietern. Statt api.openai.com oder api.anthropic.com direkt aufzurufen, sendet Ihre App Anfragen an das Gateway, das sie an den Anbieter weiterleitet — und auf dem Weg die Richtlinien anwendet, die Sie sonst im Anwendungscode implementieren muessten: Routing, Fallback, Kostenzuordnung, Sicherheits-Scans, Logging und Prompt-Management.
Die entscheidende Eigenschaft: Es arbeitet auf Netzwerkebene. Ihr Anwendungscode aendert sich kaum — typischerweise nur die Base-URL Ihres bestehenden SDKs:
import OpenAI from "openai";
import { clientOptions } from "@grepture/sdk";
// Vorher: direkter Aufruf an OpenAI
const openai = new OpenAI();
// Nachher: gleiches SDK, gleicher Code — geroutet durch das Gateway
const openai = new OpenAI(clientOptions());
Weil jede Anfrage durch eine Stelle fliesst, sieht das Gateway, was kein einzelner Dienst sehen kann: den gesamten KI-Traffic Ihrer Organisation — ueber Anbieter, Teams und Tools hinweg, einschliesslich der Aufrufe von Frameworks und Agenten, die Sie nicht selbst geschrieben haben.
Die Architektur: ein Hop im Anfragepfad
Ein Gateway fuegt genau einen Netzwerk-Hop hinzu:
Ihre App → AI Gateway → OpenAI / Anthropic / Google / ...
← ←
Auf dem Hinweg authentifiziert das Gateway den Aufrufer, wendet Sicherheitsrichtlinien an (PII-Redaktion, Secret-Scanning), waehlt Anbieter und Modell, haengt Kosten-Metadaten an und leitet die Anfrage weiter. Auf dem Rueckweg stellt es maskierte Werte wieder her, erfasst Tokens und Latenz und streamt die Antwort zurueck.
Zwei Dinge, die bei dieser Architektur Sorgen machen — und die ehrlichen Antworten:
- Latenz. Ein gut gebautes Gateway fuegt einstellige Millisekunden Verarbeitung hinzu. Gegen LLM-Inferenzzeiten im Sekundenbereich ist der Overhead Rauschen. (Regex-basiertes Scanning laeuft in unter 2 ms; die Modell-Inferenz dominiert.)
- Verfuegbarkeit. Das Gateway ist eine neue Abhaengigkeit im Hot Path. Das ist ein echter Punkt — deshalb gehoeren Gateway-Uptime, Self-Hosting-Optionen und ein Trace-only-Modus auf die Evaluations-Checkliste weiter unten.
Die fuenf Faehigkeiten, die zaehlen
Anbieter listen Dutzende Features. In der Praxis leisten fuenf Faehigkeiten die Arbeit.
1. Multi-Provider-Routing und Fallback
Anbieter haben Ausfaelle, Rate Limits und regionale Stoerungen. Bei direkter Integration ist ein OpenAI-Ausfall Ihr Ausfall. Ein Gateway verwaltet Keys fuer mehrere Anbieter und routet automatisch um — Fallback beim selben Anbieter (anderer Key, andere Region) oder anbieteruebergreifend (GPT down, Route zu Claude). Die Mechanik haben wir in unserem Beitrag zum Fallback-Routing beschrieben.
Routing entkoppelt ausserdem die Modellwahl vom Code. Das Standardmodell zu wechseln wird eine Gateway-Konfigurationsaenderung, kein Pull Request ueber zwoelf Services.
2. Kostenerfassung und Budgets
Anbieter-Dashboards zeigen, was die Organisation ausgegeben hat. Sie koennen nicht zeigen, welches Team, welches Feature, welches Projekt oder welcher Kunde es ausgegeben hat — der Anbieter sieht nur einen API-Key. Weil das Gateway im Anfragepfad sitzt, ordnet es jeden Token dem Verursacher zu: Kosten pro Anfrage, pro Team, pro Projekt, mit harten Budget-Limits, die unkontrollierte Ausgaben stoppen, statt sie erst nach der Rechnung zu melden.
3. Sicherheit und PII-Redaktion
Jeder Prompt sind Daten, die Ihre Infrastruktur verlassen. Namen, E-Mails, Zugangstokens und Kundendaten fliessen in Dritt-APIs, wenn nichts sie aufhaelt. Auf Gateway-Ebene wird jede Anfrage gescannt — PII redaktiert (reversibel, damit Antworten personalisiert bleiben), Credentials blockiert, Prompt Injections markiert — unabhaengig davon, welcher Entwickler, welches Framework oder welcher Agent den Aufruf gemacht hat. Das verdient eine eigene Diskussion: siehe was ein sicheres LLM-Gateway wirklich erfordert.
4. Observability und Tracing
Wenn ein KI-Feature sich falsch verhaelt, lautet die erste Frage: "Was haben wir eigentlich gesendet und empfangen?" Ohne Gateway liegt die Antwort verstreut in Anwendungslogs — wenn ueberhaupt. Ein Gateway protokolliert jede Anfrage und Antwort — Modell, Tokens, Latenz, Kosten, vollstaendige Payloads mit redaktierten sensiblen Daten — und liefert Traces auf Anfrageebene ueber alle Anbieter hinweg an einem Ort.
5. Prompt-Management
Prompts sind Logik, aber die meisten Teams shippen sie als String-Literale. Ein Gateway kann Prompts vom Code trennen: versioniert, ohne Deployment aenderbar, testbar gegen Produktions-Traffic. Das wird wichtiger, sobald Nicht-Entwickler Prompt-Qualitaet verantworten.
AI Gateway vs. API Gateway
Die Namenskollision stiftet echte Verwirrung. Ein API Gateway (Kong, Apigee, AWS API Gateway) verwaltet Traffic, der in Ihre Dienste hineinkommt: Authentifizierung, Rate Limiting, Routing fuer Ihre eigenen APIs. Ein AI Gateway verwaltet Traffic, der hinaus zu LLM-Anbietern geht — und es ist inhaltsbewusst auf eine Art, die API Gateways nicht sind: Es parst Prompts und Completions, zaehlt Tokens, redaktiert PII in Nachrichteninhalten und versteht Streaming-Antworten in den Wire-Formaten von OpenAI und Anthropic.
Sie koennen Kong nicht beibringen, einen Kundennamen in einer Chat Completion reversibel zu maskieren. Andere Schicht, anderer Job. Beide koexistieren problemlos: API Gateway an der Eingangstuer, AI Gateway auf dem Weg nach draussen.
AI Gateway vs. direkte API-Aufrufe
Direkte Aufrufe sind einfacher — bis die Skalierung sie teuer macht: Keys vermehren sich in .env-Dateien, Ausgaben werden nicht zuordenbar, Sicherheit haengt davon ab, dass jeder Entwickler ans Bereinigen denkt, und ein Anbieterausfall legt Ihre Features lahm. Die vollstaendige Abwaegung steht in Warum Teams ein AI Gateway brauchen.
Wann Sie keins brauchen
Ehrlichkeit vor Kategorie-Marketing:
- Ein Prototyp oder Side-Project mit einem Entwickler und einem Anbieter — das Gateway loest Probleme, die Sie noch nicht haben.
- Keine sensiblen Daten und vernachlaessigbare Ausgaben — wenn Prompts nichts Persoenliches enthalten und die Rechnung Kleingeld ist, reichen direkte Aufrufe.
- Eine einzelne, stark angepasste Inferenz-Pipeline — wer eigene Modelle auf eigenen GPUs betreibt, braucht MLOps-Tooling, kein Gateway.
Die Ausloeser, die die Antwort aendern: Ein zweites Team beginnt, LLMs aufzurufen, Kundendaten landen in Prompts, die Monatsrechnung braucht eine Erklaerung, oder ein Anbieterausfall wird zum kundensichtbaren Incident. Die meisten Teams erreichen einen dieser Punkte wenige Monate nach dem ersten KI-Feature.
Wie man ein AI Gateway evaluiert
Die Fragen, die in der Praxis den Unterschied machen:
- Latenz-Overhead — gemessen, nicht behauptet. Fragen Sie nach der zusaetzlichen p99-Latenz mit aktiviertem Sicherheits-Scanning.
- Fehlerverhalten — wenn das Gateway ausfaellt: schlagen Ihre KI-Aufrufe fehl, laufen sie ungeschuetzt weiter, oder greift ein Fallback? Gibt es einen Trace-only-Modus, der beobachtet, ohne im Hot Path zu sitzen?
- Sicherheitstiefe — ist die PII-Redaktion reversibel? Werden Secrets und Credentials gescannt, nicht nur Namen und E-Mails? Wo laufen die Erkennungsmodelle?
- Datenresidenz und Aufbewahrung — wo werden Logs gespeichert, lassen sich Payloads ausschliessen, gibt es eine EU-Hosting-Option und einen Zero-Retention-Modus?
- Anbieterabdeckung — die Anbieter und Wire-Formate, die Sie tatsaechlich nutzen, inklusive Streaming.
- Offenheit — koennen Sie den Quellcode lesen? Koennen Sie selbst hosten, wenn sich die Anforderungen aendern?
- Preisstruktur — vorhersehbare Preise pro Anfrage, mit einem kostenlosen Tarif zum Evaluieren auf echtem Traffic.
Fuer einen Vergleich von Gateways mit angrenzendem Security-Tooling — DLP, Guardrail-Bibliotheken, inhaltsbewusste Proxies — siehe unseren Vergleich der LLM-Security-Tools.
Wie Grepture hilft
Grepture ist ein AI Gateway, gebaut in der Reihenfolge, die zaehlt: Sicherheit zuerst, dann der Rest der Schicht. Es begann als PII-Redaktions-Proxy und wuchs zum vollstaendigen Gateway — reversible Redaktion, Secret-Scanning, Multi-Provider-Fallback-Routing, Kostenerfassung pro Team und harte Budget-Limits, Request-Tracing und Prompt-Management, hinter einer einzigen Base-URL-Aenderung.
Der Proxy-Kern ist Open Source, der verwaltete Dienst ist EU-gehostet in Frankfurt, und der kostenlose Tarif (1.000 Anfragen/Monat, keine Kreditkarte) reicht, um auf echtem Traffic zu evaluieren.
Wichtigste Erkenntnisse
- Ein AI Gateway ist ein Proxy zwischen App und LLM-Anbietern, der Routing, Kostenzuordnung, Sicherheit, Observability und Prompt-Management zentralisiert — meist ueber eine einzeilige Base-URL-Aenderung.
- Es ist kein API Gateway. API Gateways verwalten eingehenden Traffic zu Ihren Diensten; AI Gateways verwalten ausgehenden LLM-Traffic und verstehen Prompts, Tokens und Streaming-Formate.
- Fuenf Faehigkeiten tragen den Wert: Multi-Provider-Fallback, Kostenerfassung mit Budgets, PII-/Secret-Scanning, Request-Tracing und Prompt-Management.
- Am Anfang kann man drauf verzichten — ein Entwickler, ein Anbieter, keine sensiblen Daten. Die Rechnung dreht sich, wenn Teams sich vervielfachen, Kundendaten in Prompts landen oder ein Ausfall zum Incident wird.
- Evaluieren Sie nach Latenz-Overhead, Fehlerverhalten, Sicherheitstiefe und Datenresidenz — dort liegen die Unterschiede zwischen Gateways, nicht in Feature-Listen.