Toda rota até um modelo de IA virou um fornecedor. Mapeie sua cadeia antes que uma política faça isso por você
Numa semana, a OpenAI chegou a outra nuvem e pôs gateways de IA sob sua aprovação, e a ServiceNow levou a revogação de agentes à placa de rede. Chegar a um modelo virou uma cadeia.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.

Pergunte a um arquiteto enterprise de onde vêm os modelos de IA da empresa e a resposta costuma ser uma lista de nomes: OpenAI, Anthropic, Google, alguns modelos de pesos abertos. Pergunte como cada requisição de fato chega a um modelo, e a resposta fica mais longa. O modelo foi construído por uma empresa, é hospedado por outra, comprado pelo marketplace de uma terceira, roteado pelo gateway de uma quarta e embrulhado pelo runtime de agentes de uma quinta antes de a sua aplicação vê-lo.
Cada uma dessas partes agora tem as próprias regras, e nesta semana três delas mudaram as suas.
- Os modelos da OpenAI estão chegando ao Google Cloud, comprados pelo marketplace contra compromissos já assinados, com alguns controles de dados ainda “em breve”.
- A OpenAI disse que, a partir de 20 de novembro, serviços que oferecem acesso direto aos seus modelos, como routers e gateways de IA, precisam da aprovação dela.
- A ServiceNow colocou um agente pessoal em disponibilidade geral e anunciou que a revogação das permissões de um agente será aplicada no runtime e, mais tarde, na placa de rede.
Lidas juntas, as três notícias descrevem algo que as empresas ainda não gerenciam como tal: uma cadeia de fornecimento de modelos.
A cadeia, camada por camada
As partes entre a sua aplicação e um modelo
Sua aplicação ou agente
- Prompts, skills, memória
Você
Sua camada de controle
- Identidade, orçamentos, logs, política de roteamento
Você, se construiu uma
Gateway ou router
- De terceiros ou interno
Pode precisar da aprovação de quem faz o modelo
Marketplace e faturamento
- Compromissos de nuvem, termos de revenda
Nuvem e runtime que hospedam
- Região, retenção de dados, computação confidencial
Quem faz o modelo
- Políticas de uso, versões, datas de descontinuação
Cada camada pode mudar o que você recebe. Quem faz o modelo descontinua uma versão ou endurece uma política. A nuvem entrega um controle depois da API direta. O marketplace muda a forma como os compromissos contam. O gateway perde a aprovação. O runtime ganha um ponto de controle, ou não tem nenhum.
Por que “fornecedor” é a palavra certa
Os bancos brasileiros já sabem gerenciar uma cadeia assim; só ainda não aplicaram a ideia aos modelos. A Resolução CMN 4.893, de 2021, exige que as instituições supervisionadas pelo Banco Central avaliem e gerenciem os riscos ao contratar serviços de processamento e armazenamento de dados e de computação em nuvem, incluindo a capacidade de continuar operando se o serviço for interrompido. Grupos com operação na Europa respondem ainda ao DORA, a regulação europeia de resiliência operacional digital, que desde janeiro de 2025 cobra o mesmo tipo de gestão dos fornecedores de tecnologia. Um gateway que pode parar de servir um modelo na data em que uma política entra em vigor é exatamente o tipo de dependência para a qual essas regras foram escritas.
A maioria das empresas gerencia quem faz o modelo como fornecedor e trata todo o resto como encanamento. Esta semana mostrou que o encanamento tem as próprias regras. Quando a OpenAI pede aprovação aos gateways, um router que o seu time escolheu por conveniência vira um fornecedor com uma dependência relevante da decisão de outro fornecedor.
Cinco perguntas por rota
Para cada carga em produção, registre a rota, e não só o modelo, e responda a cinco perguntas:
- Quem pode cortar? Liste cada parte cuja decisão poderia parar essa carga: quem faz o modelo, a nuvem, o marketplace, o gateway. Para cada uma, com quanto aviso?
- Quais termos de dados valem? A API direta, o caminho pela nuvem e um router podem ter termos de retenção e tratamento diferentes para o mesmo modelo. Diga qual governa essa carga.
- Onde a requisição roda? Região e hospedagem importam para a residência de dados, inclusive diante da LGPD, e podem variar por caminho, como variaram para o mesmo modelo Claude no Azure e na AWS.
- Qual é a alternativa? Outro caminho para o mesmo modelo, ou outro modelo que passou na mesma avaliação. Uma alternativa nunca testada é uma esperança.
- Onde está a evidência? Qual log mostra qual rota atendeu qual requisição, com modelo e versão. Sem isso, a análise de um incidente não consegue reconstruir o que aconteceu.
O que você deve possuir na cadeia
O padrão do último ano, que descrevemos no nosso framework de portfólio de modelos, é que as empresas devem possuir as camadas que permitem trocar de fornecedor: conjuntos de avaliação, política de roteamento e o registro do que rodou onde. A visão de cadeia acrescenta mais uma: a própria camada de controle. A Databricks construiu o próprio gateway porque não conseguia gerenciar custo sem ver cada requisição. É nessa mesma camada que se enxergam as dependências, se aplicam as alternativas e se guarda a evidência.
Padrões de interface ajudam. A nova especificação Open Responses, da Agentic AI Foundation, por exemplo, quer fazer a chamada a um modelo parecer igual entre provedores. Uma interface comum barateia a troca de rota. Não diz de quais rotas você depende. Só um mapa diz.
A nossa expectativa, e é uma opinião e não um fato, é que até o ano que vem as rotas até os modelos apareçam nos inventários de risco de terceiros ao lado dos provedores de nuvem, com as mesmas perguntas sobre concentração, saída e aviso prévio. As empresas que desenharem o mapa agora vão achar essa conversa curta.