Un solo flujo de trabajo de IA puede tocar cinco o seis servicios externos antes de producir una salida. Una API de LLM. Una base de datos vectorial. Una consulta al CRM. Un web scraper. Un proveedor externo de enriquecimiento. Cada uno tiene su propio historial de uptime — y ninguno llega al 100%.
Cuando uno falla, un sistema sin plan de degradación se detiene por completo. Una interrupción de 10 minutos se convierte en un paro total del pipeline. Las colas se acumulan. Los pasos posteriores agotan su tiempo de espera. Alguien abre un ticket.
La solución no es conseguir mejores SLAs de tus proveedores. Es diseñar para el fallo desde el principio.
El Ejercicio del Mapa de Dependencias
Antes de poder degradar con elegancia, necesitas saber de qué dependes.
Lista cada llamada externa que hace tu flujo de trabajo. Sé exhaustivo. Incluye:
- Endpoints de inferencia de LLM (OpenAI, Anthropic, self-hosted)
- Vector stores y capas de recuperación
- Lecturas y escrituras en el CRM
- APIs de enriquecimiento (datos de LinkedIn, proveedores firmográficos)
- Servicios de web fetch o scraping
- Microservicios internos de otro equipo
- Endpoints de autenticación y validación de tokens
Para cada dependencia, asigna una cifra de uptime mensual realista. Usa el historial de la página de estado publicada por el proveedor, no su SLA de marketing. Un servicio que anuncia 99.9% de uptime pero ha tenido tres incidentes en los últimos 90 días no es un servicio del 99.9% en la práctica.
Luego haz los cálculos. Si tu flujo de trabajo requiere cinco dependencias y cada una tiene 99.5% de uptime, la disponibilidad combinada de toda la cadena es aproximadamente 97.5%. Eso equivale a unas 18 horas de tiempo de inactividad potencial por mes — no por negligencia, sino por aritmética.
Este ejercicio suele producir dos reacciones. Primero, sorpresa ante la cantidad de llamadas externas que existen. Segundo, claridad sobre cuáles dependencias representan el mayor riesgo.
Tres Modos de Degradación
No todo fallo justifica la misma respuesta. Existen tres modos. Elegir el correcto depende del rol de la dependencia en el flujo de trabajo.
Fallback Completo (Resultado en Caché)
Úsalo cuando la dependencia provee datos que cambian lentamente y donde una respuesta ligeramente desactualizada es mejor que ninguna respuesta.
Ejemplo: una llamada de enriquecimiento firmográfico que devuelve el tamaño y la industria de una empresa. Si la API de enriquecimiento está caída, sirve el último resultado en caché con una marca de tiempo. El conteo de empleados de una empresa de hace 48 horas casi siempre es suficiente para continuar el procesamiento.
Requisitos: una capa de caché con un TTL definido, un umbral de antigüedad acordado por el equipo, y un indicador en la salida que señale que el resultado provino del caché.
Fallback Parcial (Salida Reducida con Indicador)
Úsalo cuando la dependencia contribuye a la calidad de la salida pero no es necesaria para que la salida exista.
Ejemplo: un flujo de trabajo que genera un resumen de prospecto usando tanto el historial del CRM como datos web en tiempo real. Si el web fetch falla, produce el resumen solo con los datos del CRM. Marca la salida como enrichment_incomplete: true para que los consumidores posteriores sepan que deben tratarla con menor confianza.
Esto mantiene el pipeline en movimiento. También crea un rastro de auditoría claro. Cuando la dependencia se recupera, puedes reprocesar los registros marcados.
Rechazo Elegante (Fallar en Voz Alta y Rápido)
Úsalo cuando la dependencia es crítica y ningún resultado parcial es mejor que un resultado incorrecto.
Ejemplo: una verificación de cumplimiento que debe ejecutarse antes de enviar un mensaje. Si la API de cumplimiento no es alcanzable, no envíes el mensaje. No adivines. Rechaza el trabajo de inmediato, registra el motivo y enrútalo a una cola de reintentos con un esquema de backoff.
La palabra clave es rápido. Un rechazo elegante que agota el tiempo de espera después de 30 segundos no es elegante. Establece timeouts agresivos — de 2 a 5 segundos para la mayoría de las llamadas a APIs — y rechaza temprano. Esto protege el resto de tu pipeline de demoras en cascada.
El Patrón de Separación
El error de implementación más común es incrustar la lógica de fallback directamente dentro de la función principal del flujo de trabajo. Se ve así: un largo bloque condicional que verifica errores, intenta un caché, verifica de nuevo y eventualmente devuelve algo. Después de que dos ingenieros lo tocan, nadie tiene certeza de qué hace realmente.
Patrón de separación: trata cada dependencia como un cliente envuelto, no como una llamada directa.
El wrapper es responsable de tres cosas:
- La llamada en vivo
- El comportamiento de fallback para esa dependencia específica
- El contrato de logging e indicadores
La lógica principal del flujo de trabajo llama al wrapper y recibe ya sea un resultado o un objeto de falla estructurado. No sabe si el resultado provino de datos en vivo o del caché. No contiene ninguna lógica de reintentos. Solo procesa lo que recibe.
Esto mantiene el código de degradación aislado y testeable. Puedes hacer unit tests del fallback de cada wrapper de forma independiente. Puedes cambiar una estrategia de caché sin tocar la lógica del flujo de trabajo. Cuando se agrega una nueva dependencia, el patrón ya está establecido.
Un beneficio secundario: cuando ocurre un incidente, los logs del wrapper te dicen exactamente qué dependencia falló, a qué hora y qué modo de fallback se activó. Depurar una interrupción en producción toma minutos en lugar de horas.
Cómo Se Ve Esto en la Práctica
Un flujo de trabajo que procesa 200 registros de prospectos por hora encontrará fallas de dependencias con regularidad — no de forma ocasional. Con cifras de uptime realistas, espera al menos un evento de falla parcial por día en un pipeline moderadamente complejo.
Los sistemas construidos con modos de degradación manejan estos eventos sin intervención humana. El pipeline continúa. Los registros marcados se reprocesan cuando las dependencias se recuperan. Los operadores ven una métrica en el dashboard, no un ticket de soporte.
Los sistemas sin modos de degradación se detienen, alertan y esperan a que alguien los reinicie.
La diferencia no es heroísmo de ingeniería. Es un mapa de dependencias, tres modos definidos y un patrón de separación aplicado de forma consistente.
Si estás construyendo o auditando un pipeline de IA y quieres revisar el mapa de dependencias para tu flujo de trabajo específico, Inicia una conversación →