Cloudflare hat AI Gateway eine Steuerung hinzugefügt, mit der Betreiber bei Modellanfragen von Drittanbietern Anbieteranmeldeinformationen anfordern können. Die Änderung ist in Bezug auf die Schnittstelle geringfügig, löst jedoch ein praktisches Governance-Problem für Teams, die KI-Verkehr über ein Gateway weiterleiten: Was soll passieren, wenn ein Kunde, ein Projekt oder ein Mieter keinen gültigen Anbieterschlüssel angegeben hat?

Vor diesem Update konnte Cloudflare AI Gateway sein Unified Billing-Setup als Fallback-Pfad für unterstützte Drittanbieter verwenden. Das kann praktisch sein, wenn eine Anfrage andernfalls fehlschlagen würde, es kann aber auch dazu führen, dass Kostenzuordnungs- und Compliance-Grenzen verschwimmen. Mit der neuen BYOK-only-Einstellung können Gateway-Besitzer diesen Fallback verhindern und verlangen, dass Anfragen stattdessen explizit bereitgestellte Bring-Your-Own-Key-Anmeldeinformationen verwenden.

Cloudflare gibt an, dass die Einstellung im Dashboard oder über die API mit byok_only=true aktiviert werden kann. Außerdem wurde ein Header pro Anfrage hinzugefügt, cf-aig-no-wholesale, für Fälle, in denen Teams die Verwendung von Anmeldeinformationen im Großhandel oder von Cloudflare verwalteten Anmeldeinformationen bei einzelnen Anrufen blockieren möchten.

Was sich geändert hat

Mit dem AI Gateway-Änderungsprotokoll vom 14. September wird eine Anmeldeinformationsanforderung für Anfragen von Drittanbietern eingeführt. Wenn es aktiviert ist, greift das Gateway nicht stillschweigend auf die von Cloudflare verwalteten Unified Billing-Anmeldeinformationen zurück, wenn der Anrufer keine akzeptablen Anbieteranmeldeinformationen angegeben hat.

Diese Unterscheidung ist wichtig, da KI-Gateways zunehmend zwischen vielen internen Anwendungen, externen Kunden und mehreren Modellanbietern platziert werden. Ein fehlender Schlüssel ist nicht nur ein technischer Fehler. Es kann entscheiden, welcher juristischen Person eine Rechnung gestellt wird, welches Konto das Anbieterkontingent verbraucht und ob die Nutzung in der richtigen Kostenstelle angezeigt wird.

Die neue Steuerung gibt Plattformteams einen strengeren Betriebsmodus. Anstatt fehlende Kundenanmeldeinformationen als Routing-Unannehmlichkeiten zu behandeln, kann das Gateway sie als Richtlinienverstoß behandeln. Dies ist besonders relevant für Reseller-Setups, kundeneigene Schlüsselbereitstellungen und Unternehmensumgebungen, in denen die Anbieterbeziehung direkt an eine Geschäftseinheit oder einen Mandanten gebunden bleiben muss.

Warum es für KI-Gateway-Betreiber wichtig ist

Das KI-Gateway-Design hat sich oft auf Routing, Latenz, Caching, Wiederholungsversuche und Modellabstraktion konzentriert. Das Abrechnungsverhalten verdient die gleiche Aufmerksamkeit. Wenn ein Gateway den Anmeldeinformationsmodus automatisch ändert, wenn ein Pfad nicht verfügbar ist, kann die nachgelagerte Berichterstattung irreführend sein. Eine Anfrage kann wie gewöhnlicher Anwendungsverkehr aussehen, während die Rechnung woanders landet.

Für Unternehmen, die eine zentrale KI-API-Kostenkontrolle betreiben, birgt dies ein Betriebsrisiko. Finanzteams können saubere Rückbuchungsdaten verlieren. Sicherheitsteams wissen möglicherweise nicht, welche Anmeldeinformationen tatsächlich verwendet wurden. Produktteams haben möglicherweise Schwierigkeiten zu erklären, warum die Nutzung eines Mandanten über ein Plattformkonto und nicht über das eigene Anbieterkonto dieses Mandanten abgerechnet wurde.

Der Nur-BYOK-Modus hilft auch bei Kundenverpflichtungen. Einige Käufer verlangen, dass ihre eigenen Anbieterverträge, Datenverarbeitungsbedingungen oder regionalen Einstellungen Modellaufrufe regeln. Wenn ein Gateway auf verwaltete Abrechnungsanmeldeinformationen zurückgreifen kann, wird es schwieriger, diese Verpflichtung durchzusetzen, es sei denn, der Fallback wird durch die Richtlinie deaktiviert.

Der Pro-Anfrage-Header fügt eine detailliertere Option hinzu. Eine Plattform kann für einige Workloads ein umfassenderes Unified Billing-Verhalten verfügbar halten und es gleichzeitig für Anfragen verhindern, die strengere Compliance-, Reseller- oder Attributionsanforderungen erfordern. Das gibt Entwicklern einen Migrationspfad, ohne jede Anwendung gleichzeitig in den strengsten Modus zu zwingen.

Wer ist betroffen?

Die unmittelbare Zielgruppe ist jedes Team, das Cloudflare AI Gateway verwendet, um Anfragen an Drittanbieter von KI weiterzuleiten. Die Änderung ist am relevantesten, wenn mehrere Teams, Mandanten oder Kunden ein Gateway gemeinsam nutzen und Anbieteranmeldeinformationen voraussichtlich außerhalb des zentralen Plattformkontos liegen.

Enterprise-KI-Plattformteams sollten überprüfen, ob ihr Gateway-Verhalten mit internen Richtlinien übereinstimmt. Wenn ein Projekt sein eigenes OpenAI-, Anthropic-, Google-, Mistral- oder anderes Anbieterkonto verwenden soll, sollte das Gateway diese Abhängigkeit sichtbar und durchsetzbar machen. Ein Fallback, das zum Erfolg einer Demo beiträgt, kann in der Produktion zu einem Problem werden, wenn es fehlerhafte Anmeldeinformationseinstellungen verbirgt.

Reseller und Partnerplattformen haben eine schärfere Version des gleichen Problems. Wenn Kunden ihre eigenen Anbieterschlüssel mitbringen, müssen Plattformbetreiber darauf vertrauen können, dass der Datenverkehr nicht versehentlich in eine über die Plattform abgerechnete Nutzung umgewandelt wird. Andernfalls können Margen, Rechnungen, Prüfaufzeichnungen und das Vertrauen der Kunden beeinträchtigt werden.

Entwickler sind ebenfalls betroffen, allerdings meist durch eindeutigere Fehlermodi. Bei einer reinen BYOK-Erzwingung sollte eine Anfrage ohne ordnungsgemäße Anmeldeinformationen fehlschlagen und nicht über einen alternativen Abrechnungspfad weitergeleitet werden.Dies erfordert möglicherweise bessere Onboarding-Prüfungen, eine klarere Fehlerbehandlung und Bereitstellungstests, die Anbieterschlüssel überprüfen, bevor der Datenverkehr live geht.

Praktische Konsequenzen

Der erste praktische Schritt ist die Richtlinieninventur. Teams sollten entscheiden, welche Workloads das von Cloudflare verwaltete Unified Billing verwenden dürfen und welche kundeneigene oder projekteigene Anbieteranmeldeinformationen verwenden müssen. Diese Entscheidung sollte explizit sein und nicht dem Standardverhalten des Gateways überlassen werden.

Der zweite Schritt ist die Beobachtbarkeit. Protokolle und Nutzungsanalysen sollten aufzeichnen, welcher Anmeldeinformationsmodus verwendet wurde, ob eine Anfrage blockiert wurde, weil „Nur BYOK“ aktiviert war, und welcher Mandant oder welches Projekt den Schlüssel bereitgestellt hat. Ohne diese Transparenz kann eine strengere Kontrolle Unklarheiten bei der Abrechnung reduzieren, den Betreibern aber dennoch schlechte Daten zur Fehlerbehebung liefern.

Der dritte Schritt ist der Entwickler-Workflow. Anwendungen, die von AI Gateway abhängig sind, sollten frühzeitig fehlschlagen, wenn Anmeldeinformationen fehlen. Eine Startprüfung, eine Bereitstellungsvalidierung oder eine Warnung in der Admin-Konsole ist besser, als das Problem zu entdecken, nachdem eine Produktionsanforderung abgelehnt wurde.

Die verbleibende Unsicherheit betrifft weniger die Funktion selbst als vielmehr die Einführungsmuster. Cloudflare hat die neue Kontrolle dokumentiert, aber jeder Betreiber muss noch entscheiden, wo er sie anwendet. Einige Teams bevorzugen die Stabilität der Fallback-Abrechnung für interne Experimente. Andere machen „Nur BYOK“ zum Standard für den Datenverkehr im Produktionsmandanten. Die wichtige Änderung besteht darin, dass es sich nun um eine Governance-Entscheidung handelt und nicht um ein implizites Verhalten, das innerhalb der Routing-Ebene verborgen ist.