Dados prontos para IA
A distância entre ter dados e a IA usar esses dados.
Todo piloto de IA que empaca tem a mesma autópsia: os dados não estavam prontos. Medimos a distância — qualidade, estrutura, acesso — e construímos o que a fecha, na ordem que desbloqueia o seu primeiro caso de uso.
O que construímos
- Diagnóstico de prontidão diante dos seus casos de uso reais de IA
- Pipelines de limpeza e estruturação para os dados que importam primeiro
- Preparação para recuperação — chunking, indexação e avaliação onde isso se justifica
- Acesso moldado em torno das suas permissões e controles
Quando os times nos procuram
- Um piloto de IA empacado na qualidade dos dados
- Um fornecedor disse “basta conectar seus dados” e nunca foi tão simples
- O Discovery Sprint descobriu que o primeiro passo real eram os dados — este é esse passo
Como construímos
Diagnosticar contra o caso de uso
prontidão é relativa ao que se quer construir
Corrigir em ordem de valor
primeiro o subconjunto que desbloqueia o primeiro valor
Preparar acesso e recuperação
permissões, estrutura, indexação
Verificar com a própria IA
avaliação sobre consultas reais, não sobre suposições
As quatro perguntas
Prontidão não é uma propriedade de um banco de dados. É a resposta a quatro perguntas, feitas sobre um caso de uso por vez:
Acesso
O sistema que vai usar os dados consegue de fato alcançá-los, com as permissões que esses dados já têm? "Está no warehouse" e "o modelo consegue ler" são estados diferentes, e a distância costuma ser um mês de trabalho que ninguém orçou.
Qualidade
Eles são verdadeiros? Duplicatas, registros desatualizados, campos que significam coisas diferentes em sistemas diferentes. Um modelo treinado nisso vai errar com toda a confiança exatamente onde os dados erram.
Estrutura
Eles têm a forma de que o caso de uso precisa? A recuperação quer chunks e um índice; um preditor quer uma tabela com um rótulo; um agente quer registros sobre os quais possa agir. Os mesmos dados estão prontos para um e não para o outro.
Um caminho
Existe um caminho de onde o dado nasce até onde o modelo o lê que rode sem uma pessoa? Um pipeline que alguém reexecuta à mão é uma demo, não prontidão.
A maioria dos pilotos que empacam falha em uma das quatro. Quase nenhum falha nas quatro — e é por isso que a correção costuma ser menor que o medo.
O que “pronto” acabou significando
O erro que mais vemos é tratar a prontidão como um projeto que termina antes de a IA começar: limpar tudo, estruturar tudo e só então começar. Nunca termina, e o piloto espera um ano por uma base da qual precisava de um décimo. Prontidão é relativa a um caso de uso. Um assistente que responde perguntas a partir da sua documentação precisa que esses documentos estejam indexados e atualizados, e nada mais. Um modelo que prevê churn precisa de uma tabela, com os joins feitos, rotulada e atualizada — e nada mais.
Por isso o trabalho corre em ordem de valor: o subconjunto de dados que desbloqueia o primeiro caso de uso, tornado confiável primeiro, com a própria IA como teste. Se o assistente responde corretamente a perguntas reais com os dados como foram preparados, os dados estavam prontos. Se não, a avaliação diz qual das quatro perguntas continua aberta — e esse é o trabalho da semana seguinte, não uma reescrita do plano.
Funciona bem com
Perguntas frequentes
Quanto tempo leva ficar pronto?
Depende do que o caso de uso precisa — estar pronto para um assistente não é estar pronto para tudo. É por isso que dimensionamos até o primeiro valor.
Nossos dados são bagunçados demais para IA?
Bagunça é o estado padrão das empresas reais. A pergunta é qual subconjunto importa primeiro.
Precisamos de tudo pronto antes de começar?
Não. A prontidão e o piloto avançam juntos.
O que vocês entregam de fato?
Para o caso de uso em escopo: um diagnóstico que nomeia quais das quatro perguntas estão abertas e quanto custa fechar cada uma; os pipelines e as estruturas que fecham as que estão no caminho crítico; e um conjunto de avaliação com consultas reais e respostas conhecidas, para que "pronto" seja uma medição e não uma opinião.
Temos um data warehouse. Isso não basta?
É um bom começo, e muitas vezes não é o problema. Warehouses são construídos para relatórios: agregados, atualizados de madrugada, com a forma de um dashboard. A recuperação precisa de documentos indexados no momento da consulta; agentes precisam de registros sobre os quais possam agir. O warehouse nos diz que os dados existem; prontidão é sobre a forma de que eles precisam para o que você quer construir.
Nossos dados precisam sair do nosso ambiente?
Não. O trabalho acontece onde os dados já moram — sua cloud, suas permissões, seu log de auditoria. Os pipelines que construímos rodam ali, e o que levamos é o diagnóstico e o conjunto de avaliação, não os dados.
Descubra exatamente em que estado estão seus dados.
O sprint inclui viabilidade técnica e requisitos de dados.