Especificações de Agentes São Artefatos de Governança

Em janeiro, publiquei um guia sobre como escrever specs para agentes de IA. O foco era prático: estrutura, modularidade, os cinco princípios que separam uma spec funcional de um prompt vago. O artigo tratava specs como ferramentas de engenharia.

Estava incompleto.

Nas semanas seguintes, três frameworks de governança independentes chegaram à mesma conclusão por caminhos diferentes. O Auton Framework, publicado no arXiv em fevereiro de 2026, introduziu o conceito de “Cognitive Blueprint”: uma spec declarativa em YAML ou JSON que é “versionável, diffável e auditável.” A Cloud Security Alliance publicou seu Agentic Trust Framework com cinco dimensões de governança e autonomia progressiva. E Singapura lançou o primeiro framework nacional de governança para IA agêntica, o Model Governance Framework do IMDA.

Nenhum desses três grupos se referência mutuamente. A convergência é independente. E o ponto de convergência é o mesmo: a especificação do agente não é documentação. É um artefato de controle.

De ferramenta de engenharia a superfície de controle

Uma revisão interna do GitHub de mais de 2.500 arquivos de configuração de agentes identificou seis áreas onde specs são efetivas: comandos, testes, estrutura do projeto, estilo de código, workflow git e limites. Como exploramos no artigo anterior, essas seis áreas formam a base de qualquer spec funcional.

O que não ficou explícito naquele artigo é que essas seis áreas mapeiam diretamente para controles de segurança organizacional.

O modelo de fronteiras em três níveis (Sempre Faça, Pergunte Antes, Nunca Faça) é estruturalmente idêntico ao RBAC, o modelo de controle de acesso baseado em papéis que existe desde 1992. Allow, Conditional, Deny. As categorias mudam de nome, mas a lógica é a mesma: definir quais ações um ator pode executar sem supervisão, quais exigem aprovação e quais são proibidas.

Reconhecer isso importa porque muda o enquadramento. Se specs são RBAC para agentes, elas herdam décadas de melhores práticas em controle de acesso. Versionamento obrigatório. Auditoria de mudanças. Segregação de funções. Revisão periódica. Não precisamos inventar governança para agentes. Precisamos adaptar o que já funciona.

O paradoxo que specs modulares resolvem

Existe um problema real que complica essa adaptação. Pesquisadores demonstraram que a performance de modelos de linguagem degrada conforme o volume de instruções aumenta. O fenômeno “lost in the middle”, documentado por Liu et al. em 2023 e confirmado em estudos subsequentes, mostra que informações posicionadas no meio de contextos longos são sistematicamente ignoradas.

Isso cria um paradoxo de governança. Governança abrangente exige regras abrangentes. Regras abrangentes degradam a capacidade do agente de segui-las. Quanto mais controles você adiciona, menos confiável se torna o cumprimento de cada controle individual.

Como discutimos em Quando a Especificação É o Produto, Quem Governa a Especificação?, essa tensão entre velocidade e controle não é teórica. Ela aparece toda vez que uma spec de produção cresce além do que o modelo consegue processar com fidelidade.

A solução é modularidade. Specs separadas por domínio (backend, frontend, banco de dados, segurança) entregues seletivamente conforme a tarefa. Cada agente recebe apenas o contexto relevante para sua função. Isso não é apenas boa engenharia. É o princípio de privilégio mínimo aplicado a informação.

Yan et al. demonstraram essa ideia de forma rigorosa com o framework GAM (arXiv:2511.18423), que aplica privilégio mínimo à memória de agentes. O resultado: 57,75 de F1 no benchmark LoCoMo contra 48,62 do MemoryOS. Agentes que recebem menos contexto, selecionado com critério, performam melhor do que agentes que recebem tudo. A pesquisa é acadêmica, sem implantação em produção ainda, mas a direção é consistente com o que equipes de engenharia estão descobrindo empiricamente.

Três frameworks, uma conclusão

Vale examinar cada framework em detalhe porque a convergência não é superficial.

Auton Framework (arXiv 2602.23720). Propõe que todo agente autônomo opere a partir de um “Cognitive Blueprint” declarativo. O blueprint define capacidades, restrições, protocolos de escalonamento e critérios de sucesso. O formato é YAML ou JSON. Versionável por git, diffável em pull requests, auditável por ferramentas de compliance existentes. Os autores argumentam explicitamente que esse blueprint é a unidade de governança, não um acessório da implementação.

CSA Agentic Trust Framework (fevereiro 2026). A Cloud Security Alliance define cinco dimensões de governança para agentes: identidade, autorização, observabilidade, contenção e confiança. A dimensão de autorização descreve “autonomia progressiva”: agentes começam com permissões mínimas e ganham autonomia conforme demonstram conformidade. É o mesmo modelo de três níveis (Sempre/Pergunte/Nunca), mas enquadrado como política de segurança corporativa, não como configuração de desenvolvedor.

Singapore Model Governance Framework (IMDA, janeiro 2026). O primeiro framework nacional a tratar IA agêntica como categoria distinta. Define requisitos de transparência, rastreabilidade e responsabilidade para agentes que operam com autonomia. O documento é regulatório, não técnico, mas as exigências de rastreabilidade pressupõem exatamente o tipo de spec auditável que os outros dois frameworks descrevem.

Três comunidades diferentes (pesquisa acadêmica, segurança corporativa, regulação governamental) chegaram à mesma estrutura. Isso não é coincidência. É convergência por necessidade.

A primitiva que conecta tudo: reprodutibilidade

Holmes, pesquisador de segurança, argumenta que se uma ação de agente não é reproduzível por um humano executando o mesmo comando, ela não pode ser auditada. O argumento tem fundamento prático. SOC 2 e ISO 27001 exigem evidência de execução de controles. “O agente fez isso” não é evidência. “Execute este comando e observe este resultado” é.

A implicação para specs é direta. Cada permissão, cada restrição, cada limite definido na spec precisa ser verificável de forma independente. Se a spec diz “nunca faça push direto para main”, deve existir um mecanismo que confirme o cumprimento, não apenas a declaração de intenção.

Isso não significa que agentes devem operar exclusivamente via CLI, como Holmes sugere. MCP, APIs e interfaces programáticas são legítimas. O critério não é o canal. É a reprodutibilidade do resultado. Se um auditor pode reexecutar a ação e verificar o output, o controle é válido.

Blueprints da Stripe ilustram isso na prática. Como analisamos em A Regra dos 65%, cada workflow da Stripe alterna entre nós determinísticos e agênticos, com limites codificados que forçam escalonamento após duas falhas de CI. O blueprint é a spec. A spec é o controle. O controle é auditável porque é código.

A contra-evidência que importa

Seria desonesto apresentar apenas a convergência sem mencionar os dados que apontam na direção oposta.

Pesquisadores da ETH Zurich testaram arquivos de contexto gerados por LLMs e encontraram que eles reduziram a taxa de sucesso em cinco de oito configurações testadas. Specs geradas automaticamente, sem curadoria humana, podem ser contraproducentes. Mais contexto, nesse caso, significou pior performance.

Esse resultado não invalida specs como artefatos de governança. Reforça a necessidade de tratá-las como artefatos de engenharia, não como output descartável. Uma política de segurança gerada automaticamente e nunca revisada também seria um risco. O problema não é a automação da criação. É a ausência de revisão.

O que fazer com essa convergência

O NIST abriu em fevereiro de 2026 sua AI Agent Standards Initiative, com prazos em 9 de março e 2 de abril. A janela para influenciar padrões está aberta. Isso importa porque padrões de governança, uma vez estabelecidos, definem o que “compliance” significa por anos.

Para equipes que já operam agentes em produção, três ações concretas se justificam.

Reclassifique suas specs. Se arquivos como CLAUDE.md, agents.md ou blueprints YAML vivem no repositório como “documentação de desenvolvedor”, mova-os para o escopo de governança. Isso significa versionamento com revisão obrigatória, log de mudanças, e inclusão no escopo de auditoria. O conteúdo não muda. O tratamento muda.

Aplique privilégio mínimo à informação. Cada agente deve receber apenas as specs relevantes para sua função. Não por conveniência, mas por controle. Se um agente de frontend não precisa saber as regras do banco de dados, não entregue essas regras. Menos contexto, seletivamente entregue, produz melhor conformidade.

Teste seus limites, não apenas suas funcionalidades. A maioria dos testes de agentes verifica se o agente faz o que deveria. Poucos verificam se o agente respeita o que não deveria fazer. Testes de limites (o agente tentou acessar um recurso proibido? Solicitou aprovação quando deveria?) são a evidência que auditores procuram.

A tese, sem rodeios

Specs de agentes já são artefatos de governança. A questão não é se deveriam ser. É se sua organização as trata como tal.

Se suas specs vivem como arquivos informais que desenvolvedores editam sem revisão, você tem controles que ninguém controla. Se vivem como artefatos versionados, revisados e testados, você tem uma camada de governança que acompanha a velocidade dos seus agentes.

Três frameworks independentes, um regulador nacional e o NIST concordam na direção. A convergência é forte demais para ignorar.

Fontes

Auton Framework. “Cognitive Blueprint for Autonomous Agents.” arXiv:2602.23720. Fevereiro 2026.
Cloud Security Alliance. “Agentic Trust Framework.” Fevereiro 2026.
IMDA Singapore. “Model Governance Framework for Generative AI — Agentic Applications.” Janeiro 2026.
Liu et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the ACL, 2024. Preprint julho 2023.
Yan et al. “GAM: Goal-Aware Memory for Conversational Agents.” arXiv:2511.18423. Novembro 2025.
NIST. “AI Agent Standards Initiative — Call for Participation.” Fevereiro 2026.
ETH Zurich. “Evaluating LLM-Generated Context Files for Code Agents.” 2026.

A Victorino Group ajuda organizações a transformar specs de agentes em camada de governança auditável: contato@victorino.com.br | www.victorino.com.br