IA en el medio, RPA en los bordes y personas antes del efecto irreversible
Por Equipo Quantum Developers
Resumir:
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.
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.
La arquitectura híbrida de referencia
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.
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.
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.
Cómo representarlo en Quantum
La capacidad pública de conciliación de medios de pago aporta el contexto de negocio. En Quantum Automation Center, el objeto puede reunir estado, ejecuciones, línea de tiempo, artefactos, logs y aprobación humana. La ontología pública de Quantum ayuda a mantener una identidad de negocio común entre agentes y automatizaciones.
Quantum no vuelve determinística una interpretación ni sustituye la política financiera. Su valor en esta arquitectura es hacer visibles los límites: qué componente propuso, cuál validó, quién aprobó, qué robot ejecutó y qué lectura verificó.
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.
Sources
Temas del artículo
