Agentes de IA verificáveis: por que a confiança empresarial exige rastreabilidade de grau blockchain

Nos últimos dezoito meses, vi conselhos em finanças, energia, governo e saúde lidando com a mesma pergunta. Sabem que agentes de IA podem comprimir prazos, reduzir custos e estender a capacidade humana. O que não sabem é como responder ao seu auditor, ao regulador ou ao conselho quando algo dá errado e a pergunta é: 'Quem autorizou essa decisão, que informação o agente usou, e você pode provar?'.

A autonomia está correndo mais do que o accountability

Toda onda tecnológica séria das últimas duas décadas — cloud, mobile, SaaS, open banking — eventualmente chegou ao mesmo ponto de inflexão. A tecnologia funcionava. As empresas adotavam. E então a pergunta virava: quem é responsável? Não no sentido moral, mas legal, auditável, reconstruível. Cloud teve SOC 2 e ISO 27001. Mobile teve revisão de app stores. Pagamentos teve PCI DSS. Cada uma só escalou para nível enterprise quando o framework de accountability alcançou a tecnologia.

Os agentes autônomos de IA estão agora nesse ponto de inflexão — e o framework de accountability não alcançou. Um agente que lê um contrato, propõe uma ação financeira ou triaga um caso de suporte está tomando decisões. Se essas decisões estiverem erradas, alguém carrega o custo. Hoje, quando perguntamos 'como o agente decidiu?' a resposta honesta geralmente é 'temos um arquivo de log, provavelmente, se não foi rotacionado'. Isso não é uma resposta que um auditor aceite. Não é uma resposta que o EU AI Act aceite quando sistemas de alto risco caem sob seu escopo. E não é uma resposta que um conselho deva aceitar.

O que 'verificável' significa de fato?

Um agente de IA verificável é aquele para o qual qualquer terceiro autorizado — auditor interno, regulador, cliente — consegue responder três perguntas com evidência criptográfica, não com a palavra do fornecedor:

• Identidade — Qual agente tomou essa ação, em nome de quem, com qual autoridade delegada? Não um nome de serviço em uma linha de log, mas uma credencial assinada e revogável que amarra a ação a uma identidade autorizada.
• Proveniência — Quais inputs o agente usou? Qual versão de modelo, qual contexto, quais ferramentas, quais fontes de dados? O 'bill of materials' de cada decisão.
• Trilha de ação — O que exatamente o agente fez, em que ordem, com que resultados? Não o resumo do happy path, mas a sequência completa de chamadas a ferramentas, raciocínio intermediário e transições de estado.
• Integridade — O registro foi alterado desde que a ação ocorreu? É aqui que os bancos de dados tradicionais falham: quem os administra pode reescrever a história. Um sistema verificável torna a alteração detectável por design.

Nenhum desses é conceito novo. Temos construído trilhas de auditoria para bancos, aviação e ensaios clínicos há décadas. O novo é a combinação: os agentes agem mais rápido e em volume maior que humanos; seu raciocínio é probabilístico; e invocam ferramentas em dezenas de sistemas em segundos. O substrato de auditoria precisa acompanhar.

Por que blockchain é o substrato certo — e quando não é

Vou ser direto: não acredito que blockchain seja a resposta para a maioria dos problemas. Fernando Boiero escreveu uma comparação honesta de quando um banco de dados supera um ledger, e concordo com cada palavra. Mas o caso de uso de agentes verificáveis é exatamente onde as propriedades da blockchain se alinham ao problema.

Uma blockchain — permissioned ou pública — fornece três propriedades simultâneas que nenhum sistema centralizado fornece juntas: uma fonte compartilhada de verdade que nenhuma parte sozinha pode reescrever, uma trilha de auditoria criptográfica que terceiros podem verificar sem acesso ao banco subjacente, e um mecanismo nativo de identidade assinada e delegação. Para governança de agentes, essas três propriedades são exatamente o que falta.

Na prática, você não precisa — nem deve — colocar conversas cruas de agentes on-chain. Seria caro, destruidor de privacidade e tecnicamente desnecessário. O que você coloca on-chain é um conjunto de atestações: hashes dos inputs, outputs e transições de estado de cada ação significativa do agente, assinados com a chave de identidade do agente e ancorados com um timestamp verificável. Os dados crus ficam no seu armazenamento seguro. A prova do que aconteceu, quando e por quem vive em um ledger que qualquer autorizado pode auditar.

O quadro regulatório está se movendo rápido

Da minha posição como advogado e CEO de uma empresa que opera na Europa, LATAM e Estados Unidos, posso dizer que a trajetória regulatória é inconfundível. Três frameworks são os que mais pesam agora.

O EU AI Act, já em vigor, exige que sistemas de IA de alto risco mantenham logs que permitam rastreabilidade durante todo o ciclo de vida, incluindo quem usou o sistema e que outputs produziu. Para agentes autônomos operando sobre dados regulados, o espírito da lei é claro: você precisa poder reconstruir decisões sob auditoria. A ISO/IEC 42001, primeiro padrão de sistema de gestão para IA, formaliza os processos de governança que as organizações devem implementar — incluindo identidade documentada, accountability e gestão de mudanças para sistemas de IA. O NIST AI RMF, referência de fato na América do Norte, faz essencialmente as mesmas perguntas por uma lente de gestão de risco.

Na América Latina vemos movimento no Brasil com o PL da IA em discussão, na Argentina com orientação setorial do BCRA e da CNV, e no México e Chile com frameworks que ecoam a abordagem europeia. As especificidades regionais variam. A demanda central — que decisões automatizadas sejam rastreáveis, explicáveis e auditáveis — não.

Aqui está a parte que a maioria dos times de liderança perde: os reguladores não estão pedindo um novo relatório de compliance. Estão pedindo uma propriedade de sistema. Um sistema construído para ser verificável desde o dia zero produz os artefatos de compliance como subproduto da operação. Um que não é, precisa gerar esses artefatos depois do fato, frequentemente de forma imperfeita, com custo recorrente. A diferença se acumula.

Como abordamos isso na Xcapit

Nossa posição é simples: todo agente que colocamos em produção carrega sua accountability consigo. Isso significa três coisas por padrão.

Primeiro, todo agente tem uma identidade criptográfica emitida no deployment. Quando um agente invoca uma ferramenta, chama outro agente ou grava em um sistema de registro, essa ação é assinada com a chave do agente e amarrada ao humano ou organização que a autorizou. Não é teórico — é como nosso framework multi-agente ArgenTor gerencia delegação e por isso nossa plataforma de revisão de segurança AiSec pode dizer ao cliente não só 'o achado existe' mas 'este agente específico, com esta versão específica de modelo, produziu este achado neste timestamp, e aqui está a cadeia de evidências'.

Segundo, toda ação significativa gera uma atestação assinada — um registro pequeno e estruturado, hashado e ancorado em uma timeline verificável. Para clientes regulados, essa timeline é uma blockchain permissioned que eles cogovernam. Para outros, é uma âncora pública que preserva integridade sem divulgar dados. De qualquer forma, a história de auditoria é a mesma: os dados crus ficam privados, a prova é verificável de forma independente.

Terceiro, e aqui a lente legal importa: tratamos verificabilidade como contratual. Se uma empresa vai aceitar decisões de agentes dentro de um processo regulado, as propriedades de verificabilidade são escritas no acordo, não prometidas em um pitch deck. A mesma disciplina que trazemos a addenda de tratamento de dados e schedules de segurança se aplica à governança de agentes.

O que os times de liderança deveriam estar fazendo agora

• Parem de tratar 'governança de IA' como um documento de política. É um conjunto de propriedades de sistema que ou existem no seu stack ou não. Uma política que referencia capacidades que sua tecnologia não tem é pior que não ter política — é exposição.
• Exijam que seus fornecedores respondam as três perguntas. Antes que um agente toque um fluxo regulado, peçam ao fornecedor para demonstrar identidade, proveniência e trilha de ação com evidência verificável por terceiros. Se não puderem, vocês estão herdando o risco deles.
• Invistam em verificabilidade como plataforma, não por projeto. As organizações que ganharem a próxima década terão uma única fábrica de accountability sob todos os seus agentes, não quarenta esquemas de logging isolados.
• Alinhem os times legais, de risco e de tecnologia cedo. Agentes verificáveis são uma questão de governança tanto quanto de engenharia. As empresas que fazem isso certo têm seu general counsel, CISO e CTO na mesma conversa — não sequenciados ao longo de trimestres.
• Tratem compliance como feature de produto. Um sistema construído para auditabilidade acelera as vendas enterprise, encurta procurement e transforma mudança regulatória de ameaça em estreitamento do campo competitivo.

As empresas que adotarem agentes autônomos hoje estão fixando o precedente de accountability para a década. Se seus agentes conseguirem responder ao auditor amanhã, você tem uma franquia. Se não, você tem uma responsabilidade fantasiada de história de produtividade.

O Fernando escreveu, em paralelo, sobre os protocolos técnicos que tornam sistemas multi-agente interoperáveis. A governança verificável é a outra metade dessa conversa — sem ela, a interoperabilidade escala o problema em vez de resolvê-lo.

Se seu time está desenhando a camada de accountability para agentes de IA e quer um parceiro que já tenha levado isso para produção em ambientes regulados, vamos conversar.