A cena se repete em empresas de todos os tamanhos. Um VP chega com uma proposta pra automatizar reports executivos usando agentes de AI. O time já testou num piloto, o output parece correto, o board vai adorar a narrativa de inovação. O pedido: 4 engenheiros por 3 meses. O VP provavelmente sabe que existem riscos, mas não tem a quem recorrer pra mapeá-los formalmente antes de levar a proposta pra cima.
O que ninguém checou antes de aprovar: as unidades de crédito e de seguros usam definições diferentes de "cliente ativo." A fonte de dados do piloto não passa por validação formal de qualidade. O pipeline que alimentaria o modelo em produção ainda não existe, e construí-lo levaria mais que os 3 meses do projeto inteiro. O report do piloto estava correto por acidente: rodou numa amostra limpa que não refletia o ambiente real.
Se alguém com repertório suficiente pra cruzar essas dimensões tivesse avaliado antes da aprovação, o projeto teria morrido em uma semana de diagnóstico. Sem essa triagem, o cenário provável é conhecido: meses de desenvolvimento, um relatório automatizado que chega ao board com números divergentes dos que finanças apresentou na mesma reunião, e a credibilidade da área de dados comprometida por tempo indeterminado.
Esse cenário é baseado em padrões que se repetem em organizações de todos os portes e setores. Eu trabalho com dados desde 2004 e vi versões dessa história em fintech, govtech, marketplace e autotech. Se você trabalha com dados, produto ou engenharia, provavelmente reconheceu alguma versão dele na sua empresa. A pergunta que esse artigo tenta responder: quem deveria ter puxado o freio, e com base em quê?
Os números que confirmam o padrão
A taxa de falha de projetos de AI dobrou em um ano. Segundo compilação de dados da RAND, MIT, Gartner e S&P Global, a proporção de empresas que abandonam a maioria de suas iniciativas de AI antes de chegarem a produção subiu de 17% em 2024 para 42% em 2025. A organização média descarta 46% dos seus proofs of concept no caminho. A RAND Corporation cita estimativas segundo as quais mais de 80% dos projetos de AI fracassam, o dobro da taxa de projetos de TI tradicionais. Dados preliminares do MIT NANDA Initiative, baseados em 150 entrevistas e análise de 300 deployments públicos, reforçam o quadro: apenas 5% dos pilotos de GenAI geram aceleração real de receita.
O custo de cada fracasso tem número. A S&P Global calculou US$4,2 milhões de custo médio afundado por projeto abandonado, com tempo mediano de 11 meses até a organização admitir que não vai funcionar. Onze meses de time alocado, infraestrutura provisionada e custo de oportunidade acumulando antes de alguém puxar o freio.
OS NÚMEROS: O Gartner prevê que mais de 40% dos projetos de agentic AI (AI com agentes autônomos, como os do cenário que abrimos, capazes de executar tarefas sem intervenção humana a cada passo) serão cancelados até 2027. Parte do problema é o que o próprio Gartner chama de "agent washing": de milhares de vendors que afirmam ter capacidades de AI agêntica, apenas cerca de 130 são legítimos. O resto rebatiza chatbots e automações existentes sem governança real. O motivo que lidera os cancelamentos é consistente: "poor use-case selection combined with lack of clear business value" (seleção ruim de use case combinada com falta de valor de negócio claro). A tecnologia raramente é o gargalo principal. Em muitos desses casos, o problema central está na seleção ruim do caso de uso, no valor mal definido e na ausência de triagem estratégica antes do commitment de recursos.
O instinto diante desses números é buscar um método de priorização. O mercado tem vários: modelos de pontuação, matrizes de impacto vs esforço, processos de aprovação por fases (os chamados stage gates). Todos existem há décadas. A Harvard Business Review publicou em 2021 um estudo de uma década na Sony Ericsson (Klingebiel) mostrando que aprovações por fases, paradoxalmente, dificultam a morte de projetos ruins. O processo cria a ilusão de que algo está sendo avaliado quando na prática os projetos passam de fase por inércia organizacional. George Day, na HBR, documentou que 85 a 90% dos portfólios de inovação são compostos por projetos incrementais seguros que raramente geram o crescimento que a empresa busca.
Este artigo não propõe mais um framework. Frameworks avaliam o que alguém apresenta pra eles. Um modelo de pontuação classifica "automatizar report do board" como alto impacto e baixo esforço porque essas são as variáveis que alguém preencheu. Ele não consegue pontuar "a definição de cliente ativo diverge entre as BUs" porque ninguém levantou essa informação como variável. O processo funciona perfeitamente dentro dos parâmetros que recebeu. O problema é que os parâmetros estavam incompletos, e nenhum framework corrige isso por conta própria. O que corrige é alguém que transita entre as disciplinas e percebe o que está faltando antes de os parâmetros serem definidos.
O espaço onde "não" tem o maior retorno
John Cutler, que pesquisa há anos como trabalho entra em times de produto, descreveu o problema com precisão: "One of the challenges with Scrum and other approaches that start with 'the backlog', is that they (by design, feature not a bug) omit all that stuff to the left... how the stuff got there in the first place." Em tradução livre: um dos desafios de métodos que começam pela lista de tarefas aprovadas (o backlog) é que eles omitem, por design, tudo que aconteceu antes. Como o trabalho chegou ali.
Na prática, quatro fontes alimentam qualquer lista de tarefas de um time: sinais de cliente que alguém interpretou, diretivas de liderança que alguém traduziu em escopo, incidentes que criaram urgência, e ideias que alguém articulou e conectou com recursos disponíveis. Nenhuma dessas fontes passa por triagem formal na maioria das empresas. O trabalho simplesmente aparece como demanda aprovada, como se tivesse brotado do chão.
O Data Translator opera nesse espaço anterior à execução. É o profissional que convive com os 8 eixos do radar de competências (engenharia, arquitetura, análise, ML/IA, governança, privacidade, produto de dados e estratégia de negócio) e consegue avaliar uma proposta de projeto cruzando dimensões que nenhum especialista individual enxerga sozinho. No cenário do report, é quem pergunta pro time de governança se as definições de "cliente ativo" estão alinhadas entre as BUs, pergunta pro time de engenharia se o pipeline de produção existe, e pergunta pro negócio qual decisão esse report vai alimentar e se o custo se justifica.
A qualidade desse diagnóstico depende de existir governança de dados funcionando. Se ninguém catalogou as definições de "cliente ativo" nas BUs, o Translator também não descobre a divergência em uma semana. O perfil não substitui governança. Ele depende dela pra operar com precisão.
Com a triagem feita, o Translator volta pra mesa com o VP e traduz o resultado em linguagem de decisão: "o projeto faz sentido, mas precisa de 2 meses de preparação de dados antes de começar" ou "o custo real inviabiliza o retorno no prazo que o board espera, e aqui estão os números."
POR QUE ISSO É IMPORTANTE: A McKinsey confirmou com dados no State of AI de 2025: empresas de alta performance em AI (as que atribuem mais de 5% do EBIT ao uso de AI) são quase três vezes mais propensas a ter redesenhado seus workflows de ponta a ponta antes de escolher a tecnologia. De todos os fatores testados pela McKinsey, o redesenho de workflows é um dos mais fortemente associados a impacto real no resultado financeiro. O espaço anterior à execução é onde o retorno do "não" é maior. Cada projeto ruim que morre nessa fase libera capacidade, orçamento e credibilidade pra um projeto que vale a pena.
O peso da quilometragem
Nicholas Carlini, pesquisador da Anthropic, escreveu sobre o que separa pesquisa medíocre de pesquisa relevante: "You could probably, with some work, turn this into a paper. But it's not going to become a good paper. When this happens, just kill the idea and pick something new." Em tradução livre: você consegue transformar isso num paper, mas não vai ser bom. Mate a ideia e escolha outra. Troque "paper" por "projeto de AI" e a lógica é a mesma.
Nesses 22 anos trabalhando com dados, o que me fez crescer rápido foi a habilidade de juntar disciplinas diferentes com foco num resultado claro. Cinco anos no governo me obrigaram a praticar isso todos os dias, lidando com políticos e pessoas não-técnicas que precisavam de respostas concretas sem ter vocabulário pra formular a pergunta. Levar essa bagagem pro mercado de startups, com velocidade extrema e baixa tolerância a falha, só afiou o que eu já tinha construído. Ninguém me explicou como fazer isso. Eu desbravei cada pedaço na prática. Na prática, esse discernimento se traduz em três perguntas que acontecem antes de qualquer aprovação.
A primeira é sobre o domínio, não sobre a ferramenta. A segunda é sobre custo real. Priyanka Vergadia, ex-Developer Relations no Google Cloud, publicou uma análise detalhada de TCO (Total Cost of Ownership, o custo total real de um projeto, incluindo tudo que não aparece na proposta do fornecedor). A conclusão dela: o custo real de adoção de AI em empresas roda entre 3 e 5 vezes acima das estimativas iniciais. Vergadia cita uma declaração do VP de finanças do Gartner estimando que projeções de custo de AI feitas por CFOs estão erradas por 500 a 1.000%. O que infla a conta são custos que ninguém coloca no slide: preparação de dados, integração com sistemas legados, manutenção contínua, compliance e o time que precisa auditar o que o agente produz.
A terceira é sobre foco. Nagji e Tuff, na HBR, demonstraram que líderes que concentram investimento em poucos use cases geram o dobro do retorno de quem espalha recursos em muitos ao mesmo tempo.
PANORAMA GERAL: O estudo do METR que Vergadia cita traz um dado revelador num recorte específico: desenvolvedores experientes ficaram 19% mais lentos usando ferramentas de AI, mas reportaram se sentir 20% mais rápidos. Sem alguém calibrando percepção contra realidade, organizações operam sobre uma ilusão de produtividade que consome orçamento real.
Como dizer não sem ser demitido
Dizer "acho que não devemos fazer isso" é opinião. Qualquer pessoa pode ter opinião. O que transforma opinião em diagnóstico é dado, timing e posição organizacional.
Projetos que definem métricas claras antes da aprovação têm 54% de taxa de sucesso contra 12% dos que não definem, segundo compilação de dados da RAND, MIT e Gartner. Empresas que fazem assessment formal de data readiness antes de iniciar atingem 47% de sucesso contra 14%. O MIT Sloan Management Review documentou em 2025 que 61% dos projetos de AI foram aprovados com base em valor projetado que nunca foi formalmente medido após o deploy.
Esses mesmos números contam outra história quando lidos pelo outro lado. Projetos que passam por triagem real (métricas definidas, dados avaliados, sponsor comprometido) sobrevivem a taxas 4 a 5 vezes maiores. Dados preliminares do MIT NANDA apontam na mesma direção: projetos comprados de vendors especializados funcionam 67% das vezes, contra 33% dos builds internos sem curadoria de implementação. A triagem não serve só pra matar o que não presta. Serve pra proteger o que presta de morrer por falta de fundação.
O Translator na tríade de Produto, Engenharia e Negócio tem a posição pra apresentar esse diagnóstico com credibilidade porque transita entre as áreas e fala a linguagem de cada uma. O "não" dele quase nunca é "não façam." É "não assim" (o TCO real pode ser de 3 a 5 vezes o que o vendor prometeu e vocês precisam saber disso antes de assinar), "não agora" (63% das empresas não têm práticas de dados adequadas pra AI segundo o Gartner, e se a definição de "cliente ativo" diverge entre BUs, a nossa não é exceção), ou "não isso, mas aquilo" (esse use case tem ROI incerto, esse outro tem dados prontos e impacto mensurável em 90 dias).
Treinar o time em novas ferramentas sem redesenhar quem faz a triagem estratégica é reorganizar cadeiras sem olhar pra direção do barco. Aprovar projetos sem medir resultado é o oposto de ser data-driven.
MORAL DA HISTÓRIA: O retorno do "não" bem fundamentado é invisível porque se mede em dinheiro que não foi gasto, meses que não foram perdidos, e reputação de área de dados que não foi queimada com mais um projeto cancelado. A S&P Global calculou US$4,2 milhões de custo afundado por projeto e 11 meses até a organização admitir o erro. A empresa média abandona 2,3 projetos por ano. O Translator que evita dois projetos ruins gera mais valor financeiro que o engenheiro que executa com perfeição um projeto que nunca deveria ter existido.
Referências que valem a pena
- AI Project Failure Statistics 2026 (Pertama Partners, compilação RAND/MIT/Gartner/S&P Global, 2026)
- Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (Gartner, 2025)
- Lack of AI-Ready Data Puts AI Projects at Risk (Gartner, 2025)
- The State of AI in 2025 (McKinsey, 2025)
- Research: How to Get Better at Killing Bad Projects (Klingebiel, HBR, 2021)
- Managing Your Innovation Portfolio (Nagji & Tuff, HBR, 2012)
- Is It Real? Can We Win? Is It Worth Doing? (George Day, HBR, 2007)
- AI is Cheaper Than Humans — Until You Do the Math (Priyanka Vergadia, 2025)
- How to Win a Best Paper Award (Nicholas Carlini, 2026)
- What You Know That AI Doesn't (Priyanka Vergadia, TED Talk, 2026)
- O Data Translator que você conheceu em 2023 evoluiu (Vinícius Coimbra, LinkedIn Pulse, 2026)