Ein AI Gateway ist kein zusätzlicher API-Endpunkt um seiner selbst willen. Es ist die Stelle, an der ein Unternehmen Modellzugriffe vereinheitlicht und Regeln durchsetzt, bevor Daten einen Provider erreichen. Ohne diese Schicht entstehen direkte Integrationen mit unterschiedlichen Schlüsseln, Logging-Formaten, Fallbacks und Kostenmodellen.
Cloudflare meldete am 24. Juli 2026 die Verfügbarkeit eines weiteren Anthropic-Modells über sein AI Gateway. Solche Ankündigungen zeigen, wie schnell sich das Providerangebot verändert. Die Architekturfrage ist deshalb nicht, welches Modell heute das beste ist. Entscheidend ist, ob neue Modelle kontrolliert aufgenommen und wieder entfernt werden können.
Was gehört vor den Modellaufruf?
Ein Gateway sollte mindestens folgende Entscheidungen treffen:
- Wer oder welcher Dienst stellt die Anfrage?
- Für welchen Workflow und Kunden entsteht sie?
- Welche Datenklasse enthält der Request?
- Welche Modelle und Regionen sind erlaubt?
- Welches Budget und welche Rate Limits gelten?
- Welche Logs dürfen gespeichert werden?
Diese Informationen müssen vor dem Routing verfügbar sein. Nachträgliche Kostenzuordnung kann fehlende Identität oder Datenklassifikation nur schwer reparieren.
Eine gemeinsame Schnittstelle, aber keine falsche Gleichheit
Ein einheitliches API-Format reduziert Integrationsaufwand. Modelle bleiben trotzdem verschieden. Tool Calling, strukturierte Ausgaben, Kontextfenster, Caching, Sicherheitsfilter und Fehlermeldungen unterscheiden sich.
Das Gateway sollte Providerunterschiede sichtbar machen, statt sie vollständig zu verstecken. Definieren Sie einen gemeinsamen Kern und behandeln Sie providerspezifische Fähigkeiten als explizite Optionen. Sonst wird Portabilität nur behauptet.
Routing und Policy trennen
Routing entscheidet, welches Modell eine Aufgabe erhält. Policy entscheidet, welche Auswahl überhaupt zulässig ist. Ein günstiges Modell darf zum Beispiel für eine öffentliche Zusammenfassung erlaubt sein, aber nicht für vertrauliche Personendaten oder einen Workflow mit festgelegter Region.
Diese Trennung erleichtert Audits. Sie können zeigen, dass eine Route nicht nur technisch funktionierte, sondern den freigegebenen Regeln entsprach.
Fallbacks brauchen Grenzen
Automatische Fallbacks erhöhen Verfügbarkeit, können aber Kosten, Datenpfad und Qualität verändern. Ein Wechsel zu einem anderen Provider ist keine neutrale technische Wiederholung.
Definieren Sie pro Route:
- welche Provider als Fallback erlaubt sind,
- ob dieselbe Datenregion eingehalten wird,
- welche Qualitätsgrenze gelten muss,
- wie oft wiederholt werden darf,
- wann der Workflow kontrolliert scheitert.
Manche Prozesse sollen lieber stoppen als unbemerkt einen anderen Datenpfad zu verwenden.
Observability ab der ersten Anfrage
Jede Anfrage braucht eine Trace-ID sowie Zuordnung zu Workflow, Modell, Provider und Ergebnisstatus. Erfassen Sie Latenz, Tokens, Cache-Status, Retries und Kosten. Für Agenten kommen Tool-Aufrufe und Stopbedingungen hinzu.
Das Ziel ist nicht ein möglichst dichtes Dashboard. Es ist eine nachvollziehbare Antwort auf die Frage, welcher Workflow mit welcher Qualität welche Kosten erzeugt hat.
Gateway-Ausfall und Exit mitplanen
Das Gateway wird zu kritischer Infrastruktur. Planen Sie Hochverfügbarkeit, Konfigurationsversionen, Rollback und einen sicheren Degradationsmodus. Ebenso wichtig ist der Exit: Routen, Prompts, Evaluationssets und Logs sollten exportierbar sein.
Ein Gateway reduziert Abhängigkeit von Modellprovidern, kann aber eine neue Abhängigkeit vom Gateway-Anbieter schaffen. Prüfen Sie beide Ebenen.
Quellen
- Cloudflare AI Gateway Documentation: https://developers.cloudflare.com/ai-gateway/
- LiteLLM Proxy Documentation: https://docs.litellm.ai/docs/simple_proxy
- OpenTelemetry Traces: https://opentelemetry.io/docs/concepts/signals/traces/
- Cloudflare Developers auf X, 24. Juli 2026: https://x.com/CloudflareDev/status/2080755723860901977
Nächster Schritt
Erfassen Sie alle direkten Modellintegrationen, API-Schlüssel und Fallbackregeln. Wählen Sie danach einen Workflow für den Gateway-Pilot und definieren Sie Identität, Datenklasse, erlaubte Provider, Budget, Logging und Abbruchverhalten vor der technischen Integration.