Conectar un modelo de inteligencia artificial a una API y conseguir que una demostración funcione suele ser relativamente sencillo. Conseguir que esa misma automatización siga funcionando cuando aparecen timeouts, límites de uso, respuestas duplicadas, servicios caídos o ejecuciones interrumpidas es otra historia.

En producción, una automatización con inteligencia artificial no debería diseñarse suponiendo que todos sus pasos terminarán correctamente. Hay que partir de la hipótesis contraria: alguno fallará.

La diferencia entre una automatización frágil y una robusta no está únicamente en la calidad del modelo. Está en cómo responde el sistema cuando una dependencia deja de contestar, una petición llega dos veces, un proceso muere a mitad de ejecución o no sabemos con certeza si una operación llegó a completarse.

La buena noticia es que no tenemos que inventar soluciones nuevas para todos estos problemas. Muchos de los patrones que necesitamos proceden de décadas de ingeniería de sistemas distribuidos: reintentos controlados, idempotencia, colas de errores, observabilidad, compensación y escalado humano.

El verdadero problema: una ejecución no es una sola operación

Imagina una automatización aparentemente sencilla:

1. llega un formulario de un cliente;
2. un modelo de IA clasifica la solicitud;
3. se consulta información en el CRM;
4. se genera una respuesta;
5. se actualiza el CRM;
6. se envía un correo;
7. se registra el resultado.

Ahora supongamos que el paso 6 devuelve un timeout.

¿Qué significa realmente?

Podría significar que el correo nunca se envió. Pero también podría significar que el servidor sí lo envió y que la respuesta se perdió antes de llegar a nuestra automatización.

Si simplemente repetimos el paso, podríamos enviar el mensaje dos veces.

Este problema se repite constantemente en sistemas distribuidos: no siempre podemos distinguir entre “la operación falló” y “la operación terminó, pero no recibí confirmación”.

Por eso una arquitectura robusta necesita responder, como mínimo, a estas preguntas:

• ¿Qué errores merece la pena reintentar?
• ¿Cuántas veces?
• ¿Con qué intervalo?
• ¿Qué ocurre si la misma operación se ejecuta dos veces?
• ¿Cómo aislamos los trabajos que nunca terminan correctamente?
• ¿Cómo reconstruimos después qué ocurrió?
• ¿Cuándo debe intervenir una persona?

1. No todos los errores deben reintentarse

Uno de los errores más habituales en automatización consiste en envolver cualquier fallo en un bucle de reintentos, no funciona.

Hay errores transitorios, que pueden desaparecer solos, y errores permanentes, que seguirán ocurriendo independientemente de cuántas veces repitamos la operación.

Una respuesta 503 Service Unavailable, un timeout o determinados errores 429 Too Many Requests suelen ser candidatos razonables para un nuevo intento.

Una petición con parámetros inválidos normalmente no lo es. La documentación de Google Cloud recomienda utilizar reintentos para errores transitorios, limitar el número de intentos y aplicar exponential backoff en lugar de repetir las solicitudes inmediatamente.

Una política simplificada podría ser:

Esta tabla es una guía, no una ley universal. Cada API tiene su propio contrato y conviene seguir su documentación específica.

2. Exponential backoff: fallar sin empeorar el problema

Cuando un servicio está saturado, enviar otra petición inmediatamente puede aumentar la saturación.

Por eso se utiliza el exponential backoff: después de cada fallo incrementamos progresivamente el tiempo antes del siguiente intento.

Una secuencia sencilla podría ser:

1 s → 2 s → 4 s → 8 s → 16 s

Pero todavía existe un problema.

Si mil automatizaciones fallan simultáneamente y todas utilizan exactamente la misma secuencia, las mil volverán a atacar al servicio al mismo tiempo. Para evitarlo se añade jitter: una pequeña componente aleatoria al tiempo de espera.

Google Cloud describe precisamente este patrón de truncated exponential backoff with jitter, que además establece un límite máximo en lugar de seguir reintentando indefinidamente.

Conceptualmente:

delay = min(maxDelay, exponentialDelay + randomJitter)

La idea importante no es la fórmula exacta, sino estas cuatro reglas:

• aumenta progresivamente la espera;
• introduce aleatoriedad;
• limita el número total de intentos;
• define qué errores pueden activar un reintento.

Un retry infinito no es resiliencia. Es un incidente esperando ocurrir.

3. Idempotencia: repetir sin duplicar efectos

Los reintentos introducen inmediatamente otro problema: una operación puede terminar ejecutándose más de una vez. Aquí entra la idempotencia. Una operación es idempotente cuando ejecutarla varias veces produce, desde el punto de vista del sistema, el mismo resultado que ejecutarla una sola vez.

Consultar un registro suele ser idempotente.

“Establecer el estado del pedido a Procesado” puede diseñarse como una operación idempotente.

“Incrementar el saldo en 100 euros” no lo es automáticamente.

“Enviar otro correo” tampoco.

Para operaciones con efectos secundarios, una estrategia habitual es asignar una clave de idempotencia única a la operación lógica.

Por ejemplo:

customer-9281-invoice-2026-09

Si el sistema recibe dos peticiones con esa misma clave, debe reconocer que ambas representan la misma operación y evitar ejecutar el efecto dos veces. Stripe utiliza este patrón explícitamente: sus APIs permiten utilizar claves de idempotencia para repetir solicitudes sin crear accidentalmente un segundo objeto o repetir una operación.

En una arquitectura propia podemos aplicar algo parecido:

1. Recibir operación con idempotency_key
2. Buscar la clave en almacenamiento
3. Si ya terminó:
      devolver resultado anterior
4. Si está en proceso:
      evitar ejecución concurrente
5. Si no existe:
      registrar operación
      ejecutar
      guardar resultado

La clave de idempotencia debería representar la intención del negocio, no simplemente cada petición HTTP. Si generamos una clave nueva en cada reintento, hemos destruido precisamente la protección que buscábamos.

4. Diseña para “al menos una vez”, no para un mundo perfecto

En sistemas distribuidos es habitual trabajar con mecanismos de entrega que pueden procesar un mensaje más de una vez. Por ejemplo, la documentación de Amazon SQS advierte de que, dependiendo del procesamiento y de los tiempos de visibilidad, un mensaje puede volver a entregarse y ser procesado de nuevo. La consecuencia arquitectónica es importante: el consumidor también debe estar preparado para duplicados.

No basta con intentar evitar que aparezcan. Un flujo robusto debería almacenar algún identificador estable del evento o trabajo:

event_id = 7ca1...

Antes de ejecutar un efecto irreversible:

if event_id already_processed:
    return previous_result

Este patrón resulta especialmente importante cuando conectamos automatizaciones, webhooks, colas y agentes de IA.

5. Cuando los reintentos se agotan: Dead-Letter Queue

¿Qué hacemos con una operación que ha fallado cinco veces?

La peor opción suele ser seguir intentándolo eternamente. Otra mala opción es descartarla silenciosamente. Una solución clásica es moverla a una Dead-Letter Queue, o DLQ.

AWS define las DLQ como colas destinadas a recibir mensajes que una cola de origen no ha conseguido procesar correctamente. Esto permite aislar los casos fallidos, analizarlos y posteriormente reprocesarlos si procede.

El flujo queda así:

Trabajo
  ↓
Procesamiento
  ↓
¿Éxito?
  ├── Sí → Terminado
  └── No
       ↓
     Retry
       ↓
¿Superó el límite?
  ├── No → Nuevo intento
  └── Sí → DLQ

Una DLQ no debería convertirse en un cementerio olvidado.

Necesita, al menos:

• alertas cuando aumenta el número de mensajes;
• motivo del fallo;
• número de intentos;
• timestamps;
• identificador de correlación;
• payload suficiente para diagnosticar el problema;
• mecanismo controlado de reprocesamiento.

Si un mensaje termina en la DLQ y nadie lo observa, hemos convertido un error visible en un error silencioso.