De demo a produccion: como diseno automatizaciones de IA fiables

Construir una demo de automatizacion con IA puede ser sorprendentemente rapido. Un formulario activa un workflow, un LLM interpreta el mensaje, una API ejecuta una accion y llega una notificacion. La primera prueba funciona y parece que el sistema esta terminado.

Normalmente, el trabajo importante empieza justo despues.

Una automatizacion preparada para produccion debe seguir siendo fiable cuando una API tarda, un usuario envia dos veces la misma solicitud, el modelo devuelve una estructura inesperada, falta un dato o una ejecucion se detiene a mitad del proceso.

En los sistemas que construyo, intento que la IA aporte flexibilidad sin convertir todo el proceso en algo impredecible. Para conseguirlo, separo interpretacion, reglas, acciones y recuperacion.

Respuesta directa: que necesita una automatizacion de IA para ser fiable

Una automatizacion de IA fiable necesita entradas validadas, operaciones idempotentes, reintentos controlados, estados persistentes, observabilidad, limites explicitos y una salida humana cuando el sistema no puede actuar con seguridad.

Capa	Pregunta que debe responder
Contrato de entrada	¿Que datos necesita realmente el proceso?
Validacion	¿La solicitud es completa, coherente y autorizada?
Idempotencia	¿Que ocurre si el mismo evento llega dos veces?
Estado	¿En que punto se encuentra cada ejecucion?
Reintentos	¿Que fallos son temporales y cuales requieren intervencion?
Observabilidad	¿Podemos reconstruir que ocurrio?
Revision humana	¿Cuando debe dejar de automatizar el sistema?

La calidad del prompt importa, pero ninguna frase dentro de un prompt sustituye estas capas.

El ejemplo: una reserva creada desde WhatsApp

Imaginemos un asistente que recibe este mensaje:

Quiero una mesa para cuatro manana a las nueve.

La demo feliz parece sencilla:

1. el LLM extrae fecha, hora y numero de personas;
2. el sistema consulta disponibilidad;
3. crea la reserva;
4. envia una confirmacion.

Pero antes de llamar a este sistema "fiable" hay que responder bastantes preguntas:

• ¿Que zona horaria utiliza "manana"?
• ¿El restaurante abre a esa hora?
• ¿Faltan nombre o datos de contacto?
• ¿Que pasa si WhatsApp reenvia el webhook?
• ¿Y si la reserva se crea, pero falla el mensaje de confirmacion?
• ¿Debe reintentarse toda la ejecucion?
• ¿Como sabe una persona si la reserva llego a registrarse?

Estos detalles son la diferencia entre una automatizacion que impresiona en una demo y una que realmente reduce trabajo.

1. Convertir entradas ambiguas en contratos claros

Los usuarios y los LLMs trabajan bien con lenguaje flexible. Las acciones reales necesitan datos precisos. Despues de interpretar una solicitud, transformaria el resultado a un contrato estructurado:

{
  "customer_name": "Gorka",
  "party_size": 4,
  "reservation_at": "2026-06-15T21:00:00+02:00",
  "contact_channel": "whatsapp",
  "request_id": "msg_abc123"
}

Antes de crear nada, una capa determinista debe comprobar que los campos obligatorios existen, los formatos son correctos, la fecha es valida, el horario esta permitido y la accion esta autorizada.

El LLM puede proponer la estructura. El sistema debe decidir si esa estructura es valida. Si falta informacion, la respuesta correcta es pedir solo el dato necesario y conservar el contexto ya recopilado.

2. Disenar operaciones idempotentes

Una operacion idempotente produce el mismo efecto aunque se solicite varias veces. Es una propiedad fundamental cuando intervienen webhooks, colas, redes y reintentos.

Si el mismo evento llega dos veces, el sistema no debe crear dos reservas. Para evitarlo, asociaria cada solicitud a una clave unica:

idempotency_key = canal + identificador_del_mensaje

Antes de ejecutar una accion, el servicio comprueba si esa clave ya fue procesada:

Estado encontrado	Comportamiento
No existe	Iniciar la operacion
En proceso	Esperar o devolver el estado actual
Completada	Devolver el resultado guardado
Fallida recuperable	Reanudar desde el punto seguro
Fallida definitiva	Escalar o solicitar correccion

La idempotencia no solo evita duplicados. Tambien permite reintentar sin miedo y responder con coherencia cuando distintos componentes preguntan por el mismo proceso.

3. Separar pasos reversibles e irreversibles

No todas las acciones tienen el mismo riesgo. Clasificar una intencion, resumir texto o preparar un borrador son operaciones faciles de repetir. Enviar un email, crear una reserva, cobrar, cancelar o modificar un registro tiene efectos externos.

Antes de cada efecto irreversible, conviene establecer un punto de control:

Interpretar
    -> validar
        -> comprobar permisos
            -> registrar intencion
                -> ejecutar accion
                    -> guardar resultado
                        -> notificar

Si falla la notificacion final, el sistema no deberia volver a crear la reserva. Debe recuperar el resultado ya guardado y reintentar solamente la notificacion. Esta separacion hace que recuperarse sea mucho mas seguro que reiniciar el workflow completo.

4. Utilizar reintentos con criterio

Reintentar todo de inmediato puede empeorar un problema. Si una API esta saturada, cientos de ejecuciones insistiendo a la vez generan mas carga. Si el error es un dato invalido, repetir no cambiara el resultado.

Tipo de fallo	Ejemplo	Respuesta
Temporal	Timeout, limite de peticiones, servicio no disponible	Reintentar con espera
Permanente	Campo invalido, permiso denegado, recurso inexistente	Corregir o escalar
Desconocido	Respuesta inesperada o inconsistencia	Detener, registrar y revisar

Para fallos temporales utilizaria exponential backoff: esperar progresivamente mas tiempo entre intentos, con un pequeno componente aleatorio para evitar que todas las ejecuciones vuelvan a llamar a la vez.

Tambien fijaria un limite. Cuando se supera, la ejecucion debe ir a una cola de errores o quedar marcada para revision. "Reintentar para siempre" no es una estrategia de recuperacion.

5. Persistir estado fuera del workflow

Un workflow visual muestra bien el camino que deberia seguir un proceso, pero no siempre debe ser la unica fuente de verdad. Para operaciones relevantes, conservaria un estado explicito:

RECEIVED -> VALIDATED -> APPROVED -> EXECUTING -> COMPLETED
                                      |
                                      -> FAILED_RETRYABLE
                                      -> NEEDS_REVIEW

Cada transicion deberia registrar fecha, identificador de ejecucion y contexto minimo. Esto permite saber donde se detuvo el proceso, reanudar desde un punto seguro, evitar repetir acciones completadas, investigar incidentes y medir tiempos y tasas de fallo.

El workflow orquesta. La persistencia conserva lo que realmente ocurrio.

6. Disenar observabilidad que permita responder preguntas

Guardar muchos logs no garantiza entender un fallo. La observabilidad debe ayudar a reconstruir la historia de una ejecucion.

Como minimo, registraria:

• un identificador de correlacion compartido entre componentes;
• origen y tipo del evento;
• version del workflow, servicio y prompt;
• modelo utilizado y latencia;
• herramientas o APIs llamadas;
• validaciones superadas o rechazadas;
• cambios de estado;
• errores clasificados;
• resultado final y motivo de escalado.

No registraria datos personales innecesarios ni prompts completos de forma indiscriminada. La trazabilidad debe convivir con minimizacion, controles de acceso y politicas de retencion.

Una buena prueba es intentar responder: ¿cuantas ejecuciones fallaron?, ¿en que paso?, ¿la accion externa llego a completarse? y ¿el sistema se recupero o necesita una persona? Si responder exige abrir varios sistemas y adivinar, todavia falta trabajo.

7. Tratar al LLM como un componente no determinista

Un modelo puede devolver respuestas distintas ante entradas parecidas. Tambien puede producir JSON invalido, omitir campos o seleccionar una herramienta incorrecta.

No intentaria eliminar completamente esa variabilidad. La encerraria dentro de limites:

• salidas estructuradas y validadas;
• listas permitidas de herramientas;
• permisos separados por accion;
• limites de iteraciones, tiempo y coste;
• comprobaciones deterministas;
• fallback cuando el modelo o proveedor no esta disponible;
• revision humana para decisiones sensibles.

En una automatizacion, el LLM deberia interpretar, clasificar, extraer o proponer. Las reglas del negocio deben decidir que puede ejecutarse.

8. Preparar una salida humana util

Escalar a una persona no significa enviarle un mensaje que diga "el agente ha fallado". Una buena transferencia debe incluir que queria conseguir el usuario, que datos se recopilaron, que acciones se intentaron, que resultado devolvio cada sistema, por que se detuvo la automatizacion y que decision falta.

El objetivo es continuar desde donde termino el sistema, sin repetir toda la investigacion ni pedir de nuevo informacion ya disponible. El escalado humano no es una derrota de la automatizacion: es una ruta prevista para casos que necesitan criterio, permisos o contexto adicional.

9. Evaluar antes y despues del despliegue

Antes de produccion, probaria bastante mas que el camino feliz:

• eventos duplicados;
• campos ausentes o contradictorios;
• fechas ambiguas;
• respuestas invalidas del modelo;
• timeouts y limites de peticiones;
• interrupciones despues de ejecutar una accion;
• solicitudes no autorizadas;
• intentos de prompt injection.

Despues del despliegue, observaria metricas operativas y de calidad:

Metrica	Que ayuda a detectar
Tasa de finalizacion	Si el flujo resuelve el objetivo
Duplicados evitados	Si la idempotencia funciona
Reintentos por integracion	APIs inestables
Tiempo hasta resolucion	Cuellos de botella
Escalados y sus motivos	Casos no cubiertos o reglas demasiado estrictas
Acciones corregidas manualmente	Errores que la tasa de exito oculta
Coste por ejecucion	Ineficiencias de modelos y herramientas

Una automatizacion no queda terminada al desplegarla. Produccion genera evidencia sobre como debe mejorar.

Lista de comprobacion antes de automatizar una accion real

• La entrada se convierte en un contrato validado.
• Existe una clave de idempotencia.
• Los efectos externos estan separados de la interpretacion.
• Cada error tiene una politica de reintento o escalado.
• El estado importante persiste fuera de una unica ejecucion.
• Los logs permiten reconstruir el proceso sin exponer datos innecesarios.
• Hay limites de coste, tiempo, permisos e iteraciones.
• Una persona puede continuar un caso escalado con contexto.
• Existen pruebas para fallos y duplicados, no solo para el camino feliz.
• Se han definido metricas para revisar el comportamiento real.

Mi criterio final

La diferencia entre una demo y un sistema de produccion no es solamente el volumen. Es la capacidad de responder correctamente cuando algo sale diferente a lo esperado.

En una automatizacion fiable, el camino feliz puede ser corto. Lo que demuestra la calidad de la arquitectura son los caminos de recuperacion: evitar duplicados, conservar estado, limitar el dano, explicar que ocurrio y permitir que una persona intervenga.

Automatizar no es hacer que una tarea se ejecute sola; es disenar que debe ocurrir incluso cuando falla.

Este enfoque complementa mi guia sobre como elegir entre n8n, FastAPI y Spring y el sistema de reservas para restaurante con IA y WhatsApp, donde una conversacion termina convirtiendose en una accion real.

Puedes consultar mas proyectos en mi portfolio o contactar conmigo desde la pagina de contacto.