Gestionar excepciones, aprobaciones y escalado

Una automatización fiable no elimina las excepciones: las hace visibles y las encamina. Cuando un caso no cumple las condiciones del flujo normal, el peor resultado es que desaparezca en un log o quede detenido sin responsable.

Las excepciones deben formar parte del diseño de negocio. BPMN permite representar eventos y rutas alternativas, pero el principio es independiente de la notación: cada condición no estándar relevante necesita un estado, un propietario y una salida posible.

Cuando interviene IA, además, la supervisión humana puede ser necesaria para determinados niveles de riesgo. El NIST AI RMF puede servir como marco voluntario para pensar en responsabilidades, monitorización y gestión de riesgos; no convierte por sí mismo ninguna revisión concreta en obligación jurídica.

Crea un catálogo de excepciones

Empieza por clasificar qué puede apartar un caso del recorrido normal.

Ejemplos:

• falta un dato obligatorio;
• existe una contradicción entre sistemas;
• una regla produce dos resultados incompatibles;
• una salida de IA no cumple el formato;
• la confianza o evidencia es insuficiente;
• un sistema externo está indisponible;
• una aprobación vence;
• una acción supera el límite de autonomía permitido.

Para cada excepción registra causa, detectabilidad, impacto, responsable y posible recuperación.

Convierte la excepción en un estado

Evita tratar la excepción únicamente como un error técnico. Si un documento necesita revisión, el caso puede pasar a requiere_revision_documental. Si falta una aprobación, a pendiente_aprobacion. Si la integración con ERP no confirma el resultado, a estado_incierto_erp.

Un estado explícito permite:

• medir cuántos casos llegan;
• asignar una cola;
• aplicar un SLA interno;
• conservar contexto;
• reanudar desde un punto conocido.

Separa revisión de aprobación

Revisar no significa autorizar. Una persona puede comprobar que una extracción documental es correcta sin tener autoridad para aprobar un pago o un contrato.

Diseña roles distintos cuando el proceso lo necesite:

• revisor: valida información o calidad;
• aprobador: toma una decisión autorizada;
• operador: resuelve una incidencia técnica u operativa;
• responsable de excepción: decide qué hacer con casos no contemplados.

No concentres todos los permisos en la misma cuenta administrativa por comodidad.

Diseña el paquete de contexto humano

Una revisión humana es ineficiente si obliga a reconstruir todo el caso desde cero. La cola debe mostrar la información necesaria para decidir:

• motivo de escalado;
• datos relevantes;
• evidencia original;
• propuesta del sistema o de la IA;
• reglas aplicadas;
• acciones permitidas;
• plazo;
• historial del caso.

Evita mostrar datos sensibles que no sean necesarios para la decisión.

Define plazos y escalado

Una aprobación pendiente puede convertirse en un nuevo cuello de botella. Define qué ocurre cuando nadie actúa.

Ejemplo:

• a las 4 horas: recordatorio;
• a las 24 horas: reasignación a suplente;
• a las 48 horas: escalar al responsable;
• al superar el plazo máximo: cancelar o devolver el caso a una fase anterior.

Los tiempos son específicos del proceso; no copies valores de ejemplo como si fueran universales.

Mantén las acciones humanas seguras ante repetición

Una persona puede pulsar dos veces un botón o abrir el mismo caso en dos pestañas. Las acciones humanas que producen efectos también necesitan protección contra duplicados y comprobación del estado actual.

Antes de aprobar, valida que el caso siga en pendiente_aprobacion y que la versión revisada sea la misma que se muestra. Si el contenido cambió, la aprobación anterior no debería aplicarse automáticamente a una versión nueva.

Ejemplo: descuento excepcional

El workflow calcula el descuento y aplica reglas ordinarias. Cuando la solicitud supera el umbral configurado, pasa a requiere_aprobacion_comercial.

La persona aprobadora ve importe, cliente, margen de referencia, motivo de la excepción y versión del presupuesto. Puede aprobar, rechazar o solicitar cambio. Cada acción genera un evento distinto y queda asociada a la versión concreta.

Si el caso cambia después de la aprobación —por ejemplo, se modifica el importe— vuelve al estado de revisión. La automatización no reutiliza una autorización sobre datos diferentes.

Usa las excepciones como señal de mejora

El catálogo de excepciones no es solo un mecanismo defensivo. Si un 30 % de solicitudes cae siempre en la misma revisión, quizá exista una regla no modelada, un dato que debería capturarse antes o un problema en el canal de entrada.

Mide causas y frecuencia. Las excepciones recurrentes pueden convertirse en variantes explícitas; las raras y de alto riesgo pueden permanecer humanas.

Ejercicio: diseña la matriz de intervención

Elige ocho excepciones y crea una tabla:

Añade después una matriz de aprobaciones con rol, objeto aprobado, versión, datos visibles y condiciones que invalidan la aprobación.

Resultado de la lección

El workflow ya tiene rutas diseñadas para casos no estándar. Cada excepción importante puede detectarse, asignarse, resolverse y medirse. Las decisiones humanas conservan contexto y autoridad explícita. En la siguiente lección diseñarás las señales necesarias para reconstruir lo ocurrido y detectar cuándo el proceso se degrada.