SUDEBAN y RPA: lo que la regulación exige a la automatización en banca.

Un robot RPA que ejecuta un proceso en una entidad financiera venezolana no es un script invisible. Es un actor que opera con credenciales, ejecuta operaciones contables, modifica estados de clientes, dispara reportes regulatorios y deja huella en sistemas core. Para SUDEBAN — y para cualquier auditoría interna seria — eso lo coloca al mismo nivel que un usuario humano: tiene que estar identificado, autorizado, supervisado y trazado.

Esa equivalencia operativa es el punto de partida. Cuando un equipo de TI pide "automatizar la conciliación bancaria diaria" sin pensar en el robot como entidad regulada, el resultado típico es una solución funcional que falla en el primer ciclo de auditoría — no porque haga algo mal, sino porque no puede demostrar lo que hace.

La normativa SUDEBAN no menciona "RPA" textualmente — la regulación bancaria venezolana es anterior al auge del RPA y habla en general de procesos automatizados, sistemas de información, controles internos y trazabilidad. Cuando aterrizas esos conceptos al diseño concreto de un robot, salen cuatro requisitos no negociables:

i. Identidad nominal del actor

Cada robot opera con una cuenta de servicio dedicada, nunca con credenciales personales reutilizadas. La cuenta tiene nombre, propósito documentado, ámbito de permisos mínimo necesario y un humano responsable asignado en el inventario de TI. Si la auditoría pregunta "¿quién hizo esta operación?", la respuesta es siempre identificable y rastreable.

ii. Trazabilidad de cada operación

Toda operación ejecutada por el robot deja registro estructurado: timestamp, identificador del proceso, payload de entrada, resultado, sistema destino, evidencia de respuesta. No basta el log de aplicación del sistema core — el orquestador del robot mantiene su propio audit trail consultable por el equipo de auditoría sin tener que pedirlo a TI.

iii. Evidencia documental archivable

Para los procesos con impacto regulatorio (reporting SUDEBAN, conciliaciones, validación KYC, generación de reportes IGTF), el robot guarda evidencia archivable durante el plazo de retención legal aplicable: ficheros generados, capturas o XMLs de envío, acuse de recibo del receptor, hash de integridad. La pregunta "¿se envió el reporte X el día Y?" tiene que poder responderse con un fichero, no con un log.

iv. Capacidad de rollback y control humano

Ninguna operación crítica se ejecuta sin posibilidad de reversión documentada. Si el robot procesa un lote y detecta anomalía a mitad de ejecución, hay un circuit breaker que detiene la operación y notifica a un humano antes de propagar el error. Las decisiones materiales — un asiento contable, un reporte regulatorio, una validación AML — pasan por gates con criterio explícito, no por flujo continuo sin interrupción.

La diferencia entre un RPA que pasa la auditoría y uno que la dispara no está en la calidad del código — está en si la documentación nació con el proyecto o se preparó tres días antes de la visita del auditor.

En entornos regulados, los entregables documentales se generan durante el desarrollo, no después:

• PDD (Process Definition Document): describe el proceso "as-is" antes de automatizar, con flujo, sistemas implicados, frecuencia, volumen y criterios de excepción.
• SDD (Solution Design Document): describe la solución "to-be" — arquitectura del robot, librerías, integraciones, manejo de excepciones, plan de pruebas.
• Business Case con estimación de ROI fundamentada, riesgo regulatorio identificado y plan de mitigación.
• Test cases UAT con cobertura de happy path, paths de error, y casos límite específicos del sector.
• Runbooks operativos para el equipo que opera el robot post go-live: cómo arrancar, parar, diagnosticar, escalar.

Cuando estos cinco entregables existen desde el día uno y se mantienen con el código, la auditoría regulatoria deja de ser un evento traumático y se convierte en una revisión rutinaria.

Hay una línea fina pero clara entre lo que se automatiza y lo que se asiste. En banca regulada, esa línea separa el cumplimiento del incidente reportable.

Lo que automatizamos sin pestañear: preparación, agregación, validación de formato, generación de documentos, envío masivo, conciliación cruzada, alertas tempranas. Procesos repetitivos de alto volumen donde la decisión está claramente codificada por reglas.

Lo que no automatizamos sin supervisión humana explícita:

• Decisiones crediticias: evaluar si se otorga un préstamo. El robot prepara el expediente, calcula scoring auxiliar y presenta evidencia — la decisión es del oficial.
• AML judgment: el robot detecta patrones y genera alertas; el oficial de cumplimiento decide si escala a la UNIF.
• Atención a clientes VIP o casos sensibles: nunca por flujo automatizado sin opción de derivación humana inmediata.
• Excepciones a normativa interna: el robot reconoce la excepción, la marca, y la deja en bandeja del responsable. No la resuelve.

Esta delimitación no es opinable: es lo que distingue un programa RPA maduro de un experimento que va a generar problemas regulatorios cuando escale.

Antes de empezar la conversación técnica con un proveedor RPA, los siguientes elementos definen si el proyecto puede pasar el primer ciclo de auditoría:

1. ¿Hay cuentas de servicio nominales aprovisionables por TI con permisos mínimos? Si la respuesta es "usaríamos la cuenta de Juan", la conversación se detiene ahí.
2. ¿Existe política interna de uso de robots aprobada por el área de cumplimiento, o se documenta como parte del proyecto? Sin política previa o nueva, hay vacío regulatorio.
3. ¿El proceso candidato tiene frecuencia y volumen documentados? Sin baseline, no hay forma de calcular ROI ni de detectar anomalías post go-live.
4. ¿Hay un responsable identificable para cada robot que se desplegará? "El equipo de TI" no es responsable: lo es una persona con nombre.
5. ¿La entidad mantiene plazo de retención de logs y evidencias alineado con la normativa aplicable, y el robot puede integrar a ese sistema?

Estos cinco puntos no son requisitos del proveedor RPA — son requisitos de la entidad que automatiza. Sin ellos, el robot puede funcionar técnicamente pero no operará dentro de un marco regulatorio sostenible.