Cloudflare a ajouté un contrôle à AI Gateway qui permet aux opérateurs d'exiger les informations d'identification du fournisseur pour les demandes de modèles tiers. Le changement est mineur en termes d'interface, mais il répond à un problème de gouvernance pratique pour les équipes qui acheminent le trafic d'IA via une passerelle : que doit-il se passer lorsqu'un client, un projet ou un locataire n'a pas fourni de clé de fournisseur valide ?
Avant cette mise à jour, Cloudflare AI Gateway pouvait utiliser sa configuration de facturation unifiée comme voie de secours pour les fournisseurs tiers pris en charge. Cela peut s’avérer pratique lorsqu’une demande échouerait autrement, mais cela peut également brouiller les limites d’attribution des coûts et de conformité. Le nouveau paramètre BYOK uniquement permet aux propriétaires de passerelle d'éviter cette solution de repli et d'exiger que les demandes utilisent à la place les informations d'identification Bring-your-own-key fournies explicitement.
Cloudflare indique que le paramètre peut être activé dans le tableau de bord ou via l'API avec byok_only=true. Il a également ajouté un en-tête par requête, cf-aig-no-wholesale, pour les cas où les équipes souhaitent bloquer l'utilisation des informations d'identification en gros ou gérées par Cloudflare lors d'appels individuels.
Ce qui a changé
Le journal des modifications d'AI Gateway du 14 septembre introduit une exigence d'informations d'identification pour les demandes de fournisseurs tiers. Lorsqu'elle est activée, la passerelle ne reviendra pas silencieusement aux informations d'identification de facturation unifiée gérées par Cloudflare si l'appelant n'a pas fourni d'informations d'identification de fournisseur acceptables.
Cette distinction est importante car les passerelles IA se situent de plus en plus entre de nombreuses applications internes, clients externes et plusieurs fournisseurs de modèles. Une clé manquante n’est pas seulement un mode de défaillance technique. Il peut décider quelle entité juridique est facturée, quel quota de fournisseur de compte est consommé et si l'utilisation apparaît dans le bon centre de coûts.
Le nouveau contrôle donne aux équipes de la plateforme un mode de fonctionnement plus strict. Au lieu de traiter les identifiants client manquants comme un inconvénient de routage, la passerelle peut les traiter comme une violation de politique. Cela est particulièrement pertinent pour les configurations de revendeurs, les déploiements de clés appartenant au client et les environnements d'entreprise dans lesquels la relation avec le fournisseur doit rester directement liée à une unité commerciale ou à un locataire.
Pourquoi c'est important pour les opérateurs de passerelles IA
La conception des passerelles IA s'est souvent concentrée sur le routage, la latence, la mise en cache, les tentatives et l'abstraction du modèle. Le comportement de facturation mérite la même attention. Si une passerelle change automatiquement de mode d'identification lorsqu'un chemin n'est pas disponible, les rapports en aval peuvent devenir trompeurs. Une requête peut ressembler à du trafic d'application ordinaire alors que la facture arrive ailleurs.
Pour les entreprises exploitant une couche de contrôle central des coûts des API d'IA, cela crée un risque opérationnel. Les équipes financières peuvent perdre des données de rétrofacturation claires. Les équipes de sécurité peuvent ne pas savoir quel identifiant a été réellement utilisé. Les équipes produit peuvent avoir du mal à expliquer pourquoi l'utilisation d'un locataire a été facturée via un compte de plate-forme au lieu du propre compte de fournisseur de ce locataire.
Le mode BYOK uniquement facilite également les engagements des clients. Certains acheteurs exigent que leurs propres contrats de fournisseur, conditions de traitement des données ou paramètres régionaux régissent les appels de modèles. Si une passerelle peut recourir à des informations d'identification de facturation gérées, cet engagement devient plus difficile à appliquer, à moins que la solution de repli ne soit désactivée par une stratégie.
L'en-tête par requête ajoute une option plus granulaire. Une plate-forme peut conserver un comportement de facturation unifiée plus large disponible pour certaines charges de travail tout en l'empêchant pour les demandes qui comportent des exigences de conformité, de revendeur ou d'attribution plus strictes. Cela donne aux développeurs un chemin de migration sans forcer chaque application sur le mode le plus strict à la fois.
Qui est concerné
Le public immédiat est toute équipe utilisant Cloudflare AI Gateway pour transmettre des requêtes à des fournisseurs d'IA tiers. Le changement est particulièrement pertinent lorsque plusieurs équipes, locataires ou clients partagent une passerelle et lorsque les informations d'identification du fournisseur doivent être détenues en dehors du compte de plateforme centrale.
Les équipes de plateforme d'IA d'entreprise doivent vérifier si le comportement de leur passerelle correspond à la politique interne. Si un projet est censé utiliser son propre compte OpenAI, Anthropic, Google, Mistral ou autre fournisseur, la passerelle doit rendre cette dépendance visible et exécutoire. Une solution de secours qui contribue au succès d'une démo peut devenir un problème en production si elle cache une configuration d'identifiants cassée.
Les revendeurs et les plateformes partenaires ont une version plus précise du même problème. Si les clients apportent leurs propres clés de fournisseur, les opérateurs de plateforme doivent avoir l’assurance que le trafic n’est pas accidentellement converti en utilisation facturée par la plateforme. Dans le cas contraire, les marges, les factures, les dossiers d'audit et la confiance des clients peuvent tous être affectés.
Les développeurs sont également affectés, mais principalement à travers des modes d'échec plus clairs. Avec l’application BYOK uniquement, une demande qui ne dispose pas des informations d’identification appropriées devrait échouer plutôt que d’emprunter une autre voie de facturation.Cela peut nécessiter de meilleurs contrôles d'intégration, une gestion plus claire des erreurs et des tests de déploiement qui vérifient les clés du fournisseur avant la mise en ligne du trafic.
Conséquences pratiques
La première étape pratique est l'inventaire des politiques. Les équipes doivent décider quelles charges de travail sont autorisées à utiliser la facturation unifiée gérée par Cloudflare et lesquelles doivent utiliser les informations d'identification du fournisseur appartenant au client ou au projet. Cette décision doit être explicite et non laissée au comportement par défaut de la passerelle.
La deuxième étape est l'observabilité. Les journaux et les analyses d'utilisation doivent enregistrer quel mode d'identification a été utilisé, si une demande a été bloquée parce que BYOK uniquement a été activé et quel locataire ou projet a fourni la clé. Sans cette visibilité, un contrôle plus strict peut réduire l'ambiguïté de facturation, mais laisser les opérateurs avec de mauvaises données de dépannage.
La troisième étape est le flux de travail des développeurs. Les applications qui dépendent d'AI Gateway devraient échouer rapidement lorsque les informations d'identification sont manquantes. Il est préférable d'effectuer une vérification de démarrage, une validation de déploiement ou un avertissement de la console d'administration plutôt que de découvrir le problème après le rejet d'une demande de production.
L'incertitude restante concerne moins la fonctionnalité elle-même que les modèles d'adoption. Cloudflare a documenté le nouveau contrôle, mais chaque opérateur doit encore décider où l'appliquer. Certaines équipes préféreront la résilience de la facturation de secours pour les expériences internes. D’autres feront du BYOK uniquement la valeur par défaut pour le trafic des locataires de production. Le changement important est qu'il s'agit désormais d'un choix de gouvernance plutôt que d'un comportement implicite caché à l'intérieur de la couche de routage.