Nesta semana, uma pesquisa da ServiceNow com mais de 3.700 líderes de tecnologia e segurança mostrou que quase nove em cada dez organizações tiveram algum incidente envolvendo IA agêntica no último ano. Só 13% têm um programa considerado defensável (ServiceNow, 2026). A manchete fala de segurança, mas os dados descrevem, sobretudo, um problema de governança.

Vou puxar o assunto para o meu lado, que é o dia a dia do desenvolvimento de software. Daqui, enxergo o problema em duas camadas: a da organização, que define regras e responsabilidades, e a do repositório, onde o agente de código efetivamente trabalha. Para cada uma, há alternativas interessantes: o módulo AI Governance do ITIL 5 e o Spec-Driven Development, em particular o Spec Kit do GitHub.

Vale deixar claro o recorte. Essas são as camadas que vejo na minha rotina. Em empresas maiores, com mais áreas, fornecedores, jurisdições e exigências regulatórias, as lacunas tendem a ser bem mais numerosas, e duas camadas provavelmente não dão conta de tudo. Também não defendo que essas ferramentas sejam respostas definitivas: são recentes, ainda pouco testadas em escala e têm limites que vou apontar. Mas oferecem um ponto de partida concreto, e me parece que o ganho maior está em usá-las juntas.

Depois das duas camadas, trato de dois temas que afetam diretamente quem desenvolve. O primeiro é que a mesma capacidade que permite a um agente escrever o nosso software permite a ele reconstruir o software dos outros. O segundo é que tudo isso acontece num ambiente regulatório que ainda não se resolveu, nem no mundo nem no Brasil. Os assuntos se influenciam, e é assim que pretendo tratá-los.

O que torna um sistema agêntico

Vale começar pela definição, porque o termo virou rótulo de marketing. Tecnicamente, um agente é um modelo de linguagem executando em laço: recebe um objetivo, planeja, chama uma ferramenta, observa o resultado, atualiza seu estado e decide o próximo passo, até atingir um critério de parada. A diferença para um chatbot não está no modelo, e sim no fato de que as ferramentas executam ações reais, com credenciais delegadas.

Isso significa que o comportamento de um agente não é definido só pelo código. Ele resulta da combinação de alguns componentes, e cada um deles é um ponto de controle:

• Modelo: fornecedor e versão. Trocar a versão pode mudar o comportamento sem nenhum commit.
• Instruções: prompt de sistema e políticas que delimitam o que o agente deve e não deve fazer.
• Ferramentas: quais APIs, comandos ou servidores MCP ele pode chamar, e se com permissão de leitura ou de escrita.
• Contexto: os dados que entram na janela de contexto, como documentos, e-mails, páginas e respostas de outros sistemas.
• Memória: o que persiste entre execuções e quem pode escrever nela.
• Identidade: com que credencial o agente age e qual o alcance dela.
• Orquestração: se ele delega tarefas a outros agentes e como essas mensagens são autenticadas.

Duas propriedades técnicas explicam boa parte dos riscos. A primeira é o não determinismo: a mesma entrada pode gerar sequências de ações diferentes, o que limita o valor dos testes tradicionais. A segunda é que, na janela de contexto, instruções e dados chegam pelo mesmo canal. Não existe separação rígida entre plano de controle e plano de dados, e é por isso que um texto dentro de um documento pode alterar o objetivo do agente. Isso ajuda a explicar por que a injeção de prompt é tão difícil de eliminar, mas não é a única causa. Também pesa o comportamento do próprio modelo, treinado para seguir instruções e sem garantia de distinguir quem as escreveu. E pesa, sobretudo, o desenho da aplicação: o risco cresce muito quando um mesmo agente lê conteúdo não confiável, tem acesso a dados sensíveis e consegue enviar informação para fora. Por isso a mitigação também é em camadas, com permissões restritas, separação entre o que o agente lê e o que ele pode executar, confirmação humana para ações sensíveis e monitoramento. Nenhuma delas, sozinha, resolve o problema.

Outro ponto que vejo confundido no dia a dia: dar autonomia a um agente não é como ligar ou desligar um interruptor. Existem graus, e decidir em qual deles cada agente vai operar é, para mim, uma das escolhas de governança que mais importam. O Quadro 1 resume os níveis que costumo usar como referência.

Nível	O que o agente faz	Controle típico
1. Sugere	Propõe a ação; um humano executa	Revisão da sugestão
2. Age com aprovação	Executa após confirmação explícita	Aprovação por ação ou por lote
3. Age dentro de limites	Executa sozinho dentro de um escopo e reporta	Permissões restritas, monitoramento, alertas
4. Autônomo	Define subtarefas e age sem confirmação	Observabilidade contínua, limites de custo e de ação, desligamento

O critério que me parece mais útil para escolher o nível é a reversibilidade. Uma ação fácil de desfazer, como classificar um chamado, tolera autonomia alta. Uma ação irreversível ou de alto impacto, como apagar dados, movimentar dinheiro ou fazer merge em produção, pede um nível mais baixo, por mais capaz que o modelo seja.

Repare que cada item dessa lista é ao mesmo tempo uma decisão de engenharia, que implementa, de segurança, que impõe, e de governança, que aprova e responde. No dia a dia do desenvolvimento, porém, quem configura o agente costuma tomar essas decisões sozinho, muitas vezes sem perceber que está decidindo algo de segurança ou de governança.

O que os dados mostram

A pesquisa avalia os programas em cinco dimensões: superfície de ataque, responsabilização, segurança desde a concepção, visibilidade e preparo para auditoria (ServiceNow, 2026). Três achados resumem o quadro:

• Controle tardio: só 44% das equipes aplicam controles antes de o agente ser criado.
• Inventário incompleto: 29% já encontraram agentes em produção que ninguém tinha registrado.
• Pouca capacidade de reação: só 19% enxergam mais de 90% dos agentes em tempo real, e 66% não conseguem agir automaticamente diante de comportamento anômalo.

No primeiro achado, o que falha é a camada do repositório: o agente nasce sem regras. No segundo e no terceiro, falha a camada da organização: o agente opera sem dono, sem registro e sem processo de resposta. É por isso que uma camada sozinha não basta.

A camada da organização: ITIL AI Governance

Para quem vem do desenvolvimento e nunca trabalhou com ele, vale uma breve contextualização. O ITIL é um conjunto de boas práticas para gerenciar serviços de TI, criado pelo governo britânico no fim dos anos 1980 e hoje mantido pela PeopleCert. Seu propósito é garantir que a tecnologia entregue valor ao negócio de forma previsível e controlada, com práticas como gestão de incidentes, de mudanças, de configuração e de níveis de serviço, além de princípios orientadores e um ciclo de melhoria contínua. Não é uma norma rígida: é um framework para ser adaptado à realidade de cada organização. Na versão 5, o nome deixou até de significar "IT Infrastructure Library", e o escopo se ampliou para o gerenciamento de produtos e serviços digitais como um todo (TeamDynamix, 2026).

O ITIL (Version 5) foi lançado pela PeopleCert no início de 2026 e trouxe a IA para dentro do framework (TeamDynamix, 2026). Na dimensão de organizações e pessoas, há agora uma seção específica sobre IA; na de informação e tecnologia, entrou o AI Capability Model (ITSM.tools, 2026). E o esquema de certificação ganhou um módulo de extensão dedicado, o AI Governance (TeamDynamix, 2026). No Brasil, ainda se fala pouco disso.

O módulo se apoia em três modelos que, juntos, formam um método bastante prático.

1. AI Capability Model (6C). Classifica qual função um sistema de IA desempenha: Creation, Curation, Clarification, Cognition, Communication e Coordination (ITSM.tools, 2026). A ideia é que funções diferentes trazem riscos diferentes e pedem níveis diferentes de supervisão humana (PeopleCert, 2026). Explicar uma decisão não é o mesmo que orquestrar ações entre sistemas. Na minha leitura, é em Coordination que a IA agêntica se concentra, e um agente de código combina Coordination com Creation.

2. AI Governance Model. Estrutura a relação entre governança corporativa, governança de TI e governança de IA, e deixa claro quem decide, quem executa e quem responde. Inclui ainda a governança de IA de terceiros, que cobre agentes embarcados em plataformas de fornecedores (Global Knowledge, 2026).

3. AI Governance Improvement Model. É o ciclo de trabalho. Começa por avaliar e testar sob estresse a governança atual, usando fatores de risco contextuais e priorização por risco. Depois define requisitos, desenha ajustes e implementa. Por fim, mantém a governança com monitoramento, auditabilidade, evidências e melhoria contínua (Bakkah, 2026).

As evidências geradas na etapa de manutenção alimentam a próxima avaliação, e o ciclo recomeça a cada mudança relevante no uso da IA.

O módulo de Experience do ITIL 5 acrescenta artefatos concretos que considero valiosos para agentes: limites de decisão, regras de passagem para um humano e "cartões" documentando a capacidade de cada sistema de IA (PeopleCert, 2026).

O princípio por trás de tudo é de proporcionalidade: primeiro se entende o que a IA faz, depois se decide quanto controle ela exige. Na minha leitura, a IA entra como apoio à decisão, e não como substituta de quem decide. E, para quem já opera ITSM, há um ganho prático: o agente vira item de configuração, sua implantação vira mudança e seu comportamento anômalo vira incidente. Sem estrutura paralela.

Visto do desenvolvimento, porém, o limite do ITIL é de altitude. Ele diz à organização o que decidir, mas não chega ao momento em que o agente de código lê suas instruções e escreve uma linha. Nesse ponto entra a segunda camada.

A camada do repositório: Spec Kit

O Spec-Driven Development inverte a relação entre especificação e código. Em vez de um prompt descartável, o agente trabalha a partir de uma especificação estruturada e versionada, que continua sendo a fonte da verdade depois que o código existe (Wang, 2026). A regra prática é simples: para mudar o comportamento, atualiza-se primeiro a spec e o plano, e só depois a implementação.

O Spec Kit, que o GitHub abriu em setembro de 2025 e funciona com os principais agentes de código, organiza isso em comandos que acompanham o ciclo (GitHub, 2025; Wang, 2026):

1. /speckit.constitution define os princípios não negociáveis do projeto.
2. /speckit.specify descreve a funcionalidade em termos de produto: o que e por quê, sem o como.
3. /speckit.clarify resolve ambiguidades da spec antes do planejamento.
4. /speckit.plan define a solução técnica.
5. /speckit.tasks quebra o plano em tarefas.
6. /speckit.analyze verifica a consistência entre spec, plano e tarefas.
7. /speckit.implement executa.

O elemento que interessa à governança é a constituição, o arquivo .specify/memory/constitution.md. Ela registra princípios, restrições, portões de qualidade e uma seção própria de governança, tem versão semântica e, pelo modelo padrão, prevalece sobre qualquer outra prática do projeto (GitHub, 2025). Todo plano passa por um Constitution Check antes de o design avançar (GitHub, 2025).

A constituição é verificada no planejamento, e qualquer mudança de comportamento recomeça pela spec, não pelo código.

Na prática, isso entrega três coisas que a camada organizacional não consegue entregar sozinha. A primeira é rastreabilidade: spec, plano e código mudam juntos no mesmo pull request, e a auditoria passa a ver por que algo foi feito. A segunda é política executável: uma regra como "dados pessoais não saem da região" deixa de morar num PDF e passa a ser lida pelo agente e checada no portão. A terceira é um oráculo: uma spec testável serve de referência para verificar o que o agente entregou.

O Spec Kit, no entanto, tem limites que vale reconhecer. Análises comparativas apontam que a verificação é leve: o Constitution Check é o portão principal, e boa parte do cumprimento depende de cultura, não de imposição técnica (GZKit, [2026]). A Thoughtworks observa que a abordagem compensa em funcionalidades maiores, e não numa correção pequena (Wang, 2026). E o agente que implementa não deveria ser o mesmo que verifica a conformidade. A constituição define a regra, mas quem decide quais regras ela deve conter, e quem responde por elas, está fora do repositório.

Ligando as duas camadas

Uma camada responde ao que falta na outra. O ITIL define o que governar e quem responde, mas não alcança o repositório. O Spec Kit impõe regras no repositório, mas não diz quais regras escrever. A proposta abaixo é minha, não está em nenhum dos dois materiais, e mostra como um elemento do ITIL AI Governance pode virar um artefato do Spec Kit:

ITIL AI Governance (organização)	Spec Kit (repositório)
Classificação 6C e cartão de capacidade do sistema	Seção da spec declarando capacidade, nível de autonomia e dono
Limites de decisão e regras de passagem para humano	Regras obrigatórias na constituição, verificadas no Constitution Check
Avaliação e teste sob estresse da governança	/speckit.clarify e /speckit.analyze, com cenários adversariais na spec
Governança de IA de terceiros	Regras sobre modelos, dependências e licenças permitidos
Evidência e auditabilidade	Spec, plano e código no mesmo pull request, com histórico
Melhoria contínua	Emendas à constituição com versão semântica e registro do motivo
Change enablement	Constitution Check como porta de entrada antes do design

O fluxo resultante é de mão dupla. Quem responde pela governança decide as políticas e as traduz para a constituição. O repositório as aplica em cada funcionalidade e gera evidências. Essas evidências voltam para o ciclo de melhoria do ITIL, que ajusta as políticas. Com isso, o "controle antes da criação", que só 44% das equipes praticam (ServiceNow, 2026), deixa de depender da boa vontade de quem configura o agente.

Num time de desenvolvimento, esse "quem responde" pode ser o próprio tech lead ou arquiteto, e o ciclo é relativamente simples. Em empresas maiores, ele envolve segurança, jurídico, compliance e várias áreas de negócio, e o fluxo fica bem mais complexo do que essa tabela sugere.

Quando o agente reconstrói o software dos outros

A mesma capacidade que permite a um agente escrever o nosso software permite a ele reconstruir o software dos outros. Em outubro, o desenvolvedor Brandon Thomas publicou o ArtCraft, um conjunto de sete aplicativos de código aberto que imitam a suíte da Adobe, do Photoshop ao InDesign, escritos em Rust com ajuda de IA (Poster, 2026). Na mesma semana, o REA (Reverse Engineer Anything), uma ferramenta de código aberto que permite a agentes de IA operar descompiladores e outras ferramentas clássicas de engenharia reversa, passou de 100 mil estrelas no GitHub (Poster, 2026).

Boa parte da imprensa tratou o ArtCraft como engenharia reversa do Photoshop. O próprio projeto, porém, se descreve como uma reimplementação em sala limpa (clean-room): refazer o comportamento de um programa sem copiar o código original (Poster, 2026). A diferença não é detalhe. Na técnica clássica, usada desde os anos 1980 em clones de BIOS de PCs, uma equipe estuda o software original e escreve uma especificação do seu comportamento; outra equipe, que nunca teve contato com o original, implementa a partir apenas dessa especificação. É a separação entre as duas, documentada, que serve de prova de que nada foi copiado.

Com agentes, essa prova fica mais difícil. Como demonstrar que o agente que implementou nunca "viu" o código original, seja nos dados de treino do modelo, seja num binário descompilado por uma ferramenta como o REA?

O próprio repositório do PhotoCraft, o editor de imagens do ArtCraft, ajuda a enxergar o problema. Ele mostra muitos commits com o agente de código como coautor, ao lado de dezenas de contribuidores humanos (Storytold, 2026). Isso dá rastreabilidade de autoria: sabe-se quais mudanças tiveram participação do agente, quem as aprovou e quando. Mas não dá rastreabilidade de contexto: o registro mostra que o agente escreveu o código, não o que ele consultou para escrever. E, com cada contribuidor usando o próprio agente, na própria máquina e com as próprias instruções, a fronteira controlada que define uma sala limpa se dilui.

Não há, até aqui, verificação independente de que a sala limpa foi respeitada, e o próprio autor reconhece que os aplicativos ainda estão em versão alfa (Poster, 2026). A declaração de "sala limpa" deixa de ser apenas uma escolha técnica e vira uma questão de governança: sem rastreabilidade do contexto, é só uma afirmação.

É aqui que os assuntos se encontram. Uma sala limpa é, na essência, desenvolvimento guiado por especificação: um lado escreve a spec, o outro implementa a partir dela, e os dois não se misturam. O Spec Kit ajuda justamente na parte que o histórico de commits não cobre. Ao tornar a spec versionada a entrada formal da implementação, e ao registrar plano e decisões no repositório, ele documenta o contexto, e não só a autoria. A constituição pode, ainda, definir o que o agente pode ou não consultar. Isso não resolve tudo, já que o que o modelo traz do treino continua fora de qualquer registro, mas transforma uma afirmação em evidência, ainda que parcial. A mesma lógica vale para o nosso próprio código, mesmo quando não há nenhum clone envolvido.

Para um time de desenvolvimento, o tema ainda levanta duas questões práticas:

• Governança: podemos apontar nossos agentes para o binário de um concorrente ou de um fornecedor? Isso é uma decisão de governança de IA de terceiros, no vocabulário do ITIL, e pode virar uma regra explícita na constituição do repositório.
• Segurança: um preprint de maio mostrou que instruções escondidas em strings de um binário conseguem desviar o agente que o analisa (Menezes, 2026). Quem aponta um agente para software alheio expõe o próprio agente, e tudo a que ele tem acesso.

Uma regulação que ainda não chegou

O clone é escrito num país, publicado num repositório global e usado em qualquer lugar, enquanto as leis de software e de engenharia reversa continuam nacionais. No plano internacional, a ONU realizou em julho, em Genebra, a primeira sessão do Diálogo Global sobre Governança de IA, apoiada por um painel científico de 40 especialistas copresidido por Yoshua Bengio. Os especialistas deram destaque justamente à IA agêntica, preocupados com a possibilidade de que a escala e a velocidade dos agentes tornem o "humano no circuito" uma formalidade. Mas a ONU tem poder limitado de imposição direta (De Wet, 2026), e cada país segue seu próprio caminho, como a União Europeia com o AI Act.

No Brasil, o PL 2338/2023 foi aprovado pelo Senado em dezembro de 2024 e, desde maio de 2025, aguarda o parecer do relator na Comissão Especial da Câmara, sem votação até o momento (Brasil, 2026). A pressão, por enquanto, vem do mercado: grandes organizações já exigem padrões mínimos de governança de IA de seus fornecedores (Pascon, 2026). E a LGPD, que está em vigor, já se aplica a qualquer agente que trate dados pessoais.

Esse descompasso reforça o argumento central deste texto. Enquanto a regulação não se consolida, a governança que cada empresa e cada time constroem é a principal camada de controle disponível. E ela precisa ser demonstrável, porque é o que clientes e auditores vão cobrar. O ciclo de evidências do ITIL, alimentado pela trilha que o Spec Kit deixa no repositório, é uma forma concreta de produzir essa demonstração. E, quando a lei chegar, quem já tiver políticas versionadas e rastreáveis vai precisar apenas ajustar a constituição, não recomeçar.

Por onde eu começaria

1. Inventariar e classificar. Começar pelos agentes que o time já usa no desenvolvimento, classificando cada um pelo 6C, com dono e nível de autonomia.
2. Rodar o Improvement Model em um caso de uso. Avaliar e testar sob estresse a governança de um agente relevante, antes de tentar cobrir todos.
3. Escrever uma constituição base. Traduzir as políticas aplicáveis em regras verificáveis, incluindo o que os agentes podem ou não analisar de software de terceiros, e usá-la como ponto de partida para os repositórios do time.
4. Fazer do Constitution Check um portão real. Ligá-lo ao pipeline e ao fluxo de mudanças, com um verificador diferente do agente que implementa.
5. Fechar o ciclo. Usar a trilha de spec, plano e código como evidência e, a partir dela, revisar a constituição em versões.

Esse é o roteiro que faz sentido na escala de um time de desenvolvimento. Em organizações maiores, ele provavelmente precisa de mais etapas, como a integração com gestão de riscos corporativos, contratos com fornecedores e exigências setoriais.

Esse é um trabalho que fica no encontro entre governança de TI e engenharia de software, e é justamente onde eu atuo. Se a sua organização já tem agentes em uso e quer estruturar essa governança, do inventário à constituição dos repositórios, posso ajudar. É só me chamar para conversarmos.

Uma reflexão final

Durante anos discutimos se governança era freio ou acelerador. Com agentes, essa discussão perdeu o sentido. Sem governança não existe velocidade sustentável, só a velocidade até o primeiro incidente grave.

A autonomia de um agente deveria ser concedida aos poucos, na medida em que ele demonstra confiabilidade. É assim que fazemos com pessoas: ninguém recebe acesso de administrador no primeiro dia de trabalho. Com agentes, o raciocínio pode ser o mesmo: autonomia proporcional ao histórico de confiabilidade, ao impacto e à reversibilidade de cada ação.

Os agentes não vão pedir licença, nem às empresas nem aos países. Cabe a nós decidir, antes deles, o que podem fazer, quem responde por eles e como paramos quando algo sai do trilho.

E no seu time: quem é o dono dos agentes que estão rodando hoje?

Referências

• Bakkah (2026). ITIL AI Governance Version 5
• Brasil (2026). PL 2338/2023, ficha de tramitação na Câmara
• De Wet (2026). Strong doomer sentiment prevails at UN meeting on global AI regs, The Stack
• GitHub (2025). Spec Kit
• Global Knowledge (2026). ITIL (Version 5) AI Governance
• GZKit (2026). Comparativo de governança: Spec Kit, OpenSpec e BMAD
• ITSM.tools (2026). ITIL (Version 5) changes explained
• Menezes (2026). Skill de engenharia reversa com IA: dá para clonar o Spotify?
• Pascon (2026). Governança de inteligência artificial no Brasil, KPMG
• PeopleCert (2026). ITIL Experience (Version 5) e o papel da IA
• Poster (2026). Engenharia reversa com IA ameaça as assinaturas de software, Cartaz Comunicação
• ServiceNow (2026). Deployed but ungoverned: the state of agentic security
• Storytold (2026). PhotoCraft, repositório no GitHub
• TeamDynamix (2026). An introduction to the ITIL framework
• Wang (2026). Spec-driven development for AI agents, TrueFoundry