O número que devia estar na sua planilha
Quem precifica uma funcionalidade de IA usando a régua do SaaS carrega uma ilusão cara. Custo de servidor baixo, margem bruta de 80%, o resto vira lucro ou caixa pra crescer. A conta de inferência não segue essa régua. Ela cresce junto com o uso, entra no custo do produto vendido e não sai do resultado nunca mais.
O relatório State of AI de julho de 2026, da ICONIQ, mediu isso em centenas de empresas de software que vendem produto com IA generativa. A margem bruta média desses produtos foi de 41% em 2024, passou pra 45% em 2025 e chegou a 53% em 2026, com projeção de 59% em 2027. O benchmark de SaaS maduro sem IA fica na faixa de 80% a 90%. Mesmo com três anos seguidos de melhora, o produto de IA ainda está a mais de 20 pontos de distância, e o próprio relatório trata 2027 como teto otimista, não como meta garantida.
| Ano | Margem bruta média, produto de IA | Margem bruta, SaaS maduro |
|---|---|---|
| 2024 | 41% | 80% a 90% |
| 2025 | 45% | 80% a 90% |
| 2026 (projeção) | 53% | 80% a 90% |
| 2027 (projeção) | 59% | 80% a 90% |
Por que o custo não se comporta como em SaaS
Em SaaS tradicional, o código roda e o custo marginal de mais um usuário é quase zero. Em produto de IA, toda chamada ao modelo consome computação de verdade, e essa conta cai direto no custo do produto vendido, não em pesquisa e desenvolvimento. Quanto mais o cliente usa o produto, mais a empresa gasta pra entregar o mesmo produto pra ele. É o inverso do efeito de escala que founder acostumado com SaaS aprendeu a esperar. E é por isso que tanto plano de preço fixo mensal quebra assim que o uso passa da média.
Margem de produto de IA não é bug que a engenharia resolve sozinha. É decisão de preço e arquitetura que o dono revisa todo trimestre.
Isso vale mesmo quando IA não é o produto principal
O founder que vende IA como produto costuma já saber disso, porque a conta chega rápido. Quem sofre em silêncio é o founder que só colocou um assistente ou uma automação de IA dentro de um produto que já existia, cobrando o mesmo preço de antes. A funcionalidade nova não veio com linha própria no orçamento, então o custo de inferência se mistura com o resto da infraestrutura e ninguém percebe a margem caindo até o fechamento do trimestre. Empresa que roda SaaS com IA embutida sem separar essa conta está tomando a mesma decisão de precificação errada, só que sem o relatório pra avisar.
O que separou quem melhorou de quem não melhorou
Na mesma pesquisa, 66% das empresas melhoraram o custo por consulta em pelo menos 10% no último ano, e 19% melhoraram 30% ou mais. Não foi sorte, nem modelo mais barato aparecendo de graça. As quatro respostas que mais apareceram, nessa ordem, foram: cortar custo de inferência direto na configuração do modelo, rotear tarefa simples pra modelo barato e só escalar pro modelo caro quando a tarefa exige, crescer receita rápido o bastante pra diluir custo fixo, e trocar modelo proprietário por modelo aberto em partes do fluxo que não precisam do modelo mais forte.
Repare que nenhuma das quatro é esperar o preço do modelo cair sozinho. É decisão de arquitetura, tomada por quem constrói o produto, revisada com a mesma frequência de quem olha runway todo mês.
O que fazer na segunda de manhã
Refaça o modelo financeiro do produto de IA assumindo margem bruta de 50% a 55%, não 80%. Se o plano de caixa hoje usa a margem do resto do produto pra projetar a funcionalidade de IA, o buraco só aparece quando já não dá mais pra corrigir preço sem brigar com cliente.
Meça custo real de inferência por usuário ativo, não custo médio da empresa inteira. Usuário pesado em produto de IA custa muito mais que usuário leve, e média esconde essa diferença até a fatura de um mês ruim.
Decida a política de roteamento de modelo antes de escalar, não depois que a conta chegar: qual tarefa vai pro modelo barato por padrão, qual justifica o modelo caro, e quem aprova a exceção.
Trate essa arquitetura de custo como decisão de dono, não como problema que a engenharia resolve sozinha nas horas vagas. É o tipo de decisão que devia estar no diagnóstico técnico, antes da primeira linha de código, que é o que a consultoria de software da Overflow faz antes de qualquer proposta.
