Cloudflare vereint Workers AI und AI Gateway: Was jetzt zu tun ist

Cloudflare führt Workers AI und AI Gateway in einem gemeinsamen Control Plane zusammen. Workers AI stellt gehostete Modelle auf Cloudflares GPU-Infrastruktur bereit; AI Gateway vermittelt Anfragen an Modellanbieter und ergänzt Beobachtbarkeit, Logging, Zugriff und Sicherheitsfunktionen. Für Unternehmen soll daraus ein einheitlicher Weg zu Cloudflare-Modellen und externen Anbietern entstehen, inklusive gemeinsamer Steuerung von Kosten, Sicherheit und Betrieb.

Ein Teil dieser Vereinheitlichung ist bereits verfügbar: Das AI Binding und die REST API führen Anfragen an AI Gateway und Workers AI über denselben Pfad. Ein Standard-Gateway kann beim ersten authentifizierten Aufruf automatisch entstehen. Ebenfalls verfügbar ist die Nutzung von AI-Gateway-Guthaben für Workers AI. Model-first Routing und Smart Routing beschreibt Cloudflare dagegen als kommende beziehungsweise noch intern erprobte Funktionen. Sie dürfen heute nicht als produktive Zusage eingeplant werden.

Was das vereinte Control Plane heute verändert

Unternehmen müssen nicht mehr zuerst zwischen einem direkten Workers-AI-Aufruf und AI Gateway als separatem Produktpfad wählen. Über das AI Binding lässt sich Workers AI mit einer Gateway-ID ansprechen; Cloudflare nennt außerdem einen gemeinsamen REST-Pfad unter /ai/. Wer die ID default verwendet und noch kein Gateway eingerichtet hat, erhält laut Anbieter beim ersten authentifizierten Aufruf automatisch ein Standard-Gateway.

Dieses Standard-Gateway protokolliert vollständige Anfrage- und Antwortinhalte, zählt Tokens je Modell und ordnet Kosten zu. Im Dashboard werden unter anderem Latenzen, Tokenverbrauch und Fehlerraten sichtbar. Das verbessert Fehlersuche und Kostenkontrolle, schafft aber zugleich einen neuen Datenbestand mit möglicherweise vertraulichen Prompts und Ergebnissen. Logging muss deshalb vor dem Rollout als Datenschutz- und Sicherheitsentscheidung behandelt werden.

• Standard-Gateway nutzen, wenn ein schneller Einstieg in Logging und Kostenattribution wichtiger ist als eine feingranulare Projekttrennung.
• Benannte Gateways anlegen, wenn Anwendungen, Teams, Datenklassen oder Caching-Regeln getrennt gesteuert werden müssen.
• Direkte bestehende Aufrufe zunächst inventarisieren, bevor sie auf einen gemeinsamen Pfad umgestellt werden.
• Vollständige Payload-Protokollierung nur nach Prüfung von Datenklassen, Zugriffen und Aufbewahrung zulassen.
• Gateway-Metriken in das vorhandene Betriebs- und Kostenmonitoring übernehmen.

Gemeinsame Abrechnung ist noch keine Kostenstrategie

Cloudflare ermöglicht, AI-Gateway-Guthaben nun auch für Workers AI zu verwenden. Ein vorab geladenes Guthaben kann damit laut Anbieter für Workers AI, OpenAI, Anthropic und weitere unterstützte Anbieter eingesetzt werden. Für Workers-AI-Modelle nennt Cloudflare bei diesem Abrechnungsweg erhöhte Rate Limits; konkrete aktuelle Grenzen sollen den Entwicklerdokumenten entnommen werden.

Die Vereinheitlichung reduziert administrativen Aufwand, entscheidet aber nicht automatisch, welches Modell wirtschaftlich ist. Unternehmen sollten Kosten weiterhin pro abgeschlossenem Prozess messen. Dazu zählen Modellaufrufe, Wiederholungen, Gateway-Funktionen, Caching, menschliche Prüfung und Fehlerfolgen. Ein gemeinsames Guthaben vereinfacht Zahlung und Zuordnung, ersetzt jedoch weder Budgets je Anwendung noch Warn- und Abschaltgrenzen.

1. Kostenstellen definieren: Anwendungen und Teams auf getrennte, nachvollziehbare Gateways oder Kennzeichnungen abbilden.
2. Budgets festlegen: Warnschwellen und harte Reaktionen bei ungewöhnlichem Token- oder Anfragevolumen bestimmen.
3. Provider vergleichen: Preis, Qualität, Latenz und Ausfallverhalten mit identischen Referenzaufgaben messen.
4. Caching gezielt prüfen: Nur dort einsetzen, wo wiederholbare Antworten und Datenregeln dies erlauben.
5. Kosten pro akzeptiertem Ergebnis und nicht nur pro Token oder Request berichten.

Logging und Sicherheit vor der Migration klären

Vollständige Prompts und Antworten können personenbezogene Daten, Geschäftsgeheimnisse, Quellcode oder eingebettete Zugangsinformationen enthalten. Die neue automatische Sichtbarkeit ist deshalb nur dann ein Vorteil, wenn Zugriffe, Aufbewahrung und Löschung geregelt sind. Teams sollten vor der Aktivierung prüfen, welche Inhalte protokolliert werden dürfen und wer sie im Dashboard sehen kann.

• Zulässige Prompt- und Antwortdaten nach Anwendung dokumentieren.
• Secrets und nicht benötigte personenbezogene Daten vor dem Modellaufruf entfernen.
• Dashboard-Zugriffe nach Rollen und minimalen Berechtigungen vergeben.
• Aufbewahrungs-, Export- und Löschprozesse für Gateway-Logs festlegen.
• Testdaten verwenden, bevor produktive Nutzlasten durch das Standard-Gateway laufen.
• Prüfen, welche Anforderungen externe Modellanbieter zusätzlich an Speicherung und Verarbeitung stellen.

AI Gateway bietet eine gemeinsame Kontrollschicht, macht externe Anbieter aber nicht identisch. Datenverarbeitung, Verfügbarkeit, Modellversionen und Ausgabequalität können weiterhin abweichen. Governance sollte daher Gateway-Regeln mit einem zugelassenen Modell- und Providerkatalog verbinden.

Model-first und Smart Routing realistisch einplanen

Cloudflare beschreibt als nächste Stufe ein Routing, bei dem Anwendungen ein gewünschtes Modell statt eines festen Providers angeben. Das Control Plane soll dann Provider-Auswahl, Ausfallsicherung und Lastverteilung übernehmen. Anschließend ist Smart Routing vorgesehen: Ein Klassifikator soll Aufgabe, Komplexität und Kontextbedarf erkennen und ein passendes Modell aus einem kuratierten Pool wählen. Laut Beitrag befindet sich dieser Ansatz noch in interner Erprobung.

Für die Architekturplanung ist die Richtung relevant, aber noch keine verfügbare Betriebsgrundlage. Automatisches Routing kann Resilienz verbessern und Pflegeaufwand senken. Es kann zugleich Nachvollziehbarkeit, Datenstandort, Kostenprognose und reproduzierbare Qualität erschweren. Unternehmen sollten deshalb schon heute Anforderungen formulieren, statt künftige Automatik unkontrolliert zu übernehmen.

• Erlaubte Modelle und Provider pro Datenklasse definieren.
• Mindestanforderungen an Region, Aufbewahrung und Verfügbarkeit festhalten.
• Qualitätsgrenzen und Fallback-Reihenfolge dokumentieren.
• Automatisch geroutete Provider und Modellversionen pro Anfrage protokollieren.
• Manuelle Festlegung für regulierte oder reproduzierbare Prozesse beibehalten.

Rolloutplan für bestehende Workers-AI-Anwendungen

1. Aufrufe inventarisieren: Binding-, REST- und externe Providerpfade samt Datenklassen und Verantwortlichen erfassen.
2. Pilot-Gateway einrichten: Eine risikoarme Anwendung mit Testdaten über default oder ein benanntes Gateway führen.
3. Beobachtbarkeit prüfen: Logging, Tokenzählung, Kostenattribution, Zugriffe und Löschung verifizieren.
4. Abrechnung kontrollieren: Gemeinsames Guthaben zunächst mit Budgetgrenzen und getrennten Kostenstellen testen.
5. Schrittweise migrieren: Nur stabile Anwendungen umstellen und für Ausfälle einen direkten oder alternativen Pfad dokumentieren.

Fazit für Entscheider

Die Zusammenführung von Workers AI und AI Gateway kann KI-Infrastruktur vereinfachen: einheitliche Endpunkte, automatische Beobachtbarkeit und gemeinsame Abrechnung sind konkrete Vorteile. Der größte kurzfristige Handlungsbedarf liegt im Umgang mit vollständigen Logs, Projekttrennung und Kostenattribution. Model-first und Smart Routing sind strategisch interessant, aber noch Zukunftsfunktionen. Wer aktuelle Funktionen kontrolliert migriert und Anforderungen an künftiges Routing jetzt definiert, gewinnt Flexibilität, ohne Datenschutz, Kosten und Reproduzierbarkeit aus der Hand zu geben.