Por que não fazemos IA sem fundação de dados primeiro

Empresa nos procura porque ouviu falar de IA. Quer agente. Quer dashboard que responde sozinho. Quer que o ChatGPT "fale com os dados da gente".

A primeira pergunta que fazemos é chata: onde estão os dados?

A resposta quase sempre é a mesma. CRM numa ferramenta, ERP em outra. Planilha do financeiro num drive. Histórico de pedidos numa tabela legada que ninguém quer encostar. Lead aterrissa no HubSpot, conversa fica no WhatsApp, contrato no Google Drive, pagamento no Stripe ou Asaas. Cada um falando uma linguagem. Cada um com sua noção de cliente, produto, pedido.

Quando a gente recusa começar pelo agente, é porque já vimos o que acontece quando se ignora isso.

O cemitério dos POCs de IA

Tem um padrão. Em três etapas:

Semana 1. Time animado. Roda Claude em cima de um CSV exportado na mão. Funciona maravilhoso. Demo bonita pra diretoria.

Mês 2. Decisão de "botar em produção". Aí começa o pesadelo. Qual fonte usar? A do ERP, que está atrasada um dia? A do CRM, que tem nome diferente do mesmo cliente? Aquela planilha que o time comercial atualiza manualmente?

Mês 4. A solução vira um Frankenstein. Um script que sincroniza X com Y às 3 da manhã. Uma view manual no Postgres. Um connector "temporário" que ninguém entende. Agora qualquer mudança no schema do CRM quebra três coisas. Ninguém quer mexer.

Mês 6. O projeto morre. "Não temos o pessoal pra manter isso." Versão polite de: "construímos um castelo em cima de areia movediça."

O modelo de IA, em todo esse tempo, foi o componente mais fácil. Trocar Sonnet por GPT é uma linha de código. Trocar a fonte de verdade do banco é seis meses de migração.

A inversão que a gente prega

Antes de ligar um agente, você precisa de um warehouse honesto.

Não significa um data warehouse pomposo com Snowflake e quatro engenheiros dedicados. Significa: um lugar onde TODOS os dados relevantes estão. Atualizados. Modelados. Com um nome só por entidade. Com testes que falham quando alguém deixa um campo nulo que não deveria ser nulo.

Pode ser Postgres + dbt. Pode ser BigQuery + dbt. Pode ser Snowflake + dbt. Pode ser ClickHouse + dbt. O banco importa menos do que o fato de existir um banco único com modelagem versionada.

Quando isso existe, ligar um agente em cima vira trivial. Você dá pro Claude acesso a um schema documentado, com queries que ele pode rodar via MCP, com regras de negócio explícitas. O agente vira a parte fácil.

"Mas a gente quer começar pequeno"

Entendemos. E concordamos. Não estamos defendendo um projeto de seis meses de modelagem antes de ver uma demo.

A versão pragmática:

Semana 1-2. Discovery. Mapeamos onde estão os dados, qual é o caso de uso prioritário, o que tem que ser unido. Saída: arquitetura + plano.

Semana 3-6. Pilot. Pegamos UM caso de uso (não dez). Construímos o pedaço de warehouse que ele exige (não o universo). Modelagem só do que precisa. Botamos um agente em cima desse recorte. Funciona em produção pequena.

Mês 3+. Expansão. Agora você tem (1) confiança no time, (2) prova que a abordagem funciona, (3) o início de um warehouse que outros casos podem usar. Acrescentamos o segundo caso de uso, depois o terceiro. A fundação vai crescendo.

Em nenhum momento se sai do escopo. Em nenhum momento se promete IA num caos de dados.

O que a gente recusa

Recusamos: "vocês só fazem a parte do agente, a gente cuida do dado por dentro."

Não porque seja arrogância. É porque já vimos o final. O cliente toca a parte do dado por meses, nunca termina, o agente fica esperando, o relacionamento azeda, ninguém entrega.

Quando assumimos as duas pontas - ingestão / warehouse / modelagem do nosso lado, agente do nosso lado - o sucesso depende de uma engenharia só. Quando dividimos, o sucesso depende de dois times se coordenarem perfeitamente em algo que nenhum dos dois fez antes.

A oferta da Zechim, por isso, é integrada de propósito. Airbyte / Fivetran / conectores customizados. Postgres ou BigQuery ou Snowflake. dbt sempre. Terraform pra deixar tudo reproduzível. Aí o agente.

O sinal técnico

Quando um candidato a parceiro lista "consultoria em IA" e a competência mais profunda dele é prompt engineering, fuja.

Quando lista "consultoria em IA" e a competência mais profunda é "rodamos Airbyte + dbt + BigQuery + Terraform em produção em times sênior por anos, e agora botamos um agente em cima", fica.

A IA boa que você vê na rua é construída por engenheiros de dados que aprenderam a ligar agentes, não por consultores de IA que descobriram que existe dado.

Se sua empresa precisa de IA mas o dado está espalhado, vale uma conversa. Construímos os dois lados com a mesma engenharia. Agendar uma conversa.