Por que a IA da sua empresa falha: o problema quase nunca é o modelo

Diego, CTO de uma fintech em Belo Horizonte, aprovou o projeto em março. Em agosto, o agente de IA estava em produção — mas respondia errado 30% das vezes. Ele culpou o modelo por três semanas. Testou GPT-4o, Claude Sonnet, Gemini — os três com resultado similar. Antes de desistir, um engenheiro sênior pediu para inspecionar a base de dados de clientes que alimentava o contexto do agente. O que encontrou: quatro formatos diferentes de CPF no mesmo campo, dois campos de "status de conta" com nomenclaturas conflitantes criadas por times diferentes ao longo de cinco anos, e nenhum dicionário de dados explicando o que cada coluna realmente significava. O modelo estava correto. Os dados estavam errados. Diego tinha passado três meses e R$ 180 mil tentando resolver um problema de dados com uma solução de modelo.

Esse padrão não é exceção. É a regra. E os dados de mercado confirmam com precisão perturbadora o que CTOs e Tech Leads estão vivendo nos bastidores.

O padrão que se repete: piloto funciona, produção quebra

Análise de 140 implementações enterprise mostrou que apenas 23% das falhas foram causadas por desempenho do modelo ou complexidade de integração técnica. Os outros 77% vieram de estratégia, governança e gestão da mudança — com dados de má qualidade como causa raiz mais frequente. A Gartner estimou que apenas 12% das organizações têm dados de qualidade suficiente para suportar aplicações de IA em produção, e previu que 60% dos projetos sem dados AI-ready seriam abandonados ao longo de 2026. Esse calendário está se cumprindo.

A pergunta que CTOs deveriam fazer antes de contratar qualquer API de LLM não é "qual modelo usar". É: o que esse modelo vai consumir? E a resposta honesta, na maioria das empresas brasileiras de médio porte, é: um conjunto de dados construído ao longo de anos sem nenhuma preocupação com padronização, porque nunca havia uma máquina que fosse lê-los de verdade.

Onde a falha realmente mora: os 4 problemas estruturais

Depois de anos de promessas de transformação digital, a maioria das empresas acumulou uma dívida técnica específica que a IA torna imediatamente visível. São quatro problemas estruturais que se repetem independentemente do setor, do tamanho da empresa e do modelo de LLM escolhido.

Dados sujos — o assassino silencioso de projetos de IA

Um modelo de linguagem não sabe que CPF: 123.456.789-00 e CPF: 12345678900 representam a mesma pessoa. Ele trata como duas entidades distintas. Quando o seu pipeline de RAG (Retrieval Augmented Generation) busca contexto sobre um cliente e encontra dois registros conflitantes, ele não escolhe o correto — ele tenta reconciliar, e frequentemente inventa uma resposta coerente que é factualmente errada. Isso não é bug do modelo. É o modelo fazendo exatamente o que foi projetado para fazer: produzir texto coerente com o contexto fornecido. O contexto é que está errado.

Os problemas mais comuns em bases de dados de empresas brasileiras de médio porte, na ordem em que mais destroem projetos de IA:

APIs inexistentes e integrações quebradas

Um agente de IA que não consegue executar ações é um chatbot caro. A grande promessa dos agentes de 2026 — que eles possam não apenas responder perguntas mas executar tarefas — depende de um pressuposto que a maioria das empresas não satisfaz: que os sistemas internos exponham APIs limpas e documentadas para o agente consumir.

Na realidade brasileira de médio porte, o que existe é: um ERP de 2015 sem API REST, um CRM com webhook que funciona "às vezes", um sistema de estoque que só exporta Excel e um sistema de cobrança acessível apenas via interface web. Para um agente de IA executar uma ação nesse ecossistema, alguém precisa primeiro construir a camada de integração — e esse trabalho raramente aparece no escopo original do projeto.

O resultado é o que Neuwark Research chamou em 2026 de "agente de fachada": um LLM que descreve o que faria se pudesse executar a ação, mas que na prática gera um rascunho para um humano executar manualmente. Tecnicamente impressionante na demo. Operacionalmente inútil em produção.

# Antes de definir as ferramentas (tools) do agente,
# mapeie cada ação para o endpoint real:

AÇÃO: "consultar status do pedido"
  → GET /api/pedidos/{id}/status  ✅ existe
  → Documentado? Sim | Auth? Bearer token ✅

AÇÃO: "atualizar endereço do cliente"
  → PATCH /api/clientes/{id}      ⚠️ existe, mas não testado
  → Documentado? Incompleto | Quem mantém? Time desconhecido

AÇÃO: "emitir nota fiscal"
  → Sem API. Só via tela do ERP   ❌ bloqueante
  → Solução: construir wrapper antes de prosseguir

# Regra: se mais de 2 ações críticas não têm endpoint,
# pause o projeto de agente e abra sprint de APIs primeiro.

Documentação caótica: o problema que ninguém confessa

Existe uma categoria de problema que raramente aparece em post-mortems de projetos de IA porque ninguém quer admitir: a documentação interna é um desastre. Regras de negócio que só existem na cabeça de um analista que saiu em 2023. Fluxos de aprovação que "todo mundo sabe como funciona" mas ninguém escreveu. Campos de banco de dados com nomes crípticos que faziam sentido quando foram criados mas cujo significado atual é ambíguo até para o time que os usa diariamente.

Quando um agente de IA recebe contexto insuficiente, ele não retorna um erro — ele alucina uma resposta coerente. E o problema específico de alucinações em contexto de negócio é que elas frequentemente parecem corretas para quem lê sem conhecimento profundo do domínio. Um agente que alucina regras de negócio cria uma confiança falsa que é mais perigosa do que um erro óbvio.

A solução não é "treinar o modelo a não alucinar" — isso não funciona. A solução é eliminar as lacunas de contexto que forçam o modelo a alucinação. Isso significa documentar antes de plugar a IA:

Como estruturar a casa antes de plugar o LLM

A sequência correta não é "escolha o modelo → integre os dados → ajuste os prompts". É o inverso. O modelo é a última decisão, não a primeira. A sequência que funciona:

1. Mapeie o processo que vai automatizar — completamente. Documente cada passo, cada decisão, cada exceção. Se o processo ainda não está documentado e funcionando bem de forma manual, automatizá-lo com IA vai apenas tornar o caos mais rápido. Automatize processos que funcionam — não processos que precisam ser corrigidos.

2. Audite os dados que o modelo vai consumir. Para cada campo crítico: qual a cobertura de preenchimento? Quais são os valores distintos? Há inconsistências de formato? Esse trabalho custa entre 1 e 3 sprints. Pular custa o projeto inteiro.

3. Mapeie as ações que o agente precisa executar e confirme que os endpoints existem. Se faltam APIs, abra o escopo de desenvolvimento antes de abrir o escopo de IA. Um agente sem ferramentas funcionais é um chatbot com prompts complexos.

4. Escreva o dicionário de dados e as regras de negócio em linguagem natural. Esse documento vai diretamente para o system prompt do agente — é o que elimina as lacunas de contexto que causam alucinação.

5. Só então: escolha o modelo, escreva os prompts, integre. Nessa ordem. Com essa base, o modelo — qualquer modelo de qualidade atual — vai performar bem. Sem essa base, nem o melhor modelo resolve.

Checklist de AI-readiness para times técnicos