IA subsidiada hoje, cara amanhã: por que apostar em um modelo só é um risco de margem, e como o Bedrock resolve
O preço que você paga hoje por uma chamada de IA não é o custo real de servir aquela resposta. Boa parte da conta está sendo bancada por capital de risco, numa disputa por participação de mercado que a imprensa vem documentando. Para quem constrói produto ou processo em cima de um único modelo, isso é um risco de margem esperando a hora de aparecer. Este texto trata do porquê, e das duas rotas concretas para se proteger sem reescrever a sua aplicação: o Amazon Bedrock como camada multi-modelo e os modelos abertos rodando em infra própria.
Sou o Rodrigo Araújo, cofundador da RFX e arquiteto de soluções AWS. Uma pergunta que passou a aparecer nas reuniões com diretores e fundadores, principalmente depois que a IA saiu do piloto e virou parte do produto, é esta: "esse custo de IA que estou pagando é pra valer, ou uma hora a conta muda?". É uma boa pergunta, e a resposta honesta é que o preço de tabela de hoje reflete uma fase de mercado, não um equilíbrio de longo prazo. Quem monta a arquitetura ignorando isso está construindo em cima de uma premissa que pode não durar.
Quem está pagando a sua conta de IA hoje
A resposta direta: em boa medida, os investidores dos provedores de modelo. Treinar e servir um modelo de fronteira é caro de um jeito que o preço por token esconde. Treino consome meses de milhares de GPUs. E a inferência, cada resposta que o modelo gera para um usuário, é um custo recorrente que cresce com o uso, não some depois que o modelo fica pronto.
Os números públicos ajudam a dimensionar, e aqui vale a régua editorial da casa: nada disso é afirmação nossa sobre a saúde financeira de empresa privada, é o que veículos grandes reportaram, com atribuição.
Segundo documentos financeiros auditados revisados pela newsletter Where's Your Ed At e verificados de forma independente pelo Financial Times, noticiados pelo Yahoo Finance, a OpenAI teria registrado cerca de US$ 13 bilhões de receita em 2025 contra aproximadamente US$ 34 bilhões de gasto total no ano. Ainda segundo essa reportagem, só o gasto com inferência na Azure no primeiro semestre de 2025 teria passado de US$ 5 bilhões. É um retrato de quem serve IA muito abaixo do que arrecada, sustentado por rodadas de investimento.
Do outro lado, a Anthropic. Reportagem do TechCrunch com base em apuração do The Information indica uma margem bruta projetada perto de 50% para 2025, saindo de um patamar negativo de 94% em 2024. Ou seja: pelo que foi reportado, em 2024 servir os modelos custava quase o dobro do que se cobrava por eles. A trajetória melhora, e a Bloomberg noticiou que a receita anualizada da Anthropic superou US$ 9 bilhões no fim de 2025, mas o ponto de partida diz muito: o preço de IA vem de uma zona em que servir custava mais do que se cobrava.
A leitura executiva não é torcer contra ninguém. Essas empresas têm caixa e podem muito bem chegar à sustentabilidade. A leitura é sobre a sua margem: o preço que hoje você orça no seu plano de negócio carrega um subsídio de mercado. Quando a economia de servir modelo tiver que fechar, a correção de preço passa para o cliente, e o cliente é você.
Os sinais já apareceram nas ferramentas que você usa
Resposta direta: isso não é uma previsão distante. Nos últimos meses, os reajustes chegaram exatamente nas ferramentas de IA mais populares do mercado, sempre com o mesmo padrão: o plano fixo deixa de comportar o custo real e o acesso ao modelo mais avançado vira consumo medido.
GitHub Copilot. Em abril de 2026, o GitHub anunciou mudanças nos planos individuais do Copilot: os modelos Claude Opus saíram do plano Pro (ficando restritos ao Pro+, e mesmo lá com versões descontinuadas), novas assinaturas dos planos individuais chegaram a ser pausadas e o plano de estudantes perdeu a seleção de modelos premium. A justificativa oficial: os fluxos agênticos passaram a consumir muito mais computação do que a estrutura original dos planos suportava.
Anthropic. O Claude Fable 5, modelo mais avançado da empresa, ficou incluído nos planos pagos apenas até 7 de julho de 2026, com teto de uso semanal. Depois dessa data, o acesso passou a créditos de consumo cobrados à tarifa de API. A empresa afirma que a mudança é temporária e que pretende devolver o modelo às assinaturas quando houver capacidade. Ainda assim, o movimento mostra o mecanismo: quando o custo aperta, o modelo de ponta sai do plano fixo primeiro.
Cursor. Em junho de 2025, o editor de código com IA trocou o plano de 500 requisições rápidas por uma franquia em dólares consumida a preço de API. A mudança, mal comunicada, gerou reação forte dos usuários, pedido público de desculpas do CEO e reembolsos.
O padrão se repete nos três casos: quem construiu processo em cima de um único modelo, dentro de um plano fixo, descobriu o custo real de uma vez, sem aviso e sem plano B. É exatamente esse cenário que a arquitetura de diversificação evita.
O risco chega na sua margem, não no balanço deles
Já vi esse filme em outros setores, e ele costuma seguir o mesmo roteiro. Nos primeiros anos de nuvem, os créditos generosos de entrada faziam a conta parecer imbatível, até o projeto crescer, os créditos acabarem e o gasto real aparecer sem ninguém ter arquitetado para ele. Na mobilidade urbana por aplicativo, a corrida barata de 2016 era paga por investidor comprando mercado; alguns anos depois o preço subiu para o nível que sempre foi sustentável. O padrão é o mesmo: preço agressivo captura o mercado, o mercado vira dependência, e a correção vem depois que trocar de fornecedor já custa caro.
Onde isso morde no seu negócio: se o seu produto tem uma função de IA no caminho crítico e ela está amarrada à API de um provedor único, o seu custo unitário é refém de uma decisão de preço que não é sua. Um reajuste de tabela, ou o fim de um plano promocional, vira erosão direta de margem em um item que talvez seja o seu custo de produto (COGS). E, se a aplicação foi escrita colada no jeito específico daquele provedor, migrar deixa de ser uma troca de configuração e vira reescrita, exatamente no pior momento para fazê-la.
O antídoto não é adivinhar quando o preço sobe. É construir de um jeito que essa decisão deixe de ser um susto: preservar a capacidade de trocar de modelo, medir o custo por tarefa e nunca casar a sua arquitetura com um fornecedor só. É engenharia de opcionalidade, e na AWS ela tem duas rotas.
Rota 1: o Bedrock como camada multi-modelo
A resposta direta: o Amazon Bedrock é um serviço gerenciado que dá acesso a modelos de vários provedores (Anthropic Claude, os modelos Amazon Nova, Meta Llama, Mistral, entre outros) por uma API única. Trocar o modelo que atende uma função do seu produto passa a ser, na prática, mudar um identificador de modelo na chamada, não reescrever a aplicação. Essa é a proteção mais direta contra o lock-in de fornecedor.
O que isso muda no seu risco: quando o preço, a disponibilidade ou a qualidade de um modelo mudam, você tem para onde ir sem parar o produto. A relação deixa de ser "um fornecedor que dita o preço" e passa a ser "um mercado de modelos concorrendo pela sua carga". No post sobre IA generativa na AWS eu detalho o padrão de RAG e como o Bedrock se encaixa numa arquitetura; aqui o foco é o que ele resolve de estratégia de custo e dependência.
Tiering por tarefa: modelo caro só onde ele se paga
Um erro comum, e caro, é mandar tudo para o modelo mais poderoso disponível. A maioria das tarefas de um produto real não precisa do topo de linha. Classificar um e-mail, extrair três campos de um texto, decidir para qual fila mandar um chamado: isso roda bem em modelo pequeno e barato. Redigir uma resposta delicada a um cliente, raciocinar sobre um contrato longo: aí sim o modelo forte se justifica.
Tiering é isso: rotear cada tarefa para o modelo mais barato que a resolve com qualidade aceitável, e reservar o modelo caro para o que de fato exige. Numa camada multi-modelo, isso é decisão de roteamento, não de fornecedor. Nos projetos da RFX, é onde mora a maior economia silenciosa: a mesma funcionalidade, com a conta caindo de forma expressiva, só por parar de usar canhão para matar mosquito. E o efeito é dobrado para quem fatura em real, porque cada token cobrado em dólar sente o câmbio.
Benchmark e A/B de modelo como prática contínua
Modelo não é decisão de uma vez. O mercado lança versão nova toda hora, e o que era o melhor custo-benefício num trimestre muda no seguinte. Com o Bedrock, dá para tratar a escolha de modelo como se trata qualquer outra decisão de engenharia: com um conjunto de casos de teste representativos do seu uso, você compara modelos por qualidade, latência e custo, e roda testes A/B em produção antes de trocar de vez.
Isso transforma a diversificação de discurso em prática. Você não "acredita" que um modelo é melhor para a sua tarefa, você mede, no seu dado, com o seu critério de sucesso. É a mesma disciplina que aplico para custo de infraestrutura em FinOps: medir antes de afirmar, e deixar o número decidir.
Rota 2: modelos abertos em infra própria, e a conta honesta
A resposta direta: rodar modelos de pesos abertos (open-weights, como Llama e Mistral) na sua própria infraestrutura, em GPU no Amazon EC2 ou orquestrado no Amazon EKS, é uma opção real de independência. Mas é uma opção que compensa em cenários específicos, e quase nunca em volume baixo. Prometer que self-host é sempre mais barato seria desonesto, então vamos à conta.
O que pesa contra em volume baixo: GPU é cara e, diferente da chamada de API que você paga por uso, a GPU provisionada custa ligada mesmo parada. Se o seu tráfego de IA é intermitente, ou de algumas centenas de requisições por dia, você vai pagar por uma placa cara ociosa a maior parte do tempo. Some a isso o trabalho de operar o serviço de inferência, manter o modelo, garantir disponibilidade e escalar no pico. Nesse cenário, a API gerenciada, mesmo carregando o subsídio de mercado, tende a sair mais barata e muito mais simples.
Quando self-host passa a fazer sentido
A conta vira quando pelo menos um destes entra em jogo:
- Volume alto e estável. Se você tem carga de inferência grande e constante o suficiente para manter a GPU ocupada perto do talo, o custo por requisição da infra própria despenca e pode ficar bem abaixo do preço de API. Aqui a GPU parada deixa de ser desperdício porque ela quase não fica parada.
- Requisito de dado ou de residência. Cenários regulados, com dado sensível que não pode sair de um perímetro específico, ou exigência de residência de dado que a LGPD torna concreta em certos contratos, podem justificar rodar o modelo dentro de casa, na sua conta, na sua região.
- Fine-tuning pesado e especialização. Se o seu diferencial é um modelo profundamente ajustado ao seu domínio, com controle total sobre pesos e versões, a infra própria dá um grau de controle que a API gerenciada não oferece.
O papel do EKS aqui é o que torna isso operável sem virar um custo fixo eterno: com escalonamento automático de nós de GPU via Karpenter, o cluster sobe capacidade quando a demanda chega e devolve quando ela cai, aproximando o self-host do modelo de pagar mais pelo que usa. É a mesma lógica de elasticidade que defendo para qualquer carga sazonal: dimensionar na alta e desligar na baixa, em vez de comprar máquina para o pior dia do ano e pagar por ela 365 dias.
O ponto executivo: self-host não é a rota padrão, é a rota de exceção com gatilho claro. A maioria dos negócios começa e permanece muito bem na Rota 1. A Rota 2 entra quando volume, dado ou especialização mudam a conta, e a graça de desenhar direito é poder cruzar de uma para a outra sem refazer o produto.
A síntese executiva: arquitete para opcionalidade
Junte as duas rotas e a diretriz fica simples. O objetivo não é escolher hoje o modelo certo para sempre, é construir de um jeito que a escolha continue sua amanhã. Três decisões de arquitetura entregam isso:
- Abstraia o modelo. A sua aplicação fala com uma camada interna de IA, não com o SDK específico de um provedor espalhado pelo código. Trocar de modelo, ou de rota, vira mudança em um lugar. O Bedrock já ajuda nisso do lado do provedor; a sua camada de abstração fecha o lado da aplicação.
- Tenha contrato de fallback. Se o modelo primário fica indisponível, fica lento ou fica caro demais, a sua camada aponta para um alternativo automaticamente. Isso é resiliência de produto e é alavanca de negociação: quem tem para onde ir não fica refém de reajuste.
- Meça o custo por tarefa. Você precisa saber quanto custa cada função de IA do seu produto, por tarefa e por unidade de negócio, e não só a fatura total no fim do mês. Sem isso, tiering é chute e reajuste de preço é surpresa. Com isso, cada decisão de modelo vira número.
Essa terceira decisão puxa o próximo passo, que é onde a RFX mais gosta de atuar: controlar o gasto de IA no nível do código. Orçamento por contador, limites de tokens de entrada e saída por integração, cache de resposta, kill-switch quando o custo estoura. É o que já implementamos nos próprios backends deste site, e é tema de um próximo texto aqui no blog. A arquitetura de opcionalidade preserva a sua liberdade de escolher; o controle de custo no código garante que a escolha não fuja do orçamento no meio do mês.
Fecho com a régua que repito em todo projeto: a IA no seu negócio é uma decisão de arquitetura antes de ser uma decisão de fornecedor. Quem amarra o produto a um modelo único porque o preço de hoje é conveniente está terceirizando a própria margem. Quem constrói para trocar de modelo, medir por tarefa e cair para um alternativo quando precisa, mantém o controle onde ele deve ficar: com você. Esse é o recorte que fazemos na consultoria cloud da RFX, e o mesmo raciocínio de custo sob controle vale para a PME que está começando agora, como mostrei no post sobre IA aplicada na PME do Nordeste.
Vamos conversar pessoalmente
Se você quer discutir como desenhar a sua camada de IA para não ficar refém de um modelo só, semana que vem, dia 15 de julho, fazemos a segunda edição da Jornada AWS em João Pessoa. É onde donos e diretores da região trocam o que deu certo e o que não deu, ao vivo e sem enrolação. Custo e estratégia de IA é um dos temas que mais aparecem nas perguntas dos inscritos, e vamos tratar dele com o pé no chão. Se este texto fez sentido, o evento é o passo natural seguinte.
Jornada AWS 2026: IA aplicada ao negócio, ao vivo
Se este texto fez sentido, o evento é o próximo passo: casos reais e as suas perguntas respondidas na hora. Presencial e gratuito, vagas limitadas.
Garantir minha vagaPerguntas frequentes
Os preços de IA vão mesmo subir?
Ninguém sabe a data, e afirmar isso como certeza seria irresponsável. O que é fato público, com atribuição, é que provedores de modelo vêm operando com prejuízo expressivo e servindo IA abaixo do custo, sustentados por capital de risco, conforme reportagens do Financial Times, do The Information e da Bloomberg citadas neste texto. A conclusão prudente para quem planeja margem não é apostar em um preço, é construir de um jeito que uma eventual correção não vire crise: com liberdade de trocar de modelo e custo medido por tarefa.
O que é lock-in de modelo, na prática?
É quando o seu produto depende tanto de um modelo ou provedor específico que trocar de fornecedor exigiria reescrever parte da aplicação. Acontece quando o código chama direto o SDK de um provedor, usa recursos exclusivos dele e não tem uma camada de abstração no meio. O risco é duplo: você fica exposto ao preço que aquele fornecedor decidir cobrar e perde poder de negociação, porque sair custa caro.
O Amazon Bedrock resolve a diversificação de modelos?
Em boa parte, sim. O Bedrock dá acesso a modelos de vários provedores por uma API única, então trocar ou combinar modelos passa a ser mudança de configuração, não de arquitetura. Isso cobre a Rota 1 deste texto: multi-modelo, tiering por tarefa e teste A/B de modelo sem reescrever a aplicação. Para blindagem total, some uma camada de abstração no seu código e uma política de fallback, para não depender de nenhum recurso exclusivo de um provedor só.
Vale a pena rodar um modelo aberto na minha própria infraestrutura?
Depende do volume e do requisito. Em tráfego baixo ou intermitente, quase nunca compensa, porque a GPU provisionada custa caro mesmo parada e a API gerenciada sai mais barata e simples. Passa a fazer sentido com volume alto e estável (que mantém a GPU ocupada), com exigência de dado ou residência que peça rodar dentro do seu ambiente, ou com fine-tuning pesado. Nesses casos, EKS com escalonamento de GPU via Karpenter deixa o custo mais elástico. É rota de exceção com gatilho claro, não o caminho padrão.
Como fica o custo de IA para quem fatura em real?
O peso do câmbio é real e some ao risco de subsídio. Os modelos são cobrados em dólar e por consumo, então a sua receita em real fica exposta a duas variáveis fora do seu controle: a cotação e a política de preço do provedor. Diversificar modelo e fazer tiering por tarefa ataca a segunda, e medir o custo por tarefa deixa a primeira visível antes de virar surpresa na fatura. É a mesma disciplina de câmbio que trato no post sobre IA na PME do Nordeste.
Por onde começar a reduzir esse risco sem parar o produto?
Comece pela abstração: garanta que a sua aplicação fala com uma camada interna de IA, não com o SDK de um provedor espalhado pelo código. Com isso no lugar, ative o multi-modelo no Bedrock, implemente tiering roteando tarefas simples para modelos baratos e passe a medir o custo por tarefa. Fallback e controle de gasto no código vêm em seguida. Nenhum desses passos exige reescrever tudo de uma vez, e cada um já reduz a sua dependência. É o recorte que fazemos na consultoria cloud da RFX.
