Dados para IA: o que a empresa precisa (e o que não precisa) ter

A conversa sobre dados para inteligência artificial costuma travar projetos antes de começarem. Alguém diz que primeiro é preciso organizar todos os dados da empresa, montar um repositório central e só depois pensar em IA. Parece prudente. Na prática, adia o valor por anos e não garante nada.

Este artigo separa o que a sua empresa realmente precisa ter do que pode esperar. A regra geral é simples: os dados se organizam a partir de um processo concreto, não de um plano abstrato.

Preciso de um data lake antes de usar IA?

Não. Um data lake é um repositório central que junta dados de vários sistemas. Ele tem utilidade, mas não é pré-requisito para a maior parte dos usos de IA nas empresas hoje.

Os agentes de IA atuais trabalham bem com o que já existe: contratos em PDF, manuais, planilhas, e-mails, cadastros no ERP e históricos no CRM. Eles leem esses materiais como estão, desde que tenham acesso a eles e saibam qual versão vale.

O risco do caminho inverso é conhecido. A empresa passa um ano organizando dados que ninguém sabe se vai usar. Quando o primeiro caso de uso aparece, descobre que faltava justamente a informação que importava.

Dado organizado sem uso definido vira custo. Dado organizado para um processo vira resultado.

Quais dados a IA realmente precisa?

A IA precisa dos dados que a pessoa que hoje faz o trabalho consulta. Se um analista responde a uma dúvida olhando o contrato, a tabela de preços e o histórico do cliente, são esses três que o agente precisa acessar.

Um bom jeito de mapear é acompanhar a tarefa por um dia e anotar cada fonte aberta. Em geral, as fontes se dividem em dois grupos:

Os dois tipos convivem no mesmo processo. Um agente de propostas, por exemplo, lê o pedido do cliente (documento), consulta preços no ERP (estruturado) e monta a resposta com base nas regras comerciais (documento).

Documentos como estão: o que dá para aproveitar sem reorganizar

A maior parte do conhecimento útil de uma empresa está em documentos, não em tabelas. E boa parte pode ser usada como está.

O que costuma funcionar sem retrabalho:

• PDFs com texto, mesmo longos e com formatação irregular.
• Planilhas com cabeçalho claro, mesmo que espalhadas em pastas.
• Manuais técnicos e procedimentos internos.
• Histórico de e-mails e chamados, quando o acesso é autorizado.

O que costuma exigir ajuste:

• Várias versões do mesmo documento sem indicação de qual vale.
• Documentos escaneados de baixa qualidade.
• Regras importantes que só existem na cabeça de alguém.

Esse último ponto é o mais comum. Antes de limpar dados, muitas vezes o trabalho é escrever o que nunca foi escrito. Falamos disso em detalhe no artigo sobre base de conhecimento para IA.

Onde a qualidade dos dados importa de verdade?

A qualidade importa onde o erro custa caro. Não faz sentido exigir o mesmo rigor de todos os dados da empresa.

Uma forma prática de decidir é classificar as informações do processo pelo impacto de um erro:

1. Crítico: preço, prazo contratual, dosagem, especificação técnica, dado fiscal. Exige fonte única, conferida e com responsável.
2. Relevante: histórico de atendimento, status de pedido, contatos. Precisa estar atualizado, mas um erro pontual é corrigível.
3. Contexto: materiais de apoio, apresentações antigas, referências. Ajudam, mas a resposta não depende deles.

Concentre o esforço de limpeza no primeiro grupo. Para o terceiro, basta indicar ao agente que é material de apoio e não fonte oficial.

Dados estruturados x documentos: quem é a fonte da verdade?

Cada informação crítica precisa ter uma fonte da verdade. Fonte da verdade é o lugar oficial onde aquela informação vale, mesmo que ela apareça em outros lugares.

Um exemplo: o prazo de entrega aparece no contrato, numa planilha do comercial e no ERP. Se os três divergem, o agente vai errar ou travar. A decisão de gestão é dizer qual deles vale. Normalmente, o sistema transacional vence para valores do dia a dia e o contrato vence para condições acordadas.

Essa é uma decisão de negócio, não técnica. Por isso cabe à liderança, não à equipe de TI sozinha.

O que a empresa não precisa ter para começar

Vale listar o que costuma ser apontado como obrigatório e não é:

• Todos os sistemas integrados. Basta integrar os que o processo escolhido usa.
• Dados históricos perfeitos. O agente trabalha com o que é atual; o histórico ajuda, mas raramente é bloqueio.
• Uma equipe de ciência de dados. Agentes que leem documentos e consultam sistemas não exigem modelos treinados do zero.
• Um projeto de governança de dados completo. Precisa de regras claras para os dados do caso de uso, não de um programa corporativo pronto.

Segundo o estudo da BCG Where's the Value in AI?, cerca de 70% do desafio de gerar valor com IA está em pessoas e processos, não em tecnologia ou algoritmos. Dados entram nessa conta, mas raramente são o gargalo principal.

Como organizar os dados a partir do caso de uso

O caminho que funciona é curto e repetível. Escolha um processo e organize apenas o que ele precisa:

1. Defina o processo e o resultado esperado.
2. Liste as fontes que a equipe consulta hoje para executá-lo.
3. Classifique cada informação pelo impacto de um erro.
4. Defina a fonte da verdade para cada informação crítica.
5. Dê ao agente acesso só ao que é necessário, com as permissões certas.
6. Registre as lacunas encontradas e corrija as que afetam o resultado.

A cada novo processo, a base fica mais organizada. Depois de alguns casos, a empresa tem dados melhores do que teria com um projeto genérico, porque cada ajuste foi feito com um motivo claro.

O papel da liderança nos dados para IA

O gestor não precisa entender de banco de dados. Precisa garantir três coisas: que cada informação crítica tenha um dono, que exista uma fonte da verdade definida e que o acesso respeite as regras de segurança e privacidade.

Com isso resolvido, a conversa muda de “nossos dados não estão prontos” para “quais dados este processo precisa”. É assim que a Horia começa os diagnósticos: pelo processo, e só depois pelos dados que ele usa.