Soluciones · Servicios financieros
En una organización financiera, un agente útil no da consejos y no aprueba nada: lee documentos y transacciones, los encuadra en una categoría de un conjunto fijo, dice cuán seguro está y puede responder «no sé». Lo demás — la decisión, la aprobación, la política — queda en manos de las personas.
Oferta, con condicionesNo escribimos «entregado», porque no tenemos un agente de ese tipo puesto en producción en un cliente del sector financiero. Lo que tenemos, y mostramos exactamente como es, es una canalización propia de ingesta que corre sobre nuestros datos: cinco módulos Python, 1.526 líneas, que leen notificaciones bancarias del correo y extractos en PDF, clasifican cada transacción mediante herramientas y la escriben en PostgreSQL con deduplicación, además de cuatro flujos de automatización para webhooks de tres procesadores de pagos. El estado real, dicho en la misma frase: el repositorio no está bajo git, los directorios `tests/` y `webhook-server/` están vacíos, y la coincidencia aproximada de nombres de contrapartida usa una heurística de n-gramas marcada en el código como «a sustituir por un servicio de embeddings antes de producción». La parte de plataforma financiera en producción — flujo de solicitud, contrato, gráfico de pagos, auditoría — es una obra separada, con sus pruebas, y ahí escribimos «entregado».
Las solicitudes de agentes AI en servicios financieros casi siempre vienen en la forma «que respondan a los clientes a preguntas sobre nuestros productos». Es una solicitud legítima, pero no es ahí donde se gana tiempo. El tiempo se pierde en otra parte: alguien abre cada día decenas de notificaciones bancarias y extractos, mira una descripción del tipo una cadena de mayúsculas con un código y decide si es un cobro de un cliente, un salario, un impuesto, una cuota hacia un acreedor o un gasto de explotación. Ese trabajo es repetitivo, aburrido y, precisamente por eso, lleno de errores.
Un modelo lingüístico es bueno para eso, con una condición: no pedirle que escriba una respuesta en texto libre. Si le pides una frase, la vas a parsear tú, y el parseo lo vas a hacer mal. En nuestra tubería, el modelo no escribe: recibe siete herramientas y debe llamar exactamente a una —cobro de un cliente, salario, impuesto, pago a un acreedor, gasto de explotación, comisión bancaria o desconocido. Cada herramienta exige, además del nombre de la contrapartida o la categoría, un score de confianza entre 0 y 1. «Desconocido» pide un motivo escrito. La salida es una estructura, no una opinión.
La segunda regla es que nada entra dos veces. Cada transacción extraída de una notificación o de un extracto recibe un identificador externo calculado como prefijo de 16 caracteres de una huella SHA-256 sobre sus campos, la columna es única en la tabla, y la inserción se hace con `ON CONFLICT (external_id) DO NOTHING`. La consecuencia práctica: el buzón puede releerse tantas veces como quieras, y el saldo no se duplica. Sin esa regla, cualquier tubería de ingesta financiera acaba, en la tercera semana, produciendo duplicados que alguien limpia manualmente.
Lo que no hace un agente así, y por qué es importante escribirlo en la página: no aprueba un pago, no toma una decisión de crédito, no da recomendaciones de inversión y no responde al cliente en nombre de la institución. El score de confianza que devuelve es la evaluación del modelo sobre sí mismo, no una medida de la precisión hecha por nosotros —esa distinción es la diferencia entre una herramienta y una ilusión de control.
Qué incluye
Las notificaciones se leen del buzón por IMAP, los extractos desde PDF. Cada transacción recibe un identificador externo de una huella SHA-256 sobre sus campos, la columna `external_id` es `NOT NULL UNIQUE` en la tabla, y la inserción se hace con `ON CONFLICT (external_id) DO NOTHING`, con registro separado para la fila insertada y para la omitida como duplicado. La relectura del mismo buzón no produce ningún duplicado.
Siete herramientas, no texto libre: cobro de un cliente, salario, impuesto, pago a un acreedor, gasto de explotación, comisión bancaria, desconocido. El modelo debe llamar a una sola. Las primeras seis exigen obligatoriamente, además del nombre o la categoría, un score de confianza entre 0,0 y 1,0, declarado en el esquema de la herramienta; la séptima pide un motivo. El modelo usado se declara en el código, no se oculta en la configuración.
Un clasificador al que no se le permite decir «no sé» clasificará mal, con alta confianza, precisamente las transacciones inusuales —es decir, las que importan. Por eso la herramienta de desconocido está tan disponible como las demás y pide un motivo escrito, que llega a la fila. Las filas desconocidas son la lista de trabajo de la persona, no un fallo del sistema.
La misma empresa aparece en extractos bajo tres ortografías. Encima de la clasificación existe un emparejamiento por similitud coseno entre vectores. Decimos exactamente qué son esos vectores hoy: una heurística de n-gramas de caracteres, escrita en el código con el comentario de que para producción debe sustituirse por una llamada real a un servicio de embeddings. Funciona para variaciones de escritura; no es un emparejamiento semántico.
Cuatro flujos de automatización, uno por cada tres procesadores de pagos y uno de reconciliación diaria, con 7 a 10 nodos cada uno. La idea de arquitectura es que las fuentes distintas —correo, PDF, webhook— no producen tres tablas que luego hay que reconciliar, sino filas en la misma tabla, con la misma regla de deduplicación.
Las llamadas pasan por un gateway propio en `api.megapromoting.com/v1`, con 44 modelos configurados, cada uno con coste por token y límite de contexto. La clave de proyecto tiene lista blanca de modelos, presupuesto y periodo, se puede rotar manteniendo el historial, y el consumo se consolida diariamente por usuario × clave × modelo. El detalle que sorprende a todo el mundo: los modelos de razonamiento producen pasos internos que el sistema de seguimiento no ve, pero el proveedor los factura — así que el presupuesto bruto por clave se fija por debajo del techo deseado.
Para los pasos que no requieren un modelo grande — la extracción de campos de un formato conocido, la coincidencia de nombres, las comprobaciones de coherencia — no hace falta ningún proveedor externo; es código normal. El modelo solo se llama para el paso de encuadre. Cuando tu política prohíbe la salida de datos, la cuestión es qué se envía exactamente al modelo, no si se usa AI: se puede enviar la descripción de la transacción sin los identificadores de cuenta.
No aprueba un pago y no ejecuta una transferencia. No toma la decisión de crédito — las reglas, los umbrales y la aprobación son la política de la institución. No da recomendaciones de inversión y no responde al cliente en tu nombre sin un flujo separado de aprobación. Y no te garantiza la exactitud: la puntuación de confianza es la salida del modelo sobre sí mismo, no una medición independiente.
Traseul
La primera entrega no es un agente, sino una lista: las categorías en las que tiene permiso para encuadrar, qué campos obligatorios exige cada una, y qué significa «desconocido» para ti. Si la lista no se puede escribir en una página, la tarea no es adecuada para un agente — y es más barato averiguarlo ahora.
La lectura desde correo electrónico, PDF o webhook, la extracción de campos, el cálculo del identificador externo y la escritura en la base se hacen y se verifican sin ninguna llamada a un modelo. Entregamos una canalización que ingiere correctamente y no duplica. Si ese paso no es sólido, un modelo encima solo produce errores más convincentes.
Encima de la canalización que funciona ponemos las herramientas de clasificación y ejecutamos sobre un conjunto de transacciones reales tuyas, con el resultado correcto establecido por la persona que hace hoy el trabajo. Entregamos la tabla con los acuerdos y desacuerdos, no una afirmación sobre la exactitud. El umbral a partir del cual la fila pasa a una persona se elige de esa tabla.
Clave de proyecto con lista blanca de modelos y presupuesto, consolidación diaria del consumo, registro con la herramienta llamada y la puntuación, y un gate que envía a una persona todo lo que esté por debajo del umbral o sea desconocido. Entregamos los accesos, el documento de puesta en marcha y la lista escrita de lo que hace el agente por sí solo y lo que no.
Los datos
Las reglas difieren de una industria a otra. Estas son las que se aplican en servicios financieros.
Un caso
La situación
Las notificaciones bancarias y los extractos mensuales llegaban a un buzón y eran leídos por una persona, que los clasificaba por categorías. La primera variante obvia — un script que lee el buzón y escribe en la base — tiene un problema que solo se ve en la tercera semana: ante cualquier reinicio o relectura, las mismas transacciones entran otra vez.
Qué construimos
Escribí cinco módulos, 1.526 líneas de Python: dos analizadores de notificaciones por IMAP, un extractor de extractos PDF, el clasificador mediante herramientas y la escritura en PostgreSQL. La regla central es el identificador externo — un prefijo de 16 caracteres de una huella SHA-256 sobre los campos de la transacción — con la columna única en la tabla e inserción `ON CONFLICT DO NOTHING`. La clasificación no devuelve texto: el modelo llama a una de siete herramientas, con puntuación de confianza obligatoria, y «desconocido» pide motivo.
Qué salió
El buzón se puede releer en cualquier momento, y las filas ya procesadas se omiten y se anotan como duplicado en el registro. Las transacciones que el modelo no puede clasificar aparecen como lista de trabajo, con el motivo al lado, en lugar de ser empujadas a una categoría para que parezca que todo salió bien.
Qué no dice el caso
Es una canalización interna, no un sistema entregado a un cliente financiero: no está en git, los directorios de pruebas están vacíos, y la coincidencia aproximada de nombres usa una heurística de n-gramas que el código marca explícitamente como provisional. La describí aquí porque muestra el método, no porque sea un producto.
Preguntas
No, y no es una limitación técnica que vayamos a superar en la próxima versión. La aprobación es una decisión con consecuencias jurídicas, que corresponde a una persona autorizada de la institución. El agente prepara: clasifica, completa, señala lo que no encaja. Un sistema que aprueba por sí solo debería poder responder ante un auditor, y una puntuación de confianza no es una respuesta.
No por la puntuación de confianza — esa es la evaluación del modelo sobre sí mismo, no una medida. Se sabe por la comparación con las decisiones de la persona que hoy hace el trabajo, sobre un conjunto de transacciones reales, hecha antes de poner algo en modo automático. El resultado de esa comparación es una tabla que entregamos, incluidas las filas en las que el agente se equivocó.
Llama a la herramienta de «desconocido» y escribe el motivo. La fila pasa a la lista de trabajo de la persona, no a una categoría elegida al azar para que parezca que el sistema funcionó. Un clasificador sin salida de «no sé» se equivoca justo donde el error cuesta: en las transacciones inusuales.
No. Cada transacción tiene un identificador externo calculado como huella sobre sus campos, la columna es única, y la inserción usa `ON CONFLICT (external_id) DO NOTHING`. La fila omitida se registra en el log como duplicada, así que se ve que fue leída de nuevo.
Para el paso de clasificación, sí: la descripción de la transacción y la suma van al modelo elegido, a través de nuestro gateway, con clave de proyecto, lista blanca de modelos y presupuesto. El resto de los pasos — lectura, extracción, deduplicación, coincidencia de nombres — son código normal y no salen a ninguna parte. Qué está permitido que salga se define por escrito antes, no se descubre en los logs después.
Sí, es uno de los módulos del flujo. Lo que hay que saber es que un extracto PDF es un formato frágil: se lee según la estructura que produce ese banco, y cuando el banco cambia la plantilla, el módulo hay que ajustarlo. Por eso se escribe con verificaciones que fallen en voz alta, no que adivinen.
Porque nuestra regla exige un mínimo de dos implementaciones propias para escribir «entregado», y el flujo descrito aquí funciona con nuestros datos, no en producción en un cliente del sector financiero. También tiene carencias que nombramos: no está en git, no tiene pruebas, y la coincidencia de nombres usa una heurística marcada en el código como provisional. Cuando podamos citar dos implementaciones en clientes, cambiamos la palabra.
Tres cosas: la lista cerrada de las categorías en las que se le permite clasificar, un conjunto de transacciones reales con la respuesta correcta dada por la persona que hace hoy el trabajo, y la decisión escrita sobre qué campos pueden salir de vuestra red. Sin el tercer punto no empezamos, porque es el único que no se puede arreglar después.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.