A maioria das equipas não fica bloqueada na governação de agentes porque falta mais um portão de aprovação. 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 Governação da IA numa empresa de desenvolvimento de software nativa de IA. O artigo anterior apresentou cinco camadas: Identidade, Action, Saída, Change e Resultado. 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 resultados que resista a escrutínio técnico.
Na prática, três sistemas escondidos tornam essas camadas possíveis:
- um Knowledge System
- um Execution System
- 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
Identidade 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 política 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 saída?
- que versões de instrução, modelo, ferramentas e política estavam ativas?
- como o saída se tornou uma alteração em produção?
- o que aconteceu depois do colocação em produção?
- a capacidade melhorou resultados ou apenas aumentou atividade?
Se estas perguntas exigirem uma reconstrução manual a partir de conversas, painéis e memória humana, a governação continua a ser sobretudo um processo administrativo.
Se essas respostas exigem reconstrução manual a partir de chats, painéis e memória humana, a governação continua a ser sobretudo processo.
Governação sem infraestrutura transforma-se em teatro.
Sistema 1: camada de conhecimento
A governação de Saída começa antes de o agente produzir qualquer saída. 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 governação: páginas wiki antigas, tickets, decisões em Slack, screenshots, runbooks copiados e documentos de política 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 responsável
- qual é a canonical source
- a que âmbito se aplica
- quando foi revisto
- quando precisa de revalidation
- qual é o authority tier
- de onde veio a claim
- se existem conflitos
- como o tempo de execução 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 contexto.
Dividir documentos em claims governadas
Um documento longo não é uma boa unidade de controlo. Políticas, 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 implantação, 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, responsável e version.
O princípio é simples:
Se todo o conhecimento é prose, a governação também é prose.
A camada 3, dedicada aos resultados, não pode ser fiável se a infraestrutura que a sustenta for ambígua, desatualizada ou não auditada.
Sistema 2: camada de execução
Depois de o conhecimento estar estruturado, a governação tem de acompanhar o agente durante a execução.
Depois de estruturar o conhecimento, a governação tem de acompanhar o agente durante a execução.
Dois registos diferentes são importantes.
A rasto de decisão 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 rasto de decisão útil deve capturar pelo menos:
- root trace ID
- parent trace ID
- rasto de decisão ID
- agent ou capacidade ID
- capacidade version
- instrução version
- model version
- ferramenta versions e schemas
- knowledge objects e citations usados
- versão das regras ativa
- entradas importantes
- uncertainty ou confidence signal
- structured resultado
- timestamps e actor identidade
Isto cria a evidência necessária para Saída.
Para Change é necessário manter uma linha durável do pedido até produção:
pedido -> plan -> PR -> CI -> colocação em produção -> tempo de execução -> reversão
Um identificador de correlação deve sobreviver a todo o percurso.
Work tracking, code revisão, testes, implantação, observability, incidents e reversão 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:
Num sistema baseado em agentes, todos os elementos seguintes podem alterar o comportamento em produção:
- instrução updates
- mudanças de modelo
- ferramenta-schema changes
- encaminhamento
- retrieval configuration
- knowledge-index refresh
- regras estruturadas
- capacidade especializada ou instruction changes
Se o código passa por um promotion path governado mas instruções e ferramentas podem ser alterados diretamente em produção, a organização possui dois sistemas de change control.
Esta é uma falha estrutural de governação.
Se o comportamento muda fora do canal de entrega, a governação está quebrada.
Um sistema de execução maduro trata todos os artefactos que podem alterar o comportamento como artefactos de produção versionados. Estes passam por etapas de promoção controladas, incluem dados sobre o impacto, emitem métricas e dispõem de mecanismos de reversão.
Um Execution System maduro trata qualquer artefacto que altere o comportamento como production artefacto: versionado, promovido, observado e reversível.
Sistema 3: camada de avaliação
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 capacidade e da versão.
Métricas úteis incluem:
- accept rate
- rework rate
- refusal rate
- escalation rate
- reversão involvement
- respeito pelos limites de autonomia respect rate
- cost per completed task
- tempo até à conclusão delta
- evidência completeness
Para decidir expansão de autonomia é também necessário behavioral benchmarking.
Um single-instrução test é demasiado fraco para muitos agent cargas de trabalho porque o comportamento real decorre ao longo de vários steps, ferramentas, permissões e contexto shifts.
Os cenários devem parecer trabalho real:
- modificar um service sob política constraints
- resolver conflicting knowledge
- recusar pedidos fora do autonomy limite
- escalar em caso de ambiguidade
- recuperar de ferramenta failure
- manter-se dentro de budget e âmbito
- terminar a tarefa com trace completeness
Sinais determinísticos e Avaliação por um LLM são ambos úteis.
Checks determinísticos funcionam melhor para política violations, utilização de ferramentas correctness, trace completeness, reversão e limite 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:
- a montante model muda
- instrução é revisto
- retrieval corpus muda
- ferramenta recebe mais authority
- task distribution altera-se
- regra estruturada muda
Por isso a avaliação deve estar ligada a capacidade versions e que altera o comportamento releases.
Sem esta camada, o scaling de autonomia torna-se político.
A equipa com a demonstração mais convincente recebe mais autoridade. O fornecedor com o plano de evolução mais ambicioso ganha a discussão. Uma ferramenta popular mantém-se mesmo quando os resultados por versão mostram mais retrabalho ou reversões.
Sem evaluation, autonomia transforma-se numa negociação, não numa decisão.
Juntar o verdadeiro pilha de governação
Os três sistemas reforçam-se mutuamente.
Os três sistemas reforçam-se.
O Knowledge System publica conhecimento canonical, validado e utilizável por máquinas 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 pedido ao reversão.
O Evaluation System consome traces e resultados, compara versões, deteta regressões e transforma evidência em decisões de autonomia.
A dependência é simples:
Knowledge permite Saída. Execution permite Change. Evaluation permite Resultado.
Na prática:
- governed knowledge objects entram no tempo de execução
- o tempo de execução emite structured decision traces
- o canal de entrega versiona e promove todos os que altera o comportamento artefactos
- observability e incident systems ligam-se pelos mesmos correlation IDs
- evaluation classifica capacidade versions
- 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 aprovação 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 políticas e documentos operacionais realmente usados pelos agentes. Adicione ownership, provenance, freshness, lifecycle state e um pequeno schema legível por máquinas.
2. Rasto de decisão schema
Defina o minimum event contract para decisões materiais: trace IDs, capacidade versions, knowledge references, entradas, resultados e uncertainty.
3. De ponta a ponta correlation
Propague um identificador de correlação através de pedido, plan, PR, CI, colocação em produção, incident e reversão.
4. Comportamento versioning no canal de entrega
Leve instruções, modelos, ferramentas, encaminhamento rules, retrieval artefactos e regras estruturadas para o mesmo promotion model utilizado pelo código. Sem silent swaps e sem alterações diretamente em produção.
5. Resultado metrics mais benchmarking
Comece com poucas métricas capacidade-level e uma pequena suite em várias etapas. Use os resultados para decidir se a autonomia aumenta, diminui ou permanece igual.
A ordem é importante, porque cada sistema fornece as evidências de que o seguinte necessita.
Não comece pelos painéis. 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.
Isso exige sistemas reais.
Uma equipa que para em identidade, permissões e portões de aprovação 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 capacidade melhorou resultados?
- essas respostas estão ligadas por evidência durável?
Se assim não for, o problema de governação é arquitetural.
O próximo artigo entra na fronteira seguinte: uma política pode existir em papel e falhar completamente se nunca chegar ao tempo de execução.
Próxima parte: A camada de regras executáveis: Why Governação Dies Before Tempo de execução.
Publicado originalmente por Reza Arani no Medium em 6 de maio de 2026. Adaptado para Aipolix como terceira parte da série Governação da IA numa empresa de desenvolvimento de software nativa de IA.
Comentários
Ainda não há comentários. Seja o primeiro a comentar.
Deixe um comentário