IA Agents precisam de pipelines. Quem constrói isso?
Todo mundo fala de AI agents e RAG. Quase ninguém fala da infraestrutura de dados que faz tudo isso funcionar em produção. Esse post mostra o que separa uma demo de um produto — com uma demonstração interativa.
Todo mundo está falando de AI agents, RAG, automação com IA. O LinkedIn está cheio de posts sobre como criar um agent em 10 minutos com LangChain. Tutoriais de RAG com 20 linhas de código. Demos impressionantes rodando num notebook.
Mas quase ninguém fala do que acontece quando essa demo precisa virar produto.
O agent é só a ponta
Um AI agent sozinho não sabe nada. Ele depende de contexto. E contexto vem de dados. Dados que precisam estar atualizados, limpos, estruturados e acessíveis.
Quando alguém monta um RAG pra responder perguntas sobre documentos internos da empresa, o fluxo real não é "conecta o PDF e pronto". O fluxo real começa antes:
- De onde vêm esses documentos? SharePoint? Google Drive? Sistema legado?
- Com que frequência eles mudam?
- Como você garante que o agent não está respondendo com base num documento de 6 meses atrás?
- Quem tem permissão de ver o quê? O estagiário pode perguntar sobre o contrato do cliente X?
- O que acontece quando o pipeline de ingestão falha às 3 da manhã?
Nenhum curso de prompt engineering responde essas perguntas. Porque essas perguntas não são de IA. São de engenharia de dados.
O que um AI agent precisa de infraestrutura
Trabalho com engenharia de dados há 10 anos. Mais recentemente, comecei a implementar integrações via MCP (Model Context Protocol) em projetos de clientes, conectando modelos a fontes de dados reais. E uma coisa ficou clara: a parte de IA propriamente dita é a menor parte do problema.
O trabalho pesado está na infraestrutura de dados. O que isso inclui na prática:
Pipeline de ingestão automatizado. O agent precisa de dados frescos. Se o seu RAG lê documentos que foram indexados uma vez e nunca mais atualizados, em duas semanas as respostas já estão desatualizadas. Você precisa de um pipeline que ingere, transforma e carrega dados continuamente. Airflow, dlt, Cloud Scheduler, o que for. Mas precisa rodar sozinho, todo dia, com monitoramento.
Qualidade de dados. Dado sujo entra, resposta errada sai. O modelo não vai te avisar que o campo de receita está vindo como string em vez de float, ou que 15% dos registros estão duplicados. Se você não valida antes de alimentar o agent, ele alucina com confiança. Ferramentas como Soda Core e Great Expectations existem pra isso. Testes automatizados no pipeline, não revisão manual.
Transformação e modelagem. O dado bruto quase nunca está no formato que o agent precisa. Você precisa de uma camada de transformação (dbt, Spark, SQL puro) que limpa, padroniza e agrega antes de chegar na vector store ou no contexto do agent.
Governança e controle de acesso. LGPD não desaparece porque você colocou IA no meio. Se o dado tem informação sensível (CPF, salário, dados médicos), o pipeline precisa mascarar antes de alimentar o agent. Criptografia determinística, tokenização, masking por perfil de acesso. Isso é engenharia de dados, não engenharia de ML.
Orquestração e monitoramento. O pipeline precisa rodar em schedule, ter alertas de falha, retry automático e logs. Quando o CEO perguntar pro agent "qual foi o faturamento de ontem?" e o agent responder com dados de terça-feira passada, alguém vai precisar explicar por que o pipeline parou e ninguém percebeu.
Veja na prática
A teoria é uma coisa. Mas dá pra sentir o problema na pele. Abaixo está o mesmo agent respondendo a mesma pergunta — "qual foi o faturamento de ontem?". Desligue cada camada de infraestrutura e veja o que acontece com a resposta:
Repare que o agent nunca diz "não sei". Ele sempre responde com confiança. A diferença entre a resposta certa e a resposta errada não está no modelo. Está na infraestrutura que alimenta ele.
O gap que ninguém fala
O mercado criou uma separação artificial: de um lado, o "pessoal de IA" (ML engineers, prompt engineers, AI engineers). Do outro, o "pessoal de dados" (data engineers, analytics engineers). Como se fossem mundos diferentes.
Na prática, um AI agent em produção precisa dos dois. E pelo que tenho visto, na maioria das empresas o gargalo não é o modelo. O modelo funciona. O gargalo é o dado que alimenta o modelo.
O modelo virou commodity. Você troca GPT por Claude por Gemini com algumas linhas de configuração. Os dados não. A fonte está espalhada, o schema é inconsistente, não tem pipeline de consolidação, ninguém garante a qualidade. É aí que o projeto trava.
O que nenhum tutorial de RAG ensina
A maioria dos tutoriais de RAG segue esse fluxo:
- Carrega uns PDFs
- Faz chunking
- Gera embeddings
- Joga num vector store
- Conecta no LLM
- "Pronto, seu RAG está funcionando"
E funciona. Na demo. Com cinco documentos estáticos.
O problema aparece quando isso precisa escalar: milhares de documentos que mudam toda semana, vindos de fontes diferentes, com controle de acesso por departamento e auditoria de quem perguntou o quê. O tutorial não cobre essa parte.
Porque essa parte é engenharia de dados:
- Um pipeline de ingestão que detecta documentos novos e alterados automaticamente
- Re-indexação incremental, pra não reprocessar tudo toda vez
- Controle de acesso por perfil, integrado ao pipeline
- Logs de uso: quem perguntou o quê, quando, e qual fonte foi usada como contexto
- Monitoramento de qualidade das respostas ao longo do tempo
O agent é a interface. A engenharia de dados é o motor.
Freshness importa mais que volume
Um erro comum é achar que quanto mais dado, melhor o agent. Não é bem assim. Um agent com mil documentos atualizados responde melhor do que um com cem mil documentos desatualizados.
Em casos de uso corporativo, freshness (quão recente é o dado) costuma importar mais do que volume. Se o agent responde uma pergunta sobre política de férias com o documento de 2022 em vez do de 2025, o resultado é pior do que não responder.
O pipeline de ingestão precisa ter lógica de expiração. Documentos antigos saem do índice ou recebem peso menor. Isso não é configuração do LLM. É configuração do pipeline.
Sem pipeline, você tem uma demo. Com pipeline, você tem um produto.
Essa é a diferença entre o que funciona num notebook e o que funciona em produção. O notebook roda uma vez, com dados estáticos, sem monitoramento, sem schedule, sem controle de acesso. Produção é outra história.
Se você está planejando implementar IA na sua empresa, antes de escolher o modelo, responde essas perguntas:
- Onde estão os dados que o agent vai usar?
- Com que frequência esses dados mudam?
- Quem é responsável por garantir que o pipeline está rodando?
- O que acontece quando falha?
- Quem não deveria ter acesso a certas informações?
Se você não tem resposta pra maioria dessas perguntas, o problema não é de IA. É de dados. E é aí que eu trabalho.
Se você está planejando um projeto de IA e precisa estruturar a camada de dados antes de começar, a GC Data pode ajudar. Agende uma conversa.
Quer praticar data engineering na prática? Tem desafio gratuito toda semana na GC Data Academy.