Cómo diseñar un modo degradado cuando la inteligencia artificial no está disponible

Define primero el servicio esencial. Un modo degradado no intenta reproducir todas las funciones con menos recursos. Su propósito es conservar la parte mínima que protege al cliente y mantiene la operación comprensible. Identifica qué resultado no puede desaparecer: recibir una solicitud, registrar un pago, confirmar una cita o conservar un documento. Después separa funciones convenientes, como clasificación avanzada o redacción automática. Esta prioridad evita que una falla del modelo detenga actividades que podrían continuar mediante reglas sencillas, formularios estructurados o intervención humana limitada.

Establece señales claras de activación. La ausencia total de respuesta es solo una forma de falla. También existen latencia excesiva, errores repetidos, resultados incompletos, consumo fuera de presupuesto o respuestas que no superan la validación. Define umbrales observables y un responsable de activar el modo degradado. La transición debe ocurrir antes de que usuarios repitan acciones o el sistema acumule solicitudes ambiguas. Una bandera visible, un monitor simple y una regla de tiempo pueden ser suficientes para evitar que el equipo espere indefinidamente una recuperación que todavía no tiene confirmación.

Sustituye inteligencia por reglas seguras. Cuando el modelo no está disponible, utiliza decisiones deterministas para los casos más comunes. Un mensaje puede enviarse a una cola general, una consulta puede recibir confirmación de recepción y una tarea puede clasificarse por campos obligatorios. Las reglas de respaldo deben ser conservadoras: registrar antes que interpretar, pausar antes que ejecutar una acción crítica y solicitar datos faltantes en vez de inventarlos. El objetivo no es mantener la misma sofisticación, sino preservar continuidad sin aumentar el riesgo durante una situación de menor capacidad.

Controla las colas y los duplicados. Las solicitudes pendientes necesitan un identificador, hora, estado y criterio de reintento. Si el usuario vuelve a enviar, el sistema debe reconocer el caso existente y evitar acciones duplicadas. Define cuánto tiempo puede permanecer una tarea en espera y cuándo se convierte en revisión manual. También separa trabajos que pueden retomarse automáticamente de aquellos cuyo contexto puede haber cambiado. Una cola sin reglas solo aplaza el problema; una cola gobernada conserva orden y permite recuperar el servicio sin ejecutar dos veces la misma intención.

Comunica la capacidad disponible. El usuario no necesita detalles técnicos, pero sí saber qué función está temporalmente limitada, qué ocurrió con su solicitud y cuándo recibirá la siguiente actualización. Evita mensajes que afirmen normalidad mientras el sistema entrega resultados parciales. Internamente, informa qué acciones están habilitadas y cuáles deben detenerse. Una comunicación uniforme reduce intentos repetidos, decisiones contradictorias y presión sobre soporte. El modo degradado debe tener plantillas preparadas para clientes, equipo operativo y responsables de negocio.

Planifica la recuperación y la reconciliación. Cuando vuelve el servicio, no envíes automáticamente toda la cola sin revisar. Confirma que el contexto siga vigente, elimina duplicados y aplica límites de velocidad. Compara registros del modo degradado con los sistemas principales para detectar solicitudes omitidas o estados diferentes. Algunas tareas necesitarán nueva aprobación porque el tiempo cambió su relevancia. La recuperación es una fase propia: incluye priorización, validación, ejecución gradual y confirmación final. De esta manera, volver a la normalidad no crea un segundo incidente.

Ensaya el modo degradado antes de necesitarlo. Desconecta deliberadamente el componente de inteligencia artificial en un entorno controlado y observa si el equipo puede recibir, registrar, priorizar y recuperar trabajo. Mide tiempo de detección, cantidad de solicitudes conservadas, errores y claridad de comunicación. Actualiza instrucciones después de cada prueba. Un servicio verdaderamente resiliente no depende de que un proveedor nunca falle; depende de que el negocio conozca su función esencial, pueda operar temporalmente con menos capacidad y vuelva al flujo completo sin perder control ni confianza.