Automatización con aprobación humana: cómo diseñar la compuerta
La compuerta de aprobación no es un freno: es el diseño. Qué acciones exigen aprobación por acción, cuáles por lote y cuáles notificación con ventana; qué debe registrar la bitácora para valer algo — incluido el campo que casi nadie escribe — y por qué un botón de paro que nadie probó no es un botón de paro.
La compuerta no es el freno: es el diseño
La objeción más común cuando alguien escucha "automatización con aprobación humana" es que suena a lo peor de los dos mundos: la complejidad de un sistema automático más la lentitud de esperar a que alguien apruebe. Es una objeción razonable y equivocada, por una razón que se entiende mejor invirtiendo la pregunta.
Sin compuerta, la decisión no desaparece. Se adelanta. Alguien decidió — en el momento de construir el flujo, sin datos del caso concreto y sin quedar registrado — que todas las ejecuciones futuras se ejecutarían. La compuerta no agrega una decisión: mueve la decisión al momento en que existe información para tomarla, y deja constancia de quién la tomó.
Lo que sigue es cómo se diseña esa compuerta: qué se aprueba, con qué granularidad, qué queda escrito y cómo se detiene todo si hace falta.
Qué acciones exigen compuerta
La regla base de un sistema gobernado es que nada que produzca un efecto se ejecuta sin visto bueno. La pregunta de diseño no es si hay compuerta, sino cómo se configura para cada clase de acción. Cuatro preguntas ordenan casi cualquier flujo:
¿Es reversible? Escribir un renglón en una hoja interna se deshace en segundos. Cancelar un CFDI, transferir dinero o borrar un registro maestro, no. La irreversibilidad es el criterio más fuerte y el menos discutible.
¿Es visible fuera de la empresa? Un correo a un cliente, un mensaje a un proveedor, una publicación: el flujo no puede recogerlos. Aunque el efecto interno sea nulo, la acción ya salió de tu control.
¿Tiene consecuencia económica o fiscal? Emitir, cancelar, pagar, aplicar un descuento. Aquí la compuerta no es prudencia operativa: es la única forma de tener después una respuesta a "¿quién autorizó esto?".
¿Toca datos personales? Compartir, exportar o borrar información de personas cambia la naturaleza del riesgo y de la responsabilidad.
Del otro lado quedan las acciones de lectura, cálculo y preparación: consultar, comparar, clasificar, redactar un borrador, armar un expediente. Ese trabajo es donde la automatización rinde más y donde la aprobación por acción solo agrega fricción, porque el resultado todavía no toca nada. La regla práctica: automatiza la preparación completa, gobierna el momento del efecto.
Tres formas de configurar la compuerta
Elegida la clase de acción, la compuerta se configura de una de tres maneras. No son niveles de "cuánta gobernanza aceptas": son formas distintas de poner la decisión humana en el lugar correcto.
Aprobación por acción
Cada caso se presenta solo, con su contexto, y alguien lo autoriza o lo rechaza. Es la configuración correcta cuando la consecuencia es alta y el volumen bajo: la nota de crédito, el pago a proveedor nuevo, la baja de un registro maestro. Su costo es real — atención humana por caso — y por eso aplicarla a todo es un error de diseño: una bandeja con doscientas aprobaciones diarias no se revisa, se aprueba en bloque sin leer, y la compuerta se volvió un trámite decorativo.
Aprobación por lote
El flujo prepara todos los casos del periodo y los presenta juntos, con los renglones que se salen del patrón marcados arriba. La persona revisa el resumen, atiende las excepciones y autoriza el conjunto. Es la configuración correcta para volumen alto con consecuencia media y reglas estables: la corrida de recordatorios de cobranza del día, la carga de comprobantes de la semana.
La condición que la hace legítima: el lote tiene que llegar ordenado por riesgo, no en orden de llegada. Un lote que obliga a leer doscientos renglones iguales para encontrar los tres raros es una aprobación por acción disfrazada.
Notificación con ventana de objeción
La acción se programa, se avisa a la persona responsable y se ejecuta al cerrarse una ventana explícita — treinta minutos, dos horas — durante la cual cualquiera puede detenerla. Es la configuración correcta para acciones reversibles y repetitivas donde el costo de esperar aprobación activa supera al riesgo: el reporte que se envía cada lunes, la sincronización nocturna entre dos sistemas.
Aquí está el matiz que separa el gobierno real del teatro: la ventana solo vale si la objeción es efectiva. Si al oprimir "detener" la acción ya se ejecutó, no era una ventana; era un aviso. Y esa es exactamente la clase de detalle que hay que probar antes de la entrega, no descubrir en producción.
Qué debe registrar la bitácora para valer algo
Empecemos por el campo que casi ninguna bitácora incluye y que es el que la vuelve útil: qué habría pasado. El estado previsto antes de ejecutar — qué registros iba a tocar, con qué valores, sobre cuántos casos.
Sin ese campo, una entrada aprobada solo dice que alguien dijo que sí; no dice a qué. Y una entrada rechazada o detenida no dice absolutamente nada, porque no hubo efecto que registrar: el evento más importante de tu bitácora — la vez que la compuerta funcionó — quedaría en blanco. Registrar el contrafactual convierte cada rechazo en evidencia de que el control opera, que es justo lo que un auditor quiere ver y lo que un flujo sin gobierno nunca puede mostrar.
Con ese campo puesto, la lista completa de lo que una entrada tiene que llevar es corta:
- Quién. La persona que aprobó o rechazó, identificada individualmente. "El sistema" y "el área de operaciones" no son respuestas.
- Qué. La acción concreta, no su categoría: no "actualización de registro", sino qué campo, de qué registro, de qué valor a qué valor.
- Cuándo. Fecha y hora de la ejecución y de la aprobación. Cuando ambas coinciden al segundo en cada entrada, alguien está aprobando sin leer, y la bitácora lo delata.
- Sobre qué datos. La entrada que originó la corrida, identificable después: el correo, el archivo, el folio.
- Qué habría pasado. El contrafactual de arriba.
- Cuál fue el resultado. Ejecutado, rechazado, detenido, fallido — y, si falló, el error tal cual.
Dos propiedades cierran el diseño. La bitácora es inmutable: se corrige agregando un renglón que anula al anterior, nunca editando el original — un registro que se puede reescribir no prueba nada. Y es legible por quien no construyó el flujo: si hace falta el proveedor para interpretarla, no sirve para lo que existe.
La reversa es requisito de diseño, no plan de emergencia
Un flujo no debería correr por primera vez sin que exista, por escrito, el procedimiento para deshacer lo que hizo. No como plan de contingencia: como parte del diseño, escrita antes de la primera ejecución real.
El motivo es que la reversa es una prueba de comprensión. Si no puedes describir cómo se deshace una acción, es porque no tienes claro qué toca exactamente ni en qué orden — y ese es justo el flujo que no debería estar ejecutando nada sin supervisión.
Hay acciones cuya reversa es imposible por naturaleza: un correo enviado no se retira, un pago aplicado no se deshace unilateralmente. Ahí la reversa no es técnica sino operativa, y también se escribe: a quién se avisa, con qué mensaje, en cuánto tiempo. Una acción sin reversa posible es, por definición, una acción que exige aprobación por acción.
Un botón de paro que nadie probó no es un botón de paro
El botón de paro es la promesa más fácil de hacer y la más fácil de incumplir sin darse cuenta. La versión que falla se ve así: el botón detiene la programación futura pero no la corrida en curso; o marca el flujo como pausado mientras la cola ya despachada sigue ejecutándose; o requiere permisos que solo tiene quien construyó el sistema — exactamente la persona que puede no estar disponible el día que hace falta.
La única forma de saber que existe es apretarlo. Con el flujo corriendo sobre datos de prueba, la persona que va a operarlo — no el proveedor — lo oprime, y se verifica lo único que importa: que se detuvo, en cuánto tiempo, en qué estado quedó lo que iba a medias y qué muestra la bitácora. Eso es un criterio de aceptación, y merece estar en el documento de alcance junto con los demás.
Por qué en México esto no es opcional
Dos realidades vuelven la evidencia obligatoria, y ninguna es hipotética.
El SAT. Si tu automatización toca facturación, toca CFDI 4.0 — un documento fiscal con requisitos estrictos de emisión y cancelación. Un flujo que emite o cancela comprobantes sin registro de qué hizo, cuándo, con qué dato y bajo qué autorización es un pasivo esperando revisión.
ISO 9001. La norma exige información documentada y trazabilidad sobre los procesos que afectan la calidad. Cuando el auditor pregunta quién aprobó una salida y con qué criterio, un script suelto no tiene respuesta; un flujo gobernado la tiene impresa, con nombre y hora.
En ambos casos la evidencia se produce sola si la bitácora se diseñó al principio, y se reconstruye a mano —con el costo y la duda que eso implica— si se dejó para después.
El punto que resume todo
Automatización gobernada significa cuatro cosas concretas, y las cuatro son verificables: compuertas de aprobación, bitácora de auditoría de cada acción, botón de paro y procedimiento de reversa documentado. No son características de venta: son las condiciones que hacen que un sistema automático se pueda defender ante un cliente, un auditor o la autoridad fiscal.
Un flujo que corre bien pero no se puede explicar no es un activo. Es un riesgo con buena productividad.
Empieza por saber dónde estás
Nuestro diagnóstico gratuito toma 3 minutos y entrega un puntaje de madurez con recomendaciones priorizadas por impacto — sin tarjeta y sin llamada obligatoria.
Cada automatización que construimos se entrega con las cuatro condiciones de arriba, alcance fijo por escrito y capacitación para que tú la operes. La oferta completa está en simiriki.com/automatizacion.
---
Fuentes citadas en este artículo:
- SAT (México) — CFDI 4.0, requisitos de emisión y cancelación de comprobantes fiscales digitales (Anexo 20)
- ISO 9001:2015 — información documentada y trazabilidad de procesos
- Las condiciones de gobierno, plazos y alcance corresponden a la oferta vigente en /automatizacion
¿Qué proceso te está costando más horas?
El Diagnóstico gratuito toma 3 minutos, te da un puntaje de madurez operativa y nombra el proceso por el que conviene empezar. Sin tarjeta y sin llamada obligatoria.