Três Equipes, Um Padrão: O Que PM, Segurança e Infraestrutura Construíram para Governança de Agentes

Um gerente de produto em Bangalore constrói um sistema de 15 agentes especializados para automatizar ciclos de lançamento. Um engenheiro de segurança no GitLab desenha um assistente de detecção de ameaças com 1.870 palavras de system prompt. Um arquiteto de infraestrutura na Pulumi codifica políticas de compliance em Rego.

Nenhum dos três sabia o que os outros estavam fazendo. Nenhum consultou o mesmo framework. Nenhum partiu da mesma disciplina.

E os três chegaram ao mesmo lugar.

Quatro Padrões, Três Domínios

O PM Agent OS, publicado por Deepesh Kumar Gupta em março de 2026, expõe mais de 50 endpoints de API e orquestra 15 agentes com responsabilidades distintas: priorização, análise de backlog, planejamento de sprint, retrospectivas. O sistema inclui um Policy Center com allowlists, mascaramento de PII e políticas de retenção. Cada ação de agente passa por portões de aprovação multi-revisor. Um log imutável de GovernanceEvents registra quem fez o quê, quando e por quê.

A frase que define a filosofia do projeto: “O modelo nunca inventa métricas, dados ou citações.”

O GitLab Duo Detection Engineering Assistant, descrito por Matt Coons no mesmo mês, opera com 337 linhas de system prompt que definem exatamente o que o agente pode e não pode fazer. O assistente mapeia ameaças contra a taxonomia MITRE ATT&CK e exige validação humana antes de qualquer regra entrar em produção. A documentação do GitLab é explícita: o agente “não substitui um engenheiro de detecção qualificado, mas amplifica um.”

A Pulumi, por sua vez, integrou Open Policy Agent com Rego como linguagem de política de primeira classe. Levi Blackstone apresentou, em março de 2026, três níveis de enforcement: mandatório (bloqueia a implantação), consultivo (alerta sem bloquear) e desabilitado. Compliance packs pré-construídos cobrem CIS, NIST e PCI DSS.

Três equipes. Três domínios. Os mesmos quatro padrões emergiram em todas:

Portões de aprovação. Nenhum agente executa ações consequentes sem validação. No PM Agent OS, revisores humanos aprovam antes da execução. No GitLab, regras de detecção passam por revisão antes de entrar no pipeline. Na Pulumi, políticas mandatórias impedem deploy sem conformidade.

Trilhas de auditoria. Cada sistema registra decisões de forma imutável. O PM Agent OS mantém logs de GovernanceEvents. O GitLab registra cada interação do assistente. A Pulumi grava o resultado de cada avaliação de política.

Saída estruturada. Os agentes não produzem texto livre para consumo direto. Produzem artefatos com formato definido: relatórios com campos específicos, regras de detecção em formato padronizado, resultados de política em JSON.

Política como código. Regras não vivem em documentos de governança. Vivem no repositório, versionadas, testáveis, auditáveis. Rego na Pulumi. Policy Center no PM Agent OS. System prompts versionados no GitLab.

Por Que a Convergência Importa

Quando um único time adota um padrão, pode ser preferência. Quando dois adotam, pode ser tendência. Quando três times em domínios completamente diferentes, sem contato entre si, constroem a mesma arquitetura de controle, o padrão está dizendo algo sobre a natureza do problema.

Agentes de IA em produção geram um tipo específico de risco: ações autônomas com consequências reais. Um agente de PM que reprioriza o backlog afeta o roadmap do produto. Um agente de segurança que cria regras de detecção afeta o que a equipe investiga. Um agente de infraestrutura que aprova deploys afeta o que chega a produção.

O denominador comum é que decisões automatizadas precisam de supervisão proporcional à consequência. Os quatro padrões não são arbitrários. São respostas funcionais a esse requisito:

Portões de aprovação garantem que humanos validem antes da consequência. Trilhas de auditoria permitem reconstruir a cadeia de decisão depois. Saída estruturada reduz ambiguidade na interface humano-agente. Política como código torna as regras verificáveis por máquinas e humanos.

Como exploramos em A Camada de Governança Que Já Existia, a disciplina que funciona com agentes não é nova. São práticas de engenharia de software aplicadas a um contexto diferente. A convergência que vemos agora reforça essa tese: equipes que partem de problemas reais redescobrem os mesmos controles.

O Que Muda Quando Política Vira Código

A diferença entre governança documental e governança como código é a diferença entre intenção e execução.

Um documento de política diz: “Todos os deploys devem estar em conformidade com PCI DSS.” Uma política em Rego diz exatamente quais propriedades de quais recursos precisam atender a quais critérios, e bloqueia o deploy automaticamente se algum critério falhar.

A Pulumi oferece três níveis de enforcement por um motivo prático. Nem toda política justifica bloqueio imediato. Políticas mandatórias impedem deploy. Políticas consultivas alertam sem bloquear, úteis durante migração ou quando o impacto ainda está sendo avaliado. Políticas desabilitadas permitem que regras existam no repositório sem efeito, prontas para ativação.

Esse modelo de graduação aparece, com variações, nos três sistemas. O PM Agent OS permite configurar quais ações exigem aprovação e quais são automáticas. O GitLab define quais sugestões do agente passam por revisão humana obrigatória e quais são informativas. A granularidade do controle é, por si só, um padrão.

Como documentamos em O Que 220 Controles Ensinam, governança funcional exige controles específicos o suficiente para serem testáveis. Política como código é a implementação literal dessa ideia.

O Padrão Que Falta

Os quatro padrões convergentes resolvem problemas de controle. Falta um quinto que os três sistemas apenas tangenciam: feedback loop contínuo.

Portões de aprovação são binários. Aprovado ou rejeitado. Trilhas de auditoria registram o passado. Políticas definem limites. Nenhum desses mecanismos responde à pergunta: o agente está melhorando com o tempo?

O PM Agent OS coleta métricas de qualidade dos outputs. O GitLab mede quantas sugestões o engenheiro aceita versus descarta. A Pulumi rastreia conformidade ao longo do tempo. São dados valiosos. Mas nenhum dos três os alimenta de volta no sistema de forma que os agentes aprendam com as correções humanas.

Isso não é uma falha dos projetos. É o próximo problema a resolver. Governança estática (regras que não mudam) funciona enquanto o contexto é estável. Agentes em produção operam em contexto que muda continuamente. As políticas de hoje serão insuficientes amanhã.

O quinto padrão, quando emergir, provavelmente será: observabilidade como insumo de governança. Não apenas registrar o que aconteceu, mas usar o registro para atualizar as regras.

O Que Isso Significa na Prática

Se você está implantando agentes de IA em qualquer domínio, a convergência de três equipes independentes oferece um roteiro confiável.

Comece pelos portões de aprovação. Defina quais ações do agente exigem validação humana e quais são automáticas. A distinção entre mandatório, consultivo e desabilitado da Pulumi é um bom modelo inicial.

Implemente trilhas de auditoria desde o primeiro dia. Não depois do incidente. Não no próximo sprint. Agora. O custo de adicionar auditoria retroativamente é ordens de magnitude maior do que incluí-la no design original.

Force saída estruturada. Agentes que produzem texto livre para consumo direto criam risco de interpretação ambígua. Defina schemas. Valide outputs. Trate a interface humano-agente com o mesmo rigor que você trata APIs entre serviços.

Codifique as políticas. Se uma regra de governança não está no repositório, versionada e testável, ela não existe de verdade. Existe apenas na intenção.

Esses quatro padrões não são teoria. São o que três equipes diferentes, resolvendo problemas reais em produção, construíram de forma independente. A convergência é a evidência.

Fontes

Gupta, Deepesh Kumar. “PM Agent OS: AI-Powered Product Management.” Março 2026.
Coons, Matt. “Detection Engineering Assistant.” GitLab, Março 2026.
Blackstone, Levi. “Policy as Code with Pulumi and OPA.” Pulumi, Março 2026.

Victorino Group ajuda equipes a implantar agentes de IA com governança desde o primeiro dia: contato@victorino.com.br | www.victorino.com.br