Agentes viraram autores de mudanças em produção. Seu processo de mudança agora governa os agentes

Olhe o que os agentes enterprise entregaram na última semana e aparece um padrão que tem pouco a ver com chat. O Autonomous Engineer da ServiceNow planeja, constrói e testa mudanças de workflow. O agente de EKS para GKE do Google traduz manifestos Kubernetes e os propõe via GitOps. O desenho de migração da AWS gera código de infraestrutura a partir de módulos aprovados. Nos três casos, a saída do agente é o mesmo tipo de objeto: uma mudança num sistema em produção.

Isso importa porque as empresas já têm um controle maduro para mudanças em produção. É antigo, pouco glamoroso e auditado todo ano. A nossa leitura, e é uma leitura, não um fato, é que a gestão de mudanças vai virar o principal lugar onde a autonomia dos agentes é governada, e que a maioria das empresas chega lá mais rápido estendendo o processo que já tem do que inventando um processo específico para IA.

Os sinais

• Mudanças de workflow. O AI Workflow Factory da ServiceNow junta process mining, construção por agentes e deploy num loop, com o Autonomous Engineer (em Early Access) programando sem supervisão.
• Mudanças de infraestrutura. O agente de migração de EKS para GKE do Google (em Public Preview) coloca portões de aprovação e GitOps entre o agente e o cluster. A arquitetura de migração da AWS tem um agente que monta código de infraestrutura com módulos aprovados.
• Mudanças no próprio agente. Trocar o modelo muda o comportamento sem mudar uma linha de código, e por isso dissemos que aposentar um modelo é a nova depreciação de API.
• Apps que ninguém codificou à mão. Plataformas como o Copilot Managed Runtime rodam aplicações geradas a partir de linguagem natural, que continuam precisando de um processo de release.

O que muda quando o autor é um agente

Os processos de mudança foram desenhados para autores escassos. Um time produzia um número administrável de mudanças, e o comitê de mudanças conseguia olhar as arriscadas. Agentes acabam com a escassez. Quando um agente consegue propor vinte melhorias de workflow por semana, três coisas quebram:

1. Volume. Revisão humana de toda mudança não escala, e aprovar no automático é pior do que não revisar.
2. Atribuição. “Autor: svc-automacao” não diz qual agente, qual versão, qual modelo, nem quem pediu.
3. Segregação de funções. Se o agente da mesma plataforma escreve, testa e promove a mudança, o controle que separa autor de aprovador sumiu sem ninguém perceber.

Um registro de mudança para trabalho feito por agente

1. Autor: ID do agente, versão, modelo
2. Patrocinador: a pessoa que pediu
3. Escopo: sistemas e dados afetados
4. Evidência: testes e checagens
5. Aprovador: outra identidade
6. Rollback: plano e gatilho

Registrado pela plataformaPessoas com nome

Depois, use as categorias de mudança que o seu time de TI já conhece do ITIL para decidir onde entra a autonomia:

• Mudanças padrão são pré-aprovadas, de baixo risco e repetíveis. É aqui que um agente pode agir sozinho depois de ter histórico, por exemplo aplicando um template já testado ao workflow de uma nova área. A escada do nosso framework de autonomia conquistada vale direto: uma classe de mudança só vira “padrão” para um agente com evidência.
• Mudanças normais precisam de avaliação e aprovação. Agentes podem ser autores, mas a evidência (testes, checagens de política, análise de impacto) tem de vir do pipeline, não da descrição do agente, e o aprovador tem de ser outra identidade, pessoa ou motor de políticas.
• Mudanças emergenciais continuam humanas. O agente pode diagnosticar e propor, mas a decisão de pular a aprovação normal é de uma pessoa que responde por ela.

A resposta ao volume não é um comitê maior. É levar a evidência para o pipeline (testes automatizados, política como código, execuções comparativas) para que as pessoas revisem a decisão, não o diff.

Por que a auditoria vai chegar primeiro

Empresas brasileiras com ADRs em Nova York respondem aos controles gerais de TI da SOX, e gestão de mudanças em programas é um dos domínios centrais. Bancos e seguradoras passam pelo mesmo escrutínio na auditoria interna e nos supervisores. Um auditor que amostra mudanças num workflow financeiro vai perguntar quem escreveu, quem aprovou e qual teste sustentou a aprovação. “Foi o agente” não é uma resposta que o framework de controles reconhece; “agente X versão Y, pedido pela pessoa A, aprovado pela pessoa B depois do teste Z” é. Nossa expectativa é que, em um ano, a autoria por agente vire um campo padrão nas amostras de auditoria.

O que fazer agora

1. Inclua campos de autoria por agente nos registros de mudança: identidade, versão e modelo, e a pessoa patrocinadora.
2. Exija uma identidade aprovadora diferente em toda mudança normal escrita por agente.
3. Defina quais classes de mudança um agente pode tratar como padrão, e exija evidência para incluir cada uma.
4. Leve a evidência para o pipeline para que a aprovação olhe resultados, não descrições.
5. Trate atualização de modelo e de prompt como mudança no próprio agente, com o mesmo registro.
6. Acompanhe à parte, por seis meses, as mudanças feitas por agentes, com taxa de falha e de rollback, antes de dar mais autonomia.

Para fechar

A pergunta de governança para agentes que escrevem mudanças em produção tem uma resposta antiga: gestão de mudanças. Estenda o processo com autoria por agente, mantenha autor e aprovador separados e deixe a evidência do pipeline decidir que tipo de mudança um agente pode fazer sozinho.