Reglas, IA y revisión humana en la conciliación de pagos
5 min de lectura
Una conciliación financiera no necesita elegir entre “todo con RPA” y “todo con un agente”. Ambos extremos mezclan trabajos incompatibles. RPA es fuerte al repetir una secuencia conocida; IA puede interpretar una excepción ambigua; una persona debe conservar autoridad sobre un registro o movimiento difícil de revertir. **La arquitectura de referencia pone RPA en los bordes determinísticos, IA en el centro ambiguo y personas antes del efecto irreversible.**
Resumir con IA
La arquitectura híbrida de referencia
Este artículo desarrolla un control específico del proceso de conciliación automatizada: conserva separadas la venta, la liquidación y la confirmación del abono.
La decisión de diseño no depende de qué tecnología sea más moderna. Depende de variabilidad, verificabilidad y reversibilidad. Un paso con entrada estructurada, regla estable y resultado comprobable no necesita razonamiento probabilístico. Una excepción con texto libre y evidencia incompleta no debería forzarse a una macro rígida. Y ninguna de las dos tecnologías debería aprobar su propio efecto material.
El flujo puede organizarse en ocho capas con contratos explícitos:
- Captura y bloqueo del lote. API o RPA recoge archivos y confirma que cada fuente tenga identidad, periodo y huella.
- Normalización determinística. Reglas convierten fechas, monedas, referencias y códigos a un esquema común; entradas inválidas quedan en cuarentena.
- Matching determinístico. Claves exactas, tolerancias aprobadas y estados de fuente resuelven casos explicables sin IA.
- Preparación de excepción. El sistema crea un objeto con diferencia, evidencia disponible, razón preliminar y acciones permitidas.
- Clasificación asistida por IA. El modelo interpreta texto o contexto, propone categoría y explica qué evidencia soporta la recomendación.
- Gate de política. Reglas externas al modelo verifican monto, segregación, estado, confianza, permisos y prohibiciones.
- Aprobación y ejecución. Una persona autoriza el efecto material; API o RPA registra la decisión de manera idempotente.
- Verificación y ledger. Una lectura independiente confirma el estado remoto y vincula entrada, decisión, ejecución y resultado.
El estándar BPMN 2.0.2 de OMG ofrece una notación formal para procesos con tareas, eventos, gateways y participación humana. No obliga a esta arquitectura, pero aporta una disciplina importante: modelar explícitamente dónde cambia el tipo de trabajo y quién recibe el control.
Estructura común
Regla para asignar cada paso
Antes de escoger tecnología, clasifique el paso:
| Condición | Mecanismo principal | Motivo |
|---|---|---|
| Entrada estructurada y regla estable | Regla o API | Resultado reproducible y fácil de probar |
| Sistema legado sin API, interacción estable | RPA | Automatiza el borde sin delegar la decisión |
| Evidencia no estructurada y varias interpretaciones plausibles | IA asistiva | Resume y propone, sin ocultar incertidumbre |
| Acción material o difícil de compensar | Persona con gate técnico | Conserva autoridad y segregación |
| Confirmación posterior | Regla o lectura independiente | Verifica efecto en el sistema de registro |
La confianza declarada por un modelo no convierte una excepción en determinística. La transición debe depender también de completitud de evidencia, tipo de diferencia, política vigente y reversibilidad. Una recomendación bien redactada puede seguir siendo incorrecta.
Qué hacer cuando el importe coincide, pero la referencia no
Ejemplo ilustrativo: el POS tiene dos ventas de 120.000 COP en la misma tienda. El reporte del adquirente trae una operación de ese importe, pero su referencia no corresponde al número del ticket. Elegir la venta más cercana por fecha puede producir un cruce convincente y equivocado. Primero hay que comprobar si autorización, terminal, comercio o referencia del procesador permiten establecer una relación única.
La regla determinística debe distinguir cero, uno y varios candidatos. Un único candidato solo es aceptable si cumple los campos y tolerancias aprobados. Si quedan dos candidatos, una explicación generada por IA puede ayudar al revisor a encontrar soportes, pero no reemplaza el dato que falta. El estado de salida es pendiente de identificación, no conciliado con baja confianza.
Después de identificar la venta, todavía falta conciliar la liquidación y el abono. Una referencia correcta no demuestra que la comisión sea la pactada ni que el banco haya recibido el neto. Esas comprobaciones deben tener resultados separados, para que un cruce exitoso no oculte una diferencia económica.
El revisor debe poder reconstruir qué archivos se leyeron, qué versión de la regla se aplicó y por qué se aceptó un candidato. Si se modifica la regla, la prueba debe incluir operaciones conocidas que antes daban cero, uno y varios candidatos. Medir solo el porcentaje de cruces aumenta el riesgo de premiar coincidencias falsas.
El contrato del objeto de conciliación
Todas las capas deben trabajar sobre la misma identidad. Un objeto mínimo incluye:
| Campo | Función de control |
|---|---|
| reconciliation_id | Une el caso entre sistemas y ejecuciones |
| source_items | Referencia inmutable a movimientos y documentos |
| observed_at | Separa el tiempo del dato del tiempo de captura |
| difference | Importe, moneda, campo o estado que no concilia |
| reason_code | Categoría estable, aunque cambie la explicación |
| evidence_refs | Artefactos que soportan la clasificación |
| proposed_action | Verbo y parámetros permitidos |
| policy_version | Reglas aplicadas antes de autorizar |
| decision | Aprobación, rechazo o solicitud de información |
| execution_ref | Identidad idempotente de la escritura |
| verified_state | Estado leído después de ejecutar |
El modelo W3C PROV distingue entidades, actividades y agentes, además de relaciones de derivación y responsabilidad. Aplicado aquí, los movimientos son entidades; normalizar, clasificar y registrar son actividades; software y personas son agentes con roles distintos. Esa estructura evita que una explicación del modelo se convierta en el único linaje.
Ejemplo ilustrativo: una referencia ambigua
Suponga que un movimiento bancario contiene una referencia abreviada que no coincide exactamente con una cuenta por cobrar. Los identificadores y condiciones son ilustrativos. La normalización valida fecha, moneda e importe; el matching exacto no encuentra clave. En lugar de probar combinaciones mediante RPA, el flujo crea una excepción.
La IA compara el texto con documentos autorizados y propone una cuenta candidata, citando los artefactos usados. El gate comprueba que la cuenta esté abierta, que el importe corresponda y que el agente no tenga permiso para aplicar el pago. Un analista acepta o rechaza. Solo entonces el robot abre el sistema legado, registra la aplicación con una clave idempotente y sale. Una lectura posterior confirma el estado; si no coincide, el caso permanece abierto.
Cada tecnología hizo el trabajo que puede demostrar. La IA no escribió; RPA no interpretó la ambigüedad; la persona no tuvo que recolectar manualmente toda la evidencia.
Fallas aisladas por capa
La arquitectura también define continuidad:
- si cambia el esquema, cuarentena antes de clasificar;
- si el modelo no está disponible, la cola ambigua espera sin detener matches exactos;
- si el gate de política falla, ninguna escritura material se libera;
- si RPA pierde confirmación, se consulta el estado remoto antes de reintentar;
- si falta aprobador, se escala sin convertir espera en aprobación;
- si la verificación difiere, el objeto no se marca como conciliado.
El NIST AI Risk Management Framework Core recomienda definir roles humano-IA, supervisión y controles para componentes y datos de terceros. Separar capas hace posible aplicar controles al componente que introduce el riesgo, en vez de tratar el agente como una sola caja.
El contrapunto: un agente de extremo a extremo es más simple
En apariencia, sí. Una sola interfaz que lee, decide y registra reduce orquestación inicial. Pero esa simplicidad concentra clasificación, permisos, reintentos y evidencia. Cuando una escritura queda dudosa, el equipo debe reconstruir si el error estuvo en interpretación, política o ejecución. La arquitectura híbrida acepta más contratos a cambio de pruebas y recuperación localizadas.
No agregue capas por estética. Si un paso puede expresarse como regla, manténgalo como regla. Si una API reemplaza la fragilidad de pantalla, retire RPA. Si la persona siempre rehace la recomendación, elimine IA o mejore el contexto antes de ampliar autonomía.
Cuándo no usar esta arquitectura
No use IA cuando claves y tolerancias estables resuelven todos los casos relevantes. No use RPA cuando el sistema ofrece una API confiable y auditable. No construya una cola inteligente si las excepciones ambiguas son tan raras que una revisión manual resulta más barata y clara.
Y no automatice el efecto material si no puede definir segregación, reversión y verificación independiente. La arquitectura híbrida no es una forma de evitar esas decisiones; es una forma de convertirlas en gates ejecutables y evidencia que sobrevive a cada componente.
- Candidato único con soporte
- Comisión validada por separado
- Abono confirmado en banco
