Gontzal Bilbao

17 de junio de 2026

1 min lectura

Contexto

Montar un prototipo que llama a un LLM y devuelve texto es cosa de una tarde. Ponerlo en producción, conectado a una plataforma de negocio real, que no se caiga cuando falla el proveedor de IA, que escale sin ahogarse y que un equipo pueda operar y depurar, ya es otra historia. Esa diferencia —entre demo y plataforma— es justo lo que cuento aquí.

El punto de partida era un backend de negocio en Laravel que necesitaba IA conversacional de verdad: no “responder algo”, sino razonar sobre la intención, repartir el trabajo entre agentes de dominio, usar herramientas reales y devolver respuestas trazables. Para eso construí un servicio de orquestación de IA en Python/FastAPI desplegado en AWS.

Enfoque propuesto

En vez de un único “endpoint que llama al modelo”, diseñé una topología donde cada pieza tiene su responsabilidad y un contrato claro, y donde la IA es un componente más de un sistema operable.

La orquestación multiagente

El flujo central reparte el trabajo en tres piezas en lugar de pedirle todo a una sola llamada:

• Supervisor — interpreta la intención de la consulta y selecciona el agente adecuado.
• Workers especializados — cada agente trabaja con su prompt de dominio y puede invocar herramientas externas mediante MCP / function calling.
• Synthesizer — recompone la respuesta final cuando han intervenido varios agentes o herramientas.

El recorrido completo es:

Laravel API → FastAPI → Supervisor → Worker especializado → MCP tools → Synthesizer → Response

Hay un detalle que importa más de lo que parece: la respuesta no devuelve solo texto, sino metadatos técnicos (agente seleccionado, tools usadas, proveedor LLM, versión de prompt). En producción esa es la diferencia entre “el bot ha dicho algo raro” y “esta consulta fue al agente X, usó la tool Y con el proveedor Z y el prompt v4”. Es decir, entre adivinar y poder depurar de verdad.

Runtime dual: evolucionar sin big-bang

Cambiar el motor de un sistema en producción de golpe es pedir a gritos un incidente. Por eso hago coexistir dos runtimes —uno legacy y uno nuevo basado en LangGraph— y gobierno la transición por configuración, no por despliegue:

• Canary rollout: un porcentaje ajustable del tráfico va al runtime de grafo. Subes del 5% al 100% sin redeploy.
• Fail-open: si el grafo falla, la petición cae automáticamente al runtime legacy. El usuario no se entera.
• Fallback de proveedor: soporta varios proveedores LLM (mock, OpenAI, LM Studio, Amazon Bedrock) con modo degradado si el principal no responde.

Así una migración que daba miedo se convierte en una palanca que giras poco a poco y revierte en segundos.

Colas: que una carga pesada no ahogue lo interactivo

Redis hace de broker, con workers ARQ, y la topología de colas separa el tráfico por criticidad. Si lo metes todo en una sola cola, un proceso batch o una herramienta lenta acaban degradando el chat en tiempo real. Por eso las separo:

• Realtime — chat síncrono de baja latencia.
• Tools pesadas — ejecuciones largas de herramientas.
• Batch — procesos diferidos.
• Dead-letter queue — captura de fallos para inspección y reproceso.

El servicio expone endpoints síncronos (respond) y asíncronos (submit), de modo que el backend Laravel elige el modo según el caso de uso.

Integración backend-to-backend, con contrato

La conexión con Laravel no es un amasijo frágil de URLs sueltas, sino un contrato explícito: autenticación por token de servicio, callbacks y base URL configurables. Y aquí va una de las decisiones que más disgustos me ha ahorrado: un preflight de entorno que valida las variables cruzadas entre el servicio de IA y Laravel —tokens, endpoints, credenciales— antes de arrancar. Si algo no cuadra, el servicio te lo dice al arrancar, no dos horas después con un error opaco en producción.

CI/CD y despliegue en AWS

El despliegue es automatizado de commit a instancia:

• Pipeline GitLab CI/CD con stages de validate, test y deploy.
• Empaquetado del artefacto y publicación del bundle en S3.
• CodeDeploy ejecuta el despliegue en la instancia con hooks de ciclo de vida.
• Docker para empaquetado y ejecución reproducible.

Observabilidad: diseñado para operarse

Un servicio de IA en producción hay que poder vigilarlo como cualquier otro servicio crítico. Por eso expone señales pensadas para quien lo opera:

• GET /health — estado del servicio y de sus dependencias.
• GET /metrics — latencias (percentiles), counters, estado de colas y error rate.
• GET /alerts — alertas activas sobre colas, errores y fallbacks.

Y como el comportamiento de un sistema de IA vive en sus prompts, añadí gestión de prompts en producción: versionado, override, preview, publish e histórico vía API administrativa. Cambiar cómo se comporta un agente no pasa por un despliegue.

Buenas prácticas y riesgos

• Devuelve metadatos en cada respuesta (agente, tools, proveedor, versión de prompt): sin trazabilidad, depurar IA en producción es a ciegas.
• Separa colas por criticidad y añade una dead-letter queue desde el día uno.
• Diseña el fallback antes que la feature: proveedor caído y runtime caído son cuándo, no si.
• Valida la configuración cruzada en el arranque; la mayoría de incidentes de integración son variables mal puestas.
• Riesgo: el canary y el fail-open añaden complejidad de estado; documenta qué runtime sirvió cada petición o perderás la pista al depurar.

Resultado

Lo que quedó no es “una integración con un LLM”, sino una plataforma de IA operable: orquestación multiagente con tools reales, resiliencia ante fallos de runtime y de proveedor, despliegue automatizado y observabilidad de verdad. Resuelve a la vez la capa de IA (agentes, MCP, prompts) y la capa de infraestructura y operación (CI/CD, colas, despliegue, métricas).

Si me quedo con una idea: poner IA en producción es, sobre todo, un problema de ingeniería de plataforma. El modelo lo puedes cambiar; lo que sostiene el servicio es todo lo que hay alrededor.

Siguiente paso

Si te interesa cómo encaja esto con el resto de mi trabajo cloud, puedes ver otros proyectos en el portfolio. ¿Estás llevando un backend de IA a producción y quieres comentarlo? Escríbeme aquí.