Ledger11 min de leitura

Por Que a IA Agêntica Não Tolerará os Ledgers Não Serializáveis

Um agente de IA que inicia um pagamento contra um ledger que não pode garantir execução exatamente uma vez produzirá débitos duplicados, créditos fantasmas e corrupção de estado irrecuperável. Isso não é um risco a ser mitigado com lógica de retentativa. É uma incompatibilidade arquitetônica entre os padrões de transação agênticos e o modelo de isolamento em que operam a maioria dos bancos de dados financeiros.

44% das equipes financeiras implantaram IA agêntica em workflows produtivos a partir de 2026 (Forrester). Os 50 maiores bancos anunciaram mais de 160 casos de uso de IA em 2025. Agentes agora iniciam transações, ajustam limites de risco, acionam workflows de settlement e tomam decisões de compliance em ambientes produtivos. A maioria opera contra infraestrutura projetada para padrões de transação de ritmo humano e envio único.

O Problema de Exactly-Once Sob Carga Agêntica

Um humano que inicia um pagamento por uma interface de usuário cria um evento único e discreto. Há intenção, uma etapa de confirmação e um envio. Um agente opera de forma diferente. Ele retenta em timeouts de rede sem saber se a solicitação original fez commit. Executa sub-workflows concorrentes direcionados às mesmas contas. Recebe sinais ambíguos: um 408 Request Timeout que encobriu um write bem-sucedido, um 502 Bad Gateway que ocultou uma execução parcial, um 200 OK de um gateway de API que nunca chegou ao banco de dados.

Os padrões tradicionais de chave de idempotência abordam parte disso: incluir um token único em cada solicitação e o servidor deduplica ao receber. Isso funciona quando a geração de chaves é determinística e o agente é a única fonte dessa chave. Ambas as suposições falham sob arquiteturas agênticas reais.

Quando um agente falha e reinicia a partir de um checkpoint, pode reproduzir eventos em uma ordem diferente da execução original. Quando dois agentes coordenam um objetivo compartilhado por uma janela de contexto compartilhada, ambos podem iniciar a mesma transação subjacente com chaves geradas independentemente. Quando um workflow de múltiplas etapas sofre timeout na etapa 3 de 5, o agente que retoma pode não saber quais etapas já fizeram commit e quais não fizeram.

O problema estrutural mais profundo: a verificação de idempotência e o write do ledger não são atômicos. A sequência é verificar-antes-de-escrever: verificar se a chave está ausente, depois inserir a transferência. Entre a etapa um e a etapa dois, outro agente, outra thread ou outra retentativa pode já ter escrito uma transferência para a mesma operação. Sob isolamento READ COMMITTED, essa janela é invisível. Sob REPEATABLE READ, o resultado da verificação pode estar obsoleto para quando o write é executado. Apenas SERIALIZABLE fecha essa lacuna, e SERIALIZABLE sob carga agêntica concorrente é precisamente onde bancos de dados de propósito geral atingem seu teto de contenção.

Condições de Corrida na Vazão de Agentes

Um único humano envia um pagamento por interação. Um agente que processa 500 instruções por segundo pode iniciar centenas de transações contra uma conta de settlement compartilhada dentro do mesmo segundo. Quando 50 agentes concorrentes rebalanceiam posições de tesouraria em 200 pares de moedas, cada rebalanceamento envolve transferências multipernas através de um pequeno número de contas agregadoras: a conta de settlement EUR tocada por cada perna EUR, a conta de suspense de clearing tocada por cada pagamento de saída.

O PostgreSQL serializa writes em linhas disputadas. Sob isolamento SERIALIZABLE, a detecção de conflitos adiciona overhead adicional: quando duas transações tocam a mesma conta em janelas sobrepostas, uma recebe ERROR: could not serialize access due to concurrent update e deve retentar. A 50 agentes concorrentes enviando cada um 10 transações por segundo para uma conta de settlement compartilhada, a taxa de retentativa sob contenção supera 60% em segundos. Cada retentativa consome um round-trip ao banco de dados, retém uma conexão e compete novamente pela mesma linha.

A degradação não é linear. A 50 TPS com distribuição uniforme de contas, a contenção é insignificante. A 500 TPS contra uma distribuição zipfiana de contas, onde o 1% superior de contas recebe 30% das transferências, a Lei de Amdahl aplica-se diretamente: se 10% da carga de trabalho é inerentemente serial devido à contenção de contas quentes, a aceleração máxima teórica por paralelização é 10x independentemente do hardware. Adicionar mais capacidade ao pool de conexões piora a contenção: mais threads competindo pelo mesmo bloqueio de linha.

O bloqueio otimista com colunas de versão transfere a detecção de conflitos para a camada de aplicação, mas não elimina o custo de retentativa. Cada conflito ainda produz um write desperdiçado, um round-trip e um reenvio. Com vazão agêntica, esse overhead não é incidental.

O Que a Deduplicação em Nível de Protocolo Provê

As chaves de idempotência da camada de aplicação são insuficientes para garantias de exatamente uma vez quando a verificação e o write são operações separadas. A garantia exige que a deduplicação seja atômica com o write do ledger. Ambos acontecem dentro do mesmo limite atômico, não através de uma sequência visível para a aplicação.

Um motor de settlement construído para o propósito implementa deduplicação como restrição de protocolo. Cada transferência carrega uma ID de transferência de 128 bits. O motor rejeita qualquer transferência cuja ID ele já tenha processado antes de alcançar o armazenamento, em nível de protocolo, antes de o código de aplicação executar. A verificação e o write não são duas operações em sequência. São uma operação: a transferência faz commit com sua ID registrada, ou é rejeitada de plano. Não há janela entre eles.

Para agentes que geram novas IDs de transferência ao retentar (que é o comportamento correto: nova tentativa, nova ID), o protocolo fornece a propriedade de segurança subjacente: nenhuma ID de transferência é executada mais de uma vez. A política de retentativa do agente e a deduplicação do motor são mecanismos ortogonais. Juntos fornecem execução exatamente uma vez sem exigir que o agente mantenha estado perfeitamente consistente entre reinícios.

Processamento em Lotes e o Modelo de Vazão Invertido

O teto de vazão do bloqueio em nível de linha existe porque concorrência e correção estão em tensão: mais escritores concorrentes significam mais conflitos, mais retentativas e mais trabalho desperdiçado. O teto é uma propriedade do modelo de bloqueio, não do hardware.

Um motor de settlement por lotes inverte essa relação. As transferências são coletadas em lotes, até 8.190 operações por lote, e aplicadas atomicamente em uma única passagem sequencial. Não há acesso concorrente a registros individuais de conta dentro de um lote: o lote é a unidade de atomicidade, e o lote executa sequencialmente. Sem conflitos. Sem retentativas. Sem falhas de serialização.

Sob carga agêntica crescente, o modelo de vazão melhora: mais agentes concorrentes significam lotes mais cheios. Lotes mais cheios significam melhor amortização do overhead por lote (rodada de consenso, flush de WAL, I/O de armazenamento). A 1.000 transações iniciadas por agentes por segundo, o motor é mais eficiente do que a 100, porque os lotes se aproximam de seu fator de preenchimento máximo. A relação entre carga e vazão é monotônica até os limites físicos de largura de banda de memória e I/O de disco, não a degradação não linear de um sistema baseado em bloqueios.

O modelo de consistência é estritamente serializável por construção: as transações dentro de um lote são aplicadas em ordem de envio, e nenhuma transação pode observar o estado parcial de outra transação no mesmo lote. A ordem serial é a ordem do lote. Não há anomalias a serem prevenidas porque não há concorrência dentro do caminho de execução.

O Requisito de Rastreabilidade da DORA Aplicado a Agentes

O Artigo 11 da DORA requer "gestão rigorosa de incidentes relacionados a ICT" incluindo a capacidade de reconstruir a história completa de qualquer evento ICT. Quando um agente de IA é um sistema ICT que participa em operações financeiras, esse requisito aplica-se tanto ao agente quanto à infraestrutura contra a qual opera.

Para sistemas agênticos, rastreabilidade significa que a decisão do agente de iniciar uma transação, os parâmetros que utilizou, o caminho de execução através do workflow e o resultado final devem ser recuperáveis a partir de um único identificador de auditoria. Logs de aplicação espalhados por frameworks de orquestração de agentes, motores de workflow e tabelas de banco de dados não satisfazem esse requisito se não puderem ser correlacionados a uma única instância de transação.

A execução durável provê essa propriedade arquitetonicamente. Cada etapa de workflow é registrada em um journal antes da execução. Cada entrada do journal carrega a ID de workflow, o número da etapa, a entrada, a saída e o tempo. Um auditor que rastreia um pagamento iniciado por um agente recebe uma única ID de workflow e pode reconstruir cada etapa: a instrução do agente, a chamada de screening AML, o débito do ledger, o envio de clearing e qualquer compensação que se seguiu. Não porque logging tenha sido adicionado como pensamento posterior. O modelo de execução requer um journal para funcionar, e o journal é o trail de auditoria.

O Artigo 5 da DORA exige que as entidades financeiras gerenciem o risco de ICT através de "todas as funções de negócio suportadas por ICT". Quando os agentes de IA se tornam sistemas ICT que executam operações financeiras, seus modos de falha devem ser avaliados e documentados. O modo de falha primário de um sistema agêntico contra um ledger não serializável é estado parcial: uma operação de múltiplas etapas que faz commit em algumas etapas e em outras não, sem um caminho de recuperação determinístico. O estado parcial se acumula mais rápido sob vazão agêntica do que os ciclos de reconciliação podem eliminá-lo.

A Dimensão da Lei de IA da UE

A Lei de IA da UE, vigente desde agosto de 2024, classifica sistemas de IA que operam no setor financeiro como de alto risco sob o Anexo III. Sistemas de IA de alto risco exigem documentação técnica sob o Artigo 11 que descreva a finalidade pretendida do sistema, as limitações de desempenho conhecidas e a interação com outros sistemas técnicos.

Quando um agente de IA interage com um ledger, o comportamento do ledger sob carga agêntica concorrente é parte dessa documentação técnica. Um ledger que produz falhas de serialização sob carga concorrente de IA é uma limitação operativa documentada. Um ledger que produz transações duplicadas quando os agentes retentam é um defeito documentado. Esses devem aparecer na documentação técnica e nos registros de gestão de riscos que o Art. 9 exige.

A implicação prática: implantar agentes de IA contra infraestrutura financeira requer arquitetura auditable em ambas as camadas: o agente e o ledger. O agente deve produzir um trail de auditoria completo e correlacionável. O ledger deve fornecer garantias de execução exatamente uma vez às quais o trail de auditoria do agente possa se referir. Nenhuma camada pode satisfazer o requisito regulatorio independentemente.

Compromissos

A serializabilidade estrita tem um custo de desempenho. Um sistema estritamente serializável aceita menos escritores concorrentes do que um eventualmente consistente, porque deve fazer cumprir garantias de ordem que os sistemas eventualmente consistentes não fornecem. Para aplicações de ritmo humano a 10 transações por segundo, esse custo é insignificante. Com vazão agêntica, o custo depende do modelo de execução.

Os bloqueios em nível de linha produzem o pior desempenho sob isolamento serializável: alta concorrência contra contas quentes cria uma tempestade de retentativas. O processamento em lotes elimina o custo de retentativa por completo, mas introduz uma restrição diferente: todos os writes em um lote fazem commit atomicamente, então a latência de write individual está limitada pelo tempo de acumulação do lote mais o overhead do commit atômico. A 8.190 transferências por lote executando-se com latência de commit sub-milisegundo, a latência por transferência está bem abaixo de 1 ms. Mas o motor opera como processo separado e não expõe uma interface SQL, o que significa que o código de aplicação existente baseado em SQL deve adaptar-se à API do motor.

O custo de migração é real. Para equipes que hoje operam ledgers de alto volume em PostgreSQL, adaptar-se a um motor de settlement construído para o propósito é um projeto de vários trimestres que envolve migração de esquema, reescrita de consultas e mudanças de tooling operativo. Para equipes que constroem novos sistemas, a decisão é direta: o modelo de execução correto é mais barato do que adaptar garantias de exatamente uma vez a uma arquitetura que não as fornece nativamente.

Fernel Context

O ledger da Fernel impõe serializabilidade estrita através de processamento em lotes, não bloqueios em nível de linha. As transferências são acumuladas e aplicadas atomicamente em uma única passagem sequencial, sem acesso concorrente a registros individuais de conta dentro de um lote. Cada transferência carrega uma ID de transferência de 128 bits que o motor valida em nível de protocolo antes do armazenamento. A deduplicação é atômica com o write, não uma verificação separada que o precede. O motor executa-se como processo isolado com seu próprio espaço de memória e validação. Um bug na lógica de pagamentos de um agente de IA não pode corromper o ledger: o motor rejeita qualquer transferência que viole suas invariantes, incluindo transferências com IDs duplicadas, transferências que violariam o equilíbrio da partida dobrada, e transferências que referenciam contas pertencentes a diferentes inquilinos.

Fontes:

Forrester, Post-Money20/20 Europe 2026 Analysis, adoção de IA agêntica em serviços financeiros
Money20/20 Europe 2026, 50 maiores bancos: 160+ casos de uso de IA anunciados em 2025
DORA, Regulamento (UE) 2022/2554, Art. 5-6 (Gestão de Riscos ICT), Art. 11-12 (Resposta, Recuperação, Rastreabilidade)
Lei de IA da UE, Regulamento (UE) 2024/1689, Anexo III (Sistemas de IA de Alto Risco em Serviços Financeiros), Art. 9 (Sistema de Gestão de Riscos), Art. 11 (Documentação Técnica)
Amdahl, Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967
Documentação do PostgreSQL: Serializable Isolation e Serializable Snapshot Isolation (SSI), https://www.postgresql.org/docs/current/transaction-iso.html