Por Qué la IA Agéntica No Tolerará los Ledger No Serializables
Un agente de IA que inicia un pago contra un ledger que no puede garantizar ejecución exactamente una vez producirá débitos duplicados, créditos fantasma y corrupción de estado irrecuperable. Esto no es un riesgo que se mitigue con lógica de reintento. Es una incompatibilidad arquitectónica entre los patrones de transacción agenticos y el modelo de aislamiento en el que operan la mayoría de las bases de datos financieras.
El 44 % de los equipos financieros ha desplegado IA agentica en workflows productivos a partir de 2026 (Forrester). Los 50 bancos más grandes anunciaron más de 160 casos de uso de IA en 2025. Los agentes ahora inician transacciones, ajustan límites de riesgo, desencadenan workflows de settlement y toman decisiones de compliance en entornos productivos. La mayoría opera contra infraestructura diseñada para patrones de transacción de ritmo humano y envío único.
El Problema de Exactly-Once Bajo Carga Agéntica
Un humano que inicia un pago a través de una interfaz de usuario crea un evento único y discreto. Hay intención, un paso de confirmación y un envío. Un agente opera de manera distinta. Reintenta ante timeouts de red sin saber si la solicitud original hizo commit. Ejecuta sub-workflows concurrentes dirigidos a las mismas cuentas. Recibe señales ambiguas: un 408 Request Timeout que enmascaró un write exitoso, un 502 Bad Gateway que ocultó una ejecución parcial, un 200 OK de una puerta de enlace API que nunca llegó a la base de datos.
Los patrones tradicionales de clave de idempotencia abordan parte de esto: incluir un token único en cada solicitud y el servidor deduplica al recibir. Esto funciona cuando la generación de claves es determinística y el agente es la única fuente de esa clave. Ambas suposiciones fallan bajo arquitecturas agenticas reales.
Cuando un agente falla y reinicia desde un checkpoint, puede reproducir eventos en un orden distinto al de la ejecución original. Cuando dos agentes coordinan un objetivo compartido a través de una ventana de contexto compartida, ambos pueden iniciar la misma transacción subyacente con claves generadas independientemente. Cuando un workflow de múltiples pasos sufre timeout en el paso 3 de 5, el agente que se reanuda puede no saber qué pasos ya hicieron commit y cuáles no.
El problema estructural más profundo: la verificación de idempotencia y el write del ledger no son atómicos. La secuencia es verificar-antes-de-escribir: comprobar que la clave está ausente, luego insertar la transferencia. Entre el paso uno y el paso dos, otro agente, otro hilo o otro reintento puede haber escrito ya una transferencia para la misma operación. Bajo aislamiento READ COMMITTED, esta ventana es invisible. Bajo REPEATABLE READ, el resultado de la verificación puede estar obsoleto para cuando se ejecuta el write. Solo SERIALIZABLE cierra esta brecha, y SERIALIZABLE bajo carga agentica concurrente es precisamente donde las bases de datos de propósito general alcanzan su techo de contención.
Condiciones de Carrera con Década de Agentes
Un solo humano envía un pago por interacción. Un agente que procesa 500 instrucciones por segundo puede iniciar cientos de transacciones contra una cuenta de settlement compartida dentro del mismo segundo. Cuando 50 agentes concurrentes rebalancean posiciones de tesorería a través de 200 pares de divisas, cada rebalanceo implica transferencias multirriego a través de un pequeño número de cuentas agregadoras: la cuenta de settlement EUR tocada por cada riego EUR, la cuenta de suspense de clearing tocada por cada pago saliente.
PostgreSQL serializa writes en filas disputadas. Bajo aislamiento SERIALIZABLE, la detección de conflictos añade overhead adicional: cuando dos transacciones tocan la misma cuenta en ventanas superpuestas, una recibe ERROR: could not serialize access due to concurrent update y debe reintentar. A 50 agentes concurrentes enviando cada uno 10 transacciones por segundo a una cuenta de settlement compartida, la tasa de reintento bajo contención supera el 60 % en segundos. Cada reintento consume un round-trip a la base de datos, retiene una conexión y compite de nuevo por la misma fila.
La degradación no es lineal. A 50 TPS con distribución uniforme de cuentas, la contención es insignificante. A 500 TPS contra una distribución zipfiana de cuentas, donde el 1 % superior de cuentas recibe el 30 % de transferencias, la Ley de Amdahl aplica directamente: si el 10 % de la carga de trabajo es inherentemente serial debido a contención de cuentas calientes, la aceleración máxima teórica por paralelización es 10x independientemente del hardware. Agregar más capacidad al pool de conexiones empeora la contención: más hilos compitiendo por el mismo bloqueo de fila.
El bloqueo optimista con columnas de versión traslada la detección de conflictos a la capa de aplicación, pero no elimina el costo de reintento. Cada conflicto todavía produce un write desperdiciado, un round-trip y un reenvío. Con débito agentico, este overhead no es incidental.
Qué Provee la Deduplicación a Nivel de Protocolo
Las claves de idempotencia de capa de aplicación son insuficientes para garantías de exactamente una vez cuando la verificación y el write son operaciones separadas. La garantía requiere que la deduplicación sea atómica con el write del ledger. Ambos ocurren dentro del mismo límite atómico, no a través de una secuencia visible para la aplicación.
Un motor de settlement construido para el propósito implementa deduplicación como restricción de protocolo. Cada transferencia lleva una ID de transferencia de 128 bits. El motor rechaza cualquier transferencia cuya ID ya haya procesado antes de llegar al almacenamiento, a nivel de protocolo, antes de que corra código de aplicación. La verificación y el write no son dos operaciones en secuencia. Son una operación: la transferencia hace commit con su ID registrada, o se rechaza de plano. No hay ventana entre ellos.
Para agentes que generan nuevas IDs de transferencia al reintentar (que es el comportamiento correcto: nuevo intento, nueva ID), el protocolo provee la propiedad de seguridad subyacente: ninguna ID de transferencia se ejecuta más de una vez. La política de reintento del agente y la deduplicación del motor son mecanismos ortogonales. Juntos proveen ejecución exactamente una vez sin requerir que el agente mantenga estado perfectamente consistente entre reinicios.
Procesamiento por Lotes y el Modelo de Débito Invertido
El techo de débito del bloqueo a nivel de fila existe porque la concurrencia y la corrección están en tensión: más escritores concurrentes significan más conflictos, más reintentos y más trabajo desperdiciado. El techo es una propiedad del modelo de bloqueo, no del hardware.
Un motor de settlement por lotes invierte esta relación. Las transferencias se acumulan en lotes, hasta 8.190 operaciones por lote, y se aplican atómicamente en un único paso secuencial. No hay acceso concurrente a registros individuales de cuenta dentro de un lote: el lote es la unidad de atomicidad, y el lote se ejecuta secuencialmente. Sin conflictos. Sin reintentos. Sin fallos de serialización.
Bajo carga agentica creciente, el modelo de débito mejora: más agentes concurrentes significan lotes más llenos. Lotes más llenos significan mejor amortización del overhead por lote (ronda de consenso, flush de WAL, I/O de almacenamiento). A 1.000 transacciones iniciadas por agentes por segundo, el motor es más eficiente que a 100, porque los lotes se acercan a su factor de llenado máximo. La relación entre carga y débito es monotónica hasta los límites físicos de ancho de banda de memoria y I/O de disco, no la degradación no lineal de un sistema basado en bloqueos.
El modelo de consistencia es estrictamente serializable por construcción: las transacciones dentro de un lote se aplican en orden de envío, y ninguna transacción puede observar el estado parcial de otra transacción en el mismo lote. El orden serial es el orden del lote. No hay anomalías que prevenir porque no hay concurrencia dentro del camino de ejecución.
El Requisito de Trazabilidad de DORA Aplicado a Agentes
El Artículo 11 de DORA requiere "gestión estricta de incidentes relacionados con ICT" incluyendo la capacidad de reconstruir la historia completa de cualquier evento ICT. Cuando un agente de IA es un sistema ICT que participa en operaciones financieras, este requisito aplica tanto al agente como a la infraestructura contra la que opera.
Para sistemas agenticos, trazabilidad significa que la decisión del agente de iniciar una transacción, los parámetros que utilizó, el camino de ejecución a través del workflow y el resultado final deben ser recuperables desde un único identificador de auditoría. Logs de aplicación dispersos a través de frameworks de orquestación de agentes, motores de workflow y tablas de base de datos no satisfacen este requisito si no pueden correlacionarse a una única instancia de transacción.
La ejecución durable provee esta propiedad arquitectónicamente. Cada paso de workflow se registra en un journal antes de la ejecución. Cada entrada del journal lleva la ID de workflow, el número de paso, la entrada, la salida y el tiempo. Un auditor que rastrea un pago iniciado por un agente recibe una única ID de workflow y puede reconstruir cada paso: la instrucción del agente, la llamada de screening AML, el débito del ledger, el envío de clearing y cualquier compensación que siguió. No porque se haya añadido logging como pensamiento posterior. El modelo de ejecución requiere un journal para funcionar, y el journal es el trail de auditoría.
El Artículo 5 de DORA requiere que las entidades financieras gestionen el riesgo ICT a través de "todas las funciones de negocio soportadas por ICT". Cuando los agentes de IA se convierten en sistemas ICT que ejecutan operaciones financieras, sus modos de fallo deben evaluarse y documentarse. El modo de fallo primario de un sistema agentico contra un ledger no serializable es estado parcial: una operación de múltiples pasos que hace commit en algunos pasos y en otros no, sin un camino de recuperación determinista. El estado parcial se acumula más rápido bajo débito agentico de lo que los ciclos de conciliación pueden eliminarlo.
La Dimensión de la Ley de IA de la UE
La Ley de IA de la UE, vigente desde agosto de 2024, clasifica los sistemas de IA que operan en el sector financiero como de alto riesgo bajo el Anexo III. Los sistemas de IA de alto riesgo requieren documentación técnica bajo el Artículo 11 que describa el propósito previsto del sistema, las limitaciones de rendimiento conocidas y la interacción con otros sistemas técnicos.
Cuando un agente de IA interactúa con un ledger, el comportamiento del ledger bajo carga agentica concurrente es parte de esa documentación técnica. Un ledger que produce fallos de serialización bajo carga concurrente de IA es una limitación operativa documentada. Un ledger que produce transacciones duplicadas cuando los agentes reintentan es un defecto documentado. Estos deben aparecer en la documentación técnica y los registros de gestión de riesgos que requiere el Art. 9.
La implicación práctica: desplegar agentes de IA contra infraestructura financiera requiere arquitectura auditable en ambas capas: el agente y el ledger. El agente debe producir un trail de auditoría completo y correlacionable. El ledger debe proveer garantías de ejecución exactamente una vez a las que el trail de auditoría del agente pueda referirse. Ninguna capa puede satisfacer el requisito regulatorio independientemente.
Compromisos
La serializabilidad estricta tiene un costo de rendimiento. Un sistema estrictamente serializable acepta menos escritores concurrentes que uno eventualmente consistente, porque debe hacer cumplir garantías de orden que los sistemas eventualmente consistentes no proveen. Para aplicaciones de ritmo humano a 10 transacciones por segundo, este costo es insignificante. Con débito agentico, el costo depende del modelo de ejecución.
Los bloqueos a nivel de fila producen el peor rendimiento bajo aislamiento serializable: alta concurrencia contra cuentas calientes crea una tormenta de reintentos. El procesamiento por lotes elimina el costo de reintento por completo, pero introduce una restricción diferente: todos los writes en un lote hacen commit atómicamente, así que la latencia de write individual está limitada por el tiempo de acumulación del lote más el overhead del commit atómico. A 8.190 transferencias por lote ejecutándose con latencia de commit sub-milisegundo, la latencia por transferencia está bien por debajo de 1 ms. Pero el motor opera como proceso separado y no expone una interfaz SQL, lo que significa que el código de aplicación existente basado en SQL debe adaptarse a la API del motor.
El costo de migración es real. Para equipos que hoy operan ledgers de alto volumen en PostgreSQL, adaptarse a un motor de settlement construido para el propósito es un proyecto de varios trimestres que involucra migración de esquema, reescritura de consultas y cambios de tooling operativo. Para equipos que construyen nuevos sistemas, la decisión es directa: el modelo de ejecución correcto es más barato que adaptar garantías de exactamente una vez a una arquitectura que no las provee nativamente.
Fernel Context
El ledger de Fernel impone serializabilidad estricta a través de procesamiento por lotes, no bloqueos a nivel de fila. Las transferencias se acumulan y aplican atómicamente en un único paso secuencial, sin acceso concurrente a registros individuales de cuenta dentro de un lote. Cada transferencia lleva una ID de transferencia de 128 bits que el motor valida a nivel de protocolo antes del almacenamiento. La deduplicación es atómica con el write, no una verificación separada que lo precede. El motor se ejecuta como proceso aislado con su propio espacio de memoria y validación. Un bug en la lógica de pagos de un agente de IA no puede corromper el ledger: el motor rechaza cualquier transferencia que viole sus invariantes, incluyendo transferencias con IDs duplicadas, transferencias que violarían el equilibrio de partida doble, y transferencias que referencian cuentas pertenecientes a diferentes inquilinos.
Leer más: El Ledger | Settlement Determinista: Por Qué la Latencia Sub-Milisegundo Importa en Finanzas | Por Qué las Bases de Datos de Propósito General Fallan en OLTP Financiero
Fuentes:
- Forrester, Post-Money20/20 Europe 2026 Analysis, adopción de IA agentica en servicios financieros
- Money20/20 Europe 2026, 50 bancos más grandes: 160+ casos de uso de IA anunciados en 2025
- DORA, Reglamento (UE) 2022/2554, Art. 5-6 (Gestión de Riesgos ICT), Art. 11-12 (Respuesta, Recuperación, Trazabilidad)
- Ley de IA de la UE, Reglamento (UE) 2024/1689, Anexo III (Sistemas de IA de Alto Riesgo en Servicios Financieros), Art. 9 (Sistema de Gestión de Riesgos), Art. 11 (Documentación Técnica)
- Amdahl, Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967
- Documentación de PostgreSQL: Serializable Isolation y Serializable Snapshot Isolation (SSI), https://www.postgresql.org/docs/current/transaction-iso.html