Noticias, guías y análisis
Diseña un plan de degradación para que tu flujo siga funcionando cuando falle la IA
Un flujo útil no debería desaparecer cuando el modelo responde lento, supera el presupuesto o pierde acceso a una herramienta. Esta guía convierte el fallo en una operación limitada pero controlada.
El fallo más costoso es el que detiene una promesa al cliente. Una automatización puede depender de un modelo, una API, una base de datos, un proveedor de correo y varios permisos. Basta con que una pieza responda tarde para que el flujo completo parezca roto. El problema no es que la tecnología falle alguna vez; es haber diseñado el proceso como si nunca pudiera fallar. Un plan de degradación permite conservar el resultado esencial con menos capacidad mientras se recupera la ruta principal.
Primero dibuja la cadena y marca sus puntos frágiles. Escribe cada paso desde la entrada hasta el resultado: qué activa el flujo, qué datos consulta, qué decisión toma, qué herramienta ejecuta y cómo se confirma el cierre. Junto a cada paso registra tres riesgos: indisponibilidad, respuesta incorrecta y costo excesivo. Esta lista evita el diagnóstico genérico de “la IA no sirve”. También permite distinguir si el problema está en el modelo, la conexión, los datos, la regla de negocio o la entrega final.
Después define el resultado mínimo que no puede desaparecer. Un sistema de atención quizá redacta una respuesta personalizada, consulta historial y actualiza el CRM. En modo reducido puede limitarse a confirmar recepción, guardar el mensaje y prometer un plazo real de revisión. Una automatización de propuestas quizá genera un documento completo; su alternativa puede crear una tarea con datos ordenados y una plantilla base. La degradación correcta elimina sofisticación, pero conserva continuidad, trazabilidad y una expectativa clara para la persona afectada.
Crea tres niveles con condiciones visibles. El nivel normal usa todas las capacidades aprobadas. El nivel reducido se activa cuando la latencia, el consumo, la calidad o la disponibilidad salen de un umbral. El nivel manual asigna el caso a una persona cuando tampoco existe una salida segura simplificada. Define los umbrales antes del incidente: segundos de espera, número de errores, presupuesto por ejecución o ausencia de un dato crítico. Sin condiciones, el equipo discute cada caída desde cero y pierde más tiempo que el sistema.
La alternativa debe evitar acciones irreversibles. Cuando existe incertidumbre, el flujo puede preparar, registrar o solicitar revisión, pero no debería cobrar, eliminar, prometer, publicar o cambiar permisos sin confirmación. Diseña el modo reducido alrededor de acciones reversibles y mensajes honestos. No ocultes la degradación con una respuesta que finge normalidad. Informar que una solicitud fue recibida y será revisada protege mejor la confianza que una salida inventada. La continuidad útil mantiene servicio sin convertir una falla técnica en un riesgo comercial o legal.
Ensaya la caída como parte de la implementación. Desconecta de forma controlada una integración de prueba, fuerza un tiempo de espera y supera un límite simulado. Comprueba si la alerta llega, si se activa la ruta correcta, si el responsable recibe contexto y si el usuario entiende qué ocurrirá. Mide tiempo de recuperación y casos atrapados. La primera prueba casi siempre descubre dependencias invisibles, como una plantilla que también necesitaba la API caída o un responsable que no tenía permiso para abrir la tarea de respaldo.
Cierra cada incidente con una mejora concreta. Registra qué falló, qué nivel se activó, cuánto duró, qué trabajo manual apareció y qué información faltó. No conviertas el informe en una búsqueda de culpables. Úsalo para ajustar umbrales, simplificar dependencias y decidir si una parte necesita otro proveedor o una copia local. Un flujo resiliente no es el que jamás se interrumpe, sino el que cae de forma predecible, conserva el servicio esencial y vuelve a la normalidad sin perder casos ni obligar al cliente a comenzar de nuevo.