Cómo llevar un agente de IA a producción (sin que muera en demo)

Llevar un agente de IA a producción significa convertir una demo que funciona “casi siempre” en un sistema que tu equipo usa cada día con confianza. Lo que separa una cosa de la otra no es el modelo: es la trazabilidad, los evals, el control de costes y una interfaz que la gente quiera abrir. Esta guía recorre esa arquitectura mínima, paso a paso.

Llevo mis propios productos con IA en producción (un CRM y un SaaS de restauración de fotos) y antes pasé más de diez años desplegando software en sitios donde un fallo cuesta dinero de verdad: banca, retail, aerolíneas. El patrón se repite en todos: la demo se construye en una semana y entusiasma a todo el mundo; el paso a producción es donde el 90% se queda por el camino. No por falta de capacidad del modelo, sino por todo lo que rodea al modelo. Vamos a ello.

¿Qué es un agente de IA?

Un agente de IA es un sistema que usa un modelo de lenguaje (LLM) para decidir qué pasos dar y ejecutarlos con herramientas externas, en lugar de limitarse a responder texto. Mientras un chatbot contesta, un agente actúa: consulta una API, lee una base de datos, manda un correo, revisa el resultado y vuelve a intentarlo si hace falta.

La diferencia clave es el bucle: el agente observa, decide, actúa y vuelve a observar hasta cumplir un objetivo. Eso es lo que lo hace potente y también lo que lo hace difícil de poner en producción, porque cada paso puede fallar de formas que un simple “pregunta-respuesta” nunca tiene.

¿Por qué el 90% de los agentes no llega a producción?

Porque la demo y la producción miden cosas distintas. La demo se valida con la mirada (“¡mira, funciona!”); la producción se valida con datos, a escala y con dinero real de por medio. Las razones concretas se repiten tanto que escribí un artículo aparte sobre ellas: por qué la mayoría de pilotos de IA no llegan a producción.

Lo he vivido en mis propios productos: la función de IA que en pruebas parecía redonda empieza a recibir tráfico real y el primer día aparecen los casos que ninguna prueba manual había contemplado. No es mala suerte: es que la mirada aprueba demos y los datos reales las desmontan.

El resumen es este: una demo tolera el fallo ocasional porque hay un humano vigilando; un agente en producción se ejecuta solo, muchas veces al día, sobre datos que nunca viste. Sin las cuatro piezas que vienen ahora (arquitectura, trazabilidad, costes e interfaz) el agente no es un producto, es una anécdota.

La arquitectura mínima viable de un agente en producción

No necesitas un framework enorme para empezar, pero sí estas cuatro capas. Si falta una, el agente se cae en cuanto sale del entorno controlado.

Orquestación

Es el cerebro que decide el siguiente paso: cuándo llamar a una herramienta, cuándo pedir más contexto, cuándo parar. Empieza simple y explícito (un bucle con pasos acotados y un número máximo de iteraciones) antes de saltar a orquestaciones multi-agente. La mayoría de los problemas de producción vienen de agentes que “piensan demasiado” sin límite: pon siempre un tope de pasos y un timeout.

Herramientas (tools)

Las herramientas son las manos del agente: funciones que conectan el modelo con tus sistemas (APIs, bases de datos, búsqueda). Tres reglas que evitan el 80% de los incidentes:

• Define entradas y salidas tipadas. El modelo debe recibir errores claros, no excepciones crudas.
• Haz las herramientas idempotentes siempre que puedas: que reintentarlas no duplique un pago ni mande dos correos.
• Mínimo privilegio. Una herramienta de solo lectura no debería poder escribir. Si el agente se descontrola, que el daño esté acotado por diseño.

Si tus integraciones pasan por muchos sistemas, conviene exponerlas con un estándar como MCP (Model Context Protocol), el “USB-C” para conectar LLMs con herramientas. Lo explico en detalle en Model Context Protocol: lo que funciona y lo que falla y en cómo convertir cualquier API REST en un MCP con FastMCP.

Memoria

Un agente sin memoria repite preguntas y pierde el hilo. Distingue dos tipos: memoria de la tarea (el estado de lo que está haciendo ahora) y memoria a largo plazo (preferencias, hechos del usuario, histórico). No metas todo en el contexto del modelo “por si acaso”: cada token cuesta dinero y latencia. Recupera solo lo relevante (ahí es donde entra RAG) y resume lo viejo.

Guardrails

Son las barreras que evitan que el agente haga algo caro, peligroso o vergonzoso: validación de entradas y salidas, listas de acciones que siempre requieren confirmación humana, filtros de datos sensibles y límites de gasto. La pregunta que define un buen guardrail es: “¿qué es lo peor que puede hacer este agente y cómo lo impido por diseño, no por confianza?”

Un ejemplo de guardrail que yo aplico en mis propios sistemas: nada que salga hacia fuera (un correo, una publicación, una escritura en base de datos de producción) se ejecuta directamente. El agente lo deja preparado en una bandeja de salida y una persona lo aprueba. El agente trabaja solo; lo irreversible, no.

¿Cómo sabes que tu agente funciona? Trazabilidad y evals

Esta es la sección que separa a quien ha puesto agentes en producción de quien solo ha hecho demos. Si no puedes responder “¿por qué el agente hizo esto?” y “¿está funcionando mejor o peor que ayer?”, no tienes un producto, tienes una caja negra.

Trazabilidad significa registrar cada ejecución completa: el prompt, las herramientas que llamó, qué devolvieron, cuántos tokens gastó y cuánto tardó. Cuando un usuario reporta “el agente se equivocó”, necesitas reproducir exactamente ese paso. Sin trazas, depurar un agente es adivinar.

Evals son tu suite de tests para comportamiento no determinista. La idea: un conjunto de casos representativos (los típicos, los raros y los que ya fallaron) con el resultado esperado, que ejecutas en cada cambio de prompt o de modelo. Te dan un número objetivo (“acertamos el 92%”) en vez de una sensación.

• Empieza con 20-50 casos reales, no sintéticos. Los casos que rompen tu agente ya están en tus logs.
• Mide lo que importa al negocio (¿resolvió la tarea?), no solo si el texto “suena bien”.
• Cada vez que un usuario corrige al agente, ese caso entra en el set de evals. Así el sistema mejora de verdad con el uso.

Control de costes y latencia: la economía del agente

Un agente que funciona pero cuesta 4 € por ejecución no es viable si lo lanzas 10.000 veces al día. La economía del agente es una decisión de arquitectura, no un detalle que se mira al final.

• Elige el modelo por tarea, no por moda. Usa un modelo grande solo donde aporta; las tareas simples (clasificar, extraer, enrutar) van en modelos rápidos y baratos. Una buena arquitectura mezcla modelos.
• Controla el contexto. El coste crece con cada token de entrada. Recupera lo justo, resume lo viejo y no arrastres todo el historial en cada llamada.
• Cachea lo repetido. El prompt caching abarata muchísimo los prompts de sistema largos que se repiten en cada ejecución.
• Vigila la latencia percibida. Un agente que tarda 30 segundos sin dar señales de vida se siente roto aunque acierte. Streaming y estados visibles (“buscando…”, “leyendo el documento…”) cambian por completo la experiencia.

Para entender de qué depende el presupuesto de un proyecto de IA de principio a fin, lo desgloso en cuánto cuesta integrar IA en tu empresa.

La interfaz importa: el agente que nadie abre no sirve

Esto se subestima siempre. Puedes tener el mejor agente del mundo, pero si la interfaz no genera confianza, nadie lo usa dos veces. La adopción es parte del trabajo de producción, no algo que viene después.

Lo que más mueve la confianza:

• Muestra el razonamiento y las fuentes. Que el usuario vea de dónde sale la respuesta. Un agente que cita su fuente se gana la confianza; uno que afirma sin más, no.
• Diseña para el error. El agente se va a equivocar. La interfaz debe dejar corregirlo, deshacer y reportar de forma fácil. Y como vimos, cada corrección alimenta los evals.
• Pide confirmación en lo irreversible. Mandar dinero, borrar datos, escribir a un cliente: confirmación humana explícita, siempre.

Checklist: ¿está tu agente listo para producción?

Antes de decir “está listo”, repasa esto. Si fallas en tres o más, todavía tienes una demo:

• Hay un límite de pasos y un timeout por ejecución.
• Cada herramienta tiene entradas/salidas tipadas y mínimo privilegio.
• Las acciones irreversibles requieren confirmación.
• Registras trazas completas de cada ejecución (prompt, tools, tokens, latencia).
• Tienes un set de evals con 20+ casos reales y un número de acierto.
• Conoces el coste por ejecución y has elegido modelo por tarea.
• La interfaz muestra fuentes, permite corregir y comunica el estado.
• Todo lo que sale hacia fuera (correos, publicaciones, producción) pasa por aprobación humana.
• Hay un dueño del agente que vigila métricas y atiende fallos.

Lo construyo contigo

Si tienes una demo que funciona pero no te atreves a ponerla delante de tus clientes, ese salto, de demo a producción, es exactamente lo que hago: construyo agentes de IA listos para producción, con trazabilidad, evals y control de costes desde el primer día. Puedes ver cómo trabajo en desarrollo de agentes de IA o escríbeme y lo vemos con tu caso concreto.

---

¿Quieres entender antes por qué tantos proyectos se quedan en la demo? Te lo cuento en por qué la mayoría de pilotos de IA no llegan a producción.