Governança na operação de conhecimento

Integração de fontes (art. 4) só escala com regras claras. Governança é o que separa Knowledge Operations de “mais um índice de documentos”.

Políticas de acesso

Conhecimento operacional raramente é universal. Desenvolvedor, SRE, gestor, auditor e parceiro externo precisam visões diferentes, às vezes do mesmo incidente, com campos distintos visíveis. Knowledge Operations aplica filtros por papel, projeto, classificação e cliente antes da busca semântica ranquear resultados.

Implementação madura separa três camadas: autenticação (quem é), autorização (o que pode ver), auditoria (o que consultou). Busca para agente segue a mesma política do humano: agente não é bypass de segregação. Em operações multi-cliente, índice isolado por cliente é requisito, não otimização.

Caso típico: plantonista em produção pergunta ao copiloto como reiniciar um serviço de mensageria. O assistente retorna runbook de homologação, indexado sem flag de obsolescência e sem filtro de ambiente. O comando “parece” correto, mas causa perda de fila. O risco não é alucinação fantasiosa: é ação errada com confiança. Em governo ou multi-tenant, o custo inclui auditoria e responsabilização, não só downtime.

A matriz abaixo é simplificada, mas ilustra o tipo de decisão que precisa estar explícito antes de indexar para IA:

Papel	O que pode ver	O que não deve ver
Desenvolvedor	Runbooks do sistema, ADRs do squad, histórico de deploy	Dados de outro cliente, credenciais de produção sem escopo
SRE / plantão	Procedimentos de incidente, mapa de dependências, playbooks vigentes	Conteúdo classificado de auditoria ou contrato de terceiro
Gestor	Status, SLA, decisões registradas, relatórios agregados	Detalhe técnico com segredo operacional ou PII
Auditor	Trilha de acesso, versões aprovadas, log de promoção	Rascunhos não aprovados, índices de outros tenants
Parceiro externo	Escopo contratual do projeto, documentação compartilhada	Conhecimento interno fora do boundary acordado

Curadoria humana

Agentes de IA podem propor atualizações, resumos ou candidatos a runbook. Nunca promovem conhecimento canônico sem revisão. Fluxo típico: proposta (humano ou agente) → revisão por curador de domínio → approval gate → merge/indexação → notificação de vigência.

Rejeição também é governança: proposta recusada volta para rascunho, não some no índice nem vira “quase canônico”. O curador documenta motivo (obsoleto, escopo errado, falta evidência). Sem esse retorno, equipes perdem confiança no gate e voltam a publicar direto no wiki.

Humanos decidem. Agentes preparam. Essa sequência é inegociável na UCloud, e deveria ser em qualquer ambiente onde erro operacional tem custo real.

Na prática UCloud

Na UCloud, a base institucional vive em Git (ucloud-kb), indexada pelo serviço de contexto do UCloud One. Frontmatter com owner, classificação e vigência; alteração via merge request; agentes não escrevem direto no canônico. O mesmo padrão se replica no domínio de cada cliente: operação, produto ou compliance com repositório editorial próprio.

Em atendimento gerenciado, cada interação relevante gera laudo com numeração institucional (UC# no interno, LEKTO# onde o contrato exige). Promoção de runbook ou procedimento passa por workflow com aprovador nomeado. O objetivo não é burocracia: é responder, em due diligence, quem aprovou, quando e o que mudou.

Em operações multi-cliente, segregação por tenant é regra de arquitetura: índice, política e trilha separados. Copiloto em sessão de um cliente não recupera contexto de outro, mesmo que o embedding “pareça” similar.

Rastreabilidade

Cada promoção editorial deveria gerar evento auditável, não só arquivo novo no repositório. Exemplo de registro mínimo:

• Quem propôs: autor humano ou agente (com sessão identificada).
• Quem aprovou: curador de domínio ou gate institucional.
• O que mudou: diff ou referência ao MR/workflow.
• Quando entrou em vigência: data e escopo (sistema, cliente, ambiente).
• Quem consultou depois: log de busca ou recuperação em incidente.

Em procurement institucional ou due diligence, isso responde pergunta concreta: “como vocês controlam o que a IA e a operação sabem, e quem alterou o quê?”. Sem trilha, a resposta vira “temos política”, insuficiente para fintech, saúde, governo ou contrato com cláusula de subcontratação de IA.

Onde governança pesa na decisão

• Setor público. Compliance, transparência, LGPD e auditoria contínua. Busca e promoção precisam ser demonstráveis, não só descritas em norma interna.
• Fintech e saúde. Dados sensíveis, segregação forte, log de acesso a conteúdo classificado, inclusive em sessão de copiloto.
• Operações multi-cliente. Isolamento por cliente, proibição de cruzar contexto entre tenants, mapa de fontes e responsáveis por boundary.

Mesmo em verticais menos reguladas, governança leve (dono por domínio, fluxo de aprovação documentado, log de promoção) acelera onboarding, reduz incidente por runbook errado e prepara adoção de IA sem susto na primeira auditoria externa.