Pular para conteúdo

Capítulo 4.12 — Catálogo e governança de fontes de conhecimento

🎯 Objetivo

Consolidar, em um único lugar, uma responsabilidade que aparece espalhada pelo resto do livro: saber quais fontes de conhecimento existem, de quem são, de onde vêm, quão atuais são e quem pode usá-las. RAG, GraphRAG, memória semântica e fine-tuning todos consomem "conhecimento corporativo" - mas raramente alguém mantém o inventário governado dessas fontes. Este capítulo trata desse inventário.

🧭 Nota sobre o nome. "Registro" / "catálogo" de fontes de conhecimento é vocabulário estabelecido de data governance (catálogo de dados, registro de fontes) - não é nome de produto. Por isso é usado aqui. Nomes como "Memory Bank", "Engine Orchestration" ou "Evaluation Center", às vezes propostos para organizar capacidades de uma plataforma de IA, não são adotados neste livro: soam a módulo comercial e os conceitos por trás deles já têm nomes melhores e mais precisos (respectivamente memória persistente - Cap. 3.6, harness/runtime - Cap. 3.3-3.4, e eval harness - Cap. 2.11, 5.4). O conceito de catálogo de fontes, por outro lado, não estava consolidado no livro - daí este capítulo.

🧠 Conceito principal

Um catálogo de fontes de conhecimento é o metadado sobre as fontes, distinto do índice vetorial ou do grafo em si. Para cada fonte (uma coleção de documentos, um banco, um grafo, um feed externo), ele registra:

Atributo Por que importa
Identidade e descrição Saber o que é a fonte e o que ela cobre
Owner Quem responde por correção, atualização e acesso
Origem / lineage De onde o dado veio e por quais transformações passou
Classificação de sensibilidade Público, interno, confidencial, restrito
Política de acesso Quais roles/tenants podem recuperar dela
Jurisdição / residência Onde o dado pode ser processado e armazenado
Cadência de atualização e freshness Quão atual é; idade mediana e p95 dos itens
Versão Versão do conteúdo, do pipeline e do modelo de embedding usado
Status de ciclo de vida Ativa, em deprecação, em quarentena, removida
Rastreabilidade Ligar uma resposta de RAG de volta à fonte e à versão exata

A tese é a mesma do resto da Parte 4: o que não está catalogado não é governável. Sem catálogo, ninguém responde "de qual fonte, em qual versão, veio esta resposta?" - e isso é exatamente a pergunta que aparece em auditoria e em incidente.

🏗️ Como isso aparece em produção

O conceito já foi tocado em vários pontos; o catálogo é o que os conecta:

  • Ingestão de RAG (Cap. 2.6) produz lineage e classificação de sensibilidade por documento - o catálogo agrega isso por fonte.
  • Knowledge graphs (Cap. 2.9) precisam de owner de ontologia e de versão do esquema - entram no catálogo.
  • Qualidade de dados (Cap. 1.2) define contratos por dataset - o catálogo referencia esses contratos.
  • Supply chain (Cap. 4.9) trata datasets e modelos como artefatos com proveniência - o catálogo de fontes é a face "conhecimento" disso.
  • Governança e audit (Cap. 4.11) exige inventário - o catálogo de fontes é parte desse inventário, ao lado do inventário de modelos e agentes.

🚨 Modos de falha

  • Fonte "fantasma". Um índice RAG aponta para um drive que ninguém mantém; o conteúdo envelhece e ninguém percebe.
  • Sem owner. Documento errado é recuperado e citado; não há a quem escalar a correção.
  • Mistura de jurisdições. Conteúdo de uma região entra num índice servido para outra, sem registro de residência.
  • Reembedding cego. Troca-se o modelo de embedding sem saber quais fontes/índices dependem dele.
  • Fonte contaminada sem quarentena. Documento malicioso (vector poisoning, Cap. 4.5) não tem caminho rápido de retirada porque a fonte não está catalogada.

🛡️ Controles e práticas

  • Catálogo versionado (pode ser um arquivo declarativo, uma tabela governada ou um data catalog existente - o ponto é existir e ter owner).
  • Toda fonte tem owner nomeado (técnico e de negócio).
  • Classificação obrigatória na entrada de uma nova fonte; fonte sem classificação não entra em produção.
  • Política de acesso por fonte referenciada pela policy-as-code (Cap. 4.7) e aplicada no storage/retriever (Cap. 2.7).
  • Freshness e indexing lag monitorados por fonte, com SLA (Cap. 5.5).
  • Ciclo de vida explícito: aprovação para adicionar fonte, quarentena para suspeita, deprecação com janela (Cap. 7.4).
  • Rastreabilidade ponta a ponta: a resposta cita a fonte; a fonte aparece no catálogo; o catálogo liga à versão e ao owner.

📌 Checklist

  • [ ] Existe um inventário de fontes de conhecimento com owner por fonte?
  • [ ] Cada fonte tem classificação de sensibilidade e jurisdição registradas?
  • [ ] A política de acesso por fonte é aplicada no storage/retriever, não só no prompt?
  • [ ] Freshness e indexing lag são monitorados por fonte?
  • [ ] Há processo de aprovação, quarentena e deprecação de fontes?
  • [ ] É possível ligar uma resposta de RAG de volta à fonte e à versão exata?

📚 Referências