Qué debe pasar cuando una automatización falla a las 03:00

Toda automatización fallará alguna vez. Una API cambia de formato, un proveedor deja de responder, llega un documento que nadie había previsto o caduca una credencial. Lo que diferencia un flujo de demostración de uno preparado para el trabajo real es lo que ocurre cuando falla.

La prueba que uso es sencilla. Si esta automatización falla un sábado a las 03:00, ¿quién se entera, cuándo y qué se ha perdido?

El peor fallo es el que no avisa

Un error que lo detiene todo es molesto, pero visible. El fallo peligroso es el silencioso. El flujo parece funcionar, pero deja de registrar pedidos, avisa a quien no corresponde o duplica facturas. Se descubre días después, cuando reclama un cliente o no cuadra el cierre.

Por eso cualquier automatización que pongo en marcha tiene, como mínimo, estas piezas.

1. Registros que se pueden consultar

Cada ejecución deja constancia de qué entró, qué hizo y qué salió. No hace falta un sistema complejo, pero alguien tiene que poder responder a «¿se registró el pedido 4521?» sin revisar código.

Unos buenos registros permiten:

• Saber qué ha pasado sin reproducir el error.
• Volver a procesar solo lo que falló.
• Demostrar lo que hizo el sistema ante una reclamación.

2. Avisos a una persona concreta

Un error que solo aparece en un panel que nadie mira es un error silencioso. Los avisos deben llegar a una persona responsable, por el canal que utiliza a diario, y con información suficiente para actuar: qué falló, con qué dato y qué hacer.

También hay que evitar el extremo contrario. Si el sistema avisa de todo, nadie lee los avisos. Conviene distinguir lo que requiere acción inmediata de lo que puede esperar al lunes.

3. Reintentos con límites

Muchos fallos son temporales, como una API que no responde durante unos minutos. Un nuevo intento automático, espaciado en el tiempo, resuelve la mayoría sin intervención. Un reintento mal planteado puede empeorar las cosas:

• Si repetir la operación no da el mismo resultado, reintentar puede duplicar un cobro o un registro.
• Si se reintenta sin límite, se satura al proveedor o se agota la cuota de uso.

La regla es reintentar lo temporal un número limitado de veces y asegurarse de que repetir una operación no la duplica.

4. Una cola para no perder nada

Cuando un sistema de destino no está disponible, lo que llega no debería perderse. Guardar las operaciones pendientes en una cola permite procesarlas cuando el sistema vuelva, en orden y sin intervención manual.

5. Excepciones separadas de errores técnicos

No todo lo que no encaja es un error técnico. Un documento ilegible, un cliente que no existe o un importe fuera de rango son excepciones del proceso. El sistema funciona, pero el caso necesita el criterio de una persona. Esos casos deben ir a una bandeja de revisión con el motivo, donde una persona del proceso pueda entenderlos y decidir.

6. Vuelta atrás prevista

Antes de poner en marcha un cambio, conviene saber cómo volver al estado anterior: desactivar el flujo, recuperar temporalmente el proceso manual o restaurar datos. Si nadie sabe cómo deshacerlo, el cambio es más arriesgado de lo que parece.

En sistemas con datos críticos, esto incluye copias de seguridad que se han probado a restaurar. Una copia que nunca se ha restaurado es una hipótesis.

7. Un responsable interno

Toda automatización necesita a alguien en la empresa que entienda qué hace, reciba los avisos del proceso y decida sobre las excepciones. Sin responsable, el flujo se deteriora poco a poco cuando cambian las personas o el proceso.

8. Vigilar el resultado, no solo el servidor

Que el servidor esté activo no garantiza que el proceso funcione. La monitorización útil vigila el resultado. «Hoy se han registrado cero pedidos cuando lo normal son cien» es un aviso más valioso que «el procesador está al 90 %».

Si hay IA en el flujo

Cuando una parte del proceso usa un modelo de IA, aparecen fallos propios: respuestas incorrectas que parecen correctas, cambios de comportamiento al actualizar el modelo o costes que se disparan. Las medidas anteriores siguen siendo válidas, y se añaden dos:

• Umbral de confianza. Por debajo de ese nivel, el caso pasa a revisión humana.
• Conjunto de evaluación. Casos reales que se prueban antes de cada cambio para detectar si el resultado empeora.

Una lista para revisar tus automatizaciones

1. ¿Queda registro de cada ejecución y se puede consultar sin tocar código?
2. ¿Quién recibe los avisos y por qué canal?
3. ¿Qué pasa si el sistema de destino no responde?
4. ¿Reintentar puede duplicar algo?
5. ¿A dónde van las excepciones del proceso?
6. ¿Cómo se vuelve atrás?
7. ¿Quién es el responsable interno?
8. ¿Se vigila el resultado del proceso o solo el servidor?

Si varias respuestas son «no lo sé», la automatización funcionará hasta el día en que deje de hacerlo. Revisar y reforzar flujos existentes forma parte de la automatización de procesos y del mantenimiento que ofrezco después de cada implantación.