Resposta rápida: Nove custos de IA ficam fora da proposta: a arrumação do dado antes de começar, o tempo do time interno, a manutenção da instrução quando a regra muda, o consumo variável que escala de forma não linear, a integração com o sistema legado, a monitoria e a revisão humana contínuas, a formação e a reciclagem do time, o custo de sair do fornecedor, e o processo paralelo que continua rodando durante a transição. Juntos, costumam somar mais que a licença, e nenhum deles é omissão de má-fé: são custos da empresa, e a proposta só cobre o que o fornecedor entrega.
Existe uma conversa que se repete no terceiro trimestre de todo projeto. O executivo olha o realizado, compara com a proposta aprovada e pergunta como a conta dobrou se o fornecedor cobrou exatamente o que combinou. A resposta quase sempre é a mesma: o fornecedor cobrou o combinado, e o projeto custou outra coisa.
Vale declarar o viés antes de seguir: eu vendo implementação de IA, e esta lista torna as propostas do meu setor mais difíceis de aprovar, inclusive as minhas. Escrevo assim mesmo porque projeto que estoura orçamento no meio do caminho é pior para quem entrega do que projeto que nasce com a conta certa.
O critério: custo real que a empresa paga e que não está no documento
Entrou na lista o custo que a empresa desembolsa ou consome de verdade e que não aparece como linha na proposta comercial. Ficou de fora o custo de oportunidade e a estimativa de risco, que são conversas legítimas de outra natureza e que ninguém consegue colocar numa planilha de aprovação sem virar chute.
A ordem segue a linha do tempo do projeto, do que aparece antes de começar ao que só chega depois do primeiro ano. Essa ordem importa porque o padrão de estouro é característico: os três primeiros derrubam o cronograma, os três do meio derrubam o orçamento corrente, e os três últimos derrubam a renovação.
Uma observação sobre ordem de grandeza. Eu evito publicar percentual, porque a variação entre empresas é grande demais para que um número médio ajude alguém. O que eu faço é indicar como dimensionar cada item na sua própria casa, que é mais trabalhoso e menos errado.
Vale dizer também o que esta lista não é. Ela não serve como acusação ao fornecedor, e usá-la assim na mesa de negociação estraga a conversa que interessa. Nenhum dos nove itens é responsabilidade contratual de quem vende, e o bom fornecedor costuma ficar aliviado quando o comprador levanta esses pontos antes, porque projeto que estoura no meio também queima a reputação dele. A pergunta produtiva é o que o cronograma pressupõe da nossa parte, e não o que você deixou de cobrar.
1. A arrumação do dado antes de começar
O que é: deduplicar cadastro, padronizar campo preenchido a esmo, reconciliar base que diverge entre sistemas, escrever a regra de negócio que ninguém documentou. Nada disso é IA, e sem isso a IA entrega saída errada com forma convincente.
Por que some da proposta: o fornecedor de IA cota o que ele faz. A arrumação do dado é trabalho da empresa, muitas vezes de uma área diferente da que está comprando, e frequentemente ninguém pergunta o tamanho dela antes de aprovar o cronograma.
Como dimensionar: peça a uma pessoa que conhece a base para pegar uma amostra de duzentos registros e classificar quantos estão utilizáveis como estão. A proporção que sair dessa amostra é a melhor estimativa disponível, e ela costuma surpreender para baixo. Se a resposta for que ninguém consegue fazer essa amostra em uma tarde, isso também é informação: significa que a base não tem dono. Um detalhe de sequência que economiza dinheiro: dá para usar IA na própria arrumação, deduplicando e sugerindo preenchimento com revisão humana. É menos vistoso que o projeto principal e costuma ser o trabalho de maior retorno do primeiro trimestre. Vale ler arrumar dados antes da IA, a ordem que funciona.
2. O tempo do time interno
O que é: as horas de quem conhece o processo, gasta em workshop, validação, teste, correção de rumo e resposta a dúvida do fornecedor. São as pessoas mais ocupadas da empresa, porque são justamente as que dominam o assunto.
Por que some da proposta: hora interna não vira fatura, e o que não vira fatura não entra na planilha de aprovação. O custo aparece deslocado, em entregas atrasadas de outra frente, e quase nunca é atribuído ao projeto de IA que o causou.
Como dimensionar: pergunte ao fornecedor quantas horas de pessoa da casa o cronograma pressupõe, por semana e por perfil. Fornecedor sério tem esse número e ele costuma ser maior do que o comprador imagina. Depois multiplique pelo custo real da hora dessas pessoas, incluindo o que elas deixam de fazer. É o item que mais frequentemente dobra a conta e o que menos aparece em post-mortem, porque ninguém gosta de contabilizar o próprio tempo. Existe um agravante de concentração: o projeto quase sempre precisa das mesmas duas ou três pessoas, aquelas que conhecem o processo de ponta a ponta. Se uma delas tirar férias ou pedir demissão no meio, o cronograma para, e nenhuma cláusula contratual protege contra isso.
Leia também
3. A manutenção da instrução quando a regra muda
O que é: alguém precisa atualizar o que o agente sabe toda vez que política, tabela de preço, regra fiscal ou procedimento mudar. Testar, publicar, conferir que não quebrou outra coisa.
Por que some da proposta: o contrato de suporte cobre indisponibilidade e defeito, e não mudança de regra de negócio, que é responsabilidade da empresa. A distinção é justa e quase nunca é explicitada na conversa comercial.
Como dimensionar: conte quantas vezes esse processo mudou de regra nos últimos doze meses. Multiplique por algumas horas de quem vai manter. Se o número de mudanças for alto e não existir uma pessoa com nome e tempo alocado para isso, o custo real deste item não é de manutenção: é o custo de operar por meses com uma automação silenciosamente errada, que é muito maior e chega sem aviso. A pergunta que resolve isso na negociação é direta: quem atualiza o agente quando a nossa tabela de preço mudar, e em quanto tempo. Se a resposta envolver abrir chamado e esperar orçamento, some esse prazo a cada mudança prevista no ano.
4. O consumo variável que escala de forma não linear
O que é: o gasto por uso, que no piloto é irrisório e na operação vira linha relevante. Cresce com o número de pessoas, com o tamanho das tarefas e com a sofisticação do que o time aprende a pedir.
Por que some da proposta: a estimativa é feita com dados do piloto, em que poucas pessoas usavam pouco. A premissa parece razoável e é errada, porque o uso maduro não é o uso inicial multiplicado por pessoas.
Como dimensionar: peça a projeção em três cenários e exija a premissa de cada um por escrito. Depois olhe a curva do piloto por semana, e não a média do período, porque a média esconde a aceleração. O sinal de alerta é o fornecedor que responde com um número único e sem premissa declarada. Vale olhar também o que acontece quando o time fica bom: pessoa experiente pede tarefas maiores, com mais contexto e mais passos, e cada uma custa mais que a tarefa iniciante. O consumo cresce junto com a maturidade, o que é uma boa notícia operacional e uma surpresa orçamentária. Vale ler custo unitário de IA e FinOps para o CFO.
Leia também
5. A integração com o sistema legado
O que é: fazer o agente conversar com o ERP de vinte anos, com o sistema que a empresa comprou de um fornecedor que não existe mais, ou com a planilha que virou banco de dados por acidente.
Por que some da proposta: o fornecedor cota a integração que conhece, com sistema que tem interface documentada. O legado só é examinado depois do contrato assinado, e é ali que aparece a necessidade de um trabalho que ninguém previu.
Como dimensionar: antes de assinar, liste os sistemas que precisam ser tocados e pergunte, para cada um, se existe interface documentada e quem na empresa a conhece. Sistema sem interface e sem pessoa que o conheça é o maior risco de cronograma do projeto inteiro. Vale antecipar essa conversa mesmo que ela atrase a assinatura em duas semanas, porque ela evita atrasar a entrega em dois meses. O caso mais caro que eu vi envolvia um sistema que só aceitava leitura por exportação manual em horário fixo. Tecnicamente havia integração, e na prática o agente dependia de um arquivo que uma pessoa gerava toda manhã, o que reintroduziu no fluxo exatamente o gargalo humano que o projeto queria remover.
6. A monitoria e a revisão humana contínuas
O que é: alguém lendo amostra de saída toda semana, classificando erro, tratando a fila de exceção e ajustando o que precisa. Trabalho permanente, e não tarefa de implantação.
Por que some da proposta: o projeto é vendido como implantação com fim, e a operação é tratada como algo que a empresa absorve. Em processo com cliente na ponta, essa absorção tem tamanho, e ela nunca é zero.
Como dimensionar: estime o volume que vai passar pelo agente, defina a fração que será revisada por amostra e o tempo por item revisado. Some a fila de exceção, que costuma ser maior no começo. O número que sai daí é uma fração de pessoa por semana, e o erro comum é assumir que essa fração cabe no tempo livre de alguém que já está cheio. Quando cabe no tempo livre de ninguém, a monitoria simplesmente deixa de acontecer. E o efeito da ausência é silencioso, porque o painel continua mostrando volume atendido e tempo de resposta, indicadores que melhoram mesmo quando a qualidade cai. A empresa só descobre pelo canal mais caro possível, que é o cliente reclamando de algo que vinha acontecendo havia semanas.
7. A formação e a reciclagem do time
O que é: ensinar as pessoas a operar com a ferramenta, e reensinar quando a ferramenta muda, quando entra gente nova e quando o processo é redesenhado. É custo recorrente, e não evento único.
Por que some da proposta: quando existe, aparece como um treinamento de implantação, com carga horária fechada. A reciclagem que vem depois não é de ninguém, e a rotatividade natural do time garante que ela seja necessária.
Como dimensionar: pegue a rotatividade da área e o número de pessoas que precisam operar. Some as mudanças de ferramenta esperadas no ano. O resultado é uma trilha permanente e não um curso, e a diferença entre as duas coisas aparece no orçamento do segundo ano. Empresa que trata formação como evento descobre no ano seguinte que metade dos usuários treinados saiu ou mudou de função. Há ainda a parte que quase ninguém orça: formar quem revisa. Operar a ferramenta se aprende rápido, e julgar se a saída está certa exige conhecer o processo a fundo. É uma competência mais escassa e mais cara, e ela precisa ser mantida justamente enquanto a automação reduz as oportunidades de praticá-la.
Leia também
8. O custo de sair do fornecedor
O que é: o que a empresa paga se decidir trocar. Migração de dado, refazer integração, reescrever a instrução, retreinar o time, e o tempo em que os dois sistemas rodam juntos.
Por que some da proposta: nenhum fornecedor cota o custo da própria saída, o que é compreensível. E o comprador não pergunta, porque perguntar sobre saída no momento da compra parece falta de confiança.
Como dimensionar: pergunte, ainda na negociação, em que formato a empresa recupera os próprios dados e as próprias configurações, e em quanto tempo. A resposta é reveladora mesmo quando o produto é bom. O custo maior nem sempre é técnico: é que o processo foi redesenhado em volta daquela ferramenta, e trocar significa redesenhar de novo. Existe uma assimetria que vale conhecer na renovação: o fornecedor sabe exatamente quanto custaria para você sair, porque ele acompanha o seu uso, e você normalmente não sabe. Fazer essa conta uma vez por ano, mesmo satisfeito com o serviço, é o que devolve poder de barganha à mesa. Vale ler dependência de fornecedor de IA e lock-in.
9. O processo paralelo durante a transição
O que é: o período em que o jeito antigo continua rodando junto com o novo, porque ninguém desliga o que funciona antes de confiar no que chegou. Duas operações, custo dobrado.
Por que some da proposta: o cronograma assume corte limpo numa data. Na prática o paralelo se estende, às vezes por meses, porque desligar exige uma decisão que ninguém quer assinar sozinho.
Como dimensionar: defina antes de começar qual é o critério objetivo de desligamento do processo antigo e quem assina esse desligamento. Sem critério e sem nome, o paralelo vira permanente e o projeto nunca captura a economia que justificou o investimento. Este é o item que mais destrói caso de negócio, porque a economia prometida depende inteiramente de o processo antigo parar. O critério que funciona é numérico e combinado antes: por exemplo, o agente resolve uma proporção definida dos casos por quatro semanas seguidas, com taxa de erro abaixo de um limite acordado. Sem número, a decisão vira sensação, e sensação nunca é suficiente para alguém assumir o risco de desligar.
Leia também
O mapa em uma tabela
| custo | quando aparece | por que some da proposta | como dimensionar |
|---|---|---|---|
| Arrumação do dado | antes de começar | é trabalho da empresa | amostra de 200 registros |
| Tempo do time interno | durante todo o projeto | hora interna não vira fatura | horas por semana no cronograma |
| Manutenção da instrução | a partir do segundo mês | suporte cobre defeito, não regra | mudanças de regra em 12 meses |
| Consumo variável | cresce após adoção | estimado a partir do piloto | curva semanal, não média |
| Integração com legado | depois de assinar | legado só é visto depois | interface documentada por sistema |
| Monitoria contínua | operação permanente | vendido como implantação com fim | volume e fração revisada |
| Formação e reciclagem | recorrente | tratada como evento único | rotatividade da área |
| Custo de sair | na renovação | ninguém cota a própria saída | formato e prazo de devolução do dado |
| Processo paralelo | durante a transição | cronograma assume corte limpo | critério e dono do desligamento |
Quando nenhum destes nove custos deve travar a decisão
Esta lista tem um mau uso previsível: virar argumento para não fazer nada. Em empresa com resistência a mudança, nove custos ocultos são munição perfeita para adiar indefinidamente, e adiar também custa, com a diferença de que o custo do adiamento nunca aparece em planilha nenhuma.
Existe também o caso em que quase nada disso se aplica. Ferramenta de prateleira, usada por um time pequeno, em processo que não toca sistema legado nem cliente final. Ali o custo real fica perto do preço de lista, a decisão é barata e reversível, e exigir análise de nove linhas antes de testar é burocracia que custa mais que o erro possível.
A régua para separar os dois casos é o grau de irreversibilidade. Quando o processo vai ser redesenhado em volta da ferramenta e o time vai depender dela, a conta completa vale o trabalho. Quando dá para desligar na sexta sem consequência, teste e descubra.
Existe um terceiro caso que merece nota, porque ele engana. A empresa faz a análise completa, chega a um número alto, e conclui que IA sai cara. O que costuma estar errado ali é o escopo, e não a conta: o projeto foi desenhado grande demais para o estágio da casa. Refazer o escopo com um processo só, com dado que já está limpo e sem tocar o legado, derruba sete das nove linhas de uma vez. A conta alta é frequentemente um sinal de escopo mal escolhido.
A régua que eu deixo com o líder
Antes da próxima aprovação, coloque as nove linhas ao lado da proposta e preencha o que der, mesmo com estimativa grosseira. As que você não conseguir estimar são as perguntas que faltam ao fornecedor, e fazê-las antes de assinar muda a conversa comercial de forma mensurável. Reserve meia hora para isso com quem conhece o processo, e não sozinho na sua sala, porque três das nove linhas só quem opera consegue estimar.
E leve o número consolidado para a aprovação, com a premissa declarada. Executivo que aprova a conta completa e erra dentro da faixa mantém credibilidade. O que aprova só a licença e volta em seis meses pedindo suplementação perde a próxima. Para o outro lado dessa mesma conta, o que ninguém conta sobre o ROI da IA trata do que entra como retorno.