Consultoria de dados e IA: por que andam juntas e o que fazer quando seus dados são ruins
Consultoria de dados e IA são o mesmo trabalho: nenhum projeto de IA sobrevive a dado sem dono, sem chave e sem histórico. Como diagnosticar em semanas, definir o mínimo viável e construir na ordem certa.
A objeção mais comum que ouvimos em uma primeira conversa é “nossos dados são ruins, ainda não estamos prontos para IA”. É uma objeção honesta e quase sempre verdadeira. Também é o motivo pelo qual consultoria de dados e IA são, na prática, o mesmo trabalho. Não existe projeto de IA que não comece pelo dado, e não existe motivo para arrumar o dado sem um caso de uso que diga o que arrumar primeiro.
Este texto explica por que os projetos morrem no dado, como diagnosticar a situação em poucas semanas, qual é o mínimo para um primeiro caso e em que ordem construir o resto. A tese: dados ruins não são motivo para adiar. São o primeiro projeto.
Por que projetos de IA morrem no dado
O padrão se repete. A empresa escolhe um caso de uso, monta um time, e nas primeiras semanas descobre que o dado necessário está em três sistemas que não conversam, com chaves diferentes, com campos preenchidos de forma inconsistente e sem ninguém que responda por ele. O projeto de IA vira projeto de integração, o orçamento acaba e a IA nunca chega.
As causas mais frequentes que encontramos:
- Dado sem dono. Ninguém responde pela qualidade do cadastro de cliente ou da tabela de produtos. Quando aparece erro, ninguém corrige.
- Dado sem chave. O mesmo cliente tem identificadores diferentes no CRM, no ERP e no sistema de atendimento. Cruzar exige heurística, e heurística erra.
- Dado sem histórico. O sistema sobrescreve o estado atual e não guarda o que era antes. Sem histórico, não há como treinar modelo preditivo nem medir o que mudou.
- Dado preso. Está no sistema, mas só sai por relatório manual ou por acesso que leva dois meses para aprovar.
- Dado sem definição. “Cliente ativo” significa uma coisa para vendas e outra para financeiro. O modelo aprende a definição errada.
Nenhum desses problemas é técnico no sentido estrito. São problemas de organização que aparecem como problemas técnicos. É por isso que uma consultoria de IA que não trabalha dados e analytics junto entrega um modelo bonito sobre uma base em que ninguém confia.
Diagnóstico de dados: fontes, qualidade, acesso, governança
O diagnóstico não é um inventário de todos os dados da empresa. Isso leva meses e não muda nada. É um levantamento orientado por um ou dois casos de uso candidatos, respondendo a quatro perguntas em três a quatro semanas.
Fontes
Quais sistemas contêm o dado que o caso precisa. Quem administra cada um. Como o dado sai de lá hoje: API, banco, arquivo, relatório. Com que frequência é atualizado. O resultado é um mapa de origem por campo, não por sistema.
Qualidade
Para cada campo crítico: percentual de preenchimento, valores fora do domínio esperado, duplicidade, consistência entre fontes e atraso em relação ao evento real. Medimos com consultas simples sobre amostras reais, não com questionário. Os números costumam surpreender, para os dois lados.
Acesso
Quem pode ler o quê, por qual mecanismo e em quanto tempo. Um dado de boa qualidade que leva oito semanas para ser liberado é, para efeito do projeto, um dado que não existe. O diagnóstico registra o caminho real de aprovação.
Governança
Existe dono nomeado para o dado. Existe definição escrita dos termos de negócio. Existe classificação de sensibilidade, com a LGPD em mente. Existe processo para corrigir erro na origem. As respostas costumam ser não, e tudo bem. O ponto é saber onde se está.
Checklist que usamos ao fechar o diagnóstico:
- Mapa de origem por campo, com sistema, dono e mecanismo de extração
- Métricas de qualidade medidas em amostra real para cada campo crítico
- Tempo real de acesso a cada fonte, com o caminho de aprovação
- Lista de termos de negócio com definição acordada entre as áreas
- Classificação de sensibilidade e base legal para cada dado pessoal
- Lista priorizada do que precisa ser corrigido antes do primeiro caso, e do que pode esperar
O mínimo viável de dados para um primeiro caso
O erro oposto a “nossos dados são ruins” é “vamos construir o data lake completo antes de qualquer IA”. Isso leva dois anos e produz uma plataforma sem casos de uso. O caminho certo é definir o mínimo que um caso específico precisa e construir só isso, com qualidade.
O mínimo depende do tipo de caso. Uma engenharia de dados para IA bem feita começa por esta separação.
| Tipo de caso | Dado mínimo | O que pode esperar |
|---|---|---|
| Preditivo (score, previsão) | Histórico rotulado de 12 a 24 meses, com chave estável e data do evento | Catálogo completo, dados de outras áreas |
| Generativo com RAG (busca, atendimento) | Documentos aprovados, com dono, versão e permissão de acesso | Dados transacionais, histórico de conversas |
| Agentes de IA sobre processo | Acesso de leitura e escrita aos sistemas do processo, com log | Integração com sistemas fora do processo |
| Analytics operacional | Uma fonte confiável por indicador, atualizada no ritmo da decisão | Modelo dimensional completo |
Exemplo ilustrativo: uma empresa quer usar IA para priorizar cobrança. Precisa de histórico de faturas, pagamentos e contatos dos últimos 18 meses, com chave de cliente consistente entre financeiro e atendimento. Não precisa do cadastro de fornecedores, nem do estoque, nem de um catálogo corporativo. Três tabelas limpas, com dono e atualização diária, bastam para o primeiro modelo. O resto vem depois, puxado pelo segundo caso.
Pipeline, catálogo e camada analítica
Com o mínimo definido, o trabalho de construção tem três peças. Elas são pequenas no primeiro caso e crescem com os seguintes.
Pipeline. Extração automatizada das fontes, transformação com regras versionadas e carga em um repositório analítico separado dos sistemas de origem. Com testes de qualidade rodando a cada carga: preenchimento, domínio, duplicidade, atraso. Quando um teste falha, alguém é avisado antes que o modelo consuma dado errado.
Catálogo. Não precisa de ferramenta cara no início. Precisa de um lugar onde cada tabela e cada campo tem definição, dono, origem e classificação. Começa como documento e cresce para ferramenta quando o volume justificar. O que importa é que a definição de “cliente ativo” esteja escrita e acordada.
Camada analítica. As tabelas prontas para consumo, modeladas em torno das entidades do negócio, com métricas calculadas uma vez e reutilizadas. É daqui que o modelo de IA lê, é daqui que o painel de gestão lê, e é daqui que a área de negócio confere se o número bate. Quando os três leem da mesma camada, a discussão sobre qual número está certo acaba.
Essas três peças são o núcleo do que entregamos em dados e analytics. Não são infraestrutura genérica. São construídas em torno do caso, com o tamanho que o caso exige.
Sequência de uma consultoria de dados e IA: dado, analytics, IA
A ordem importa e não é arbitrária. Dado primeiro, porque sem ele nada funciona. Analytics em seguida, porque é o jeito mais barato de validar que o dado está certo e de gerar valor enquanto o modelo não existe. IA por último, sobre uma base que o negócio já usa e já confia.
Isso não significa três projetos em sequência de um ano cada. Significa três camadas construídas em torno do mesmo caso, em semanas. Um projeto típico de consultoria de dados e IA para um primeiro caso segue mais ou menos assim:
- Semanas 1 a 3: diagnóstico orientado pelo caso, com o mapa de origem e as métricas de qualidade.
- Semanas 4 a 7: pipeline e camada analítica mínima para o caso, com testes de qualidade e catálogo inicial. Painel operacional entregue para a área.
- Semanas 8 a 12: modelo ou agente construído sobre a camada, avaliado contra a rubrica do negócio, colocado em produção com monitoramento.
O painel da semana 7 costuma ser, sozinho, o primeiro retorno do projeto. A área passa a enxergar o processo com dado confiável antes de qualquer modelo. E quando o modelo chega, ele chega sobre um número que a área já aceita.
O que a sequência evita é o cenário em que a IA é construída sobre dado que ninguém validou, produz resultado em que ninguém confia e é abandonada por falta de adoção. Dado, analytics e IA andam juntos porque separados não funcionam.
Perguntas frequentes
Meus dados são ruins. Devo esperar antes de contratar consultoria de dados e IA?
Não. Dados ruins são o diagnóstico, não a contraindicação. O primeiro projeto arruma o mínimo que um caso concreto precisa e entrega valor com esse mínimo. Esperar para arrumar tudo antes costuma significar nunca começar.
Preciso de um data lake ou data warehouse antes da IA?
Precisa de uma camada analítica confiável para o caso escolhido. Se ela cabe em algumas tabelas bem definidas com pipeline testado, isso basta. A plataforma cresce com os casos, não antes deles.
Quanto tempo leva o diagnóstico de dados?
Três a quatro semanas quando é orientado por um ou dois casos de uso e feito com acesso real às fontes. Inventários completos de todos os dados da empresa levam meses e raramente mudam decisões.
Consultoria de dados e IA substitui um time interno de dados?
Não. Constrói a base e o primeiro caso junto com quem vai operar, e deixa pipeline, catálogo e camada analítica documentados para o time interno assumir. O objetivo é que o segundo caso seja feito com muito menos dependência externa.
Se a sua empresa está travada na objeção do dado ruim, o diagnóstico orientado por caso é o primeiro passo. A página de dados e analytics mostra como conduzimos esse trabalho e o que entregamos em cada fase.