Cloudflare a ajouté un contrôle petit mais important à AI Gateway : les équipes peuvent désormais exiger les informations d'identification d'un fournisseur tiers avant qu'une requête soit autorisée à s'exécuter. Si la passerelle ne trouve pas les informations d'identification applicables, la requête échoue avec HTTP 400 au lieu de revenir à la facturation unifiée gérée par Cloudflare.

Cela change la signification pratique de Bring-your-own-key, ou BYOK. Jusqu'à présent, une clé de fournisseur manquante pouvait être un problème de configuration qui produisait quand même un appel de modèle réussi, mais selon un chemin de facturation différent. Avec le nouveau paramètre, les informations d’identification manquantes deviennent une violation flagrante des règles. Pour les organisations qui séparent les comptes modèles détenus par les clients du trafic facturé de manière centralisée, cette distinction est plus importante que ne le suggère le code de statut.

Ce qui a changé

La mise à jour de Cloudflare du 14 septembre ajoute deux façons d'appliquer le nouveau comportement. Au niveau de la passerelle, les administrateurs peuvent activer un paramètre byok_only. Au moment de la demande, les appelants peuvent envoyer l'en-tête cf-aig-no-wholesale pour empêcher le repli de la facturation de gros pour cette demande.

Lorsque le contrôle s'applique et que les informations d'identification du fournisseur ne sont pas disponibles, AI Gateway renvoie HTTP 400. Cloudflare indique que les demandes Workers AI restent autorisées, la politique concerne donc spécifiquement les demandes de fournisseurs tiers qui pourraient autrement être acheminées via les informations d'identification gérées par Cloudflare.

La fonctionnalité n'est pas un nouveau modèle de routeur ou une remise de prix. Il s’agit d’un garde-fou en mode facturation. Cela le rend directement pertinent pour la facturation unifiée des API d'IA, car une passerelle unique peut désormais tracer une ligne plus nette entre le trafic facturé de manière centralisée et les demandes qui doivent être facturées sur le compte fournisseur du client.

Pourquoi le repli de facturation est risqué

Le repli est pratique lorsque la priorité est la disponibilité. Si les informations d'identification d'un fournisseur sont absentes, expirées ou non attachées au bon itinéraire, les informations d'identification gérées par la passerelle peuvent permettre à l'application de continuer à fonctionner. Mais cette même commodité peut créer une piste de facturation désordonnée.

Un fournisseur SaaS, une agence ou une équipe de plate-forme interne peut promettre que le trafic d'un locataire donné s'exécute uniquement sur le compte OpenAI, Anthropic, Google ou d'un autre fournisseur de ce locataire. Si la passerelle utilise silencieusement un identifiant de gros, la demande peut toujours aboutir, mais la signification commerciale a changé. L'opérateur de la plate-forme peut absorber le coût, le répercuter de manière incorrecte ou perdre la capacité de rapprocher l'utilisation de la facture du fournisseur du client.

Ceci est particulièrement sensible pour les modèles d'API des revendeurs et des partenaires. Un client peut utiliser BYOK en raison des règles d'approvisionnement. Un autre peut utiliser les crédits facturés par la plateforme. Un tiers peut exiger des comptes de fournisseur distincts pour des raisons de réglementation ou de gouvernance des données. Dans cet environnement, le chemin de facturation fait partie du contrat de produit et non un détail de mise en œuvre.

Le nouveau contrôle de Cloudflare donne aux équipes un moyen de rendre ce contrat exécutoire au niveau de la passerelle. Une demande échouée est ennuyeuse sur le plan opérationnel, mais elle est plus facile à déboguer qu'une demande réussie qui apparaît plus tard dans le mauvais centre de coûts.

Qui est concerné

Le public immédiat est toute équipe utilisant Cloudflare AI Gateway avec une combinaison d'informations d'identification appartenant au fournisseur et de facturation gérée par Cloudflare. Le changement est particulièrement important lorsque plusieurs locataires, environnements ou unités commerciales partagent une configuration de passerelle.

Les développeurs devront décider si une route doit privilégier la disponibilité ou une isolation stricte de facturation. Les équipes financières et opérationnelles disposent d’un mécanisme plus propre pour empêcher toute utilisation accidentelle en gros. Les équipes de sécurité et de plate-forme disposent d'un autre levier pour la gestion des clés API, car la présence ou l'absence d'informations d'identification du fournisseur a désormais un résultat direct en termes d'application.

Pour les opérateurs de passerelles IA en général, la mise à jour est un signal. Les contrôles de facturation deviennent des contrôles politiques. Il ne suffit plus de montrer qu’une requête utilisait un modèle précis. Les passerelles doivent de plus en plus enregistrer quel chemin d'identification a été utilisé, à qui appartiennent ces informations d'identification, quel locataire ou quelle clé API a lancé l'appel et si le repli a été autorisé.

Les utilisateurs de Model Gate sont confrontés au même problème sous-jacent lorsqu'ils gèrent des équipes, des clés API, des analyses d'utilisation et des accès côté partenaire. Une clé client n’est pas seulement un jeton d’authentification ; cela peut impliquer un mode de facturation, une limite de dépenses, un compte fournisseur et un ensemble d'attentes d'audit. Si ces significations ne sont pas appliquées de manière cohérente, les tableaux de bord analytiques et les factures peuvent s'éloigner de ce que les clients pensent avoir acheté.

Conséquences pratiques

Le premier changement pratique est la gestion des erreurs. Les applications qui activent les contrôles BYOK uniquement doivent traiter HTTP 400 de la passerelle comme un problème de configuration ou d'informations d'identification, et non comme un échec de modèle.Réessayer la même requête sans corriger les informations d'identification ne peut que créer du bruit.

Le deuxième changement concerne l'intégration. Les équipes qui permettent aux clients d'apporter les clés du fournisseur ont besoin d'une étape de vérification des informations d'identification plus stricte avant le début du trafic de production. Un locataire ne doit pas découvrir au cours d'un workflow en direct que sa clé de fournisseur n'a jamais été attachée à la route de la passerelle.

Le troisième changement est l'observabilité. Les journaux de passerelle et les rapports d'utilisation doivent indiquer si une demande a utilisé BYOK, la facturation de la plateforme ou un chemin de secours bloqué. Sans ce champ, les équipes d'assistance peuvent savoir qu'une requête a échoué, mais pas si l'échec a protégé une limite de facturation.

Enfin, les plateformes partenaires devraient revoir leurs valeurs par défaut. Une application stricte du BYOK n’est pas toujours le bon choix. Certains produits peuvent délibérément recourir à la facturation par plateforme pour préserver la continuité du service. D'autres peuvent avoir besoin d'une séparation stricte en raison de contrats, de la confiance des clients ou de la protection des marges. Le changement important est que la décision peut être explicite plutôt qu'accidentelle.

Ce qui reste flou

Le changement public décrit les mécanismes de la politique, mais les équipes devront toujours tester son comportement sur leur propre combinaison de fournisseurs, leur structure de routage et leur modèle d'héritage des informations d'identification. Il n'est pas non plus clair dans quelle mesure les cadres d'application et les outils d'observabilité tiers feront apparaître cette distinction de mode de facturation dans leurs tableaux de bord par défaut.

La direction générale est suffisamment claire. Les passerelles multimodèles deviennent autant des plans de contrôle financier que des proxys API. Le paramètre BYOK uniquement de Cloudflare est une fonctionnalité limitée, mais il répond à un véritable mode d'échec : la requête qui fonctionne techniquement tout en violant le modèle de facturation prévu.