Depois de entender o papel da IA (art. 3), a pergunta prática é: de onde vem o conhecimento?

Conhecimento como código

Repositórios Git já carregam runbooks, ADRs, procedimentos e histórico revisável. Knowledge Operations trata esse Git como fonte editorial: merge request, trilha auditável, indexação após aprovação, não scrape noturno de branch instável. O mesmo rigor que você exige de código em produção: quem aprova, o que entra no canônico, quando reindexar.

A UCloud mantém base institucional em Git (ucloud-kb) indexada pelo serviço de contexto do UCloud One. Frontmatter com owner, classificação, vigência; MR para alteração; agentes não escrevem direto no canônico. É padrão replicável para o domínio de cada cliente, operação, produto ou compliance com seu próprio repositório editorial.

Vantagem operacional: diff mostra o que mudou; rollback de documentação errada é possível; auditoria pergunta “quem aprovou MR #412?” e há resposta.

Fontes distintas

Nem tudo vive em markdown. Knowledge Operations registra e conecta fontes com política única de busca:

  • Git, paths docs-as-code, ADR, runbooks.
  • Wikis existentes, sincronização ou export com opt-in, não espelho cego.
  • Tickets, histórico com retenção, anonimização e exclusão de PII onde necessário.
  • Object storage, PDFs, anexos de auditoria, com classificação antes de indexar.
Integrar Git, wikis, tickets e storage com política única de busca, sem big bang documental.
O objetivo não é centralizar tudo numa UI. É unificar a busca com política única.

Engenheiros continuam no Git; operação continua no ticket; gestores continuam no wiki. Quem precisa de resposta obtém contexto filtrado e rastreável.

Anti-padrão: big bang documental

Projetos “migrar tudo para Confluence/X” falham por fadiga de curadoria, conteúdo morto on arrival e desalinhamento com o fluxo de engenharia. Knowledge Operations prioriza incremento com critério:

  1. Listar top 10 procedimentos que mais geram escalonamento ou incidente recorrente.
  2. Deduplicar e promover um canônico por tema, com dono e data de revisão.
  3. Indexar e medir uso em busca real (IDE, plantão, onboarding).
  4. Expandir perímetro só onde há evidência de valor, não onde há volume de arquivo.

Engenheiros continuam no Git; operação continua no ticket; gestores continuam no wiki. O objetivo não é centralizar tudo numa UI, é unificar a busca com política única: mesma pergunta, mesma resposta canônica, independente de onde a pessoa trabalha.

Próximo na série

Artigo 5: Governança na operação de conhecimento. Quem acessa, quem aprova e o que fica registrado.