Artigo propõe 'caixa-preta' ancorada em blockchain para auditar agentes de IA após incidente OpenAI/Hugging Face
Um paper de posicionamento e arquitetura propõe um modelo neutro de fornecedor para registrar, com ancoragem criptográfica em blockchain, comunicações entre agentes de IA, chamadas de ferramentas, aprovações humanas e artefatos de processo, sem colocar conteúdo sensível on-chain. A motivação declarada é um incidente de 2026 envolvendo OpenAI e Hugging Face, e o objetivo é dar suporte a reconstrução de incidentes, auditorias de GRC e conformidade com EU AI Act, NIS2 e o Cyber Resilience Act.
O artigo parte de um problema que já é familiar a quem trabalha com forense digital tradicional, mas aplicado a um domínio novo: agentes de IA autônomos que conversam entre si, chamam ferramentas, trocam resultados intermediários e pedem aprovação humana geram um rastro de decisões que, na maioria dos sistemas atuais, não é capturado de forma íntegra e verificável. Quando algo dá errado — como no incidente de 2026 envolvendo OpenAI e Hugging Face citado como motivação central do trabalho — a organização precisa reconstruir quem fez o quê, quando, sob qual política, e se os registros foram alterados depois do fato. Essa é exatamente a pergunta que uma cadeia de custódia responde em uma investigação convencional, só que agora aplicada a logs de agentes de IA.
A proposta técnica é uma arquitetura de "caixa-preta" para processos agênticos: em vez de armazenar o conteúdo completo das interações em blockchain (o que seria inviável em custo, escala e privacidade), o sistema gera compromissos criptográficos (commitments/hashes) de comunicações selecionadas entre agentes, de aprovações humanas no loop, de chamadas de ferramentas e de artefatos de processo, e ancora apenas esses compromissos na blockchain. O conteúdo sensível permanece fora da cadeia, mas qualquer alteração posterior nos registros originais quebra a correspondência com o compromisso ancorado, evidenciando adulteração — o mesmo princípio de hashing usado para preservar integridade de evidência em uma coleta forense tradicional, aplicado a eventos de software.
Os autores diferenciam explicitamente duas camadas de garantia: as propriedades "fundamentais", que a ancoragem por si só entrega (marcação temporal e integridade do artefato, ou seja, prova de que aquele registro existia naquele estado em determinado momento), e propriedades "adicionais" que exigem controles arquiteturais extras, como ordenação confiável de eventos, autenticidade da captura na origem, autorização de quem pode ancorar e rastreabilidade causal entre eventos. Essa distinção é importante porque evita a promessa exagerada comum em soluções baseadas em blockchain: os autores deixam claro que o mecanismo não impede o mau comportamento de um agente nem prova verdade semântica do conteúdo, apenas fortalece a base evidencial para verificação posterior.
O artigo é explicitamente um trabalho de posicionamento e arquitetura, sem avaliação empírica de desempenho ou segurança, o que limita seu peso como prova de conceito validada, mas o framing é relevante justamente pelo ângulo regulatório: os autores conectam a proposta a exigências de trilha de auditoria sob o EU AI Act, a NIS2 e o Cyber Resilience Act, argumentando que reconstrução de incidentes e testes de conformidade em GRC vão exigir esse tipo de evidência à medida que agentes autônomos ganham autonomia operacional em ambientes corporativos.
Para quem faz resposta a incidentes, o valor prático está em antecipar um problema que já apareceu no caso citado: sistemas multiagente sem trilha de auditoria à prova de adulteração tornam a reconstrução pós-incidente dependente de logs que o próprio sistema comprometido pode ter alterado. Uma camada de evidência ancorada externamente, mesmo que rudimentar, muda a pergunta de "confiamos no log?" para "o log bate com o compromisso ancorado?", o que é precisamente o tipo de garantia que sustenta cadeia de custódia em perícias envolvendo logs e timelines.