Imagina dos escenarios con la misma factura.
En el primero, un pago de USD 480,000 a un proveedor con cuenta bancaria recién modificada sale un viernes por la tarde. El lunes, tu herramienta de gobernanza lo marca en rojo en un panel muy bien diseñado: "Anomalía detectada: cambio de cuenta bancaria previo al pago". Tienes la alerta, el gráfico y el historial. El dinero ya se fue.
En el segundo, el mismo pago queda retenido el viernes. Nadie lo libera hasta que una persona distinta de quien registró el cambio de cuenta confirma, con evidencia, que el cambio es legítimo. Tienes la misma alerta, el mismo historial. Y el dinero sigue en tu cuenta.
El primer escenario es un dashboard. El segundo es un control. Ambos son útiles, pero solo uno de ellos protege. Y en el mercado, ambos se venden bajo la misma palabra: "gobernanza".
1. Qué es cada cosa, en términos de auditoría
Los auditores llevan décadas con un vocabulario preciso para esto, y conviene tomarlo prestado:
- Control preventivo: actúa antes de que la transacción se complete y puede detenerla. Ejemplo: el sistema rechaza un pago a un proveedor no aprobado.
- Control de aprobación (compuerta): actúa durante; la transacción espera a que una persona autorizada decida. Ejemplo: pagos sobre cierto umbral requieren doble firma.
- Control detectivo: actúa después y señala lo que ya ocurrió. Ejemplo: un reporte semanal de pagos duplicados.
Un dashboard es, en el mejor de los casos, un control detectivo. No hay nada de malo en eso: los controles detectivos son necesarios. El problema aparece cuando se presentan como si fueran preventivos, o cuando se usan como único mecanismo para una decisión que es irreversible.
2. Por qué importa tanto la irreversibilidad
No todo error cuesta lo mismo después. Corregir un asiento mal clasificado es una tarde de trabajo. Recuperar una transferencia enviada a una cuenta equivocada es una conversación con un banco y, a veces, un proceso que no termina bien. Un acceso concedido a la persona equivocada ya fue usado cuando lo detectas.
Por eso la pregunta útil no es "¿puedo ver lo que pasó?", sino "¿qué decisiones de mi proceso son irreversibles o muy costosas de revertir, y qué hay parado delante de cada una?". Si la respuesta a lo segundo es "un reporte", ya sabes dónde está el hueco.
"Un dashboard responde a '¿qué pasó?'. Un control responde a '¿qué puede pasar?'. Un comité de auditoría pregunta lo segundo."
3. Las cinco pruebas del comprador
No necesitas ser técnico para aplicarlas. Son preguntas que puedes hacer en cualquier demostración, y las respuestas vagas ya son una respuesta.
Prueba 1: la prueba del bloqueo
"Muéstrame, en vivo, una transacción que la herramienta impida que se complete." Si lo único que puede mostrarte es una alerta, una notificación o un color distinto en una tabla, estás frente a un dashboard. Un control real puede enseñarte el estado "retenido" y qué se necesita para liberarlo.
Prueba 2: la prueba del rodeo
"¿Qué pasa si alguien ejecuta la operación directamente en el ERP, el banco o el archivo de pagos, sin pasar por tu herramienta?" Si la respuesta es "entonces no lo vemos" o "lo detectaríamos después", el control es opcional: solo funciona cuando todos deciden usarlo. Un control robusto está en la ruta obligatoria, o bien tiene una verificación independiente de lo que efectivamente se ejecutó.
Prueba 3: la prueba de quién puede abrir la puerta
"¿Quién puede cambiar la regla, subir el umbral o liberar una retención? ¿Puede ser la misma persona que inicia la operación?" Un control que puede apagar quien se beneficia de apagarlo es una sugerencia. Aquí es donde la segregación de funciones deja de ser teoría; lo desarrollamos en por qué la segregación de funciones no desaparece con la automatización: se traslada.
Prueba 4: la prueba del fallo
"Si el sistema que evalúa la regla falla, se cae o no puede decidir, ¿la operación se detiene o continúa?" Un control que falla abierto (deja pasar todo cuando algo se rompe) protege solo mientras todo funciona bien, que es justo cuando menos lo necesitas. Para decisiones de alto riesgo, lo correcto es fallar cerrado: ante la duda, se retiene y se escala a una persona.
Prueba 5: la prueba de la evidencia
"Para una decisión específica de hace tres meses, ¿puedes mostrarme qué regla se evaluó, qué datos vio, quién la aprobó o la rechazó y cuándo?" Aquí un buen dashboard sí tiene su lugar: es la capa de evidencia. Un control sin bitácora no es auditable, y un auditor lo tratará como si no existiera. Lo que se espera de esa evidencia lo explicamos en lo que el cumplimiento SOX realmente exige a un proceso automatizado.
4. Cómo se ve cada respuesta en la práctica
| Prueba | Respuesta de un dashboard | Respuesta de un control |
|---|---|---|
| Bloqueo | "Te avisamos de inmediato." | "La operación queda retenida hasta aprobarse." |
| Rodeo | "Lo veremos en el siguiente reporte." | "No existe otra ruta, o se concilia contra lo ejecutado." |
| Quién abre la puerta | "El administrador configura las alertas." | "Cambiar reglas y liberar retenciones requiere roles distintos." |
| Fallo | "El proceso continúa; se revisa después." | "Ante la duda, se retiene y se escala." |
| Evidencia | "Puedes ver el estado actual." | "Bitácora por decisión: regla, datos, aprobador, hora." |
5. No todo debe bloquearse (y eso también es diseño)
Sería un error concluir que la respuesta es poner una compuerta en cada paso. Un proceso donde cada transacción espera aprobación humana es lento, caro y termina entrenando al equipo para aprobar sin leer. El diseño sensato es por niveles de riesgo:
- Riesgo bajo y reversible: la operación procede y queda registrada. Basta un control detectivo y una revisión por muestreo.
- Riesgo medio: procede automáticamente si cumple reglas explícitas; lo que no encaja se desvía a una persona.
- Riesgo alto o irreversible: requiere aprobación previa de alguien con la autoridad adecuada, distinta de quien lo originó. Es el caso de cambios de datos bancarios, pagos por encima de cierto monto, altas de proveedores y accesos privilegiados.
Esta misma lógica aplica cuando el que actúa es un agente de IA: la autonomía se otorga por nivel de riesgo, no por entusiasmo. Cómo se reparte la responsabilidad cuando algo sale mal lo vemos en quién responde cuando un agente de IA se equivoca en finanzas.
Una lista para llevar a tu próxima evaluación
Antes de calificar una herramienta como "gobernanza", pídele que responda por escrito estas preguntas:
- ¿Cuáles de nuestras decisiones irreversibles pasan por una compuerta de aprobación, y cuáles solo generan una alerta?
- ¿Existe alguna ruta que evite el control? ¿Cómo se detecta si alguien la usa?
- ¿Quién puede modificar reglas, umbrales y retenciones, y esa persona puede ser también quien inicia operaciones?
- ¿El control falla abierto o cerrado cuando el sistema no puede decidir?
- ¿Qué evidencia queda por cada decisión, y cuánto tiempo se conserva?
Si las respuestas son sólidas, tienes controles. Si lo que recibes son capturas de pantalla de paneles bonitos, tienes visibilidad, que vale la pena tener, pero que conviene llamar por su nombre. Y si quieres contrastar el mapa de decisiones irreversibles de tu proceso con alguien que lo haya hecho antes, escríbeme.