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. KO 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 heterogêneas

Nem tudo vive em markdown. KO registra e conecta fontes com política única de retrieve:

  • 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 retrieve, sem big bang documental.
O objetivo não é centralizar tudo numa UI. É unificar retrieve 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. KO 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 retrieve 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 retrieve 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.