Que rastro de auditoria um agente de IA precisa deixar?

Um auditor interno faz uma pergunta simples à equipe de operações: por que alguém reiniciou a tarefa de liquidação de pagamentos noturnos às 2h47 da manhã? O registro do agendador mostra uma reinicialização. O chamado indica "reexecução conforme recomendação da IA". Ninguém sabe dizer o que o agente de IA viu, o que ele tinha permissão para fazer ou quem aprovou a ação.

Resposta curta: Um agente de IA deve deixar um registro de auditoria que permita reconstruir a decisão completa, e não apenas o comando. Esse registro deve mostrar qual agente e quais pessoas estiveram envolvidas, qual contexto e evidências fundamentaram a recomendação, qual autoridade o agente possuía, quem aprovou a ação, exatamente o que foi executado e o que aconteceu depois.

Este artigo descreve a estrutura de oito partes proposta pela Rocket Software para esse registro. Ele também inclui um exemplo de registro de auditoria de um incidente real em um mainframe em lote, que você pode adaptar ao seu próprio ambiente.
 

O que é um registro de auditoria de um agente de IA?

O registro de auditoria de um agente de IA é a evidência que conecta a recomendação de um agente de IA à autoridade, aprovação, ação e resultado subjacentes. Use esta definição como ponto de partida:

Um registro de auditoria de um agente de IA é um documento cronológico e inviolável que vincula a identidade do agente, o contexto e as evidências de decisão que ele utilizou, a recomendação que fez, a autoridade que possuía, a aprovação humana que recebeu, a ação autorizada que executou e o resultado validado. Ele permite que um auditor, operador ou equipe de risco reconstrua quem fez o quê, por quê e com a permissão de quem.

A palavra-chave é "links". A maior parte dessas informações já existe em algum lugar no seu ambiente. O registro de auditoria do agente de IA as conecta, para que ninguém precise reconstruir a história a partir de cinco ferramentas diferentes posteriormente.
 

Por que os registros de sistema tradicionais não são suficientes para IA agente?

Os registros de sistema tradicionais registram eventos. Eles não registram decisões. Um registro pode mostrar que um ID de usuário emitiu um comando em um momento específico. Ele não pode mostrar por que um agente de IA recomendou esse comando, quais evidências o sustentaram ou se uma pessoa com a função adequada o aprovou.

Os registros do sistema são necessários, mas insuficientes. Você ainda precisa dos registros do System Management Facilities (SMF), dos registros de tarefas, dos registros do console e dos registros de segurança, pois eles comprovam o que aconteceu no nível do sistema. Mas um agente de IA adiciona uma nova camada de tomada de decisão entre o alerta e o comando. Se o seu registro de auditoria ignorar essa camada, "a IA fez isso" se torna a única explicação que você pode oferecer.

Eis como os dois registros diferem:

Os líderes já consideram essa lacuna um obstáculo à produção. Em um estudo da Rocket Software e da Hanover Research, realizado em junho de 2026 com 250 líderes de TI do setor de serviços financeiros, 46% afirmaram precisar de controles de governança robustos e fluxos de aprovação antes de confiar na IA em produção para diagnósticos operacionais. Outros 43% queriam precisão comprovada e validada com base em incidentes históricos. Os entrevistados também citaram a falta de explicabilidade e auditabilidade entre suas principais preocupações em relação à IA ativa em operações regulamentadas.

A IDC relata um padrão semelhante. Segundo a IDC, os primeiros usuários de IA agente citam consistentemente a visibilidade para fins de conformidade e auditoria como um desafio. A IDC também observa que a construção da confiança depende do rastreamento de insights, ações e resultados por meio de registros, trilhas de auditoria e políticas claras para supervisão humana.

O registro de auditoria de IA deve capturar o raciocínio do agente?

Uma trilha de auditoria de IA deve capturar as evidências da decisão do agente e a justificativa declarada, não a cadeia de raciocínio oculta do modelo. Os auditores precisam verificar em que o agente se baseou e a que concluiu. Eles não precisam, e geralmente não conseguem obter de forma confiável, o processo interno token por token de um modelo de linguagem complexo.

Concentre-se no que é observável e verificável:

• Entradas: as fontes de dados e os registros recuperados pelo agente.
• Evidências: os sinais específicos citados, como um código de erro ou uma espera de bloqueio.
• Recomendação: a ação proposta.
• Justificativa: a explicação em linguagem simples que forneceu ao operador.
• Incerteza: o que não pôde ser confirmado e quaisquer evidências conflitantes.

Um revisor pode testar esse registro. Ele pode abrir o mesmo log de trabalho, confirmar o mesmo código de erro e avaliar se a recomendação foi baseada nas evidências. Essa é uma base mais sólida para responsabilização do que um mero despejo de justificativas obscuras.

Como a aprovação humana deve aparecer no registro de auditoria?

A aprovação humana deve aparecer como uma etapa separada e atribuível entre a recomendação do agente e a ação executada. O registro deve tornar a sequência impossível de ser mal interpretada:

1. O agente A recomendou uma ação específica, com evidências anexadas.
2. A Pessoa B aprovou essa ação específica, sob sua própria identidade e função.
3. O agente A executou a ação aprovada, dentro do seu âmbito de atuação autorizado.
4. O Sistema C registrou o resultado e os resultados da validação.

Cada etapa precisa de sua própria identidade e registro de data e hora. Se a Pessoa B aprovou "reiniciar a partir da ETAPA 040" e o agente executou "reiniciar a partir da ETAPA 010", o registro deve sinalizar a incompatibilidade automaticamente.

Essa sequência também corresponde a níveis graduais de autoridade da IA: Observar, Recomendar, Agir com Aprovação e Agir de Forma Autônoma. A maioria das ações de produção com consequências significativas se enquadra no nível Agir com Aprovação. O registro de auditoria comprova qual nível foi aplicado a cada ação.  

O que torna um registro de auditoria de IA defensável?

Um registro de auditoria de IA defensável é completo, atribuível e à prova de adulteração. Se alguém o contestar seis meses depois, ele deverá se manter válido sem depender da memória de ninguém.

Verifique seu histórico de auditoria em relação a estes critérios:

• Atribuição: Cada entrada está vinculada a um agente ou identidade humana única, nunca a uma conta compartilhada.
• Integridade: Os registros não podem ser alterados sem serem detectados. O uso de hash ou assinatura eletrônica garante isso.
• Imutabilidade: Grave o registro imutável em um armazenamento que agentes e operadores não possam editar ou excluir.
• Marcação de tempo: Utilize fontes de tempo confiáveis ​​e sincronizadas em sistemas mainframe, distribuídos e em nuvem.
• Escopo: O registro mostra os limites da política e as permissões em vigor no momento da decisão, não as configurações atuais.
• Rastreabilidade: Um revisor pode acompanhar um único passo desde o incidente até a evidência, recomendação, aprovação, ação e resultado.
• Retenção: Mantenha os registros de acordo com os requisitos legais, regulamentares e organizacionais aplicáveis.

Os períodos de retenção variam de acordo com o setor, a jurisdição e o tipo de registro. Suas equipes de compliance, jurídica e de gestão de riscos devem defini-los.

Como é o registro de auditoria de IA durante um incidente em lote no mainframe?

Um registro de auditoria de IA útil se assemelha a um breve relato de incidente verificável. Veja como deve ser o reinício da tarefa de liquidação às 2h47 da manhã, a partir do cenário inicial.

Cenário: O job de liquidação de pagamentos noturno, PAYSETL01, é interrompido na etapa 040 com o código de erro Db2^® SQLCODE -911. Uma transação online do Sistema de Controle de Informações do Cliente (CICS) ultrapassou seu tempo limite normal e manteve bloqueios na tabela de liquidação. Um agente de IA investiga, identifica o conflito de bloqueio e recomenda uma reinicialização assim que o bloqueio for liberado. O operador de plantão reporta o problema ao líder de operações em lote, que aprova a recomendação.

Observe o que este registro faz. Um auditor pode verificar cada alegação sem precisar ligar para ninguém. O operador pode ver por que o agente fez a ligação. A equipe de desenvolvimento recebe um acompanhamento claro, em vez de um mistério.

Onde se encaixa o Rocket EVA ?

Rocket^® EVA^™ É ideal para equipes operacionais que precisam de diagnósticos assistidos por IA, que geram evidências que um humano pode revisar antes de qualquer alteração na produção.

Segundo a IDC, o Rocket EVA permite que operadores de TI e desenvolvedores façam perguntas em linguagem natural e recebam recomendações sobre o status de incidentes, dependências e correlações de causas raiz em diversas fontes, como IBM Db2^®, SMF, TMON/SDSF e dados do gerenciador de cargas de trabalho. A IDC também observa que o Rocket EVA se integra a sistemas de tickets como o Jira, o que ajuda a conectar uma recomendação ao registro do incidente e à forma como sua organização resolveu problemas semelhantes anteriormente.

Isso se relaciona diretamente aos elementos Contexto, Evidência e Recomendação da estrutura. Quando uma recomendação chega com os sinais de suporte anexados, os operadores podem validá-la e os auditores podem rastreá-la posteriormente. Também ajuda os funcionários menos experientes a conduzirem uma investigação enquanto os especialistas em mainframe mantêm o controle das decisões que exigem muita análise.

Para os elementos de Identidade, Autoridade, Aprovação Humana e Ação, confirme as funcionalidades atuais com a documentação oficial da Rocket Software. O objetivo permanece o mesmo em ambos os casos: diagnósticos mais precisos e ações controladas sobre os sistemas que você já utiliza, sem interromper os processos nos quais suas equipes confiam.