Como preparar dados para IA em funcionalidades

Preparar dados para IA no produto não significa limpar tudo, conectar tudo e esperar que a inteligência artificial encontre valor sozinha. O trabalho começa ao transformar inventário em contexto operacional: verificar se cada dado é pertinente para a tarefa da funcionalidade e acessível no momento real de uso. Se o dado não muda a resposta, não pode ser usado com permissão clara ou chega tarde demais, ainda é apenas inventário.

Quando o dado existe, mas não serve à funcionalidade

O erro comum começa em uma reunião aparentemente pragmática. Alguém pergunta quais dados a empresa tem. A lista cresce rápido: histórico de uso, cadastro de clientes, base de conhecimento, tickets, notas internas, eventos de produto, conversas, documentos comerciais, registros de atendimento.

A lista pode parecer suficiente para criar uma funcionalidade inteligente.

Mas existência não é utilidade.

Uma funcionalidade de inteligência artificial em um software precisa de dados que ajudem uma tarefa específica. Dados para IA no produto não são um lago abstrato de informações. São evidências selecionadas para melhorar uma decisão dentro de um fluxo. A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada (Anthropic). Essa definição ajuda a separar duas coisas que muitas equipes misturam: ter dados armazenados e entregar contexto útil no instante em que a IA precisa responder.

A pergunta, portanto, não é “quais bases podemos conectar?”. A pergunta é: “qual informação muda a resposta desta funcionalidade, para este usuário, neste momento do fluxo?”.

Essa diferença muda o trabalho da liderança. Em vez de aprovar um esforço genérico de organização de dados, a liderança aprova um recorte: tarefa, evidências, permissões, atualização, acesso e limites de confiança.

Defina a tarefa antes de listar bases de dados

Uma funcionalidade inteligente precisa caber em um verbo de produto. Ela pode sugerir, classificar, resumir, preencher, priorizar, explicar, comparar ou acionar um fluxo. Se a equipe não consegue nomear esse verbo, a preparação de dados ainda está cedo demais.

“Usar IA no atendimento” é amplo. “Sugerir uma resposta inicial para o atendente com base no chamado, no plano contratado e em artigos vigentes da base de conhecimento” já permite discutir dados. “Ajudar o gerente de contas” é amplo. “Resumir mudanças recentes no uso do produto antes de uma reunião com o cliente” já cria uma pergunta de contexto.

Essa definição reduz dois riscos de escopo.

O primeiro é preparar dados porque eles estão disponíveis, não porque são necessários. O segundo é confundir uma funcionalidade de produto com um projeto de exploração. Descoberta é o momento de entender a oportunidade. Hipótese é uma aposta explícita sobre o que pode melhorar. Experimento é o teste controlado dessa hipótese. Pular essa separação leva a integrações caras que ainda não respondem a uma pergunta de produto.

Uma formulação útil é: “para executar esta tarefa, que evidência faria a IA responder de modo diferente?”.

Se a evidência não muda a recomendação, a classificação, o resumo ou a ação, ela não deve entrar na primeira versão. Pode ser interessante para análise futura. Pode ajudar outro fluxo. Pode alimentar uma decisão de negócio. Mas não é, por isso, dado pertinente para essa funcionalidade.

Esse raciocínio também se conecta a uma discussão maior sobre direção de produto. Uma estratégia de inteligência artificial conectada ao negócio ajuda a priorizar onde a IA deve entrar. Neste artigo, o recorte é menor e mais operacional: depois que a funcionalidade candidata existe, quais dados merecem entrar no contexto dela?

Use pertinência como primeiro filtro de dados para IA no produto

Pertinência é a relação entre um dado e a decisão que a funcionalidade precisa apoiar. Um dado pertinente reduz ambiguidade, confirma uma restrição, atualiza uma condição ou impede uma resposta inadequada. Um dado impertinente só aumenta ruído.

Antes de discutir conectores, pipelines ou modelos, vale aplicar cinco filtros simples:

Relação direta com a tarefa: o dado influencia a resposta esperada ou apenas parece complementar?
Redução de ambiguidade: ele ajuda a escolher entre respostas possíveis?
Atualização compatível: a informação estará suficientemente atual para a decisão que a IA apoiará?
Rastreabilidade mínima: é possível saber de onde veio e por que foi usada?
Risco de erro: se estiver errado, antigo ou fora de contexto, pode induzir uma resposta pior do que a ausência do dado?

Exemplo fictício: imagine um SaaS de suporte que quer sugerir respostas ao atendente. A funcionalidade não enviará a mensagem automaticamente. Ela apenas prepara uma sugestão para revisão humana dentro da tela do chamado.

Nesse caso, alguns dados parecem pertinentes: categoria do chamado, descrição enviada pelo cliente, plano contratado, artigos vigentes da base de conhecimento e últimos tickets resolvidos do mesmo cliente. Cada um deles pode mudar a resposta sugerida. O plano contratado pode limitar uma instrução. A categoria do chamado pode direcionar o artigo correto. Tickets recentes podem evitar que a IA repita uma orientação que já falhou.

Outros dados podem existir, mas ficar fora da primeira versão: comentários internos antigos, notas comerciais soltas, documentos sem data, mensagens de canais paralelos e registros sem dono claro. Eles talvez tenham valor em outro processo, mas, para sugerir uma resposta de suporte, podem confundir o contexto ou expor informação que não deveria aparecer no fluxo do atendente.

Esse é um ponto operacional e decisivo. Contexto em excesso pode degradar o produto ao aumentar latência, custo, exposição de dados e chance de contradição. A Anthropic recomenda começar pela solução mais simples e acrescentar complexidade quando necessário ao discutir padrões de agentes e fluxos com modelos (Anthropic). Na mesma referência, a Anthropic distingue fluxos com caminhos predefinidos de agentes que decidem dinamicamente seu processo e uso de ferramentas. Aqui, o mesmo princípio vale para dados: comece pelo conjunto mínimo que sustenta a tarefa.

Verifique acesso no momento real de uso

Depois da pertinência vem o acesso. E acesso não é “alguém consegue exportar esse dado”. Acesso, em produto, significa que a funcionalidade consegue receber o dado certo, no formato certo, com permissão adequada, no momento em que a IA responde.

Essa verificação precisa passar por perguntas operacionais:

Permissão: o usuário atual pode ver esse dado? A funcionalidade pode usá-lo para essa finalidade? O modelo pode recebê-lo naquele contexto?
Disponibilidade: a origem está acessível durante o fluxo ou depende de conciliação posterior?
Atualização: o dado reflete a situação atual ou pode estar vencido?
Latência aceitável: buscar esse dado torna a experiência lenta demais para a tarefa?
Formato: a informação está estruturada o bastante para ser usada ou exigirá interpretação frágil?
Granularidade: a IA precisa do documento inteiro, de um trecho, de um atributo ou de um estado calculado?
Origem: existe uma fonte preferencial quando duas bases divergem?
Restrição por perfil: administradores, atendentes, gerentes e clientes veem o mesmo contexto?

Esse ponto evita uma armadilha frequente. Em uma demonstração, é possível preparar manualmente um conjunto de dados, colar trechos no prompt e obter uma resposta convincente. No produto, a pergunta é outra: quando um usuário real acionar a funcionalidade, a IA receberá aquele contexto sem improviso?

Se a resposta for não, o dado ainda não deve ser tratado como parte da funcionalidade. Ele pode ser uma dependência futura. Pode exigir trabalho de permissão, governança, integração ou desenho de fluxo. Mas não deve sustentar o escopo da primeira versão.

A discussão se aproxima da maturidade organizacional. Um diagnóstico de maturidade em IA não depende apenas da tecnologia escolhida. A maturidade aparece na capacidade de definir contexto, controlar acesso, medir comportamento e decidir limites.

Monte um inventário mínimo para a primeira versão

O inventário útil não é uma enciclopédia de bases corporativas. É uma lista de decisão para a funcionalidade.

Para cada dado candidato, registre em linguagem simples:

Dado necessário: qual informação a IA precisa receber.
Origem: sistema, documento, base ou evento de onde o dado vem.
Dono: área ou papel responsável pela qualidade e pelo significado daquele dado.
Finalidade na resposta: por que esse dado muda a sugestão, classificação ou ação.
Frequência de atualização: quando ele muda e quando fica arriscado usá-lo.
Permissão: quais perfis podem acessar e em quais condições.
Forma de acesso: como a funcionalidade receberá o dado no fluxo real.
Risco se estiver ausente: o que a IA deve fazer quando a informação não existir.
Alternativa manual: como o usuário resolve hoje sem automação.
Critério de exclusão: em que situação o dado sai do contexto.

A presença do “critério de exclusão” é deliberada. Muitas iniciativas só têm critérios para adicionar dados. Poucas definem quando remover. Isso cria funcionalidades cada vez mais cheias de contexto, mas não necessariamente mais confiáveis.

No exemplo fictício do SaaS de suporte, a equipe poderia decidir que artigos da base de conhecimento só entram se tiverem dono, data de vigência e status publicado. Um artigo antigo, sem responsável claro, não deve aparecer apenas porque está armazenado. Da mesma forma, tickets resolvidos podem entrar como referência, mas comentários internos marcados como restritos ficam bloqueados.

Menos dados, quando bem escolhidos, podem gerar uma experiência mais controlável. Não porque simplicidade seja uma virtude abstrata, mas porque cada dado incluído cria uma obrigação: manter, autorizar, atualizar, explicar e monitorar.

Esse inventário também ajuda a construir um roadmap de IA com dependências reais. Em vez de “conectar CRM”, a tarefa vira “permitir que a sugestão de resposta considere o plano contratado com atualização confiável e permissão por perfil”. É uma diferença pequena na frase e grande na execução.

Teste a hipótese antes de ampliar o contexto

Depois de selecionar dados pertinentes e acessíveis, a equipe ainda não provou que a funcionalidade entrega valor. Ela apenas criou uma versão testável.

A hipótese precisa ser explícita. No exemplo fictício: “se a IA tiver acesso ao plano contratado, à categoria do chamado, aos artigos vigentes e aos últimos tickets resolvidos, então as sugestões tenderão a apresentar menos incompatibilidades com a situação do cliente em uma amostra controlada”.

Isso é uma hipótese, não um resultado. O próximo passo é definir como observar se ela se sustenta.

A Microsoft descreve sua plataforma ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos (Microsoft Research). Essa referência não significa que todo produto precise de uma plataforma sofisticada nem que feedback de usuário retreine automaticamente um modelo. O ponto aplicável é mais direto: trate a funcionalidade como uma hipótese de produto que precisa ser medida antes de ampliar escopo.

Para uma primeira avaliação, a equipe pode comparar amostras de sugestões com e sem determinados dados, revisar casos em que a IA usou informação vencida, identificar respostas bloqueadas por falta de permissão e observar quando o atendente descartou a sugestão por incompatibilidade com o contexto. Antes de conectar novas fontes, defina qual evidência mostrará que o dado melhorou a funcionalidade.

Também vale separar métricas de confiabilidade do serviço. O Google SRE define objetivos de nível de serviço como metas de confiabilidade que orientam decisões de engenharia, com acordo sobre metas, orçamento de erro e processo de revisão (Google SRE). Em uma funcionalidade inteligente, essa lógica ajuda a discutir limites operacionais: quando a resposta deve ser entregue, quando deve falhar de forma segura e quando o produto deve encaminhar para um fluxo humano.

Não é necessário transformar esta pauta em uma discussão profunda de latência, custo ou produção. Mas é perigoso ignorar que dados têm comportamento operacional. Uma fonte lenta, instável ou permissiva demais pode tornar a funcionalidade inadequada mesmo quando o modelo parece bom.

Matriz de pertinência e acesso antes de construir

Use esta matriz como conversa de aprovação antes de investir na construção da primeira versão.

Tarefa do usuário

A funcionalidade tem uma tarefa específica ou está tentando usar IA de forma genérica?

Se a tarefa não couber em um verbo de produto, como classificar, sugerir, resumir ou priorizar, a preparação de dados ainda está prematura.

Pertinência

Este dado muda a resposta, a recomendação ou a ação da IA?

Se o dado apenas parece interessante, mas não altera a decisão da funcionalidade, ele fica fora da primeira versão.

Momento de uso

O dado estará disponível quando a IA precisar responder?

Se o acesso depende de exportação manual, conciliação posterior ou intervenção fora do fluxo, ele não deve ser tratado como contexto operacional.

Permissão

O usuário, a funcionalidade e o modelo podem acessar esse dado naquele contexto?

Se a permissão não estiver clara por perfil, conta ou finalidade, o dado deve ser bloqueado até revisão.

Atualização

A frequência de atualização é compatível com a decisão que a IA vai apoiar?

Se um dado vencido puder gerar uma recomendação inadequada, a funcionalidade precisa de alerta, alternativa ou exclusão desse dado.

Confiabilidade

Existe um critério para saber quando o dado está ausente, divergente ou insuficiente?

Se a IA não conseguir reconhecer ausência ou baixa confiança, o produto deve limitar a resposta ou encaminhar para fluxo humano.

Risco de excesso

Adicionar este dado aumenta ruído, custo, latência ou exposição sem ganho claro?

Se o ganho não for demonstrável em teste, o dado não entra no contexto inicial.

Decida o que fica fora da funcionalidade

Preparar dados para uma funcionalidade inteligente é também decidir o que não entra.

Dados sem atualização confiável, sem permissão clara, sem relação direta com a tarefa ou com alto risco de exposição devem ficar fora da primeira versão. Isso não é conservadorismo tecnológico. É desenho de produto. Uma funcionalidade inteligente não melhora porque recebeu mais informação. Ela melhora quando recebe o contexto certo para apoiar uma tarefa real, com limites que o produto consegue explicar e operar.

A liderança deve aprovar uma matriz simples de pertinência e acesso: quais dados a funcionalidade precisa, por que eles influenciam a resposta, quem pode usá-los, com que atualização, em qual momento do fluxo e com qual limite de confiabilidade.

A matriz deve terminar com uma exclusão deliberada: qual dado, se estiver errado ou ausente, torna a funcionalidade pior do que o fluxo atual?

Enquanto essa resposta não existir, a primeira versão deve ser menor, mais verificável e mais fácil de operar.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.