O que prova o que a IA realmente fez: PostgreSQL e a camada de evidência transacional

Um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → recebe um pedido de reembolso, recupera a ordem, avalia as regras, decide que o reembolso é permitido e chama o serviço apropriado. Do ponto de vista do sistema de IA, o fluxo teve sucesso: o trace mostra que uma decisão foi tomada e uma ferramenta foi invocada. Só que o sistema de pagamento conta outra história. A operação falhou, a transação sofreu rollback e nenhum reembolso foi efetivamente commitado.

Essa cena abre o artigo de Vibhor Kumar publicado no Planet PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, e ela resume o problema que interessa a quem está colocando automação com IA em produção: o fato de um agente ter chamado uma ferramenta e o fato de uma transação de negócio ter sido commitada são dois fatos diferentes. Confundir os dois é o caminho mais curto para uma auditoria impossível seis meses depois.

Observability diz o que a IA fez, não o que mudou

Durante a era da IA generativa, a atenção esteve sobre o que os modelos produzem: acurácia, latência, consumo de tokens, qualidade do trace. Isso faz sentido quando a interação termina numa resposta. Não basta quando ela termina numa ação de negócio.

Kumar é direto na distinção. Um trace de execução pode estabelecer que um agente invocou approve_claim() às 10:42:17. Apenas o sistema autoritativo de sinistros pode estabelecer se o sinistro 84721 de fato saiu de pending para approved. O primeiro descreve execução; o segundo descreve estado de negócio. Uma arquitetura confiável precisa conectar os dois, e o problema é que esses registros costumam viver em sistemas distintos, com identificadores, políticas de retenção e noções de sucesso diferentes.

É aí que as coisas quebram na prática. Um timeout pode fazer o agente repetir uma ação que já tinha dado certo na primeira tentativa. Um sistema downstream pode rejeitar uma operação depois que o fluxo de IA já considerou a tarefa concluída. Em cada caso, o registro de execução diz algo verdadeiro, mas não conta a história inteira.

A camada de evidência: perguntas que precisam continuar respondíveis

Kumar chama esse tecido conectivo de evidence layer, uma camada de evidência: informação durável e correlacionada que liga uma decisão ou ação da IA ao estado de negócio autoritativo que resultou dela. Não é mais um repositório de logs, nem a obrigação de capturar cada evento intermediário. É um conjunto focado de perguntas que precisa permanecer respondível:

• O que a IA estava tentando fazer?
• Qual execução produziu a ação?
• Qual entidade de negócio foi afetada?
• Qual política se aplicou?
• A transação foi commitada?
• Qual estado resultou?

O critério que ele propõe é honesto: você consegue responder isso sem reunir três times para reconciliar logs desconexos meio ano depois? Se a resposta exige uma war room, a organização tem dados de observability, mas ainda não tem uma arquitetura de evidência.

Onde o PostgreSQL entra (e onde não deve entrar)

Aqui vale sublinhar o critério do DBA, porque Kumar acerta ao resistir à tentação óbvia. O PostgreSQL não deve virar uma plataforma de observability de IA. Guardar cada prompt, cada evento de token e cada trace distribuído num banco transacional seria o instinto errado, tanto de modelagem quanto de custo.

O papel do banco é outro. Em muitos sistemas corporativos, o PostgreSQL já fica exatamente na fronteira onde o estado de negócio se torna durável, o que o torna o lugar natural para ancorar a evidência sobre o que uma ação da IA de fato mudou. A execução carrega um identificador de correlação, um execution_id, ao longo do fluxo. Quando a transação de negócio acontece, esse identificador é associado à entidade e à transição de estado que a ação produziu.

O exemplo do artigo, simplificado, é elegante justamente porque o segredo não está na tabela de evidência, e sim na fronteira transacional:

BEGIN;

WITH approved_refund AS (
  UPDATE customer_refund
     SET status = 'approved',
         approved_at = CURRENT_TIMESTAMP
   WHERE refund_id = :refund_id
     AND status = 'pending'
  RETURNING refund_id
)
INSERT INTO ai_action_evidence (
  execution_id, entity_type, entity_id, action, model_ref, policy_ref
)
SELECT :execution_id, 'refund', refund_id, 'approve', :model_ref, :policy_ref
  FROM approved_refund;

COMMIT;

O ponto crucial: a evidência está atada à transição de estado, não ao pedido do agente. Se o reembolso não estiver mais pending, o UPDATE não altera nada, o RETURNING não devolve linha e nenhum registro de evidência afirmando que houve aprovação é inserido. Se a transição ocorre, mudança de negócio e evidência se tornam duráveis juntas. Se a transação sofre rollback, nenhuma das duas representa falsamente um resultado commitado. É o desenho correto resolvendo o problema antes de qualquer camada de aplicação precisar tratar exceção.

O rollback também faz parte da história

Há uma sutileza que separa quem entende de integridade de quem só quer um log a mais. Se a transação de reembolso dá rollback, não queremos evidência de negócio durável afirmando que o reembolso foi aprovado. Mas isso não significa esquecer que a IA tentou.

A evidência de execução diz o que a IA tentou. A evidência transacional diz o que o negócio aceitou. Um rollback não deve apagar o fato de que a IA tentou algo, apenas impedir que uma evidência durável afirme falsamente que a mudança foi commitada.

Vibhor Kumar

Os dois registros respondem perguntas diferentes, e é exatamente por isso que precisam permanecer distinguíveis e correlacionados, em vez de colapsados num só. O trace de execução guarda a tentativa e a falha; a evidência transacional guarda a consequência.

Quando não cabe em uma única transação

Kumar é criterioso ao reconhecer o limite: fluxos reais raramente ficam dentro de uma única transação de banco. Se o PostgreSQL registra o pedido de reembolso mas um provedor de pagamento externo é quem move o dinheiro, a transação local não pode provar que essa perna se completou. O banco não cria atomicidade entre sistemas que não compartilham fronteira transacional, e a arquitetura não deve fingir que cria.

É o cenário clássico do transactional outbox: uma transação do PostgreSQL commita atomicamente o estado de negócio local e um evento descrevendo o que precisa acontecer em seguida; outro processo publica esse evento downstream de forma confiável; e o mesmo execution_id e os identificadores de entidade atravessam a fronteira. Logical decoding e CDC propagam as mudanças relevantes adiante, para analytics ou retenção de longo prazo. O objetivo não é um banco de auditoria gigante, e sim uma cadeia durável de evidência correlacionada entre sistemas que não compartilham transação.

Evidência não é logging

Tratar isso como problema de log subestima a coisa. Logs são otimizados para entender comportamento de sistema: alto volume, escopo operacional, retenção para troubleshooting. Evidência de negócio é diferente. Precisa sobreviver por mais tempo, correlacionar-se a identificadores de negócio autoritativos, carregar garantias de integridade mais fortes e frequentemente responder a exigências regulatórias ou contratuais de retenção. Não é preciso guardar cada token intermediário que o agente gerou ao decidir, mas pode ser preciso provar que uma execução específica levou a um reembolso específico, que a política aplicável foi avaliada, que a transação foi commitada e que o cliente recebeu o dinheiro.

Por que isso vira problema comercial

Kumar amarra o argumento com um ângulo que o dev brasileiro fazendo integração deveria ter no radar: a economia da IA está migrando de custo por token para custo por tarefa e, em alguns casos, custo por resultado de negócio bem-sucedido. Ele propõe um cenário concreto: o fornecedor reporta que a IA resolveu 10.000 solicitações; os sistemas da empresa mostram 9.300 concluídas sob a definição contratual de sucesso. Qual número vai na fatura?

A partir daí, deixa de ser um problema de observability. As duas partes precisam concordar sobre o que conta como resultado, como se atribui e qual evidência prova que aconteceu. E a evidência transacional, discretamente, passa a fazer parte da arquitetura comercial da IA.

O que levar para o próprio projeto

O leitor não precisa esperar precificação por resultado para testar a própria arquitetura contra três perguntas que Kumar deixa: dá para correlacionar uma ação da IA com a transação de negócio que ela causou? Dá para distinguir o que a IA tentou do que de fato foi commitado? E dá para reconstruir essa evidência daqui a seis meses sem montar uma força-tarefa? Se responder às três exige logs de quatro times e suposições sobre timing, o desenho ainda não está pronto para dar autoridade de ação a um agente. Quanto mais autoridade se entrega à IA, mais importa aquela fronteira durável entre intenção e consequência, e o PostgreSQL, quando é dono do estado autoritativo, é um lugar sólido para ancorá-la.

Fonte: Planet PostgreSQL