Cloudflare ha afegit un control a AI Gateway que permet als operadors requerir credencials del proveïdor a les sol·licituds de models de tercers. El canvi és petit en termes d'interfície, però aborda un problema pràctic de govern per als equips que encaminen el trànsit d'IA a través d'una passarel·la: què hauria de passar quan un client, projecte o llogater no ha proporcionat una clau de proveïdor vàlida?
Abans d'aquesta actualització, Cloudflare AI Gateway podria utilitzar la seva configuració de facturació unificada com a ruta alternativa per als proveïdors de tercers compatibles. Això pot ser convenient quan una sol·licitud fallaria, però també pot desdibuixar els límits d'atribució de costos i de compliment. La nova configuració només de BYOK permet als propietaris de passarel·les evitar aquesta alternativa i requereixen que les sol·licituds utilitzin les credencials de portar la teva pròpia clau proporcionades explícitament.
Cloudflare diu que la configuració es pot activar al tauler o mitjançant l'API amb byok_only=true. També va afegir una capçalera per sol·licitud, cf-aig-no-wholesale, per als casos en què els equips volen bloquejar l'ús de credencials a l'engròs o gestionats per Cloudflare en trucades individuals.
Què ha canviat
El registre de canvis d'AI Gateway del 14 de setembre introdueix un requisit de credencials per a les sol·licituds de proveïdors de tercers. Quan s'activa, la passarel·la no es tornarà silenciosa a les credencials de facturació unificada gestionades per Cloudflare si la persona que truca no ha proporcionat credencials de proveïdor acceptables.
Aquesta distinció és important perquè les passarel·les d'IA se situen cada cop més entre moltes aplicacions internes, clients externs i diversos proveïdors de models. Una clau que falta no és només un mode de fallada tècnica. Pot decidir quina entitat legal es factura, quina quota de proveïdor del compte es consumeix i si l'ús apareix al centre de costos adequat.
El nou control ofereix als equips de la plataforma un mode de funcionament més estricte. En lloc de tractar les credencials dels clients que falten com un inconvenient d'encaminament, la passarel·la pot tractar-les com una infracció de la política. Això és especialment rellevant per a les configuracions de distribuïdors, els desplegaments de claus propietat del client i els entorns empresarials on la relació amb el proveïdor ha de romandre directament vinculada a una unitat de negoci o un llogater.
Per què és important per als operadors de passarel·les d'IA
El disseny de la passarel·la d'IA sovint s'ha centrat en l'encaminament, la latència, la memòria cau, els reintents i l'abstracció de models. El comportament de facturació mereix la mateixa atenció. Si una passarel·la canvia automàticament el mode de credencial quan un camí no està disponible, els informes posteriors poden resultar enganyosos. Una sol·licitud pot semblar un trànsit d'aplicacions normal mentre la factura arriba a un altre lloc.
Per a les empreses que operen una capa de control de costos de l'API d'IA central, que genera risc operacional. Els equips financers poden perdre dades de retrocàrrec netes. És possible que els equips de seguretat no sàpiguen quina credencial es va utilitzar realment. Els equips de producte poden tenir problemes per explicar per què l'ús d'un inquilí es va facturar a través d'un compte de plataforma en lloc del compte de proveïdor del propi inquilí.
El mode només BYOK també ajuda amb els compromisos del client. Alguns compradors requereixen que els seus propis contractes de proveïdor, les condicions de processament de dades o la configuració regional regeixin les trucades model. Si una passarel·la pot recórrer a una credencial de facturació gestionada, aquest compromís es fa més difícil d'aplicar, tret que la política de reserva es desactivi.
La capçalera per sol·licitud afegeix una opció més granular. Una plataforma pot mantenir un comportament de facturació unificada més ampli disponible per a algunes càrregues de treball, alhora que l'impedeix per a sol·licituds que inclouen requisits de compliment, distribuïdor o atribució més estrictes. Això ofereix als desenvolupadors una ruta de migració sense forçar totes les aplicacions al mode més estricte alhora.
Qui està afectat
El públic immediat és qualsevol equip que utilitzi Cloudflare AI Gateway per enviar sol·licituds a proveïdors d'IA de tercers. El canvi és més rellevant quan diversos equips, llogaters o clients comparteixen una passarel·la i on s'espera que les credencials del proveïdor siguin propietat fora del compte de la plataforma central.
Els equips de la plataforma d'IA empresarial han de revisar si el comportament de la seva passarel·la coincideix amb la política interna. Si se suposa que un projecte ha d'utilitzar el seu propi compte OpenAI, Anthropic, Google, Mistral o un altre proveïdor, la passarel·la hauria de fer que aquesta dependència sigui visible i exigible. Una alternativa que ajudi a tenir èxit una demostració pot convertir-se en un problema de producció si amaga la configuració de credencials trencada.
Els distribuïdors i les plataformes de socis tenen una versió més nítida del mateix problema. Si els clients porten les seves pròpies claus de proveïdor, els operadors de la plataforma necessiten la confiança que el trànsit no es converteixi accidentalment en un ús facturat per la plataforma. En cas contrari, es poden veure afectats els marges, les factures, els registres d'auditoria i la confiança del client.
Els desenvolupadors també es veuen afectats, encara que sobretot a través de modes d'error més clars. Amb l'aplicació només de BYOK, una sol·licitud que no té les credencials adequades hauria de fallar en lloc de dirigir-se per una ruta de facturació alternativa.Això pot requerir millors comprovacions d'incorporació, una gestió més clara dels errors i proves de desplegament que verifiquen les claus del proveïdor abans que el trànsit s'iniciï.
Conseqüències pràctiques
El primer pas pràctic és l'inventari de polítiques. Els equips haurien de decidir quines càrregues de treball poden utilitzar la facturació unificada gestionada per Cloudflare i quines han d'utilitzar les credencials del proveïdor propietat del client o del projecte. Aquesta decisió hauria de ser explícita, no deixar-se al comportament de la passarel·la per defecte.
El segon pas és l'observabilitat. Els registres i les anàlisis d'ús haurien de registrar quin mode de credencial s'ha utilitzat, si una sol·licitud s'ha bloquejat perquè només BYOK estava habilitat i quin inquilí o projecte ha proporcionat la clau. Sense aquesta visibilitat, un control més estricte pot reduir l'ambigüitat de la facturació, però encara deixar als operadors amb dades de resolució de problemes deficients.
El tercer pas és el flux de treball del desenvolupador. Les aplicacions que depenen d'AI Gateway haurien de fallar aviat quan faltin les credencials. Una comprovació d'inici, una validació del desplegament o un avís de la consola d'administració és millor que descobrir el problema després de rebutjar una sol·licitud de producció.
La incertesa restant és menys sobre la funció en si mateixa i més sobre els patrons d'adopció. Cloudflare ha documentat el nou control, però cada operador encara ha de decidir on aplicar-lo. Alguns equips preferiran la resiliència de la facturació alternativa per als experiments interns. Altres faran que només BYOK sigui el valor predeterminat per al trànsit d'inquilins de producció. El canvi important és que ara és una opció de govern en lloc d'un comportament implícit amagat dins de la capa d'encaminament.