AI Gateway vs. AI Control Plane
Die Begriffe werden austauschbar verwendet, was ein Problem ist, wenn man Infrastruktur spezifiziert. Der Unterschied ist kein Marketing — es geht darum, wo Entscheidungen getroffen werden und wofür sie gelten.
Das eine leitet Anfragen weiter. Das andere entscheidet, was eine Anfrage sein darf.
Ein AI Gateway
Stellt einen Endpunkt vor mehrere Anbieter. Es routet, hält Schlüssel, wiederholt, cached und macht Failover. Es löst ein Konnektivitäts- und Ausfallsicherheitsproblem — und zwar für jeden, der darauf zeigt.
Eine AI Control Plane
Entscheidet, was eine Anfrage sein darf, bevor sie eine wird: wer fragt, was er ausgeben darf, welche Daten das Haus verlassen dürfen, welches Modell sie bedienen darf und welchen Nachweis die Anfrage hinterlässt. Sie löst ein Governance-Problem für die Organisation, unabhängig davon, ob jede Anwendung mitgemacht hat.
Jede Control Plane enthält ein Gateway. Nicht jedes Gateway wird zur Control Plane — dafür müssen Identität, Budgets, Policy und Audit erstklassig im Anfrageweg liegen, statt daneben angeschraubt zu sein.
Wo die Grenze tatsächlich verläuft
| Achse | Gateway | Control Plane |
|---|---|---|
| Betrachtungseinheit | Eine Anfrage und eine Route | Eine Inference-Anfrage mit Kosten, Policy und Identität |
| Geltungsbereich | Die Services, die darauf zeigen | Jeder KI-Workload der Organisation |
| Die Befugnis eines Agenten | Ein Schlüssel, der gilt, bis ihn jemand rotiert | Eine Identität mit Verantwortlichem, Lauflimit, Werkzeug-Policy und benannter Freigabeinstanz |
| Durchsetzung | Hinweisend oder Limits pro Key | Im Anfrageweg, bevor der Anbieter kontaktiert wird |
| Erzeugter Nachweis | Traffic-Logs | Entscheidungen — Modell, Begründung, Bewertung, Kosten, Akteur |
| Betrieben von | Einem Team | Der Organisation, als gemeinsame Infrastruktur |
So erkennen Sie, was Sie haben
Nützlich bei der Bewertung jedes Anbieters dieser Kategorie, auch bei uns.
- Der Opt-in-Test. Wenn ein Team morgen einen Service hochfährt und es Ihnen nicht sagt — ist er gesteuert? Ein Gateway steuert, was darauf zeigt. Eine Control Plane steuert das, was die Organisation als verpflichtend festgelegt hat — und macht das Umgehen zur erkennbaren Ausnahme.
- Der Durchsetzungstest. Wenn ein Budget überschritten wird: hält etwas an, oder färbt sich ein Dashboard rot? Hinweisende Limits sind Reporting. Eine Control Plane lehnt den Aufruf ab, bevor der Anbieter kontaktiert wird.
- Der Nachweistest. Können Sie sechs Monate später rekonstruieren, welches Modell eine Anfrage bedient hat, warum, welche Policy-Bewertungen galten, was es gekostet hat und in wessen Auftrag? Ein Gateway protokolliert Traffic. Eine Control Plane erzeugt Entscheidungen.
Dieselben drei Ereignisse, zweimal
| Ereignis | Mit einem Gateway | Mit einer Control Plane |
|---|---|---|
| Die Ausgaben eines Teams verdoppeln sich über Nacht | Sie erfahren es aus der Anbieterrechnung oder aus einem Dashboard, das niemand beobachtet hat. Die Zuordnung wird zur Datenaufgabe. | Der Soft-Budget-Webhook hat an der Schwelle ausgelöst; das harte Limit hat die Überschreitung abgelehnt, bevor sie ausgegeben wurde — und nur gegen den Zähler dieses Teams. |
| Eine neue Regel zum Datenumgang wird erlassen | Sie wird zum Ticket für jedes Team, das Modelle aufruft, und danach dauerhaft zum Thema im Code-Review. | Eine Policy-Änderung greift für jeden Workload hinter dem Endpunkt gleichzeitig, auch für die, die niemand registriert hat. |
| Ein Agent ruft ein nicht freigegebenes Werkzeug auf | Der Werkzeugaufruf lief nie durch das Gateway, es gibt also keinen Nachweis, dass er stattgefunden hat. | Werkzeuge, die über den MCP-Endpunkt des Gateways erreicht werden, stehen auf einer Whitelist — der Aufruf wurde also abgelehnt und protokolliert. Ein Server, den der Client selbst betreibt, erscheint im Agenten-Inventar. |
Oft nicht
KI ist eine Funktion in einem Service, mit einem Anbieter und einem Team. Ein Gateway hat für diesen Fall die richtige Größe, und überdimensionierte Infrastruktur ist ein eigenes Risiko. Nichts von dem unten Genannten trifft auf Sie zu, und eine Control Plane zu früh einzuführen bringt vor allem Betriebsaufwand, den Sie nicht brauchen.
Wahrscheinlich schon, sobald eines davon zutrifft:
- Mehr als eine Handvoll Teams rufen Modelle auf.
- Ausgaben müssen Kostenstellen zugeordnet und nicht nur gedeckelt werden.
- Regeln zum Datenumgang müssen anwendungsübergreifend gelten, nicht pro Repository.
- Agenten rufen externe Werkzeuge mit echten Zugangsdaten auf.
- Sie müssen jemandem außerhalb der Technik nachweisen, dass KI-Nutzung gesteuert ist.
- Das Gateway ist tragend geworden — jeder Produktpfad hängt daran.
Eine Control Plane, die Sie betreiben
Wäg ist eine Open-Source-AI-Control-Plane, die in Ihrer eigenen Infrastruktur läuft. Sie enthält das Gateway — OpenAI-kompatibel, Multi-Provider, Caching, Failover — und ergänzt Identität, hierarchische Budgets, Policy, Agenten-Governance und Audit im selben Anfrageweg. Sie importiert LiteLLM-Konfiguration; wenn Sie bereits ein Gateway betreiben, kostet ein Test also eine Base-URL.
Ein Endpunkt. Jedes Modell. Volle Kontrolle.
Betreiben Sie es in Ihrer eigenen Infrastruktur
Alles, was Sie brauchen, um eine Control Plane produktiv zu betreiben, steht unter Apache-2.0 und bleibt es auch — Routing, HA, Caching, Failover, Budgets, Policy, MCP, Jobs und Observability. Self-hosted, ohne Account, ohne Phone-Home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Kein funktionierender Pull: Die Images sind noch nicht öffentlich. Designpartner erhalten die Registry-Details vertraulich.
In 5 Minuten deployenAls Design-Partner mitgestalten
Wäg ist noch nicht öffentlich verfügbar. Wir arbeiten mit einer kleinen Gruppe von Teams, die Multi-Provider-KI produktiv betreiben und Governance und Souveränität ernst nehmen, um die Control Plane an echten Workloads zu härten.
- Jede Enterprise-Funktion enthalten, ohne Lizenzkosten
- Migration gemeinsam mit uns — auch von LiteLLM
- Direkter Draht zu den Engineers und realer Einfluss darauf, was als Nächstes kommt