Cómo diseñar un modo degradado cuando una dependencia de IA no está disponible

Un producto que depende de IA necesita decidir qué hará cuando esa capacidad no esté disponible. Una API puede fallar, alcanzar límites, aumentar latencia o devolver errores durante una ventana. Si todo el servicio queda unido a esa dependencia, un componente externo convierte una función secundaria en una caída total. Un modo degradado define de antemano qué experiencia sigue funcionando con menos inteligencia y qué acciones deben detenerse. La meta no es esconder la falla. Es preservar valor básico sin inventar resultados ni ejecutar decisiones sensibles con una sustitución que no cumple el nivel necesario.

Clasifica primero cada función según cuánto depende de la IA para ser correcta. Algunas tareas pueden usar una regla simple o una respuesta almacenada temporalmente; otras, como aprobar una excepción compleja o interpretar un documento crítico, no tienen sustituto seguro. Crea tres categorías: continuar con fallback, continuar con capacidad reducida y detener con mensaje claro. Esta clasificación evita improvisar durante el incidente. También ayuda a descubrir dependencias innecesarias: si una acción básica requiere un modelo solo porque fue cómodo implementarla así, quizá conviene desacoplarla antes de que exista una caída.

El fallback debe tener límites explícitos y no intentar imitar una capacidad que ya no posee. Si el sistema normalmente personaliza recomendaciones, el modo degradado puede mostrar opciones generales. Si resume documentos, puede ofrecer acceso directo al archivo en lugar de generar un resumen dudoso. Si clasifica casos, puede enviarlos a una cola humana. Cada alternativa debe declarar qué cambia. Una experiencia reducida pero honesta suele ser mejor que mantener la interfaz normal mientras la calidad cae silenciosamente. El usuario necesita saber cuándo una decisión ya no tiene la misma base.

La activación puede depender de señales técnicas y de calidad. No esperes únicamente a que la API devuelva un error total. Define umbrales de latencia, tasa de fallos, respuestas inválidas o capacidad agotada. Cuando la dependencia cruza el límite durante cierto periodo, el sistema cambia de modo. Evita alternar cada segundo entre normal y degradado mediante hysteresis o ventanas mínimas de estabilidad. El objetivo es que la transición sea controlada y observable. Registrar cuándo empezó, qué funciones se redujeron y qué usuarios fueron afectados facilita evaluación posterior.

Los efectos irreversibles necesitan una política más conservadora que las funciones informativas. Una recomendación puede tolerar menor personalización; un pago, publicación, cambio de permiso o comunicación sensible quizá deba detenerse. El modo degradado no es permiso para sustituir una evaluación compleja por una regla improvisada. Define qué acciones quedan bloqueadas y qué persona puede autorizarlas manualmente si existe urgencia. Esa frontera evita que la presión por “mantener todo arriba” transforme una indisponibilidad temporal en un error de negocio que luego no puede revertirse.

Prueba el modo degradado antes de necesitarlo. Simula timeout, cuota agotada, proveedor lento y respuestas inválidas. Verifica que la interfaz cambia, las colas no se duplican, los usuarios reciben información coherente y la recuperación no reprocesa acciones ya completadas. También mide cuánta capacidad manual se necesita. Un fallback que envía todo a personas puede funcionar durante diez minutos y colapsar después de una hora. La prueba debe considerar duración y volumen, no solo demostrar que existe una ruta alternativa en un diagrama.

Diseñar degradación convierte una dependencia externa en un riesgo gestionable en lugar de una sorpresa binaria. El sistema sabe qué valor mínimo puede seguir entregando, qué debe detener y cómo regresar a modo normal después de comprobar estabilidad. Conservar esa arquitectura requiere revisar el mapa cuando se añaden funciones o modelos nuevos. La resiliencia no significa que la IA nunca falle; significa que su falla no obliga al negocio a improvisar qué hacer. Un producto confiable puede perder capacidad temporalmente sin perder también claridad, control y honestidad sobre lo que todavía puede cumplir.