Porque as contas de serviço e as gates de aprovação já não são suficientes quando os agentes escrevem, revêm e colocam código em produção.

Artigo 2 de 10 — Governação de IA numa empresa de desenvolvimento de software AI-native

A frase mais cara na engenharia AI-native é normalmente dita com bastante confiança:

«Nós já temos governação.» 🫤

Na maioria das vezes, isso quer dizer três coisas:

• os agentes autenticam-se através de SSO ou de uma conta de serviço
• existem permissões nos repositórios
• um humano continua a aprovar alterações em produção

Isto não é governação. É controlo da porta de entrada.

Responde às primeiras perguntas e ignora as mais caras:

• Porque é que o agente tomou aquela decisão?
• Como é que essa decisão se transformou numa alteração em produção?
• Que outras coisas mudaram à volta dessa decisão?
• O agente melhorou realmente os resultados?
• No próximo trimestre este agente deve ter mais autonomia ou menos?

É aqui que está a lacuna.

No artigo anterior, «You Think You Have AI Governance. You Don’t.», argumentei que a governação de IA numa empresa de software não é a mesma conversa que AI Safety. É um problema de operações de engenharia. Este artigo transforma essa ideia num diagnóstico: o modelo de cinco camadas que utilizo para perceber se uma empresa tem realmente governação ou apenas alguns controlos visíveis e muita esperança.

A versão curta é direta: a maioria das equipas só tem as camadas 1 e 2, e mesmo essas de forma parcial. O resto é dívida de governação.

🧩 O modelo numa frase

A governação de agentes tem cinco camadas:

  1. Identidade: quem está a agir?
    2. Ação: o que é que o agente está autorizado a fazer?
    3. Output: o que decidiu e que evidência suporta essa decisão?
    4. Mudança: como é que esse output se tornou uma alteração em produção?
    5. Resultado: o agente ajudou, prejudicou ou sofreu drift?

Se faltar uma destas camadas, a sua stack de governação tem um ponto cego. Se faltarem as camadas 3 a 5, como acontece em muitas empresas, não existe uma stack de governação: existe controlo de acesso mais optimismo.

A ideia central, em linguagem simples:

As camadas 1 e 2 controlam o acesso. As camadas 3, 4 e 5 criam confiança à escala.

Acesso não é confiança. A confiança começa nas camadas 3, 4 e 5. Os controlos à entrada impedem os problemas óbvios. As três camadas seguintes permitem investigar, reverter e melhorar o trabalho que mesmo assim conseguiu passar.

🗂 As cinco camadas

1. Identidade
Pergunta central: Quem está a agir?
O que é bom: cada agente tem uma identidade única e verificável, credenciais limitadas e um responsável.
O que falha sem isto: credenciais partilhadas, atribuição fraca e contenção impossível.

2. Ação
Pergunta central: O que pode o agente fazer?
O que é bom: limites explícitos de autonomia, non-goals impostos pela máquina e aprovação humana quando a autoridade termina.
O que falha sem isto: scope creep, uso inseguro de ferramentas e excesso de alcance acidental.

3. Output
Pergunta central: O que decidiu o agente e porquê?
O que é bom: decision traces, ligações para evidência, confiança, citações e rationale estruturado.
O que falha sem isto: PR misteriosas, falhas de auditoria e postmortems baseados em adivinhação.

4. Mudança
Pergunta central: Como chegou esse output a produção?
O que é bom: rastreabilidade end-to-end do pedido ao PR, CI, canary e deploy, com readiness para rollback.
O que falha sem isto: falhas na timeline, drift silencioso de prompts/modelos e resposta lenta a incidentes.

5. Resultado
Pergunta central: O agente foi eficaz?
O que é bom: métricas ao nível da versão para taxa de aceitação, retrabalho, rollback, custo, escalada e drift.
O que falha sem isto: autonomia expandida por intuição, agentes fracos mantidos e erosão de confiança.

Repita-se, porque é precisamente aqui que as equipas se enganam: As camadas 1 e 2 controlam o acesso. As camadas 3, 4 e 5 criam confiança à escala. Se só construiu as duas primeiras, não terminou a stack. Construiu o átrio e deixou o resto do edifício às escuras.

Camada 1: Identidade 🔐

Todo o sistema de governação começa aqui, porque sem identidade tudo o resto se transforma em ambiguidade. Um agente sem identidade única não é governado. É apenas um processo com responsabilidade pouco clara.

No mínimo, a camada 1 significa:

• cada instância de agente tem um registo de identidade próprio
• as credenciais são únicas para esse agente e não partilhadas entre agentes
• as permissões estão limitadas ao propósito registado do agente
• a emissão, rotação e revogação de credenciais é auditável
• existe um responsável humano identificado

Parece óbvio. Na prática, muitas equipas ainda executam vários agentes com o mesmo token ou deixam agentes de IDE herdar acesso amplo de developers apenas porque é conveniente. Essa conveniência transforma-se rapidamente em dívida operacional. Se três agentes partilham uma credencial, não consegue isolar um durante um incidente. Se um agente usa o acesso de uma pessoa, perdeu a fronteira entre ação humana e ação do agente. Se um agente de produção mantém um segredo estático de longa duração, basta uma fuga de logs para criar uma violação difícil de atribuir.

Identidade não é apenas segurança. É o primeiro pré-requisito para legibilidade. Se não consegue responder a «qual agente fez isto?» numa única query, não passe para modelos de maturidade e dashboards de KPI. Ainda está na camada 1.

🛑 Camada 2: Ação

A identidade diz-lhe quem é o agente. A ação diz-lhe o que está autorizado a fazer. É aqui que vivem os limites de autonomia, os non-goals, os scopes das ferramentas, os thresholds de aprovação e as regras fail-closed.

Uma camada 2 forte torna a autoridade do agente explícita em cinco direções:

• funcional: que ações pode ou não executar
• dados: a que sistemas e domínios de dados pode aceder
• temporal: quando pode agir e quando não pode
• autoridade: que decisões exigem aprovação humana
• escalada: quando a ambiguidade ou o risco deve parar o workflow

A escolha de design principal é simples e surpreendentemente rara: a rejeição deve ser tratada como um output correto.

Se um agente não consegue perceber se um pedido está dentro do seu scope, deve recusar e escalar. Demasiadas equipas continuam a recompensar os agentes por serem «úteis» quando o comportamento governado deveria ser «parar».

Esta é a diferença entre um agente que parece inteligente numa demo e um agente que pode operar com segurança em produção. A maioria das empresas tem alguma versão da camada 2, mas normalmente é fraca: um documento de política, um prompt a dizer «não tocar em produção» ou uma aprovação manual para ações de maior risco.

Não chega. Uma verdadeira camada 2 é imposta em runtime, é machine-readable e bloqueia antes de a ação avançar. Caso contrário, os seus limites não são limites; são sugestões.

🧾 Camada 3: Output

Esta é a camada que a maioria das equipas ignora por completo, e é onde a governação começa a tornar-se real. A camada 3 pergunta: quando um agente toma uma decisão material, que evidência sobrevive a essa decisão? Não a descrição polida do PR. Não a frase de marketing de que o agente é «transparente». A evidência operacional real.

Para uma decisão relevante, deveria conseguir recuperar:

• o decision trace ID
• os inputs usados pelo agente
• as fontes de conhecimento ou referências utilizadas
• o sinal de confiança ou certeza, quando relevante
• as alternativas consideradas, quando a decisão é material
• o resultado estruturado produzido

Sem isso, obtém aquilo que muitas equipas já têm: código em main sem uma explicação fiável para a sua existência. Durante um incidente ou uma auditoria, a ausência de camada 3 significa que o postmortem começa com uma pesquisa no Slack e a resposta à compliance começa por «pensamos que».

Logs de chat não são rastreabilidade. São detritos.

Arqueologia no Slack não é auditabilidade. É reconstrução. A objeção comum é velocidade: «não conseguimos capturar tudo isto e continuar rápidos». Normalmente é falso. Não precisa de um romance para cada output; precisa de traces estruturados e consultáveis. Boa governação de output não é narrative-heavy, é schema-heavy.

É esta camada que transforma um postmortem de ficção policial em engenharia. Também é daqui que vem muita dor de auditoria. Quando compliance pergunta quem aprovou uma mudança, que versão de policy estava em vigor ou que nível de evidência suportou a decisão, equipas sem camada 3 começam a procurar em chats e screenshots. Isto não é governação; é reconstrução. A camada 3 torna o trabalho legível.

🔄 Camada 4: Mudança

A camada 3 diz o que o agente decidiu. A camada 4 diz como essa decisão se tornou uma alteração ativa. Incidentes de produção raramente acontecem no ponto da decisão; acontecem mais tarde, quando uma cadeia de sistemas transforma o output do agente em impacto no cliente.

A camada 4 liga toda a timeline: pedido → plano → PR → CI → canary → deploy → sinais runtime → incidente → rollback.

Uma boa governação da camada 4 significa:

• um correlation ID sobrevive ao caminho completo
• as ligações aos artefactos são preservadas, não copiadas de forma solta para notas
• cada ligação importante na timeline é assinada ou auditável
• ligações em falta falham de forma visível
• a readiness de rollback é verificada antes da promoção
• alterações que mudam comportamento, como prompts, versões de modelos e schemas de ferramentas, são versionadas e promovidas como código

Este último ponto é onde muitas organizações disciplinadas são apanhadas. Continuam a pensar em «mudança» como apenas source code.

Num modelo operacional AI-native, alterações de prompts, regras de routing, tool schemas, índices de retrieval e versões de modelos mudam o comportamento de produção. Um prompt que altera comportamento vivo é uma alteração de produção. Uma troca de modelo que altera comportamento de aprovação é uma alteração de produção. Um tool-schema que alarga o que o agente pode invocar é uma alteração de produção.

Se essas mudanças contornam a mesma disciplina de promoção do código, não tem change control. Tem um modelo de deployment dividido: o Git é governado, o comportamento não. Se o comportamento do sistema pode mudar fora da pipeline de deployment, o sistema não é verdadeiramente governado.

É assim que equipas acabam a investigar na sexta-feira um incidente causado por um prompt atualizado na terça-feira sem review, sem canary e sem plano de rollback. A camada 4 torna a reversibilidade real em vez de retórica.

📈 Camada 5: Resultado

A última camada faz a pergunta que os executivos vão acabar por fazer: este agente está a ajudar? Não «os developers gostam?», não «quantos prompts fizemos deploy este mês?», não «quantos tokens comprámos?».

A pergunta real é se uma versão específica de uma capacidade melhorou os resultados sem empurrar custos escondidos para outro lado. Isso implica medir, ao nível da capability-version:

• taxa de aceitação
• taxa de retrabalho
• taxa de escalada
• taxa de rollback
• diferença no time-to-done
• custo por tarefa
• taxa de respeito pela autonomia limitada
• envolvimento em incidentes

É aqui que a maioria das empresas ainda opera com base em sensações. Sabem que os agentes estão «em todo o lado», que a utilização aumentou e que o CFO quer uma história de ROI. Mas não conseguem dizer que versão ajudou a equipa de checkout, qual aumentou a carga de review, qual regrediu depois de uma troca de modelo ou qual merece maior scope no próximo trimestre.

Avaliação baseada em sensações é como agentes medianos são promovidos, agentes caros são defendidos e agentes fracos se tornam «estratégia». É também assim que erros caros se tornam normais.

Sem camada 5, o crescimento da autonomia torna-se político: ganha o defensor mais ruidoso, a demo mais brilhante ou o roadmap do fornecedor. Com camada 5, a governação torna-se melhorável: pode reduzir scope, promover versões mais seguras, retirar capacidades fracas e tomar decisões de recursos com base em evidência em vez de entusiasmo.

🏦 Um incidente visto através das cinco camadas

Um coding agent numa fintech recebe a tarefa de reduzir a latência do checkout. Reescreve um caminho crítico de query, substitui um lookup limitado por um join mais amplo, abre um PR e passa a suite de testes. Os testes validam correção com dados de fixture, não latência com cardinalidade de produção e carga concorrente. Um reviewer humano aprova rapidamente. Um deploy agent promove a mudança através do canary porque não vê aumento de erros nem violação do p95 por defeito. Ao fim da tarde, a latência está pior. A equipa faz rollback.

Se só tiver as camadas 1 e 2, provavelmente consegue dizer que conta de agente abriu o PR e que o agente tinha tecnicamente permissão para editar aquele serviço. É útil. Está longe de ser suficiente.

Camada 1, Identidade
Sabe a instância exata do agente, o responsável, o conjunto de credenciais e a versão da capability envolvida.

Camada 2, Ação
Sabe se o agente estava realmente no scope para alterar a lógica de performance do checkout, se atravessou limites de dados ou autoridade e se o threshold de review era adequado à criticidade do serviço.

Camada 3, Output
Pode inspecionar o decision trace: ficheiros lidos, evidência usada, benchmarks desatualizados eventualmente citados, confiança baixa ou sinais contraditórios ignorados.

Camada 4, Mudança
Reconstrói a timeline assinada desde o pedido ao PR, CI, canary, deploy e rollback, e consegue ver se um prompt ou tool-schema mudou na mesma janela.

Camada 5, Resultado
Compara o incidente com o histórico de performance mais amplo do agente: erro isolado? Regressão recente? Padrão em serviços críticos? Sinal para reduzir autonomia?

Essa é a diferença entre «tivemos um incidente de IA» e «compreendemos o nosso sistema operacional». A primeira postura é reativa e cara. A segunda é como se conquista confiança à velocidade.

🚧 Porque é que a maioria das equipas fica presa na camada 2?

Três razões. Primeiro, as camadas 1 e 2 parecem governação tradicional. Security controla identidade, Platform controla permissões e a liderança vê controlos visíveis, por isso sente progresso.

Segundo, as camadas 3 e 4 exigem uma disciplina desconfortável: traces estruturados, timelines assinadas, prompts fixados por versão, deteção de gaps nas deploy gates e probes de rollback. É trabalho real de engenharia e expõe quanto do processo atual depende de comportamentos informais.

Terceiro, a camada 5 obriga à honestidade. Quando mede a eficácia do agente por versão, algumas ferramentas favoritas deixam de parecer impressionantes, algumas expansões de autonomia revelam-se prematuras e algumas equipas não estão bloqueadas pela velocidade de programação, mas pelo review, incident handling ou retrieval de baixa qualidade.

Por outras palavras, as camadas mais profundas não governam apenas os agentes. Governam também as narrativas de gestão. É por isso que são adiadas. E é também por isso que importam.

✅ Uma autoavaliação rápida

Para perceber onde está, faça estas cinco perguntas:

  1. Identidade: conseguimos hoje identificar todos os agentes relevantes para produção, os responsáveis, as credenciais e o scope?
    2. Ação: conseguimos mostrar o que cada agente não pode fazer e provar que esses limites são impostos em runtime?
    3. Output: conseguimos reconstruir uma decisão material de um agente com evidência rastreável em vez de chats?
    4. Mudança: conseguimos seguir um correlation ID desde o pedido até ao deploy e rollback, incluindo mudanças de prompts e modelos?
    5. Resultado: conseguimos mostrar que versões de capabilities estão a ajudar, prejudicar ou sofrer drift?

Se respondeu «não» a alguma delas, essa camada é fraca. Se respondeu «não» às perguntas 3 a 5, está no estado mais comum: controlos básicos à frente, nevoeiro no meio e nenhuma learning loop fiável no fim.

É um ponto de partida viável. Não é um lugar seguro para ficar. Mais diretamente: se não consegue responder às perguntas 3 a 5, não tem confiança à escala. Tem exposição à escala.

🏗️ Onde construir a seguir?

Não tente implementar as cinco camadas ao mesmo tempo. Se está no início, retire as camadas 1 e 2 dos documentos de política e transforme-as em enforcement real. Se já tem isso, não salte diretamente para dashboards executivos de ROI. Construa primeiro as camadas 3 e 4. Sem elas, as métricas de outcome serão ruidosas, contestáveis e fáceis de manipular.

A ordem prática para a maioria das equipas é:

  1. identidade única do agente e credenciais limitadas
    2. limites de autonomia em runtime e non-goals explícitos
    3. decision traces para ações materiais
    4. timelines end-to-end de mudança com readiness para rollback
    5. métricas de eficácia por versão da capability

A ordem importa porque cada camada torna a seguinte credível.

🎯 O objetivo do modelo

O modelo de cinco camadas não é um exercício de taxonomia. É uma forma de parar de usar a palavra «governação» de maneira tão vaga que perde significado operacional.

Governação não é um prompt a dizer ao agente para ter cuidado. Governação não é SSO mais um template de pull request. Governação não é um comité de Responsible AI que nunca olha para a timeline de deployment.

Governação é a disciplina operacional que torna uma força de trabalho não humana legível, contida, reversível e melhorável. É isso que permite às organizações de engenharia escalar o uso de agentes sem escalar a confusão à mesma velocidade. E é isso que torna possível criar confiança à velocidade.

Se o Artigo 1 foi a mudança de enquadramento, este é o diagnóstico: a maioria das equipas não tem um problema de governação por falta de princípios. Tem um problema porque a stack só tem duas camadas e já está a apostar a produção nas cinco.

Essa aposta fica mais cara a cada trimestre.

Terminemos com a frase que interessa: As camadas 1 e 2 controlam o acesso. As camadas 3, 4 e 5 criam confiança à escala.

Se não consegue ver o trabalho, rastrear a mudança e medir o resultado, não está a governar agentes. Está a operar com confiança cega.