Por que dados ruins destroem seus agentes de IA (e como resolver)

Segundo o IBM Institute for Business Value, empresas americanas perdem US$ 3,1 trilhões por ano com dados de má qualidade — e esse número foi calculado antes da explosão dos agentes de IA. Pior ainda. Porque agora o custo não é só financeiro: é a credibilidade do projeto inteiro. Agentes de IA que tomam decisões erradas, que aluciam com confiança, que degradam silenciosamente em produção semanas depois do deploy — tudo isso tem um denominador comum que a maioria dos times demora muito pra identificar.

Você otimizou o prompt. Trocou o modelo. Ajustou a temperatura, mexeu no contexto, testou três frameworks diferentes. O agente continua respondendo absurdos. Essa é a situação de boa parte dos times de engenharia que conversamos aqui na Yaitec — e quase sempre o diagnóstico é o mesmo: o problema não está no modelo.

São os dados. Sempre foram os dados.

O que são "dados ruins" no contexto de agentes de IA?

Antes de sair aplicando checklist, vale entender o que "dado ruim" significa especificamente pra agentes — porque não é a mesma coisa que dado ruim em ML clássico.

Num modelo de predição tradicional, dado ruim costuma ser valor faltante, outlier, ou coluna com encoding errado. Simples de detectar, relativamente simples de corrigir. Em agentes de IA com memória, ferramentas e loops de raciocínio encadeado, o problema é mais sutil e muito mais perigoso.

Dado ruim em agentes inclui:

• Documentos desatualizados na base de conhecimento — o agente cita uma política de 2021 como se fosse atual
• Chunks mal formados que quebram raciocínio no meio de uma instrução técnica
• Metadados ausentes que impedem filtragem correta na hora da recuperação
• Dados contraditórios entre fontes diferentes — o agente fica "confuso" entre duas versões conflitantes de uma mesma verdade
• Schema drift — a estrutura dos dados mudou em produção sem o agente saber

Cada um desses problemas produz um sintoma diferente. Todos têm a mesma raiz.

As 4 formas como dados ruins sabotam agentes de IA

Andrew Ng, fundador do Google Brain, disse algo que resume bem: "We need to move from a model-centric view to a data-centric view of AI. What really makes a difference is getting the data right." Ele falou isso em 2021. A maioria dos times ainda não ouviu — ou ouviu e não mudou nada.

Num pipeline RAG com dados mal preparados, as alucinações aumentam entre 30% e 40% em comparação com sistemas que usam dados verificados, segundo estudos da Microsoft Research. Não é hipótese teórica. É o que a gente vê acontecer.

1. Alucinação por contexto corrompido

O agente recupera documentos irrelevantes ou contraditórios e usa como base pra resposta. O resultado parece confiante, é factualmente errado. Ninguém percebe até o cliente reclamar — ou até o agente tomar uma decisão errada num processo crítico.

Quando implementamos um chatbot RAG para um cliente do setor financeiro, o primeiro modelo que entregamos alucinou detalhes de produto com frequência alarmante. Três semanas de investigação depois: o problema estava em documentos duplicados com versões diferentes da mesma política de crédito. Dois PDFs. Isso custou semanas de debugging e atrasou o go-live em um mês. O agente não tinha culpa — ele estava fazendo exatamente o que foi pedido, usando os dados que recebeu.

2. Recuperação que nunca encontra o que precisa

Recall baixo. O agente "não sabe" algo que existe na base de conhecimento porque o chunking está errado, os embeddings foram gerados com modelo inadequado, ou os metadados não permitem filtrar corretamente.

Na prática: o usuário pergunta sobre X, o agente diz que não tem informação, a informação existe e está bem documentada — está só mal indexada. O usuário perde confiança no sistema. O time acha que é problema de alucinação quando é problema de recuperação. São bugs completamente diferentes, com soluções completamente diferentes.

3. Drift silencioso em produção

Esse é o mais traiçoeiro. O agente funciona bem no deploy. Semanas depois, começa a degradar sem avisar. Por quê? Os dados mudaram e o agente não sabe.

Preços atualizaram. Produtos foram descontinuados. Processos internos mudaram. A base de conhecimento ficou parada no tempo. O agente continua respondendo com o mundo de dois meses atrás.

Elena Samuylova, CEO da Evidently AI, descreve o problema com precisão: "Most AI failures in production aren't dramatic crashes — they're slow, silent degradations caused by data that no longer looks like what the model was trained on." Silencioso. É o que torna esse problema tão difícil de capturar antes que vire crise.

4. Viés amplificado em escala

Dado tendencioso gera decisão tendenciosa — mas agentes amplificam isso sistematicamente, em cada interação. O caso mais documentado: o sistema de recrutamento da Amazon que discriminava mulheres porque foi treinado em 10 anos de currículos de um mercado majoritariamente masculino. O sistema não criou o viés. Aprendeu e automatizou o viés que já existia nos dados.

Em agentes corporativos internos, esse problema aparece de forma menos óbvia: documentação que favorece certos departamentos, histórico de atendimento com perfis sub-representados, base de conhecimento que reflete só a perspectiva de quem escreveu os manuais.

Segundo a Gartner, até 2027, 30% das empresas que implantaram agentes de IA vão reduzir o uso em pelo menos 50% por conta de resultados imprecisos. Dados ruins são o principal motor dessa reversão.

Como diagnosticar se o problema está nos dados

Pare de mexer no prompt. Primeiro passo, sempre.

Se você já testou três versões de system prompt, mudou o modelo, e o comportamento ainda é imprevisível — é quase certo que o problema está nos dados. Cassie Kozyrkov, ex-Chief Decision Scientist do Google, resume bem o que acontece: "If you haven't put serious effort into understanding and cleaning your data, your AI model is just a sophisticated way of automating your existing mistakes." Automação de erros. É exatamente isso.

Aqui um mapa de sintomas pra diagnóstico rápido:

A forma mais rápida de confirmar a hipótese: isole o pipeline de recuperação e teste manualmente. Faça a query, veja os top-5 documentos recuperados. Se o que retorna não é o que deveria retornar, o problema é de dados — não de modelo.

Como resolver: um framework de 5 passos

Depois de mais de 50 projetos implementados em fintechs, healthtechs e e-commerce, a equipe da Yaitec consolidou um padrão que funciona independente de stack. Não é mágica. É método.

Passo 1 — Auditoria da fonte. Mapeia todas as fontes de dados que alimentam o agente. Data de criação, data de última atualização, responsável pela manutenção, processo de versionamento. Se não existe processo, esse é o primeiro problema a resolver.

Passo 2 — Validação de schema antes de indexar. Sem metadados mínimos obrigatórios, o documento não entra na base. Sem exceção.

from datetime import datetime

def validate_document(doc: dict) -> bool:
    required_fields = ["content", "source", "last_updated", "domain", "version"]
    for field in required_fields:
        if not doc.get(field):
            raise ValueError(f"Campo obrigatório ausente: {field}")

    last_updated = datetime.fromisoformat(doc["last_updated"])
    days_old = (datetime.now() - last_updated).days

    if days_old > 180:
        raise ValueError(
            f"Documento desatualizado: {days_old} dias sem atualização"
        )
    return True

Passo 3 — Chunking semântico, não só por tamanho. Chunks não devem quebrar no meio de uma ideia. Testa qual tamanho melhora retrieval precision pra seu caso específico — não existe número universal. O que funciona pra documentação técnica não funciona pra contratos jurídicos.

Passo 4 — Pipeline de atualização contínua. Dados são dinâmicos. O pipeline de ingestão precisa rodar com frequência definida, detectar mudanças, reindexar o que mudou e desativar o que foi removido. Isso precisa estar automatizado antes do go-live em produção — não depois.

Passo 5 — Monitoramento de qualidade em produção. Implementa métricas de retrieval (precision@k, recall@k) e rastreabilidade de resposta. Quando o agente responde, você precisa saber de qual documento aquela resposta veio. Sem rastreabilidade, debugging em produção é adivinhação com verniz técnico.

Segundo o survey State of AI Agents da LangChain (2024), 62% das equipes que constroem agentes citam dados incompletos ou de baixa qualidade como o maior desafio operacional. A maioria não tem um framework pra resolver isso estruturalmente. Ter um muda tudo.

O que 50+ projetos ensinaram sobre dados e agentes

Implementamos um pipeline de processamento de contratos pra um cliente do setor jurídico que automatizou 80% da revisão contratual, poupando 120 horas de trabalho por mês. Os primeiros dois meses foram caóticos — não por causa do modelo, mas por conta de PDFs mal escaneados, nomenclatura inconsistente nos arquivos, e cláusulas de versões antigas misturadas com versões atuais num mesmo diretório.

Quando a gente arrumou os dados, o agente funcionou. Simples assim.

A limitação honesta que precisamos admitir: não existe ferramenta que substitui curadoria humana por completo. Você pode automatizar 90% da validação. Os 10% restantes — julgamento de contexto, ambiguidade, relevância de domínio — exigem alguém que entenda o negócio de verdade.

Segundo a Forrester Research, empresas que priorizam qualidade de dados têm 58% mais chances de bater metas de receita do que concorrentes que não o fazem. Esse número não é coincidência — é o efeito composto de cada decisão correta que um agente bem alimentado toma ao longo do tempo.

Se você tem um agente em produção que não está performando como deveria, e já tentou de tudo no lado do modelo, a gente pode ajudar a olhar pra onde o problema provavelmente está. Fale conosco — a primeira conversa é sem compromisso.

Conclusão

Agentes de IA quebram por muitos motivos. Mas a causa mais comum, mais subestimada, e mais difícil de admitir é também a mais simples: dado ruim.

Não é o modelo. Nunca foi o modelo.

Organizações com práticas sólidas de qualidade de dados são 2,6 vezes mais propensas a obter ROI real de IA, segundo a IBM. Esse número existe porque qualidade de dados não é detalhe técnico — é o que decide se o seu agente vai funcionar em produção ou vai ser mais um projeto arquivado depois de seis meses de frustração.

O prompt pode salvar um agente mediano. Só dado de qualidade transforma um agente numa ferramenta que a empresa realmente usa — e confia.