Conciliación bancaria con IA local: arquitectura sin enviar datos a OpenAI

El dilema contable: 15 horas de fricción manual frente al riesgo de compliance

Cualquier equipo de finanzas que gestione cientos o miles de movimientos al mes se enfrenta a la misma rutina: descargar cartolas bancarias (PDF, CSV, Excel), extraer facturas del ERP (SAP, NetSuite, Odoo o el portal tributario local) y cruzar manualmente línea por línea montos, fechas, referencias truncadas y RUTs o CIFs.

El problema no es el volumen, sino la ambigüedad. En la cartola bancaria el concepto aparece como TRF 98124 BCO_STGO EXT COM, mientras que en el ERP la factura está registrada a nombre de Servicios Tecnológicos SpA. Los scripts tradicionales de Python o macros de Excel basados en coincidencia exacta se rompen de inmediato con estas variaciones.

La tentación evidente para muchos equipos es volcar estos archivos en ChatGPT o utilizar la API pública de OpenAI. Sin embargo, para un CFO, director de administración o DPO, esto representa una violación directa de las políticas de privacidad financiera, normativas bancarias locales y estándares como SOC 2 o GDPR. No puedes enviar balances de tesorería, estados de cuenta con números de cuenta bancaria y flujos de caja de clientes a servidores multi-tenant de terceros sin contratos enterprise específicos y configuraciones de retención cero.

La solución no es volver a la hoja de cálculo manual: es desplegar un agente de conciliación inteligente que corra en infraestructura privada.

Por qué fallan las soluciones convencionales

1. Sistemas basados en reglas rígidas: Exigen mantener cientos de diccionarios de sinónimos manuales. En cuanto un cliente cambia la razón social bancaria o el banco modifica el formato de la glosa, la regla falla y el movimiento cae al limbo de excepciones.
2. Fuzzy matching estadístico (Levenshtein, Jaro-Winkler): Funciona para errores tipográficos simples, pero es incapaz de inferir contexto semántico (por ejemplo, entender que una comisión cobrada en la misma transacción debe descontarse del monto bruto de la factura asociada).
3. LLMs públicos en la nube: Aunque entienden la semántica a la perfección, exponen la información más sensible de la empresa y generan costos de token recurrentes e impredecibles al procesar miles de páginas de extractos densos.

Arquitectura técnica de un agente de conciliación privado

Para resolver este problema sin comprometer datos confidenciales, diseñamos sistemas desacoplados que ejecutan modelos de pesos abiertos (open-weights) en infraestructura propia (on-premise o VPC aislada). La arquitectura se divide en cuatro capas:

[Extractos Bancarios + ERP] 
           │
           ▼
[Capa 1: Ingestión y Parsing Local (Docling / PyMuPDF)]
           │ Normalización tabular estructurada
           ▼
[Capa 2: Motor Heurístico Determinista (Reglas duras: Monto + Fecha ±3d)]
           │
     ┌─────┴────────────────┐
     ▼                      ▼
[Matches Directos]    [Excepciones y Glosas Ambiguas]
(95%+ confianza)            │
                            ▼
           [Capa 3: Agente LLM Local (Llama 3 / Mistral en VPC)]
                            │ Inferencia semántica + JSON Schema estricto
                            ▼
           [Capa 4: Matriz de Validación y Auditoría Humana]
                            │ Sincronización API
                            ▼
                        [ERP Final]

1. Ingestión y sanitización local

Los extractos bancarios en PDF se procesan mediante parsers de documentos locales (como Docling o bibliotecas OCR de código abierto si son escaneos). Los datos se limpian y estructuran en un esquema unificado:

• fecha_operacion
• monto
• tipo_movimiento (cargo/abono)
• glosa_cruda
• id_referencia_bancaria

2. Filtro determinista previo (Early exit)

No es necesario pasar cada fila por un modelo de lenguaje. El 60-70% de las transacciones coincidentes de forma idéntica en monto exacto, fecha (con una ventana de ±3 días) e identificador tributario se resuelven mediante código determinista en milisegundos. Esto ahorra cómputo y reserva la IA para los casos complejos.

3. Razonamiento semántico con modelos locales

Para el 30-40% restante (glosas truncadas, pagos consolidados donde una transferencia cubre tres facturas distintas, o deducción de retenciones de impuestos), entra en juego el agente local.

Utilizamos modelos de 8B a 70B parámetros (por ejemplo, variantes optimizadas de Llama 3 o Qwen 2.5) servidos mediante engines de inferencia de alto rendimiento como vLLM o TGI dentro de la red privada del cliente. Al agente se le inyecta:

• El registro bancario no conciliado.
• Un subconjunto acotado de facturas pendientes que calzan en monto o ventana temporal.
• Historial previo de conciliaciones aprobadas para aprendizaje en contexto (few-shot learning).

El modelo debe responder exclusivamente en formato JSON estructurado, indicando:

• ID de la factura sugerida.
• Nivel de certeza (0.0 a 1.0).
• Justificación técnica del cruce (ejemplo: "Monto bancario corresponde a Factura #402 descontando la retención del 3% estipulada en el contrato").

4. Gobernanza y Human-in-the-Loop

Las coincidencias con certeza superior al 95% pueden auto-conciliarse en el ERP. Las que caen entre 70% y 94% se presentan en una interfaz de revisión para el contador con un solo clic de aprobación. Las transacciones bajo el 70% se marcan como anomalías para investigación.

Manejo de casos de borde críticos en finanzas

Un agente de finanzas no puede alucinar. En software contable, un error de un centavo detiene un cierre de mes. Para garantizar precisión absoluta:

• Cálculo matemático fuera del LLM: El modelo nunca debe sumar o restar en texto libre. El LLM solo propone relaciones (Factura A + Factura B = Transacción C); un validador en Python verifica algebraicamente que la suma de los montos coincida al centavo antes de escribir en la base de datos.
• Restricción de esquema gramatical (Constrained Decoding): Mediante herramientas como Outlines o SGLang, se obliga al modelo a responder únicamente bajo un esquema Pydantic predefinido, eliminando el riesgo de respuestas conversacionales o formatos inválidos.
• Aislamiento de red: La instancia de cómputo donde corre el modelo no tiene conexión a internet saliente. Los datos no abandonan la infraestructura de la empresa en ningún punto del pipeline.

Pasar del prototipo al entorno productivo

Construir un script que concilie 10 filas de Excel en un Jupyter Notebook es trivial. Llevarlo a producción para procesar 10.000 operaciones diarias integradas bidireccionalmente con el ERP corporativo, con control de latencia y trazabilidad de auditoría, exige ingeniería de modelos robusta.

En Personnn desarrollamos este tipo de infraestructuras a través de ModelForge, adaptando, optimizando y desplegando modelos de pesos abiertos ajustados a la terminología contable y bancaria de cada región, operando de forma 100% aislada y soberana para garantizar el cumplimiento normativo que los equipos de finanzas necesitan.