A maioria das equipas não fica bloqueada na governação de agentes porque falta mais um approval gate. Fica bloqueada porque os sistemas por baixo dos controlos não conseguem explicar de forma fiável o que o agente sabia, o que alterou e se o resultado realmente melhorou o trabalho.

Esse é o verdadeiro implementation gap.

Este é o terceiro artigo da série de dez partes AI Governance in an AI-Native Software Development Company. O artigo anterior apresentou cinco camadas: Identity, Action, Output, Change e Outcome. As organizações normalmente avançam mais depressa nas duas primeiras porque identidade e permissões encaixam em controlos já conhecidos de security e platform engineering.

A dificuldade começa depois.

As camadas 3, 4 e 5 dependem de infraestrutura que muitas empresas ainda não possuem: conhecimento estruturado, decision traces duráveis, pipelines que versionam comportamento e medição de outcomes que resista a escrutínio técnico.

Na prática, três sistemas escondidos tornam essas camadas possíveis:

  1. um Knowledge System
  2. um Execution System
  3. um Evaluation System

Sem eles, a governação continua visível à entrada do sistema enquanto o comportamento importante permanece difícil de compreender.

A camada que falta entre governação e realidade

Identity control responde a quem está a agir.

Action control responde ao que o agente pode fazer.

São controlos necessários, mas não suficientes para criar confiança em escala.

Quando um agente passa a produzir planos, alterar código, modificar infraestrutura, emitir recomendações sensíveis a policy ou atuar diretamente em produção, a organização precisa de responder a perguntas mais difíceis:

  • em que knowledge se baseou?
  • qual versão era autoritativa?
  • que caminho de decisão produziu o output?
  • que versões de prompt, modelo, tools e policy estavam ativas?
  • como o output se tornou uma alteração em produção?
  • o que aconteceu depois do deploy?
  • a capability melhorou outcomes ou apenas aumentou atividade?

Se essas respostas exigem reconstrução manual a partir de chats, dashboards e memória humana, a governação continua a ser sobretudo processo.

Governação sem infraestrutura transforma-se em teatro.

Sistema 1: Knowledge Layer

A governação de Output começa antes de o agente produzir qualquer output. Começa pela qualidade do conhecimento que o agente pode consumir.

Muitas organizações ainda mantêm conhecimento operacional crítico em formatos bons para humanos mas fracos para machine governance: páginas wiki antigas, tickets, decisões em Slack, screenshots, runbooks copiados e documentos de policy sem metadados claros de autoridade ou lifecycle.

Um humano às vezes consegue resolver contradições através de contexto. Um agente não deve fazê-lo sem estrutura explícita.

Um governed knowledge object precisa de mais do que texto.

O sistema deve saber pelo menos:

  • quem é o owner
  • qual é a canonical source
  • a que scope se aplica
  • quando foi revisto
  • quando precisa de revalidation
  • qual é o authority tier
  • de onde veio a claim
  • se existem conflitos
  • como o runtime pode utilizar o conteúdo

Isto também muda a função da retrieval layer.

Retrieval para agentes governados não deve devolver apenas texto semanticamente semelhante. Deve devolver evidência com provenance, authority e lifecycle context.

Dividir documentos em claims governadas

Um documento longo não é uma boa unidade de controlo. Policies, procedimentos, constraints e factos devem tornar-se objetos estáveis, citáveis e versionáveis.

Registar canonical sources

Uma fonte não deve tornar-se autoritativa apenas porque apareceu primeiro numa pesquisa vetorial. É preciso distinguir systems of record de drafts e notas informais.

Detetar conflitos antes da geração

Se duas fontes discordam sobre uma regra de deployment, o agente não deve inventar um compromisso. O Knowledge System deve expor o conflito e aplicar uma authority rule ou escalation.

Preservar provenance

Cada claim importante deve ser rastreável até source, owner e version.

Se todo o conhecimento é prose, a governação também é prose.

Sistema 2: Execution Layer

Depois de estruturar o conhecimento, a governação tem de acompanhar o agente durante a execução.

Dois registos diferentes são importantes.

A decision trace explica como o agente chegou a uma conclusão material.

A change timeline explica como essa conclusão se tornou uma alteração real.

Uma decision trace útil deve capturar pelo menos:

  • root trace ID
  • parent trace ID
  • decision trace ID
  • agent ou capability ID
  • capability version
  • prompt version
  • model version
  • tool versions e schemas
  • knowledge objects e citations usados
  • policy version ativa
  • inputs importantes
  • uncertainty ou confidence signal
  • structured outcome
  • timestamps e actor identity

Isto cria a evidência necessária para Output.

Para Change é necessário manter uma linha durável do request até produção:

request -> plan -> PR -> CI -> deploy -> runtime -> rollback

Um correlation ID deve sobreviver a todo o percurso.

Work tracking, code review, testes, deployment, observability, incidents e rollback devem poder ser ligados pelo mesmo identificador.

O mesmo princípio aplica-se a alterações de comportamento que não são commits de código:

  • prompt updates
  • mudanças de modelo
  • tool-schema changes
  • routing
  • retrieval configuration
  • knowledge-index refresh
  • policy objects
  • skill ou instruction changes

Se o código passa por um promotion path governado mas prompts e tools podem ser alterados diretamente em produção, a organização possui dois sistemas de change control.

Se o comportamento muda fora do pipeline, a governação está quebrada.

Um Execution System maduro trata qualquer artefacto que altere o comportamento como production artifact: versionado, promovido, observado e reversível.

Sistema 3: Evaluation Layer

O terceiro sistema determina quando a autonomia pode aumentar de forma justificável.

A pergunta "o agente ajudou?" parece simples, mas os proxies habituais são fracos.

Usage não chega.

Token volume não chega.

Número de PRs não chega.

Algumas histórias positivas também não chegam.

A avaliação deve existir ao nível da capability e da versão.

Métricas úteis incluem:

  • accept rate
  • rework rate
  • refusal rate
  • escalation rate
  • rollback involvement
  • bounded-autonomy respect rate
  • cost per completed task
  • time-to-done delta
  • evidence completeness

Para decidir expansão de autonomia é também necessário behavioral benchmarking.

Um single-prompt test é demasiado fraco para muitos agent workloads porque o comportamento real decorre ao longo de vários steps, tools, permissions e context shifts.

Os cenários devem parecer trabalho real:

  • modificar um service sob policy constraints
  • resolver conflicting knowledge
  • recusar pedidos fora do autonomy boundary
  • escalar em caso de ambiguidade
  • recuperar de tool failure
  • manter-se dentro de budget e scope
  • terminar a tarefa com trace completeness

Sinais determinísticos e LLM-as-a-judge são ambos úteis.

Checks determinísticos funcionam melhor para policy violations, tool-use correctness, trace completeness, rollback e boundary breaches.

LLM judges podem avaliar explanation quality, completeness, citation adequacy e tradeoff reasoning sob um rubric.

É preciso usar os dois.

Também é preciso medir drift.

O comportamento pode mudar sem alteração no application code:

  • upstream model muda
  • prompt é revisto
  • retrieval corpus muda
  • tool recebe mais authority
  • task distribution altera-se
  • policy object muda

Por isso a avaliação deve estar ligada a capability versions e behavior-affecting releases.

Sem esta camada, o scaling de autonomia torna-se político.

Sem evaluation, autonomia transforma-se numa negociação, não numa decisão.

Juntar o verdadeiro Governance Stack

Os três sistemas reforçam-se.

O Knowledge System publica conhecimento canonical, validado e machine-usable com ownership, provenance e authority.

O Execution System consome esse conhecimento, emite decision traces, versiona artefactos de comportamento e preserva uma linha contínua do request ao rollback.

O Evaluation System consome traces e outcomes, compara versões, deteta regressões e transforma evidência em decisões de autonomia.

A dependência é simples:

Knowledge permite Output. Execution permite Change. Evaluation permite Outcome.

Na prática:

  1. governed knowledge objects entram no runtime
  2. o runtime emite structured decision traces
  3. o pipeline versiona e promove todos os behavior-affecting artifacts
  4. observability e incident systems ligam-se pelos mesmos correlation IDs
  5. evaluation classifica capability versions
  6. decisões de governação alimentam a versão seguinte

Esse loop é o operating system da governação real de agentes.

Não o comité.

Não o slide deck.

Não o approval template.

Ordem prática de construção

Não comece por uma plataforma de governação completa.

Construa o minimum viable substrate numa ordem em que cada etapa cria evidência para a seguinte.

1. Structured knowledge, minimum viable

Comece pelas policies e documentos operacionais realmente usados pelos agentes. Adicione ownership, provenance, freshness, lifecycle state e um pequeno schema machine-readable.

2. Decision trace schema

Defina o minimum event contract para decisões materiais: trace IDs, capability versions, knowledge references, inputs, outputs e uncertainty.

3. End-to-end correlation

Propague um correlation ID através de request, plan, PR, CI, deploy, incident e rollback.

4. Behavior versioning no pipeline

Leve prompts, modelos, tools, routing rules, retrieval artifacts e policy objects para o mesmo promotion model utilizado pelo código. Sem silent swaps e sem alterações in-place em produção.

5. Outcome metrics mais benchmarking

Comece com poucas métricas capability-level e uma pequena suite multi-step. Use os resultados para decidir se a autonomia aumenta, diminui ou permanece igual.

Não comece pelos dashboards. Comece pela evidência.

Conclusão

A governação de agentes não amadurece através da adição contínua de controlos à volta do sistema.

Amadurece quando o comportamento se torna legível, rastreável e mensurável.

Uma equipa que para em identity, permissions e approval gates normalmente não está a um único controlo da maturidade. Falta-lhe a infraestrutura que torna operacionais as camadas mais profundas.

Por isso, não pergunte apenas:

"Que controlo nos falta?"

Pergunte também:

  • os agentes consomem conhecimento em que podemos realmente confiar?
  • conseguimos explicar como uma decisão se tornou uma alteração em produção?
  • conseguimos provar que uma capability melhorou outcomes?
  • essas respostas estão ligadas por evidência durável?

Se não, o problema de governação não é teórico.

É arquitetural.

O próximo artigo entra na fronteira seguinte: uma policy pode existir em papel e falhar completamente se nunca chegar ao runtime.

Próxima parte: The Executable Policy Layer: Why Governance Dies Before Runtime.

Publicado originalmente por Reza Arani no Medium em 6 de maio de 2026. Adaptado para Aipolix como terceira parte da série AI Governance in an AI-Native Software Development Company.