Prontidão de Dados: O Pré-Requisito que a Maioria dos Projetos de AI Ignora

Conheça Priya. Ela gerencia uma empresa de serviços B2B com 120 funcionários. A receita é saudável. Sua equipe vem crescendo de forma consistente há quatro anos.

Seis meses atrás, ela aprovou um piloto de R$ 60 mil: uma ferramenta de lead scoring preditivo integrada ao CRM que sua equipe de vendas utilizava desde 2021. O fornecedor estava confiante. A Demo foi impressionante.

Três meses depois, as pontuações pareciam aleatórias. Os representantes pararam de confiar nelas. Ninguém conseguia explicar por que duas das contas com melhor perfil ficaram classificadas como baixa prioridade, enquanto uma dúzia de contatos frios apareciam como "quentes." A equipe de suporte do fornecedor analisou a configuração e enviou um documento de duas páginas sobre requisitos de completude de dados que ela nunca havia visto antes de assinar o contrato.

A AI não estava quebrada. Os dados estavam.

O Gartner relata que até 2026, as organizações vão abandonar 60% dos projetos de AI por falta de dados prontos para AI. Não por causa da qualidade do modelo. Não por falta de habilidade da equipe. Não porque a tecnologia não estava madura o suficiente. Os dados não estavam prontos.

Este é o pré-requisito sem glamour que a maioria das equipes ignora porque é entediante. E ele é decisivo.

Este artigo é para Priya, e para todo fundador, líder de operações ou responsável por departamento que quer saber se seus dados estão prontos antes de gastar mais um centavo em ferramentas de AI.

O que prontidão de dados realmente significa

"Prontidão de dados" não significa dados perfeitos. Significa dados bons o suficiente para a capability de AI específica que você quer usar.

Mais precisamente: dados que são localizáveis, acessíveis, estruturados, atualizados e permitidos para uso com AI.

• Localizáveis: você sabe onde os dados estão e consegue acessá-los sem um projeto de várias semanas
• Acessíveis: a ferramenta de AI consegue lê-los via API, exportação ou conector nativo
• Estruturados: têm schema e consistência suficientes para um modelo aprender padrões
• Atualizados: refletem a realidade atual, não o que era verdade há dois anos
• Permitidos: o jurídico, a segurança e o compliance aprovaram seu uso com AI

A maioria das equipes descobre que é fraca em uma ou duas dessas dimensões. Isso geralmente é suficiente para matar um piloto.

Os cinco modos de falha

Saber o que torna os dados não prontos é mais acionável do que saber o que os torna prontos. Aqui estão os cinco modos de falha que destroem projetos de AI antes mesmo de o modelo ter uma chance.

Modo de falha 1: dados em silos

Seu CRM tem histórico de negociações, mas não consegue ver os tickets de suporte. Sua plataforma de marketing sabe cada material que um prospect baixou, mas suas ferramentas de vendas não têm acesso a isso. Seu sistema financeiro tem três anos de histórico de pagamentos, mas sua plataforma de customer success não sabe quais contas estão 60 dias em atraso.

Este é o modo de falha mais comum em empresas de médio porte, e é invisível até você tentar construir algo que depende de dados conectados. Uma capability de Ingest consegue puxar de um sistema. Mas no momento em que sua AI precisa ver o panorama completo do cliente (histórico de compras mais interações de suporte mais engajamento por e-mail mais sinais de renovação), você precisa que esses sistemas se comuniquem entre si.

Normalmente eles não se comunicam. Não sem um trabalho real de integração que acontece antes de você comprar a ferramenta de AI, não depois.

Modo de falha 2: campos não estruturados sem schema

Seu CRM tem um campo "Observações". Sua plataforma de suporte também. Sua ferramenta de gestão de projetos e sua planilha de acompanhamento também. Cada representante o usa de forma diferente. Alguns escrevem parágrafos. Alguns não escrevem nada. Alguns escrevem "ligou, deixou recado" e outros escrevem "14/02: conversei com J. Chen, interessado mas precisa de aprovação do CFO, orçamento ~R$40K, prazo T2."

Campos de texto livre sem schema são quase inúteis para uma AI que precisa aprender padrões. A capability de Analyze consegue extrair sinal de texto não estruturado, mas somente se houver volume suficiente e consistência para o modelo distinguir sinal de ruído. As equipes frequentemente só descobrem esse problema depois de integrar a ferramenta. Os outputs do modelo parecem errados, mas o modelo está fazendo o melhor possível com inputs inconsistentes.

Modo de falha 3: contexto ausente nos registros

Um registro existe no seu banco de dados, mas faltam os campos que lhe dão significado.

Seu CRM tem 8.000 registros de empresas, mas 40% não têm uma tag de setor. Seu histórico de negociações remonta a quatro anos, mas o motivo de ganho/perda só passou a ser obrigatório há 18 meses.

Para uma capability de Predict construindo um modelo de lead scoring, esses campos ausentes não são um inconveniente menor. Eles são o sinal de treinamento. Se você não tem resultados associados a inputs, não consegue treinar um modelo de predição significativo. O contexto é o tecido conectivo. Registros sem ele são pontos de dados sem significado.

Modo de falha 4: problemas de qualidade

Duplicatas. Erros de digitação. Entradas desatualizadas. Um campo de "nome da empresa" com sete grafias diferentes da mesma conta enterprise. Estágios de negociação que nunca mudaram porque um representante esqueceu de atualizá-los.

Problemas de qualidade confundem os modelos de formas difíceis de diagnosticar. Uma capability de Generate alimentada com material de referência inconsistente produz rascunhos inconsistentes. Um modelo de lead scoring treinado com registros duplicados supervaloriza certas características porque elas aparecem várias vezes. Uma ferramenta de detecção de anomalias que aprende a partir de dados desatualizados como baseline sinaliza comportamentos normais como anômalos. Os outputs parecem errados, mas o problema não é o modelo. São os inputs.

Modo de falha 5: dados com acesso restrito

Seus dados existem. Estão limpos o suficiente. São acessíveis a humanos. Mas seu jurídico ou equipe de segurança tem uma política que impede alimentá-los em ferramentas de AI.

"Sem PII no ChatGPT" é uma política razoável. Mas se os dados que sua AI precisa contêm nomes de clientes, endereços de e-mail ou dados comportamentais vinculados a indivíduos, essa política pode bloquear todo o caso de uso. Uma capability de Execute que envia e-mails automaticamente precisa de informações de contato. Uma ferramenta de triagem de suporte precisa ler o conteúdo dos tickets. Uma ferramenta de revisão de documentos precisa dos documentos.

Antes de pilotar qualquer coisa, verifique se os dados que você alimentaria à ferramenta estão aprovados. Não apenas tecnicamente acessíveis, mas juridicamente autorizados e documentados em política. Essa conversa precisa acontecer antes do piloto, não depois.

A auditoria de cinco perguntas

Você não precisa de uma equipe de data science para realizar essa auditoria. Precisa de 30 minutos com alguém que conhece seus sistemas.

Pergunta 1: Consigo baixar os dados que minha AI precisaria hoje, sem acionar o time de TI? Se não, você tem uma dependência de acesso a resolver antes que qualquer ferramenta de AI possa fazer algo útil.

Pergunta 2: Todos os registros têm os campos que a AI precisa, ou 40% estão nulos? Puxe 100 registros aleatoriamente. Se mais de 20-30% dos campos-chave estão vazios ou claramente errados, você tem um problema de completude.

Pergunta 3: Os dados são recentes o suficiente para refletir a realidade atual? Lead scoring precisa dos últimos 12-18 meses de dados de negociações. Se seus dados limpos têm dois anos e seu processo de vendas mudou há 18 meses, o modelo aprende o processo antigo.

Pergunta 4: Existe uma fonte autoritativa única, ou quatro versões conflitantes? "O CRM é a fonte da verdade, mas as vendas mantêm uma planilha, e o financeiro tem números diferentes no ERP" é um problema de coerência. A AI não consegue reconciliar fontes concorrentes. Alguém tem que decidir qual sistema prevalece.

Pergunta 5: O jurídico ou a segurança têm uma política para alimentar esses dados a ferramentas de AI? Pergunte explicitamente. Em muitas empresas de médio porte, a política de dados para AI ainda não foi escrita. Crie-a antes de prosseguir, não depois.

Se você consegue responder as cinco perguntas de forma clara, seus dados estão prontos o suficiente para começar. Se duas ou mais lhe causam hesitação, é nelas que seu investimento pré-AI deve ir.

A pirâmide de prontidão de dados

Pense na prontidão de dados como uma pirâmide com cinco níveis. A maioria das equipes precisa subir a partir da base antes que os níveis superiores entreguem valor.

A maioria das equipes de médio porte que inicia um projeto de AI está no Nível 1 ou parcialmente no Nível 2. Isso é normal. Você pode começar trabalhos de AI no Nível 1 ou 2. Mas é preciso saber em qual nível você está, porque as capabilities que pode implantar dependem disso.

Uma equipe no Nível 1 consegue executar Workflows de Analyze a partir de texto ou registros estruturados relativamente limpos, e experimentar com Ingest para transformar documentos e áudio em forma utilizável. Elas ainda não conseguem executar Workflows sérios de Predict, porque esses requerem o Nível 3 (dados históricos rotulados).

Uma equipe no Nível 3 que não fez o Nível 4 está a uma auditoria de fornecedor de distância de ter que encerrar seus Workflows de AI. Governança não é um item opcional. É o que permite escalar sem reconstruir quando a política eventualmente chega.

O Nível 5 é o que separa equipes que mantêm valor com AI ao longo do tempo daquelas cujos pilotos degradam silenciosamente. Observabilidade significa monitoramento em funcionamento para capturar quedas de qualidade dos dados: campos ficando nulos, registros duplicados acumulando, atualização ficando para trás. Sem isso, um modelo que funcionou há seis meses pode agora produzir resultados ruins, e você só vai saber quando um representante ligar para uma conta inativa.

Prontidão mínima viável por capability ACE

Nem toda capability precisa da mesma base de dados. Aqui está o mínimo para cada uma das cinco:

Esta tabela é prática para sequenciamento. Se você tem dados de CRM limpos mas sem rótulos históricos, comece com Analyze e Generate, não com Predict. Construa o hábito de rotulação enquanto executa as capabilities de menor risco. Quando tiver 12-18 meses de resultados rotulados, Predict estará ao seu alcance.

O que fazer quando seus dados não estão prontos

A maioria das equipes está nessa posição. Aqui está o que realmente funciona.

Comece com o único sistema que está pronto. A maioria das empresas tem uma fonte de dados mais limpa que as outras. Seu sistema de tickets de suporte pode ser mais bagunçado que seu CRM, mas se o CRM tem três anos de histórico de negociações limpo com resultados, comece seu trabalho de AI por lá. Escolha o caso de uso que se adapta aos seus dados mais sólidos, não o caso de uso que você mais gostaria de fazer.

Execute Ingest e Analyze primeiro. Essas são capabilities somente leitura que produzem insights sem alterar estado externo. Executá-las antes de Predict ou Execute permite gerar valor com requisitos de dados menores enquanto você melhora a qualidade para as capabilities de maior impacto.

Construa hábitos de rotulação antes de precisar de um modelo. Se você quer lead scoring em 12 meses, comece a exigir campos de motivo de ganho/perda no seu CRM hoje. Torne-os obrigatórios. Quando estiver pronto para treinar, os rótulos já estarão lá.

Considere AI de fornecedor que traz sua própria baseline. Produtos como Salesforce Einstein, pontuação preditiva do HubSpot ou Gong vêm com modelos pré-treinados que carregam algum sinal antes de você adicionar seus próprios dados, o que reduz a penalidade de cold-start para equipes menores.

Prontidão de dados como vantagem competitiva

Aqui está a parte que não é óbvia quando você está no meio de um piloto frustrante.

As equipes que fazem o trabalho ingrato de integração (limpando seu CRM, insistindo em campos obrigatórios, unindo seus sistemas, documentando suas políticas de dados) estão construindo uma vantagem competitiva que melhorias de modelo não conseguem apagar.

A qualidade do modelo é uma commodity. OpenAI, Anthropic e Google estão competindo para oferecer modelos melhores. Em 18 meses, os modelos que você pode acessar via API serão muito mais capazes do que os atuais. Mas um modelo melhor alimentado com dados sujos e em silos ainda vai produzir resultados ruins.

As empresas que vencerão a corrida de AI nos próximos três anos não são necessariamente as que adotaram o modelo mais recente mais rápido. São as que construíram a base de dados que faz os modelos funcionarem. Dados limpos com um modelo básico supera dados bagunçados com o modelo mais recente, quase sempre.

O trabalho entediante que faz projetos de AI terem sucesso

Estas são as tarefas sem glamour que determinam se seu piloto de AI realmente entrega valor:

• Deduplique seus contatos e contas no CRM antes de conectar qualquer ferramenta de AI
• Torne o motivo de ganho/perda um campo obrigatório nos seus registros de negociações (e faça o backfill de 12 meses se puder)
• Audite seus campos de texto livre mais importantes: os representantes estão preenchendo? São consistentes?
• Mapeie seus fluxos de dados: o que entra e o que sai em cada sistema-chave
• Peça ao seu jurídico ou equipe de segurança para escrever sua política de uso de dados com AI antes de assinar qualquer contrato com fornecedor
• Identifique sua fonte autoritativa da verdade para cada tipo de dado-chave: registros de clientes, histórico de negociações, tickets de suporte
• Construa o hábito de monitoramento: quem revisa a qualidade dos dados mensalmente, e o que procura?

Nenhuma dessas tarefas é tecnicamente complexa. Todas elas requerem vontade organizacional sustentada para realmente ser feitas. Esta é a verdadeira razão pela qual a maioria das equipes pula esse trabalho. É entediante, lento e não parece "AI." Mas é o trabalho mais importante que você fará no seu programa de AI.

O que ler a seguir

O ACE Framework se constrói a partir da base de dados coberta aqui:

• Os 7 tipos de dados que seus Workflows de AI vão consumir
• Sua AI não é burra: diagnosticando problemas de qualidade de dados em implantações ativas
• O ACE Framework: a pilha completa de seis camadas, com dados como fundação
• Ingest: a primeira capability, e a mais diretamente ligada ao acesso a dados
• Por que a maioria dos frameworks de AI falha: o que a maioria dos frameworks ignora sobre o problema de dados

O entediante supera o brilhante. Acerte os dados, e a AI vai surpreendê-lo. Pule isso, e você passará seis meses se perguntando por que o modelo está "quebrado" quando o modelo está funcionando exatamente como deveria.