O projeto parece simples na reunião de aprovação. O time pede três meses, uma ferramenta nova, algumas horas de engenharia e uma camada de visualização. O slide fala em ganho de produtividade, melhor visibilidade e decisão mais rápida. Ninguém discute o banco legado que vai precisar ser remendado, a integração que ainda não existe, a definição que muda entre áreas, o treinamento que vai consumir a operação nem a manutenção que começa no dia seguinte ao lançamento.
É assim que projetos de dados parecem baratos no começo. O custo visível cabe no slide. O custo real aparece depois, quando a solução precisa operar com dado imperfeito, usuário real, regra de negócio ambígua e dependência entre times que não trabalham com a mesma definição de sucesso.
Esse é o problema dos custos invisíveis. Eles não entram no orçamento inicial com a força que deveriam, mas aparecem mais tarde em forma de atraso, retrabalho, perda de confiança, disputa política, manutenção crônica e ROI envelhecendo mal.
O custo que cabe no slide
O custo visível costuma incluir poucas linhas: horas do time, licença ou ferramenta, infraestrutura, prazo de implementação e algum apoio de fornecedor. Essas linhas importam, mas contam só a parte mais fácil de defender.
O erro começa quando a empresa trata esse recorte como custo total. A aprovação fica otimista demais porque compara um benefício projetado com um custo artificialmente limpo.
Esse padrão não é periférico. Em julho de 2024, o Gartner estimou que pelo menos 30% dos projetos de gen AI seriam abandonados depois da prova de conceito até o fim de 2025 por causas como qualidade de dados insuficiente, controles de risco inadequados, custos crescentes ou valor de negócio pouco claro (Gartner, 2024). O protótipo parece barato justamente porque ainda não carrega o peso da operação.
O custo que aparece quando a entrega encontra a realidade
Quando a iniciativa sai do ambiente protegido do piloto, a conta muda. A fonte não tem a qualidade esperada, a definição da métrica diverge entre áreas, o pipeline precisa de refactoring, o jurídico entra tarde, o usuário não adota, o modelo precisa de monitoramento, a governança descobre uma restrição e o dashboard passa a competir com outras versões da verdade.
Nada disso é exceção. É a forma como o custo escondido se manifesta em dados.
Em fevereiro de 2025, o Gartner informou que 63% das organizações ou não têm, ou não sabem se têm, as práticas de gestão de dados adequadas para IA e previu que, até 2026, 60% dos projetos de IA sem dados AI-ready seriam abandonados (Gartner, 2025). O ponto mais importante aqui não é só a taxa de abandono. É o lembrete de que aquilo que não foi tratado na base volta como custo mais tarde.
Principais custos invisíveis
| Custo invisível | Como aparece |
|---|---|
| Preparação de dados | Limpeza, padronização, deduplicação e reconciliação. |
| Integração | Conectar sistemas legados, APIs, planilhas e fontes instáveis. |
| Governança | Definição, ownership, catálogo, lineage e contratos. |
| Manutenção | Monitoramento, correção, atualização e suporte. |
| Adoção | Treinamento, mudança de processo e acompanhamento de uso. |
| Retrabalho | Refazer solução porque o problema inicial estava mal formulado. |
| Dívida técnica | Atalhos que aceleram o piloto e encarecem a produção. |
| Custo de oportunidade | Capacidade consumida em algo que impede outra iniciativa melhor. |
O valor da tabela acima não está em listar itens. Está em lembrar que o custo real é a soma dessas camadas, e não apenas o esforço de construir.
O custo técnico que ninguém aprova, mas todo mundo paga
Uma das camadas mais negligenciadas é a base técnica que sustenta o projeto. Banco mal modelado, consultas frágeis, objetos sem critério, integrações improvisadas e ambientes desorganizados não aparecem como problema estratégico na aprovação. Só que aparecem depois como refactoring recorrente, lentidão de evolução, manutenção cara e gargalo para qualquer nova entrega.
Esse ponto é antigo demais para ser tratado como detalhe de engenharia. Em materiais autorais meus sobre otimização de banco de dados, a mesma tese se repetia em contextos diferentes: quando a origem do dado é frágil, o time passa a pagar um imposto contínuo para manter o negócio funcionando. O custo deixa de ser só técnico e vira custo de capacidade.
A McKinsey descreve esse mecanismo como tech debt, o imposto que a empresa paga para corrigir problemas de tecnologia enquanto tenta fazer desenvolvimento novo. No mesmo estudo, a firma observa que custos indiretos associados ao desenvolvimento de um produto podem, em alguns casos, representar até 80% do custo total ao longo da vida do produto, e que incentivos desalinhados geram decisões ruins de gasto com perda de 20% a 30% de valor (McKinsey, 2025).
Dados ruins não ficam baratos
Dados de baixa qualidade não reduzem custo. Eles empurram custo para frente, onde ele fica mais caro. O que não foi resolvido na origem volta como reconciliação manual, debate semântico, incidente, perda de confiança, auditoria emergencial ou retrabalho do time.
É por isso que Governança de Dados não deveria ser tratada como burocracia. Em operação séria, governança é parte do custo de trabalhar com confiança.
Piloto barato pode virar produção cara
Pilotos costumam rodar em ambiente protegido. A amostra é menor, o dado é mais limpo, o usuário é mais próximo, a regra é menos ambígua e a escala ainda não expôs todas as exceções. Por isso mesmo, o piloto pode ajudar a aprender, mas não deveria ser vendido como prova completa de custo.
Quando a solução entra em produção, chegam observabilidade, controle de acesso, LGPD, SLA, suporte, treinamento, integração, gestão de mudança e sustentação. O projeto que parecia enxuto na demonstração passa a exigir uma arquitetura que suporte a repetição do uso com previsibilidade.
O custo da adoção ignorada
Uma entrega que ninguém usa também tem custo. Ela consumiu time, criou expectativa, aumentou manutenção, ocupou espaço no portfólio e ainda pode contaminar a leitura futura sobre o valor da área de dados.
Esse custo é invisível porque muitas empresas tratam adoção como nota de rodapé. Só que valor não aparece no lançamento. Ele aparece quando o ativo entra de verdade na rotina de decisão, processo ou operação. O módulo Orquestração, Change Management e Adoção existe justamente para lidar com essa passagem.
O custo político
Projetos de dados também geram custo político. Quando uma métrica crítica diverge entre áreas, alguém precisa arbitrar definição. Quando um produto de dados perde confiança, a área técnica precisa reconstruir reputação. Quando a liderança recebe números inconsistentes, o problema deixa de ser a ferramenta e passa a ser a credibilidade do sistema inteiro.
Esse custo raramente entra na planilha inicial, mas afeta orçamento, prioridade, patrocínio e autoridade organizacional.
Como estimar melhor
Antes de aprovar uma iniciativa, faça uma revisão simples:
- quais fontes serão usadas;
- quem é dono de cada fonte;
- que definição pode gerar conflito;
- que restrição de privacidade ou compliance existe;
- que parte da base técnica precisará evoluir para sustentar a entrega;
- quem vai operar depois do lançamento;
- como adoção será medida;
- que manutenção recorrente será necessária;
- qual iniciativa deixará de ser feita.
Se a resposta para metade dessas perguntas for incerta, o custo real ainda está subestimado.
Relação com ROI
ROI de dados depende tanto do retorno quanto do custo real. A discussão executiva costuma errar quando infla benefício, simplifica custo e ignora o trabalho necessário para transformar protótipo em sistema confiável.
O efeito prático é um business case que aprova bem e envelhece mal. O artigo Como provar ROI de dados organiza essa conta. O artigo ROI do não mostra o outro lado: em muitos casos, o melhor retorno está em interromper cedo o projeto cujo custo completo não fecha.
O papel do Data Translator
O Data Translator ajuda a expor custo invisível antes da aprovação. Ele conversa com engenharia sobre esforço real, com governança sobre definição e qualidade, com produto sobre adoção, com negócio sobre decisão e com liderança sobre custo de oportunidade.
Esse trabalho reduz surpresa e melhora a qualidade do "não", do "não agora" e do "sim, mas com outra sequência". A própria McKinsey mostra que, entre 25 atributos testados, o redesenho de workflows foi o fator com maior correlação com impacto em EBIT no uso de gen AI (McKinsey, 2025). Em outras palavras, a tecnologia sozinha não captura valor. O valor aparece quando custo, processo, adoção e decisão são tratados como parte do mesmo desenho.
Se quiser diagnosticar essa capacidade, faça o Radar de Competências e observe se você consegue estimar valor e custo antes de uma demanda virar backlog.