🧾 Código criado por agentes de IA: como provar a sua origem? (7/10)

O nome que aparece no histórico de um repositório já não chega para explicar a origem de uma alteração. Quando um agente de IA escreve código, outro o revê e um terceiro o coloca em produção, a questão relevante para uma auditoria deixa de ser apenas «quem escreveu isto?». É necessário demonstrar o que produziu a alteração, com que informação, ao abrigo de que regras, com autorização de quem e com que provas.

Este é o sétimo artigo da série «AI Governance in an AI-Native Software Development Company». O artigo anterior, sobre contenção, mostrou como retirar autoridade a um agente, delimitar os efeitos das suas ações e recuperar o estado do sistema. A rastreabilidade complementa esses mecanismos: permite reconstituir, depois do acontecimento, o que realmente ocorreu. Uma política que foi aplicada mas não pode ser demonstrada continua a ser uma afirmação; um incidente contido mas impossível de reconstituir fica reduzido a um relato.

Num processo de desenvolvimento em que intervêm agentes, a identidade de uma pessoa não é prova suficiente de autoria. O percurso completo da alteração tem de ser verificável.

Quando a assinatura de um commit deixa de contar a história toda

O modelo tradicional era relativamente simples. Um programador registava uma alteração, o commit tinha uma identidade assinada e era possível perguntar à pessoa por que motivo tomou aquela decisão. Num processo com agentes, pode haver vários intervenientes e uma relação menos direta entre intenção e resultado.

Uma pessoa define um objetivo. Um agente procura informação em várias fontes, chama um modelo, gera código, executa verificações e, por vezes, repete o processo. Outro agente confronta o resultado com um conjunto de políticas; um terceiro promove a alteração; um quarto observa a entrada em produção e decide se é necessário revertê-la. Cada etapa pode deixar provas, mas nenhuma fica automaticamente ligada às restantes.

Para avaliar este processo, a organização tem de conseguir recuperar a intenção original, o contexto consultado, o modelo e a sua versão, o prompt e a competência utilizados, as ferramentas invocadas e os seus argumentos, as políticas aplicadas e o resultado da avaliação. Também precisa de saber que provas surgiram em cada controlo, que intervenção foi autorizada por um humano e com que alcance, e quais foram os efeitos posteriores da alteração.

Não estamos perante nove registos independentes. Trata-se de uma cadeia contínua. Se uma ligação desaparecer, é precisamente nesse ponto que a reconstrução de um incidente contestado pode deixar de ser possível.

A cadeia de provas do trabalho realizado por agentes

Representação da cadeia de provas no trabalho dos agentes

A sequência começa na intenção, passa pela informação de contexto, pelo modelo, prompt e competência, pela ação, pelo parecer das políticas e pelo artefacto alterado. Prossegue através da implementação, dos efeitos observados durante a execução e das provas recolhidas. Cada passagem pode comprometer a ligação entre a causa e o resultado.

Os mecanismos necessários são conhecidos da engenharia de sistemas distribuídos:

• Identificadores de correlação estáveis. Cada intenção recebe um identificador que acompanha o trabalho por todos os serviços. Se um sistema o eliminar, deixa de ser possível relacionar com segurança os acontecimentos posteriores.
• Versões fixadas em cada etapa. São registados a versão do modelo, a impressão digital do prompt, a versão da competência, a versão do esquema da ferramenta e a impressão digital do conjunto de políticas. «Versão mais recente» não é uma resposta válida numa auditoria.
• Impressões digitais das entradas. Nem sempre é viável guardar tudo o que o agente leu. O hash criptográfico e uma referência à fonte permitem verificar, posteriormente, se determinado conteúdo foi efetivamente a entrada utilizada.
• Declarações assinadas em cada controlo. Cada avaliador identifica-se, regista o que analisou, a decisão que tomou e a versão das políticas aplicadas, assinando esse registo.
• Histórico apenas acrescentável. Uma prova não deve ser editada silenciosamente. Pode ser substituída por um novo registo, mas as versões anteriores têm de continuar disponíveis.

Estes elementos permitem reproduzir a análise, dificultam a negação de atos documentados e tornam visíveis as adulterações. Um histórico que não permita percorrer novamente os acontecimentos é apenas uma narrativa.

Registar a participação humana e a contribuição do agente

A frase «a IA escreveu uma parte» não é suficientemente precisa para responder a perguntas de clientes, equipas jurídicas ou responsáveis pela conformidade. Há situações distintas que o sistema deve representar: trabalho totalmente produzido pelo agente, com aprovação humana no ponto de controlo; rascunho criado pelo agente e editado por uma pessoa, conservando a diferença entre ambas as versões; texto ou código de autoria humana com sugestões do agente; implementação feita pelo agente a partir de especificações humanas; e produção integralmente humana.

A distinção pode ter implicações, consoante o caso, na propriedade intelectual, no licenciamento, nas garantias e nas obrigações aplicáveis a determinados setores. Por si só, uma categoria de autoria não determina qualquer conclusão jurídica. Mas a informação sobre quem contribuiu e de que forma tem de existir.

A solução prática é um campo estruturado e assinado, authorship, preenchido pelo próprio sistema responsável pelo trabalho quando este ocorre ou é publicado. Uma pessoa assinalar uma opção posteriormente não oferece a mesma qualidade de prova. Se os artefactos já exigem responsável, versão e origem, a autoria detalhada é uma extensão natural dessa disciplina.

Assinar os elementos que determinam o comportamento

Na produção tradicional de software, constrói-se um artefacto, calcula-se a sua impressão digital, assina-se o resultado e verifica-se, mais tarde, se o que foi entregue corresponde exatamente ao que foi construído. Com agentes, também é preciso assegurar a identidade das componentes que condicionam as suas decisões.

Devem ficar identificados e assinados: as competências, incluindo metadados, contrato e testes; os conjuntos de regras, com versão e âmbito; o prompt ativo, identificado por hash; as declarações de ferramentas e respetivas permissões; os conjuntos de políticas presentes no avaliador; e o modelo concreto, com a sua versão. As atualizações do modelo devem passar pelo processo de gestão de alterações, em vez de dependerem de uma mudança implícita do fornecedor.

Uma falha frequente ocorre quando alguém edita diretamente um prompt. A versão nova é utilizada sem registo explícito e, ao investigar a origem do código, o sistema aponta para um texto que entretanto deixou de existir. O procedimento adequado é fixar a impressão digital, assinar no momento de publicação e impedir a utilização de componentes não assinadas.

Das versões assinadas do software à identificação dos elementos que produzem o comportamento

A segurança da cadeia de fornecimento do software recorre a registos de dependências e de materiais utilizados numa versão. Os sistemas com agentes precisam de um equivalente relativo ao comportamento: uma lista exata dos modelos, prompts, competências, ferramentas, regras e políticas que produziram cada resultado, capturada no momento da produção. Não basta anexar uma lista de verificação no final. Se uma destas componentes puder mudar sem assinatura, a cadeia de auditoria deixa de ser fiável nesse ponto.

As provas têm de sobreviver à passagem entre sistemas

O quarto artigo da série defendeu a recolha de provas em cada fase de aplicação das políticas. Mas a ligação entre essas fases é igualmente importante. É na transferência de trabalho que se perdem dados de contexto, se geram novos identificadores, se deixam de fixar versões ou se removem assinaturas que o sistema seguinte não sabe verificar.

Em cada passagem, importa perguntar: o sistema de origem emite as provas necessárias? O destinatário valida-as? O identificador comum é preservado? A versão das políticas ao abrigo das quais a ação ocorreu continua disponível? Quando o processo passa para uma ferramenta externa, um fornecedor de modelos ou uma API de terceiros, a informação necessária para verificar as decisões fica registada num formato adequado?

Dentro da organização, podem reforçar-se os contratos entre serviços. Nas ligações externas, é preciso prever que o fornecedor não conserve as provas, substitua identificadores, repita ações silenciosamente ou devolva resultados que não possam ser associados a um pedido específico. Cabe ao lado responsável pela governação voltar a estabelecer a prova na fronteira, em vez de assumir que ela será transmitida sem perdas.

Rastreabilidade não significa vigiar permanentemente os engenheiros

Não é necessário gravar todas as teclas premidas por uma pessoa ou acompanhar a sua atividade minuto a minuto. Para reconstituir uma ação de um agente, interessa registar a intenção, os artefactos e políticas que influenciaram a decisão, os resultados dos controlos, as alterações introduzidas e os seus efeitos. Muitas vezes, o interveniente mais relevante é «agente X, segundo a política Y, para executar a intenção Z». Quando existe intervenção humana, o importante é a autorização concedida e os limites que definiu.

Há dois princípios essenciais. Recolher apenas as provas suficientes para explicar decisões, evitando a acumulação de informação sem utilidade demonstrada. E definir prazos de conservação limitados, tal como acontece com outros dados sensíveis. Guardar tudo indefinidamente não é um mérito. Um sistema de auditoria excessivamente intrusivo pode levar os próprios engenheiros a evitá-lo, prejudicando a confiança e a qualidade do histórico.

A rastreabilidade serve para reconstruir acontecimentos, não para observar pessoas.

Como reconhecer uma cadeia de rastreabilidade funcional

Uma organização deve conseguir relacionar qualquer alteração em produção com a intenção que lhe deu origem; recuperar a versão do modelo, o hash do prompt, a versão da competência e o conjunto de políticas envolvidos; consultar a autoria estruturada e assinada; e verificar que os registos se mantêm ligados entre os serviços internos e são restabelecidos nas fronteiras externas. As provas devem ser assinadas, apenas acrescentáveis e verificáveis através das suas impressões digitais.

Também deve ser possível responder com factos concretos à pergunta: «o que mudou no comportamento deste agente nos últimos 30 dias?». A explicação produzida pela auditoria tem de coincidir com a explicação técnica que a equipa consegue verificar.

Os sinais de alerta são igualmente claros: uma alteração atribuída a uma pessoa que apenas aprovou trabalho do agente; prompts modificados sem hash registado; atualizações de modelo sem referência de versão; muitos registos dispersos mas nenhuma ligação entre eles; ou respostas diferentes sempre que a equipa jurídica repete a mesma pergunta. Se a resposta depende de quem a conta, faltam provas articuladas.

Falhas típicas numa cadeia interrompida

Perda de identificadores: o segundo serviço abandona o identificador comum, isolando todos os registos posteriores. Desaparecimento de versões: sabe-se que houve uma alteração, mas não qual o modelo, prompt ou conjunto de políticas que a produziu. Prompts mutáveis: o resultado final está assinado, mas a entrada já foi editada. Autoria atribuída por defeito: o humano que aprovou surge como autor de todo o código gerado. Ausência de prova externa: os registos terminam na primeira ferramenta de terceiros. Auditoria por capturas de ecrã: a equipa tenta reconstruir o acontecimento recorrendo à memória, às conversas e a imagens parciais.

Comparação entre uma cadeia completa e outra com ligações perdidas

Todas estas falhas resultam de uma suposição errada: esperar que os vários registos formem espontaneamente um percurso coerente. Isso não acontece.

Uma obrigação de engenharia desde o início

O modelo tradicional de auditoria dependia muitas vezes de uma equipa pedir informação e da engenharia exportar registos, procurando explicar retrospetivamente o que tinha ocorrido. Com agentes, tal procedimento falha por razões estruturais: não é possível recuperar uma versão de modelo, um hash de prompt ou um identificador que nunca foi capturado no momento da ação.

A rastreabilidade tem, por isso, de fazer parte da arquitetura. Os mecanismos não são novos: os identificadores correspondem ao rastreio distribuído, as declarações assinadas aproximam-se das versões de software assinadas, os registos apenas acrescentáveis são um histórico de eventos e as impressões digitais permitem identificar conteúdo. A organização deve integrar estes elementos no processo de desenvolvimento, como faz com registos estruturados e compilações reproduzíveis, em vez de os tentar reunir num relatório posterior.

Por onde começar

1. Definir a cadeia necessária. Começar pelas questões concretas dos clientes, da equipa jurídica, dos responsáveis pela conformidade e dos reguladores. Trabalhar a partir das respostas exigidas, sem tentar recolher tudo.
2. Instrumentar um processo importante do princípio ao fim. A alteração de código criada por um agente, revista e colocada em produção é um bom exemplo. Acompanhar o percurso desde a intenção até ao efeito observado.
3. Tornar o identificador comum parte do contrato. Criá-lo na origem, propagá-lo por todos os serviços e validá-lo em cada passagem. A sua perda é um defeito.
4. Fixar versões e assinar os elementos comportamentais. Identificar prompts por hash, competências por versão, modelos por referência precisa e conjuntos de políticas por impressão digital.
5. Registar a autoria nos artefactos. Exigir um campo authorship estruturado, com várias categorias de participação, assinado e produzido pelo sistema na publicação.
6. Definir explicitamente as fronteiras. Criar contratos internos e voltar a estabelecer as provas nas integrações externas, indicando onde existe dependência de terceiros.
7. Testar com uma pergunta real. Escolher uma alteração recente e descobrir o que a produziu, com autorização de quem e de acordo com que política. Se a resposta demora vários minutos a ser reunida, a cadeia ainda não suporta uma auditoria exigente.

Conclusão

Numa plataforma de desenvolvimento com agentes, a auditoria deixa de ser apenas documentação preparada para um prazo e passa a ser uma capacidade técnica. A cadeia de provas deve ser concebida antes de o primeiro agente colocar alterações em produção. Já não liga somente uma pessoa à seguinte: liga a intenção ao resultado, atravessando agentes, modelos, prompts, competências, políticas, controlos e ambientes de execução. A sua solidez depende da ligação mais fraca.

Existe, porém, um limite incontornável. A rastreabilidade não consegue explicar uma alteração que o sistema nunca observou. Se o modelo for substituído por trás de um nome estável, se um prompt for editado sem registo ou se uma competência passar a disponibilizar mais uma ferramenta sem declaração, nada disso entra automaticamente na cadeia. As mudanças nas capacidades dos agentes também têm de estar sujeitas à governação. Ter muitas políticas sem conseguir provar o que aconteceu em produção é insuficiente.

O próximo artigo, o plano de gestão de alterações dos agentes, abordará a forma de tratar estas mudanças como verdadeiras implementações, com registo de versões, lançamento gradual, comunicação e possibilidade de reversão.

Publicado originalmente por Reza Arani no Medium em 4 de junho de 2026. Adaptado para a Aipolix como sétimo artigo da série.

Fontes

• Artigo original de Reza Arani no Medium