Tem uma reunião que muita gente de tecnologia já viveu: o anúncio que a empresa vai ser "AI-first"… os times recebem a missão de integrar IA nos produtos existentes, e em poucas semanas aparecem os primeiros chatbots, os primeiros assistentes e os primeiros resumos automáticos nos sistemas que já estavam ali.

Funciona na demo e é incrível, mas na segunda semana não funciona tão bem assim. E uma dúvida surge “O problema está na IA?”, já adianto a vocês que não. Está no que existe por baixo dela.

Uma reforma que não mexe na estrutura

O assistente impressiona na demonstração e decepciona no uso real, porque na demo o roteiro é controlado, na vida real o usuário faz uma pergunta levemente diferente do esperado e o sistema trava, a ferramenta de busca é sofisticada mas os dados que a alimentam são bagunçados há anos, o gerador de relatórios funciona contanto que alguém atualize a planilha de origem, o que ninguém faz.

Fica claro que não é a IA que falha, a questão é que ela foi colocada para trabalhar com material que não estava pronto.

O MIT Project NANDA publicou em 2025 um estudo cobrindo centenas de iniciativas de IA em empresas, e o resultado foi que 95% das organizações que implementaram IA generativa não obtiveram nenhum retorno financeiro mensurável, não um retorno baixo, nenhum. A RAND Corporation chegou a números parecidos pela via técnica: mais de 80% dos projetos de IA não chegam à produção, o dobro da taxa de falha de projetos de TI comuns, e a S&P Global mediu pelo abandono: em 2025, 42% das empresas jogaram fora a maior parte das suas iniciativas, contra 17% no ano anterior.

E esses números surpreendentes que parecem até errados… Como que na era da IA, no momento de maior hype, a tecnologia nos deixa na mão? A resposta é que não é somente a tecnologia que não funciona ou a culpada nesse cenário. É que ela está sendo aplicada sobre uma base que não estava pronta para ela.

O desconto da novidade acabou

Por um tempo, colocar qualquer coisa com IA num produto era suficiente para impressionar, o mercado estava curioso, as expectativas eram baixas, e a novidade cobria muita coisa e isso passou.

Hoje quem usa IA no trabalho tem referências concretas, sabe como é uma ferramenta construída do zero com IA no centro, que entende contexto, lembra do que foi dito antes, antecipa o próximo passo, e quando chega num sistema que "foi atualizado com IA" a comparação acontece automaticamente, quase nunca favorável.

O gap aparece de formas diferentes, mas tem três que aparecem o tempo todo:

• A IA responde rápido, mas o sistema ao redor é lento. O usuário sente que a IA é lenta mesmo quando o problema não é dela.

• A IA sabe pouco porque recebe pouco. Isso acontece porque as informações relevantes estão espalhadas entre sistemas que não se falam. A IBM aponta que 82% das empresas têm fluxos de trabalho interrompidos por dados em silos.

• A IA não aprende. Fica parada enquanto quem construiu certo acumula vantagem ciclo a ciclo.

O problema tem nome e é chato de resolver

Quando pesquisadores perguntam às empresas onde os projetos de IA estão travando, a resposta quase nunca menciona o modelo, menciona o que alimenta o modelo.

Diversas pesquisas (Forrester, Informatica, Gartner) com diretores de dados revelaram que segundo eles o principal obstáculo quando falamos de IA está na qualidade e prontidão dos dados apareceram e que muitas organizações não sabem ao certo se têm sequer as práticas básicas para suportar o que estão tentando fazer.

E então surge a questão: se os dados são o problema central, por que tão pouca atenção vai para eles antes de começar?

Parte da resposta está no tipo de erro que dados ruins produzem. Uma IA alimentada com dados ruins não falha de forma óbvia, ela produz respostas que parecem plausíveis mas estão erradas, o que é mais perigoso do que um sistema que claramente não funciona, porque leva mais tempo para alguém perceber.

A Zillow aprendeu isso da pior forma: em 2021 lançou um programa de compra e revenda de imóveis com precificação por IA, o modelo subestimou o risco do mercado e superestimou os valores de revenda de forma consistente, resultando em prejuízo operacional estimado em centenas de milhões de dólares, divisão fechada e 25% dos funcionários demitidos. O modelo não tinha bug, ele fez exatamente o que foi instruído a fazer, o problema é que as instruções estavam erradas.

A resposta mais comum é a mais cara

Quando esses problemas aparecem, a maioria das empresas faz a mesma coisa: adiciona algo no meio, um conector entre o sistema antigo e a IA, uma ferramenta que organiza os dados antes de passá-los adiante, um componente que faz a tradução entre o que existe e o que a IA precisa.

Isso funciona até o ponto em que o problema não é de integração, é de qualidade, e nenhuma camada de tecnologia resolve dado fragmentado, desatualizado ou mal organizado na hora de usar.

Quem já passou por modernização de sistemas conhece o padrão: começa com uma solução pontual, vem outra, depois algo para conectar as duas, depois algo para gerenciar as conexões, e em pouco tempo o "projeto de IA" virou ele mesmo um sistema complicado, frágil e com manutenção constante.

Segundo o MIT, os projetos que deram retorno real têm uma coisa em comum: foram construídos para tarefas específicas, com acesso a informações organizadas e atualizadas, não foram plugados em cima de algo que já existia. Programas que funcionam costumam gastar entre uma boa porcentagem do tempo e do orçamento só na preparação de dados, antes de escrever uma linha de código de IA, o que parece lentidão excessiva mas é o que separa quem chega à produção de quem fica eternamente em piloto.

Como sair do ciclo: 5 passos antes do próximo projeto de IA

Em vez de mais uma camada, cinco passos que mudam o ponto de partida.

1. Mapeie onde seus dados moram e onde eles não conversam. Inventário honesto: quais sistemas, qual qualidade, qual frequência de atualização, quais lacunas. Sem esse mapa, qualquer projeto de IA está chutando no escuro.

2. Defina uma tarefa específica, não uma "iniciativa de IA". Os projetos que dão retorno têm escopo cirúrgico: "reduzir tempo de resposta em tickets de suporte da categoria X em Y%". Não "transformar a operação com IA".

3. Reserve 60% a 80% do orçamento e do prazo para preparação de dados. Não é exagero, é a média do que projetos que chegam à produção gastam. Cortar essa etapa é a forma mais cara de economizar.

4. Construa para a tarefa, não em cima do legado. Resista à tentação de plugar IA num sistema antigo só pra ganhar tempo de lançamento. O custo de manutenção da gambiarra vai cobrar depois com juros.

5. Meça resultado mensurável, não engajamento com demo. Se o KPI do projeto é "quantos usuários experimentaram", o projeto ainda não saiu do piloto. KPI real é redução de custo, ganho de receita ou tempo economizado, medidos em produção.

A pergunta que ninguém quer fazer

Mudança gradual faz sentido, ninguém precisa jogar tudo fora, mas gradual só funciona quando os passos estão apontando para o lugar certo. E tem uma pergunta que a maioria das organizações não está fazendo antes de anunciar o próximo lançamento com IA: o que temos hoje ainda faz sentido para onde estamos tentando chegar? É desconfortável porque a resposta honesta implica admitir que parte do que foi construído ficou para trás, que algumas decisões de arquitetura que faziam sentido há cinco anos são hoje o motivo pelo qual a IA não funciona direito.

Enquanto essa pergunta não for feita com seriedade, o ciclo continua: demo impressiona, produção decepciona, mais uma camada é adicionada, problema segue sem solução.

A boa notícia é que a pergunta em si já é o começo da resposta. Empresas que saíram do ciclo de demo impressionante e produção decepcionante não fizeram isso com tecnologia melhor, fizeram com honestidade melhor. Pararam de perguntar "como adicionamos IA nisso?" e começaram a perguntar "o que precisamos que seja verdade para que isso funcione de verdade?". A diferença parece sutil, mas leva para lugares completamente distintos.

IA não é uma camada. É uma aposta na qualidade do que existe por baixo. E quanto antes uma organização entender isso, menos tempo vai gastar convencendo a si mesma de que o próximo projeto vai ser diferente dos anteriores antes de fazer as mesmas escolhas.

Perguntas Frequentes

Por que tantos projetos de IA não chegam à produção?

A maioria dos projetos trava antes de enfrentar qualquer problema técnico de IA. O obstáculo está na base: dados fragmentados, qualidade de informação insuficiente e arquiteturas que nunca foram pensadas para alimentar modelos. A IA produz respostas plausíveis mas incorretas, e esse tipo de falha silenciosa demora para ser detectada. A causa quase sempre é a mesma: a tecnologia foi aplicada sobre uma fundação que não estava pronta.

Qual a diferença entre "IA aplicada" e "AI-First de verdade"?

IA aplicada é adicionar uma camada de inteligência sobre um sistema existente. Funciona na demo porque o caminho foi roteirizado. No uso real, qualquer variação expõe as fragilidades do que está por baixo. AI-First significa que a arquitetura inteira foi pensada com a IA no centro desde o início, ou seja, os dados fluem de forma que o modelo consiga consumir, o contexto é preservado entre interações e o sistema aprende com o uso. A diferença não está no modelo escolhido, está em quantas decisões foram tomadas antes de escrever código.

Precisamos jogar fora o legado pra usar IA?

Não necessariamente, mas é preciso ser honesto sobre o que ele permite e o que ele impede. O que não funciona é fingir que o legado não é um obstáculo e sair adicionando camadas de integração para contornar os problemas sem resolvê-los. A pergunta certa não é "jogar fora ou não", é "o que precisa ser verdade para que isso funcione?" e agir a partir da resposta honesta.

Quanto tempo leva preparar dados antes de aplicar IA?

Mais do que quase todo cronograma inicial prevê. Projetos que chegam à produção costumam dedicar entre 60% e 80% do tempo total só à preparação de dados. Isso parece excessivo mas projetos que cortaram essa etapa para ganhar velocidade passaram meses em ciclos de correção, ou nunca saíram do piloto. Se o plano reserva menos da metade do prazo para dados, o cronograma provavelmente precisa ser revisado antes de começar.

Como saber se a empresa está pronta pra IA?

Algumas perguntas ajudam a fazer esse diagnóstico antes de comprometer orçamento. Você sabe onde cada informação relevante mora e com qual frequência é atualizada? Os sistemas que produzem esses dados se comunicam entre si? Existe alguém com responsabilidade clara sobre a qualidade dos dados? O projeto tem um KPI mensurável em produção? Nenhuma empresa responde sim para tudo antes de começar. O objetivo é ter clareza sobre onde estão as lacunas reais, porque são elas que vão determinar onde o projeto vai travar.