En toda demostración de un proceso automatizado, el camino feliz es el que se muestra: la orden entra, se valida, se aprueba, se registra. El camino alternativo es el que se vive: falta un dato, el proveedor mandó otro formato, el monto se pasa del umbral, el cliente pidió una variante, el sistema de afuera no responde.

La mayoría de los proyectos diseña el primer camino con cuidado y descubre el segundo en producción, un caso por vez, normalmente en manos de la persona con menos contexto. Este artículo explica por qué eso no es un detalle de implementación y qué conviene decidir antes de poner el proceso a correr.

Por defecto, una excepción no se resuelve: rompe o improvisa

La documentación de AWS Step Functions lo dice sin rodeos: cuando un estado informa un error, el comportamiento por defecto es fallar toda la ejecución del flujo. El sistema no elige un camino razonable; se detiene. Recién ahí aparecen las herramientas diseñadas para eso: capturar el error, reintentar o implementar un protocolo de manejo de fallos. Sin ese diseño previo, la excepción tiene apenas dos destinos posibles: frenar todo, o que alguien la resuelva por fuera del proceso, en una planilla, un correo o la memoria de quien se acuerda.

Del lado del modelado de procesos, Camunda describe el mismo punto de partida: en la automatización de procesos aparecen con frecuencia desviaciones del escenario por defecto. Su respuesta es nombrarlas: un error debe definir un código, y ese código es el que determina qué evento lo captura. Y agrega algo más importante: cuando un error se lanza y nadie lo captura, se levanta un incidente que indica la falla. Lo que no está previsto no desaparece: queda visible como incidente, o queda escondido en trabajo manual. No hay una tercera opción.

Dos reacciones distintas para dos desvíos distintos

Camunda recomienda separar con claridad las reacciones de negocio de las técnicas. Una falla transitoria —el servicio de pagos no responde durante unos minutos— no debería aparecer dibujada como un caso de negocio en cada tarea: se resuelve con reintentos o con la mecánica de incidentes, de forma genérica. En cambio, un caso que cambia la decisión —un renglón sin factura, un cliente fuera de política, un monto que exige aprobación— sí merece un camino explícito dentro del proceso.

La confusión entre ambos produce dos síntomas conocidos: modelos de proceso tan cargados de manejos técnicos que nadie los puede leer, o fallas técnicas tratadas como decisiones de negocio que llegan a una persona que no puede hacer nada con ellas. Camunda lo resume con un criterio práctico: importa menos de dónde venga el error y más cómo se reacciona ante él. Una falla técnica puede ameritar una reacción de negocio —seguir adelante con una calificación provisoria en lugar de bloquear todo—, y una decisión de negocio mal enrutada no es más que ruido.

Que la revisión humana esté diseñada, no improvisada

Cuando la excepción termina en una persona, esa persona es parte del sistema y merece ser diseñada como tal. El artículo 14 del Reglamento europeo de IA (AI Act), dedicado a la supervisión humana, exige que los sistemas de alto rieso se diseñen —incluidas las interfaces persona-máquina— para poder ser supervisados efectivamente mientras se usan, y que las medidas de supervisión sean proporcionales al riesgo, al nivel de autonomía y al contexto de uso, ya sea que estén construidas en el sistema o que correspondan implementarle a quien lo despliega.

La traducción operativa es concreta. El artículo pide que quien supervisa esté en condiciones de: comprender las capacidades y los límites del sistema y detectar anomalías o funcionamientos inesperados; ser consciente del sesgo de automatización, esa tendencia a aceptar la salida sin cuestionarla; interpretar correctamente la salida; decidir no usar el sistema o ignorar, sobreescribir o revertir su salida; e intervenir o interrumpirlo hasta dejarlo en un estado seguro.

No es normativa aplicable a todo proyecto de automatización en Argentina, y el AI Act tiene fechas propias de aplicación. Pero como lista de requisitos para diseñar el puesto que recibe la excepción es difícil de mejorar: información para interpretar, margen para discrepar y autoridad real para frenar. Sin las tres, la revisión humana es un trámite que confirma lo que la máquina ya decidió.

Lo que frena el escalado no es la tecnología

El panorama de IBM sobre automatización de procesos de negocio describe los obstáculos reales del crecimiento: lo que funciona para un conjunto de tareas no se adapta fácilmente a otro; sincronizar a las personas con los sistemas automatizados es complejo y puede exigir formación y ajuste cultural; y muchas iniciativas se estrellan contra la falta de documentación de los procesos. Su recomendación es directa: los procesos deben estar bien documentados y debe existir una estrategia para identificar y superar esos obstáculos.

También da el ejemplo donde más se ven estas decisiones: en finanzas y compras, la automatización enruta facturas con vencimiento para aprobación, concilia orden de compra contra factura y procesa pagos. Todo ese circuito funciona hasta que la factura no coincide con la orden. Ahí no falla la tecnología de enrutamiento: lo que falta —o lo que falla— es el camino del caso que no coincide.

Cinco decisiones que conviene tomar antes del go-live

Nombrar cada excepción. Lista corta y explícita: dato faltante o inválido, caso fuera de alcance, umbral de monto o de riesgo que exige aprobación, conflicto entre reglas, sistema externo no disponible. Si no tiene nombre ni código, no se puede enrutar, ni contar, ni mejorar.
Definir dónde aterriza cada una. Qué cola o persona la recibe, y con qué contexto: los datos del caso, qué intentó el sistema, por qué lo rechazó y qué opciones tiene. Una excepción sin contexto es una orden de trabajo a medio armar; la persona termina reconstruyendo lo que el sistema ya sabía.
Definir opciones, plazo y fallback. Aprobar, devolver, rechazar, escalar. Con un plazo explícito y, sobre todo, con un destino para cuando nadie responde: que el caso quede en pausa o vuelva al solicitante. Nunca que siga como si estuviera resuelto.
Separar reacción de negocio de reacción técnica. Reintentos y manejo genérico de fallas transitorias por un lado; caminos explícitos para los casos que cambian la decisión, por el otro. No conviene mezclarlos en el mismo plano del modelo.
Cerrar el circuito de aprendizaje. Cada resolución debería poder modificar el camino principal: un criterio ajustado, un dato corregido en origen, una regla aflojada o endurecida. Si las excepciones se resuelven y no dejan rastro, el proceso acumula trabajo manual sin acumular aprendizaje.

Un punto que suele quedar afuera y conviene nombrar: lo que no está capturado tiene que volverse visible. Camunda lo modela como incidente; en otros términos, una excepción sin dueño debe aparecer en una cola o un tablero, no perderse. El trabajo manual que no se ve es el que vuelve a aparecer meses después, medido como un proceso que nunca funcionó del todo.

El camino feliz se diseña; el otro se descubre

Ningún equipo elige descubrir las excepciones en producción. Simplemente pasa: el camino feliz se diseña, se prueba y se muestra, y el camino alternativo se descubre de a un caso, cuando el proceso ya está corriendo y el cliente ya está esperando.

La buena noticia es que diseñarlo no requiere un proyecto aparte. Requiere nombrar los desvíos, enrutarlos con contexto, poner plazo y fallback, separar lo técnico de lo de negocio y dar a quien revisa la información y la autoridad para discrepar. Es el trabajo que separa una automatización que corre de una que se puede sostener.

La pregunta útil antes del go-live no es qué pasa cuando todo sale bien. Es qué pasa con el primer caso que no entra en la regla.

Fuentes

AWS - Handling errors in Step Functions workflows: por defecto un error de estado falla toda la ejecución; capturar errores, reintentar y protocolos de manejo de fallos son herramientas que se diseñan, no consecuencias automáticas.
Camunda 8 Docs - Error events: las desviaciones del escenario por defecto son esperables; el código de error decide qué evento lo captura; un error no capturado levanta incidente; separar reacciones de negocio (modeladas en el proceso) de las técnicas (reintentos e incidentes).
EU AI Act - Article 14: Human Oversight: supervisión humana diseñada en el sistema, proporcional al riesgo y la autonomía; la persona debe poder detectar anomalías, awareness del automation bias, interpretar la salida, ignorar o revertirla, e intervenir o interrumpir el sistema.
IBM - What is business process automation?: obstáculos reales del escalado (lo que sirve para un conjunto de tareas no se adapta a otro, sincronía humano-sistema, falta de documentación) y el ejemplo de finanzas/compras con facturas que no coinciden con la orden.