Como estruturar conhecimento de domínio para IA

Conhecimento de domínio para inteligência artificial não é apenas conteúdo guardado em algum lugar. É a parte do produto que diz à IA o que uma informação significa, de onde ela veio, quando deixa de valer e quem responde por sua manutenção. Antes de conectar documentos, tickets ou bases internas a uma funcionalidade inteligente, a liderança precisa decidir quais informações podem orientar respostas, recomendações ou ações, quais devem ser bloqueadas e como serão revisadas.

Onde o conhecimento de domínio entra na experiência do produto

Uma funcionalidade com inteligência artificial pode usar muitos tipos de informação. Nem todos são conhecimento de domínio.

Dados transacionais mostram o que aconteceu: pedidos, acessos, status, movimentações, eventos, pagamentos, entregas. Preferências do usuário indicam escolhas individuais. Regras de interface definem o que aparece, quando aparece e como a pessoa interage. Conhecimento de domínio é outra coisa: é o conjunto de definições, critérios, exceções, políticas operacionais e interpretações que dão sentido às informações dentro daquele produto.

Em um produto SaaS de logística, por exemplo, “pedido atrasado” pode parecer uma expressão simples. Mas o domínio define se atraso começa depois do horário prometido ao consumidor, depois da janela acordada com a transportadora, depois da tentativa de coleta ou depois do prazo interno de expedição. Se a IA responde a um usuário sem saber qual dessas definições vale, ela pode soar confiante e ainda assim orientar mal.

Por isso, o primeiro recorte não é técnico. É de produto.

A pergunta é: em quais momentos a IA precisa interpretar o negócio para ajudar alguém? Pode ser ao responder uma dúvida, classificar um caso, sugerir uma próxima ação, explicar uma regra ou bloquear uma execução insegura. Esse recorte evita tratar todo conteúdo interno como insumo válido.

Esse ponto se conecta ao guia pilar sobre inteligência no produto: a inteligência só melhora a experiência quando entra em uma decisão específica do fluxo, não quando vira uma camada genérica sobre tudo.

Conhecimento de domínio para IA precisa separar significado, origem e manutenção

A organização costuma misturar três perguntas que deveriam ficar separadas.

A primeira é significado: o que essa informação quer dizer no domínio do produto? Uma sigla, uma regra ou um status precisa ter definição compreensível para produto, engenharia, suporte e operação. Se cada área usa a mesma palavra para coisas diferentes, a IA herdará essa ambiguidade.

A segunda é origem da informação: de onde ela veio e por que deve ser considerada confiável? A fonte pode ser uma documentação oficial, uma política operacional, uma taxonomia interna, uma base de ajuda, um registro de atendimento ou a orientação de um especialista. Cada uma tem valor, mas não o mesmo peso.

A terceira é manutenção de conhecimento: quem revisa, quando revisa e o que acontece quando a informação perde validade? Uma regra que estava correta no passado pode ser arriscada hoje. Para IA, conteúdo abandonado não é neutro. Ele continua podendo aparecer como resposta, recomendação ou justificativa.

A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência. Esse conjunto inclui instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada (Anthropic). Essa definição ajuda a tirar o debate do “vamos jogar documentos no modelo” e levar para uma pergunta mais operacional: qual contexto deve estar disponível para qual cenário de uso?

O ponto é definir o que entra, com qual autoridade e por quanto tempo.

Quais fontes merecem entrar no repertório da IA

Nem toda fonte interna deve orientar uma funcionalidade inteligente. Algumas são úteis para descobrir problemas. Outras são boas para entender linguagem do usuário. Poucas deveriam servir como autoridade para resposta ou ação.

Documentação oficial tende a ser uma boa fonte de definição, desde que esteja atualizada e tenha dono. Bases de ajuda ajudam a transformar linguagem técnica em linguagem compreensível, mas podem conter simplificações que não cobrem exceções. Tickets de atendimento revelam dúvidas reais, ambiguidades e casos recorrentes, mas não devem ser tratados automaticamente como regra correta. Conversas com especialistas capturam conhecimento operacional, mas precisam virar registro verificável. Políticas internas podem orientar decisões, desde que tenham versão, escopo e responsável.

Um critério simples ajuda: uma fonte só deve orientar a IA se for atual, verificável, interpretável e útil para a tarefa do produto.

• Atual significa que existe algum sinal de validade: versão, data, evento de mudança ou responsável ativo.
• Verificável significa que o time consegue apontar de onde a informação veio.
• Interpretável significa que a informação tem definição, exceções e contexto suficientes para não depender de leitura informal.
• Útil significa que ela resolve uma resposta, recomendação ou ação específica dentro do produto.

Com o conhecimento organizado, fica mais claro o que a arquitetura precisará recuperar e verificar. A discussão sobre arquitetura vem depois. Antes, a liderança precisa saber se o conhecimento que alimentará a IA merece ser usado. Para essa decisão mais ampla de priorização, vale conectar com como criar uma estratégia de inteligência artificial conectada ao negócio.

Como registrar contexto suficiente sem transformar tudo em prompt

Organizar conhecimento de domínio não significa copiar documentos inteiros para o prompt. Prompt, aqui, é a instrução enviada ao modelo para orientar uma resposta ou execução. Ele tem função, mas não deve carregar sozinho a governança do conhecimento.

O ponto de partida é mapear contexto por cenário de uso.

Para uma tarefa de responder dúvidas sobre status de entrega, o contexto necessário pode incluir definições de status, regras de atualização, exceções por tipo de operação, limites do que o produto sabe responder e sinais de que a informação está incompleta. Para uma tarefa de sugerir reclassificação de chamados, o contexto necessário pode incluir taxonomia, exemplos positivos, exemplos negativos, prioridades entre categorias e regra de bloqueio quando houver conflito.

A ideia é registrar unidades de conhecimento menores, com metadados operacionais. Metadados, neste caso, são informações sobre a própria informação: fonte, dono, versão, validade, escopo, exceções e condição de uso.

Isso importa porque modelos operam dentro de uma janela de contexto limitada, como descreve a Anthropic ao tratar engenharia de contexto (Anthropic). No desenho do produto, selecionar bem o contexto evita tratar informações de autoridade, escopo e validade diferentes como se tivessem o mesmo peso.

Um bom registro de conhecimento deveria responder:

• Qual conceito esta informação define?
• Para qual cenário de uso da IA ela pode ser aplicada?
• Em quais situações ela não deve ser usada?
• Qual fonte tem autoridade sobre ela?
• Quem responde por mudança, conflito ou retirada?
• Que sinal indica desatualização?
• O que a funcionalidade deve fazer quando faltar contexto?

Esse registro não precisa nascer como uma plataforma complexa. Pode começar como inventário disciplinado, desde que tenha dono e uso real no desenvolvimento.

Como definir donos e ciclos de revisão do conhecimento

A manutenção costuma falhar quando o conhecimento é tratado como documentação lateral. Alguém escreveu, alguém usa, ninguém sabe quem revisa.

Para IA no produto, isso é frágil. Se uma funcionalidade passa a responder ou recomendar com base em determinado conjunto de conhecimento, esse conjunto entrou na operação do produto. Logo, precisa de responsável.

O responsável não precisa ser uma pessoa isolada. Pode ser uma área, um papel ou um fórum de decisão. O ponto é evitar que o conhecimento fique sem autoridade quando houver conflito. Se a base de ajuda diz uma coisa, o especialista diz outra e o ticket histórico sugere uma terceira, qual fonte vence?

Um ciclo de revisão deveria prever quatro elementos:

• Responsável por aprovar mudanças.
• Frequência ou gatilho de revisão.
• Regra de retirada quando a informação estiver vencida, ambígua ou contestada.
• Procedimento para resolver conflitos entre fontes.

Gatilhos são especialmente úteis. Mudança de política operacional, alteração de nomenclatura, lançamento de novo fluxo, aumento de respostas bloqueadas ou recorrência de conflito entre fontes podem exigir revisão antes da próxima rodada programada.

A lógica é parecida com a disciplina de confiabilidade em engenharia. O Google SRE define objetivos de nível de serviço como metas de confiabilidade que orientam decisões de engenharia. A abordagem pressupõe acordo sobre metas, uso do orçamento de erro para priorização e um processo de revisão (Google SRE). A analogia aqui não é prometer precisão absoluta da IA. É tratar confiabilidade como acordo operacional, não como desejo.

Como medir confiabilidade sem prometer precisão absoluta

Organizar conhecimento reduz ambiguidade, mas não elimina erro. Essa distinção precisa ficar clara.

A funcionalidade pode usar fontes bem mantidas e ainda responder de forma insuficiente, recuperar um trecho pouco adequado ou encontrar uma situação nova. Por isso, a medição deve observar o comportamento operacional do conhecimento, não apenas a percepção geral de qualidade.

Alguns indicadores úteis são:

• Taxa de respostas com fonte adequada para a tarefa.
• Volume de respostas bloqueadas por conhecimento insuficiente.
• Incidência de conflito entre fontes.
• Tempo de atualização após mudança de regra.
• Frequência de uso de conteúdo vencido ou sem dono.
• Casos em que a IA pediu mais informação em vez de concluir sem base.

Esses indicadores não provam valor de negócio sozinhos. Eles mostram se o repertório usado pela IA está governável. A avaliação de impacto no produto exige hipótese, experimento e medida própria. 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). Isso não significa que feedback de usuário retreina automaticamente um modelo. Significa que mudanças de produto precisam ser testadas contra hipóteses explícitas.

Uma hipótese possível seria: se a funcionalidade bloquear respostas quando a regra estiver vencida ou conflitante, os usuários receberão menos orientações indevidas. Essa hipótese precisaria ser medida no contexto do produto. Não deve ser assumida como resultado.

Exemplo fictício: conhecimento de domínio em um SaaS de logística

Imagine um SaaS de logística que quer incluir uma funcionalidade de IA para responder dúvidas de usuários internos sobre regras de expedição e status de entrega. O exemplo é fictício e serve apenas para mostrar a aplicação dos critérios.

A equipe identifica uma pergunta recorrente: “por que este pedido aparece como aguardando coleta?”. Parece simples. Mas o status pode depender de horário de corte, integração com transportadora, confirmação do armazém, tentativa de coleta, feriado regional ou divergência entre sistemas.

Antes de conectar a IA, o time registra o conhecimento necessário.

Para o conceito “aguardando coleta”, a definição operacional diz: pedido liberado para transporte, com etiqueta emitida, ainda sem confirmação de coleta pela transportadora no sistema. A origem da definição é a documentação oficial do fluxo de expedição. A responsável é a área de produto do módulo de logística. A validade depende da versão atual do fluxo de expedição. A exceção documentada diz que pedidos em operação manual podem permanecer nesse status mesmo após separação física. A condição de bloqueio diz que a IA não deve afirmar motivo de atraso quando houver conflito entre confirmação do armazém e evento da transportadora.

Para a regra “horário de corte”, o registro inclui o escopo: aplica-se apenas a operações com coleta programada no mesmo dia. A fonte é a política operacional aprovada para aquele fluxo. O responsável é operações. O gatilho de revisão é mudança na política de coleta ou alteração no contrato operacional com transportadoras. Se a informação não tiver versão atual, a IA deve explicar que não há base suficiente para determinar o motivo e orientar a consulta ao responsável definido no produto.

Para tickets de atendimento, o time decide usá-los como fonte auxiliar de linguagem, não como autoridade de regra. Eles ajudam a identificar como usuários perguntam sobre o problema, mas não definem a resposta correta. Essa separação evita que padrões históricos de suporte virem verdade operacional.

O resultado esperado não deve ser presumido. A hipótese a testar poderia ser que respostas com fonte explícita e bloqueio em caso de conflito reduzem retrabalho do suporte. Para avaliar, seria necessário acompanhar casos de uso, qualidade das fontes recuperadas, bloqueios e correções feitas pelo time responsável.

Checklist para qualificar conhecimento de domínio antes de usar IA

Este checklist é uma forma prática de decidir se uma informação pode entrar no repertório da IA. Ele não valida a escolha do modelo, não substitui teste com usuários e não garante ausência de erro. Serve para qualificar conhecimento antes da implementação.

• Significado: a informação tem definição clara dentro do domínio do produto? Aceite apenas se produto, suporte ou engenharia conseguem explicar o mesmo conceito sem depender de interpretação informal.
• Cenário de uso: a informação serve para qual resposta, recomendação ou ação específica da IA? Aceite apenas se houver um uso definido e uma situação em que ela não deve ser usada.
• Origem: a fonte é identificável e verificável? Aceite apenas se o time conseguir apontar documento, sistema, política ou responsável.
• Autoridade: a fonte tem prioridade em caso de conflito? Aceite apenas se existir regra explícita para escolher entre documentação oficial, registros históricos, opinião de especialista e conteúdo de atendimento.
• Atualidade: a informação tem data, versão ou evento que indique validade? Aceite apenas se o time souber quando revisar e quando impedir o uso.
• Responsável: existe alguém responsável por manter esse conhecimento? Aceite apenas se houver papel ou área responsável por aprovar mudança, retirar conteúdo incorreto e resolver conflitos.
• Exceções: os casos de não aplicação estão documentados? Aceite apenas se a IA não precisar inferir sozinha quando a regra deixa de valer.
• Bloqueio: o produto sabe o que fazer quando o conhecimento é insuficiente, conflitante ou vencido? Aceite apenas se houver uma resposta segura prevista, como pedir mais informação, encaminhar para revisão humana ou não executar a ação.

Esse checklist também ajuda no roadmap de IA, porque transforma uma ideia promissora em dependências visíveis: fontes, responsáveis, revisão, risco e critério de bloqueio.

Sem significado definido, origem confiável, dono de manutenção e condição de retirada, o conhecimento não está pronto para orientar IA no produto. A funcionalidade pode até parecer inteligente, mas o produto não saberá explicar por que ela respondeu daquela forma nem quando deveria ter ficado em silêncio.

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

Leituras para continuar

• Quando usar regras, RAG ou agentes em um produto
• Como preparar dados para uma funcionalidade inteligente

Fontes

• Anthropic: Effective context engineering for AI agents
• Google SRE: Implementing SLOs
• Microsoft Research: Experimentation Platform