Cloudflare ha afegit un control petit però important a AI Gateway: els equips ara poden requerir credencials de proveïdors de tercers abans que es permeti que s'executi una sol·licitud. Si la passarel·la no troba les credencials aplicables, la sol·licitud falla amb HTTP 400 en lloc de tornar a la facturació unificada gestionada per Cloudflare.
Això canvia el significat pràctic de portar-la-teu-propia-clau o BYOK. Fins ara, una clau del proveïdor que faltava podria ser un problema de configuració que encara produïa una trucada de model reeixida, però amb una ruta de facturació diferent. Amb la nova configuració, les credencials que falten es converteixen en una infracció severa de la política. Per a les organitzacions que separen els comptes model propietat dels clients del trànsit facturat de manera centralitzada, aquesta distinció és més important del que suggereix el codi d'estat.
El que ha canviat
L'actualització del 14 de setembre de Cloudflare afegeix dues maneres d'aplicar el nou comportament. A nivell de passarel·la, els administradors poden activar una configuració byok_only. En el moment de la sol·licitud, les persones que trucen poden enviar la capçalera cf-aig-no-wholesale per evitar que la facturació a l'engròs sigui alternativa per a aquesta sol·licitud.
Quan s'aplica el control i les credencials del proveïdor no estan disponibles, AI Gateway retorna l'HTTP 400. Cloudflare diu que les sol·licituds d'IA dels treballadors continuen permeses, de manera que la política es refereix específicament a les sol·licituds de tercers que Cloudflare proporcionen a través d'altres rutes. credencials.
La funció no és un model nou d'encaminador ni un descompte de preus. És una barana en mode de facturació. Això fa que sigui directament rellevant per a la facturació unificada de l'API AI, ja que una única passarel·la ara pot traçar una línia més clara entre el trànsit facturat de manera centralitzada i les sol·licituds que s'han de carregar al compte del proveïdor del propi client.
Per què és convenient que la facturació sigui convenient quan la recuperació de la facturació és convenient. Si la credencial d'un proveïdor està absent, ha caducat o no està connectada a la ruta correcta, una credencial gestionada per passarel·la pot mantenir l'aplicació en funcionament. Però aquesta mateixa comoditat pot crear un rastre de factura desordenat.
Un proveïdor de SaaS, una agència o un equip de plataforma interna pot prometre que el trànsit d'un inquilí determinat només es dirigeix al compte d'OpenAI, Anthropic, Google o un altre proveïdor d'aquest inquilí. Si la passarel·la utilitza en silenci una credencial a l'engròs, la sol·licitud encara pot tenir èxit, però el significat comercial ha canviat. L'operador de la plataforma pot absorbir el cost, transferir-lo de manera incorrecta o perdre la capacitat de conciliar l'ús amb la factura del propi proveïdor del client.
Això és especialment sensible per als models d'API de distribuïdors i socis. Un client pot estar a BYOK a causa de les regles de contractació. Un altre pot utilitzar crèdits facturats per plataforma. Un tercer pot requerir comptes de proveïdor separats per motius reguladors o de govern de dades. En aquest entorn, la ruta de facturació forma part del contracte del producte, no un detall d'implementació.
El nou control de Cloudflare ofereix als equips una manera de fer que aquest contracte sigui exigible al límit de la passarel·la. Una sol·licitud fallida és molesta operativament, però és més fàcil depurar que una sol·licitud correcta que apareix més tard al centre de costos incorrecte.
Qui està afectat
El públic immediat és qualsevol equip que utilitzi Cloudflare AI Gateway amb una combinació de credencials propietat del proveïdor i facturació gestionada per Cloudflare. El canvi és més important quan diversos inquilins, entorns o unitats de negoci comparteixen una configuració de passarel·la.
Els desenvolupadors hauran de decidir si una ruta ha de preferir la disponibilitat o l'aïllament estricte de la facturació. Els equips de finances i operacions tenen un mecanisme més net per prevenir l'ús accidental a l'engròs. Els equips de seguretat i plataforma aconsegueixen una altra palanca per a la gestió de claus de l'API, perquè la presència o l'absència de credencials del proveïdor ara té un resultat d'aplicació directa.
Per als operadors de passarel·les d'IA en general, l'actualització és un senyal. Els controls de facturació s'estan convertint en controls de polítiques. Ja no n'hi ha prou amb demostrar que una sol·licitud utilitzava un model concret. Les passarel·les necessiten cada cop més registrar quina ruta de la credencial s'ha utilitzat, qui era el propietari d'aquesta credencial, quin inquilí o clau d'API va iniciar la trucada i si es va permetre la reserva.
Els usuaris de Model Gate s'enfronten al mateix problema subjacent quan gestionen equips, claus API, analítiques d'ús i accés als socis. Una clau d'abast del client no és només un testimoni d'autenticació; pot implicar un mode de facturació, un límit de despesa, un compte de proveïdor i un conjunt d'expectatives d'auditoria. Si aquests significats no s'apliquen de manera coherent, els taulers d'anàlisi i les factures poden allunyar-se del que els clients creuen que han comprat.
Conseqüències pràctiques
El primer canvi pràctic és la gestió d'errors. Les aplicacions que habiliten els controls només de BYOK haurien de tractar l'HTTP 400 des de la passarel·la com un problema de configuració o de credencials, no com un error del model.Tornar a provar la mateixa sol·licitud sense corregir les credencials només pot generar soroll.
El segon canvi és la incorporació. Els equips que permeten als clients portar les claus del proveïdor necessiten un pas de verificació de credencials més fort abans que comenci el trànsit de producció. Un inquilí no hauria de descobrir durant un flux de treball en directe que la seva clau de proveïdor no s'ha connectat mai a la ruta de la passarel·la.
El tercer canvi és l'observabilitat. Els registres de la passarel·la i els informes d'ús haurien d'exposar si una sol·licitud utilitza BYOK, facturació de la plataforma o una ruta alternativa bloquejada. Sense aquest camp, els equips d'assistència poden saber que una sol·licitud ha fallat, però no si l'error protegia un límit de facturació.
Finalment, les plataformes de partner haurien de revisar els seus valors predeterminats. L'aplicació estricta de BYOK no sempre és l'opció correcta. Alguns productes poden tornar deliberadament a la facturació de la plataforma per preservar la continuïtat del servei. Altres poden necessitar una separació dura a causa dels contractes, la confiança dels clients o la protecció dels marges. El canvi important és que la decisió pot ser explícita en lloc de ser accidental.
El que encara no està clar
El canvi públic descriu la mecànica de la política, però els equips encara hauran de provar com es comporta amb la seva pròpia combinació de proveïdors, estructura de ruta i model d'herència de credencials. Tampoc encara no està clar fins a quin punt els marcs d'aplicació i les eines d'observabilitat de tercers mostraran aquesta distinció de mode de facturació als seus taulers de control predeterminats.
La direcció més àmplia és prou clara. Les passarel·les multimodel s'estan convertint en plans de control financer tant com proxies d'API. La configuració només BYOK de Cloudflare és una característica limitada, però aborda un mode d'error real: la sol·licitud que funciona tècnicament mentre infringeix el model de facturació previst.