Una automatización con IA puede ahorrar trabajo en la atención al cliente, la clasificación de solicitudes o la actualización de sistemas internos. Pero si depende de un modelo, una API externa o una integración con el ERP, también necesita una respuesta prevista para el fallo. Cuando esa dependencia no está disponible, el objetivo no es que el flujo siga tomando decisiones a cualquier coste: es mantener la operación en un estado seguro, comprensible y recuperable.
Un modo degradado define qué hace el proceso cuando no puede completar su camino habitual. Puede consistir en encolar una petición, aplicar una regla determinista, pedir una revisión humana o informar al usuario de una demora. La elección depende de la consecuencia de equivocarse y de la urgencia de la tarea.
Empiece por distinguir qué puede esperar y qué no
No todas las automatizaciones tienen el mismo riesgo. Antes de diseñar una alternativa, clasifique cada acción por el daño que produciría un resultado erróneo o incompleto.
- Reversible y de bajo impacto: etiquetar un correo, proponer una respuesta que una persona revisará o crear un borrador de tarea.
- Operativa, pero corregible: actualizar un CRM, asignar un ticket o preparar un pedido para validación.
- Sensible o difícil de revertir: aprobar pagos, cambiar precios, modificar inventario, enviar comunicaciones vinculantes o conceder acceso a un sistema.
Las acciones del último grupo no deberían pasar automáticamente a una alternativa menos fiable. Si el componente de IA o la validación necesaria falla, la ruta correcta suele ser detener la ejecución y derivarla a una persona autorizada.
Las cuatro piezas de un modo degradado útil
1. Detectar el fallo con una condición explícita
Un flujo no puede recuperarse de lo que no identifica. Defina qué significa fallo para cada dependencia: una respuesta fuera del tiempo máximo, un error de autenticación, un límite de uso, datos con formato inválido o una confianza insuficiente para la decisión requerida.
No conviene tratar todos los errores igual. Un error temporal de red puede justificar un reintento limitado; una respuesta que no cumple el esquema esperado debe detenerse y registrarse. Reintentar indefinidamente puede duplicar operaciones o saturar una integración que ya está degradada.
2. Conservar la solicitud antes de actuar
Antes de llamar a un modelo o a un servicio externo, guarde un identificador de operación, la entrada necesaria, la hora y el estado inicial. Si el flujo debe reanudarse, esa evidencia permite hacerlo sin pedir de nuevo la información al usuario ni repetir efectos ya ejecutados.
Para procesos asíncronos, una cola ayuda a separar la recepción de la solicitud de su procesamiento. La cola no resuelve por sí sola un fallo, pero evita perder trabajo y permite regular el ritmo de reintentos. Cada mensaje debe tener una clave de idempotencia: al reanudar, el sistema debe reconocer si una creación de ticket, pedido o registro ya se realizó.
3. Elegir una salida proporcional al riesgo
El modo degradado debe estar definido por tipo de decisión, no improvisado ante cada incidencia. Estas son rutas habituales:
- Encolar y aplazar: adecuada cuando la tarea puede esperar y no hay una forma segura de sustituir la dependencia.
- Aplicar reglas simples: útil para clasificar casos muy claros, siempre que las reglas estén documentadas y su ámbito sea limitado.
- Solicitar revisión humana: apropiada para excepciones, importes, datos personales, compromisos con clientes o cualquier acción irreversible.
- Informar y pedir una acción alternativa: en un portal o canal de atención, es preferible explicar una demora a entregar una respuesta inventada o bloquear silenciosamente la solicitud.
Por ejemplo, si un agente clasifica solicitudes de soporte y el modelo no responde, el flujo puede crear el ticket con la categoría «pendiente de triaje» y asignarlo a una cola humana. No debería adivinar una prioridad ni cerrar la solicitud. Si el mismo agente prepara una respuesta, puede guardar un borrador, pero no enviarlo sin las comprobaciones previstas.
4. Recuperar de forma controlada
Restablecer la conexión no significa reprocesar todo sin control. Defina quién puede reanudar la cola, qué elementos se reprocesan, cuántas veces se intentará y cuándo un caso pasa definitivamente a revisión. Al recuperar, verifique el estado de los sistemas destino para no crear duplicados.
La trazabilidad mínima debería permitir responder a cuatro preguntas: qué entrada llegó, qué dependencia falló, qué ruta alternativa se aplicó y qué resultado se obtuvo. Esa información facilita resolver incidencias y revisar si la política elegida sigue siendo adecuada.
Un ejemplo: altas de clientes asistidas por IA
Imagine un flujo que recibe una solicitud web, extrae datos de documentos, comprueba campos obligatorios y crea un registro en el CRM. Un diseño prudente podría ser:
- Asignar un identificador a la solicitud y guardar los documentos en el repositorio autorizado.
- Ejecutar la extracción y validar que los campos requeridos cumplen el formato esperado.
- Si la extracción no está disponible o no supera la validación, crear una tarea de revisión con el enlace a la solicitud, sin dar de alta al cliente.
- Si el CRM no está disponible, conservar el resultado validado en una cola y reintentar según una política limitada.
- Antes de crear el registro al reanudarse, buscar el identificador de operación para evitar un alta duplicada.
- Registrar el resultado, la persona que resolvió una excepción si la hubo y la hora de finalización.
Este enfoque distingue dos problemas diferentes: que la IA no pueda interpretar un documento y que el sistema destino no esté disponible. La solución no es la misma: en el primer caso se necesita juicio humano; en el segundo, preservar el trabajo validado y esperar.
Límites que conviene fijar antes de ponerlo en producción
- Tiempo máximo: cuánto espera el flujo antes de declarar una dependencia no disponible.
- Número de reintentos: pocos y espaciados; los reintentos deben detenerse ante errores de autorización o de validación.
- Volumen de cola: un límite y una alerta para evitar que una acumulación se convierta en una incidencia invisible.
- Responsable de excepción: un equipo o rol concreto, con el contexto suficiente para decidir.
- Acciones prohibidas en degradado: pagos, cambios de permisos, envíos externos o cualquier operación que no deba ejecutarse sin las validaciones habituales.
También es importante revisar qué datos quedan en la cola y quién puede consultarlos. Si contiene información personal o confidencial, el almacenamiento temporal, la retención y los permisos deben formar parte del diseño, no de una corrección posterior.
Cómo probar que el plan funciona
Un documento de contingencia sin prueba no demuestra que el proceso se recupere. En un entorno controlado, simule al menos la indisponibilidad del modelo, un error de la API destino, una respuesta con datos inválidos y una interrupción durante el reintento. Para cada escenario, compruebe que:
- la solicitud no se pierde ni se procesa dos veces;
- la automatización no ejecuta acciones fuera de su nivel de riesgo;
- la persona responsable recibe una alerta accionable;
- el caso se puede retomar con el contexto necesario;
- el registro permite reconstruir lo ocurrido.
La meta no es eliminar todos los fallos, sino evitar que un fallo técnico se convierta en un fallo de negocio. Un modo degradado bien diseñado da al equipo tiempo y contexto para recuperar la operación sin prometer una autonomía que el sistema no puede garantizar.
En KMOOPS diseñamos automatizaciones y agentes IA conectados a los sistemas reales de la empresa, con controles operativos y trazabilidad desde el inicio. Si necesita evaluar un flujo crítico o definir su recuperación ante incidencias, puede contactar con el equipo.