A Cloudflare adicionou um controle ao AI Gateway que permite que as operadoras exijam credenciais de provedor em solicitações de modelo de terceiros. A mudança é pequena em termos de interface, mas aborda um problema prático de governança para equipes que roteiam o tráfego de IA por meio de um gateway: o que deveria acontecer quando um cliente, projeto ou locatário não fornecesse uma chave de provedor válida?
Antes desta atualização, o Cloudflare AI Gateway poderia usar sua configuração de faturamento unificado como um caminho alternativo para provedores terceirizados suportados. Isso pode ser conveniente quando uma solicitação falharia, mas também pode confundir a atribuição de custos e os limites de conformidade. A nova configuração somente BYOK permite que os proprietários de gateway evitem esse substituto e exijam que as solicitações usem credenciais de "traga sua própria chave" fornecidas explicitamente.
A Cloudflare diz que a configuração pode ser habilitada no painel ou por meio da API com byok_only=true. Ele também adicionou um cabeçalho por solicitação, cf-aig-no-wholesale, para casos em que as equipes desejam bloquear o uso de credenciais de atacado ou gerenciadas pela Cloudflare em chamadas individuais.
O que mudou
O changelog de 14 de setembro do AI Gateway introduz um requisito de credencial para solicitações de provedores terceirizados. Quando ativado, o gateway não retornará silenciosamente às credenciais do Unified Billing gerenciadas pela Cloudflare se o chamador não tiver fornecido credenciais de provedor aceitáveis.
Essa distinção é importante porque os gateways de IA ficam cada vez mais entre muitos aplicativos internos, clientes externos e vários provedores de modelo. A falta de uma chave não é apenas um modo de falha técnica. Ele pode decidir qual entidade legal será cobrada, qual cota de provedor de conta será consumida e se o uso aparecerá no centro de custo certo.
O novo controle dá às equipes da plataforma um modo operacional mais rigoroso. Em vez de tratar a falta de credenciais do cliente como um inconveniente de roteamento, o gateway pode tratá-las como uma violação da política. Isso é especialmente relevante para configurações de revendedores, implantações de chaves de propriedade do cliente e ambientes corporativos onde o relacionamento do fornecedor precisa permanecer diretamente vinculado a uma unidade de negócios ou locatário.
Por que isso é importante para os operadores de gateway de IA
O design do gateway de IA geralmente se concentra em roteamento, latência, armazenamento em cache, novas tentativas e abstração de modelo. O comportamento de cobrança merece a mesma atenção. Se um gateway alterar automaticamente o modo de credencial quando um caminho estiver indisponível, os relatórios downstream poderão se tornar enganosos. Uma solicitação pode parecer tráfego comum de aplicativo, enquanto a fatura chega a outro lugar.
Para empresas que operam uma camada de controle central de custos da API de IA, isso cria risco operacional. As equipes financeiras podem perder dados limpos de estorno. As equipes de segurança podem não saber qual credencial foi realmente usada. As equipes de produto podem ter dificuldade para explicar por que o uso de um locatário foi cobrado por meio de uma conta de plataforma, em vez da conta do próprio provedor do locatário.
O modo somente BYOK também ajuda com os compromissos do cliente. Alguns compradores exigem que seus próprios contratos de fornecedores, termos de processamento de dados ou configurações regionais governem as chamadas de modelo. Se um gateway puder recorrer a uma credencial de faturamento gerenciado, esse compromisso se tornará mais difícil de aplicar, a menos que o substituto seja desativado pela política.
O cabeçalho por solicitação adiciona uma opção mais granular. Uma plataforma pode manter um comportamento mais amplo do Unified Billing disponível para algumas cargas de trabalho, ao mesmo tempo que o impede para solicitações que tenham requisitos mais rígidos de conformidade, revendedor ou atribuição. Isso oferece aos desenvolvedores um caminho de migração sem forçar todos os aplicativos para o modo mais estrito de uma só vez.
Quem é afetado
O público imediato é qualquer equipe que usa o Cloudflare AI Gateway para fazer proxy de solicitações para provedores de IA terceirizados. A mudança é mais relevante quando várias equipes, locatários ou clientes compartilham um gateway e onde se espera que as credenciais do provedor sejam de propriedade de fora da conta da plataforma central.
As equipes da plataforma de IA empresarial devem analisar se o comportamento do gateway corresponde à política interna. Se um projeto deve usar sua própria conta OpenAI, Anthropic, Google, Mistral ou outra conta de provedor, o gateway deve tornar essa dependência visível e executável. Um substituto que ajuda uma demonstração a ter sucesso pode se tornar um problema na produção se ocultar configurações de credenciais quebradas.
Revendedores e plataformas parceiras têm uma versão mais precisa do mesmo problema. Se os clientes trouxerem suas próprias chaves de provedor, os operadores de plataforma precisarão ter certeza de que o tráfego não será acidentalmente convertido em uso faturado pela plataforma. Caso contrário, as margens, as faturas, os registros de auditoria e a confiança do cliente poderão ser afetados.
Os desenvolvedores também são afetados, embora principalmente por meio de modos de falha mais claros. Com a aplicação apenas do BYOK, uma solicitação que não tenha as credenciais adequadas deverá falhar em vez de ser encaminhada por um caminho de cobrança alternativo.Isso pode exigir melhores verificações de integração, tratamento de erros mais claro e testes de implantação que verificam as chaves do provedor antes que o tráfego entre em operação.
Consequências práticas
A primeira etapa prática é o inventário de políticas. As equipes devem decidir quais cargas de trabalho têm permissão para usar o Unified Billing gerenciado pela Cloudflare e quais devem usar credenciais de provedor de propriedade do cliente ou do projeto. Essa decisão deve ser explícita e não deixada ao comportamento padrão do gateway.
O segundo passo é a observabilidade. Os logs e a análise de uso devem registrar qual modo de credencial foi usado, se uma solicitação foi bloqueada porque somente BYOK foi habilitado e qual locatário ou projeto forneceu a chave. Sem essa visibilidade, um controle mais rigoroso pode reduzir a ambiguidade de faturamento, mas ainda deixar os operadores com dados de solução de problemas deficientes.
A terceira etapa é o fluxo de trabalho do desenvolvedor. Os aplicativos que dependem do AI Gateway deverão falhar antecipadamente quando as credenciais estiverem faltando. Uma verificação de inicialização, validação de implantação ou aviso do console de administração é melhor do que descobrir o problema após a rejeição de uma solicitação de produção.
A incerteza restante é menos sobre o recurso em si e mais sobre os padrões de adoção. A Cloudflare documentou o novo controle, mas cada operadora ainda precisa decidir onde aplicá-lo. Algumas equipes preferirão a resiliência do faturamento alternativo para experimentos internos. Outros tornarão somente BYOK o padrão para o tráfego de locatários de produção. A mudança importante é que esta é agora uma escolha de governança, em vez de um comportamento implícito escondido dentro da camada de roteamento.