Custo de automação com IA: a conta é por execução
Automação tradicional tem custo fixo. Você paga para construir uma vez e cada execução seguinte sai praticamente de graça. Quando um modelo de linguagem entra no fluxo, isso inverte: o custo passa a ser cobrado por execução e cresce junto com o volume. A conta não muda de tamanho, muda de unidade.
Por que a conta muda quando um modelo entra no fluxo?
Porque o trabalho deixa de ser executado por uma instrução escrita uma vez e passa a ser produzido de novo a cada chamada. Um script que classifica pedidos por regra roda dez mil vezes pelo custo de manter o servidor ligado. Um modelo que classifica pedidos lendo o texto cobra dez mil vezes.
Essa diferença não aparece no piloto. Com trinta casos por semana, qualquer desenho parece barato. Ela aparece quando a automação encosta no volume real da operação, que é exatamente o momento em que o ganho deveria aparecer.
O efeito colateral é que o risco financeiro do projeto inverte de sinal. Numa automação por regra, o cenário ruim é o baixo uso: você paga para construir e ninguém usa. Numa automação com modelo, o cenário caro é a adoção. Quanto mais a operação usa, maior a fatura do mês seguinte.
O preço por token caiu. Por que a conta não cai junto?
Preço e consumo são coisas diferentes, e só o preço caiu.
O AI Index 2025, de Stanford, mediu a queda: para um modelo com 64,8 pontos no MMLU, o nível do GPT-3.5, a inferência custava US$ 20 por milhão de tokens em novembro de 2022 e US$ 0,07 por milhão em outubro de 2024. Numa prova mais difícil, o GPQA, o mesmo relatório registra US$ 15 por milhão em maio de 2024 e US$ 0,12 em dezembro do mesmo ano. A Epoch AI, citada ali, estima quedas entre 9 e 900 vezes por ano conforme a tarefa.
O consumo foi na direção oposta. Modelos que raciocinam antes de responder produzem tokens intermediários, e você paga por eles. O OckBench, preprint de novembro de 2025 revisado em junho de 2026 e ainda sem revisão por pares, avaliou 37 combinações de modelo e nível de esforço em 200 problemas de matemática, engenharia de software e ciência. O resultado que importa aqui: dois modelos com acurácia praticamente igual, 82,5% contra 82,0%, gastaram em média 83,6 mil e 3,2 mil tokens.
Noutra linha da mesma tabela, uma configuração com preço por token bem mais baixo ficou um pouco abaixo em acurácia e ainda assim saiu mais cara na rodada inteira, US$ 12,60 contra US$ 9,50, porque escreveu muito mais.
Os autores chamam o efeito de imposto do excesso de raciocínio: um modelo pode parecer eficiente pela contagem de parâmetros ou pelo preço por token e ainda assim sair caro, por gerar rastros de raciocínio longos e de baixo rendimento.
Quem compara modelos profissionalmente já trocou de unidade. A Artificial Analysis publica custo por tarefa e explica o motivo na própria metodologia: como o custo reflete o uso real de tokens, modelos que produzem respostas mais longas ou mais tokens de raciocínio têm custo por tarefa maior, mesmo com preço por token idêntico.
Para quem decide orçamento, a leitura prática é curta. O preço da tabela não é o custo do seu processo, e a escolha do modelo é uma decisão de engenharia com consequência financeira mensal.
Quantas vezes por mês esse processo roda?
Essa é a pergunta que decide o projeto, e ela quase nunca está no orçamento.
Automação por regra melhora com volume, porque o custo de construir se dilui a cada execução. Automação com modelo não dilui nada, já que o custo é linear. As duas podem ter o mesmo valor de contrato e comportamentos financeiros opostos no mês seguinte.
Isso muda a conta do retorno da automação. Payback em meses descreve bem um investimento que acontece uma vez. Aqui a unidade útil é outra: custo por caso processado contra custo humano por caso, com um teto escrito para o primeiro. Sem teto, o sucesso do projeto é o que estoura o orçamento.
E existe o custo que não é de inferência. Alguém confere a saída, alguém trata o caso que o modelo recusou, alguém percebe quando a qualidade cai. Esse trabalho entra no custo de manter o sistema depois de pronto e quase nunca aparece na planilha de aprovação.
Como isso fica numa distribuidora
Um cenário, para deixar a aritmética visível. Os números abaixo são hipótese de trabalho, não medição de cliente.
Uma distribuidora recebe pedidos por e-mail e WhatsApp em texto livre. Duas pessoas transcrevem para o ERP. São 300 pedidos por dia, cerca de 6.600 por mês.
No primeiro desenho, o modelo recebe o e-mail inteiro, o histórico do cliente, a tabela de preços completa e as regras comerciais, e devolve o pedido pronto para lançar. Funciona na demonstração.
No segundo, o sistema já sabe quem é o cliente pelo remetente, qual tabela se aplica a ele e o que ele comprou nas últimas doze vezes. O modelo recebe o texto do pedido e resolve apenas o que está ambíguo nele.
Os dois entregam o mesmo resultado, e a diferença de custo por pedido não está no modelo. Está em quanto contexto precisa ser reenviado a cada execução porque o sistema não guardou nada. A aritmética você roda com os seus próprios preços: multiplique o tamanho do contexto de cada desenho pelo preço por token do seu fornecedor e depois pelo volume do mês, que aqui é 6.600. No primeiro desenho, a distribuidora paga 6.600 vezes por mês para o modelo redescobrir o que o cadastro dela deveria saber.
Como as empresas brasileiras estão colocando o modelo no fluxo
Fora do cenário, a medição existe. A pesquisa TIC Empresas 2025, do Cetic.br entrevistou 4.174 empresas e encontrou IA em 17% delas, contra 13% em 2024. Entre as pequenas, de 10 a 49 pessoas, a adoção passou de 10% para 15%.
O caminho de entrada diz mais que o percentual. Entre as empresas que usam IA, 80% adquiriram software pronto e 60% contrataram fornecedor externo para desenvolver ou adaptar, caminhos que se sobrepõem. O coordenador do estudo, Leonardo Melo Lins, descreve o movimento como adaptação dos processos das empresas, e não mudança estrutural na forma como operam.
O estudo não trata de custo por execução. Ele descreve a condição que produz esse custo: o modelo entra por cima do processo que já existe, e o processo que já existe não guarda contexto.
Quatro decisões antes de colocar o modelo no fluxo
- Separe regra de julgamento. Tabela de preço, alçada por valor, prazo por região e política de desconto são regras, e regra escrita não cobra por execução. Quanta autonomia dar ao modelo é uma decisão posterior a essa.
- Defina a unidade de cobrança do processo: por pedido, por documento, por atendimento. Escreva o teto de custo aceitável por unidade antes de aprovar e trate o estouro como defeito, não como sucesso comercial.
- Liste o que precisa ir junto em cada chamada e pergunte por que aquilo não está guardado. Contexto reenviado é cadastro que falta.
- Escreva o que acontece quando o volume dobra. Quem é avisado, qual o limite por dia, o que degrada primeiro.
Perguntas frequentes
Como calcular o retorno de uma automação que cobra por execução?
Meça o custo humano por caso hoje, com o tempo real de quem executa, e compare com o custo por caso da automação, somando inferência, conferência e tratamento de exceção. Rode o cálculo no volume do mês mais cheio do ano, nunca na média. Se o retorno só existe enquanto o volume fica baixo, não existe retorno.
Se o preço dos modelos cai todo ano, vale a pena esperar?
Esperar o preço não resolve o que pesa na sua conta. A diferença entre uma automação cara e uma barata, na mesma tarefa, vem do desenho do fluxo e do que o sistema guarda, e o preço por token cai para todo mundo ao mesmo tempo. Separar regra de julgamento e organizar o cadastro leva meses de trabalho e não fica obsoleto.
Não tenho equipe qualificada para implementar. Isso muda a conta?
Muda, no ponto que costuma ser subestimado: decidir onde o modelo entra no fluxo vale mais que escolher o modelo. Comprar pronto resolve a operação básica e mantém o custo unitário invisível, o que funciona enquanto o volume é pequeno. Se o processo é o seu diferencial e roda milhares de vezes por mês, alguém precisa responder pela arquitetura, interno ou contratado.
O próximo passo
Se você está prestes a colocar um modelo dentro de um processo que roda milhares de vezes por mês, vale olhar o fluxo antes do orçamento: o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos sobre isso.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico