O crescimento das ferramentas de desenvolvimento agentico, que confiam a agentes de IA a preparação de alterações de código, coloca a questão da auditabilidade dos workflows. Nos setores regulamentados, saber quem aprovou uma alteração já não basta: é necessário poder reconstituir o contexto, os controlos e as decisões que a produziram.
Dentro de uma grande instituição financeira que utiliza um agente no seu workflow de desenvolvimento, a equipa de auditoria interna e conformidade colocou uma questão específica. Para uma merge request (uma solicitação de fusão de código) aberta por um agente para atualizar uma dependência de um serviço de pagamento, seria possível indicar quem a tinha aprovado, que dados de entrada e que prompts o agente tinha utilizado, que controlos de política tinham sido avaliados e como reproduzir ou anular essa tarefa? A equipa não tinha resposta. O sistema de entrega não considerava o trabalho do agente como uma transação delimitada e auditável.
Um diff validado pela CI (a integração contínua, que testa automaticamente o código) e aprovado prova que uma alteração ocorreu. Não prova, no entanto, o contexto utilizado pelo agente, as decisões de política avaliadas antes da criação da merge request, nem a possibilidade de reproduzir o resultado numa execução posterior. Ora, nos ambientes regulamentados, o « como » e o « porquê » são essenciais. Esta situação verifica-se em todas as plataformas e nas organizações DevSecOps: o orçamento para as ferramentas agenticas é validado em poucas semanas, enquanto o dos registos de execução, da vinculação de identidade e das ferramentas de reexecução nunca aparece ou é tratado como um simples custo de conformidade.
Quatro exceções recorrentes
Assim que os agentes abrem merge requests num ambiente CI/CD regulamentado, surgem quatro tipos de exceções de conformidade. A primeira é a proveniência ausente: ninguém consegue dizer que dados o agente utilizou, sejam as especificações, o contexto recuperado, as chamadas de ferramentas ou o estado do repositório. A segunda é a atribuição de identidade incerta, uma vez que o agente agiu sob um token de serviço partilhado, sem um responsável humano designado. A terceira é uma cadeia de decisão não reconstituível, o raciocínio tendo sido capturado apenas de forma efémera. A quarta é o retrocesso não delimitado: as alterações do agente estando acopladas, qualquer anulação torna-se um trabalho manual através dos commits e dos repositórios.
A reconstrução a posteriori consiste em examinar os logs de conversação, as saídas parciais da CI e os rastos do agente ainda disponíveis. Na maioria das organizações, ninguém contabiliza as horas dedicadas semanalmente a esta tarefa, o que explica que o seu custo permaneça invisível. A fonte propõe um teste simples: uma equipa é capaz de produzir em menos de uma hora um dossiê de provas reunindo as especificações da tarefa, o estado do repositório, os controlos avaliados e o responsável humano na origem da ação?
« Entregar primeiro » e os seus limites
A estratégia « Entregar primeiro, governar depois » pode funcionar quando os agentes estão confinados a perímetros restritos, como a geração de testes, pequenas reestruturações ou a atualização de documentação, com uma revisão humana sólida. Fractura-se, no entanto, quando as equipas se libertam destas restrições, as bibliotecas de prompts se multiplicam com uma registo inconsistente e os tokens partilhados tornam a atribuição impossível à escala do portefólio. O artigo cita também o caso de uma grande empresa que quis construir uma base de workflow antes de generalizar os agentes: o projeto de plataforma estendeu-se por vários trimestres, e as equipas acabaram por contorná-lo.
O artigo sublinha que « a pressão competitiva recompensa a velocidade, enquanto os reguladores recompensam a capacidade de reconstituição ». Descreve o custo deste desfasamento: provas ausentes descobertas durante um controlo, remediação de várias semanas e raio de impacto que se alarga a cada ação de agente mal registada. Cita a este propósito o Crédit Agricole CIB, que pilota, segundo o texto, uma entrega reunindo milhares de programadores distribuídos por dezenas de países numa única plataforma DevSecOps, condição necessária para auditar o trabalho agentico.
Nomear e medir o trabalho
A fonte recomenda tratar este projeto como um produto a sério, batizado « Execução registada para o CI/CD agentico », com recursos que reúnam engenharia de plataforma, segurança, auditoria e experiência de programador. Os seus entregáveis abrangem um esquema de registo que captura dados de entrada, saídas, chamadas de ferramentas e versão do modelo, uma vinculação de identidade que associa cada ação a um responsável humano, logs de decisões de política, bem como mecanismos de reexecução e retrocesso. O acompanhamento pode basear-se na profundidade da fila de exceções, no tempo médio para obtenção de provas, na taxa de sucesso das reexecuções e na taxa de reabertura das exceções.
Se apenas uma etapa tiver de ser ultrapassada, o texto aconselha a começar pelos casos de maior risco, como as alterações de dependências, as modificações de Infrastructure as Code e a configuração de segurança. O último teste proposto consiste em pedir a uma equipa que anule limparmente uma alteração fundida redigida por um agente, baseando-se apenas em artefactos registados.
