Llevar IA a producción no es un problema de modelos. Es un problema de arquitectura, de gestión de superficie de ataque...
Llevar IA a producción no es un problema de modelos. Es un problema de arquitectura, de gestión de superficie de ataque, y de saber exactamente dónde termina el valor que aporta un LLM y dónde empieza el ruido que introduce.
Este artículo documenta lo que hemos construido, los errores concretos que cometimos, y los criterios que guían hoy cada decisión cuando integramos IA en un sistema productivo. No es teoría. Es lo que opera en producción ahora mismo, con sus costos, sus límites y sus incidentes incluidos.
El error de diseño que más vemos
El patrón más común cuando un equipo de desarrollo decide integrar IA es construir primero la interfaz conversacional y luego intentar conectarla al sistema. El resultado predecible: el LLM se convierte en el actor que dirige el flujo, y el equipo pierde control sobre tres cosas simultáneamente — el comportamiento del sistema, los costos de inferencia, y la capacidad de depurar cuando algo falla.
Nuestra posición es la contraria. El proceso de negocio es la columna vertebral. El LLM es una función que ese proceso invoca en puntos específicos — los únicos donde el código determinista no llega: interpretación de lenguaje ambiguo, extracción de estructura desde texto no estructurado, generación de contenido con criterio semántico.
La diferencia práctica es significativa. Cuando el modelo es una función con entrada definida, instrucción controlada y salida estructurada, puedes versionar la instrucción, sustituir el modelo sin tocar el resto del sistema, y localizar exactamente dónde falla cuando falla. Cuando el modelo dirige el flujo, ninguna de esas tres cosas es posible.
Un segundo error frecuente: asumir que más contexto siempre mejora la respuesta. Pasarle al modelo toda la información disponible tiene dos costos que no siempre se ven juntos — el costo directo de tokens de entrada, y la degradación de calidad cuando la información crítica queda enterrada en el medio de un contexto extenso. Los modelos tienen límites de memoria de trabajo efectiva que no coinciden exactamente con sus límites técnicos de ventana de contexto. La diferencia entre ambos es donde ocurren los errores silenciosos.
Pipeline de enriquecimiento: el primer caso real
El primer sistema que pusimos en producción no fue un agente. Fue un pipeline de enriquecimiento sobre un catálogo de más de 15.000 productos con fichas técnicas inconsistentes y sin optimización para motores de búsqueda.
La arquitectura es deliberadamente simple: cada producto entra como input con su información base, una instrucción del sistema define el comportamiento esperado del modelo, y la salida es JSON estructurado que va directamente a actualizar el catálogo. Sin interfaces conversacionales, sin estado entre ejecuciones, sin ambigüedad en el output.
Dos decisiones de ingeniería hicieron viable este sistema en producción — no solo en demo.
Hashing de contenido para evitar reprocesamiento. Cada producto tiene una huella basada en su información. Si el producto no cambió desde la última ejecución, no se procesa. Esto no es una optimización menor: es lo que separa un pipeline con costo predecible de uno que reprocesa indefinidamente el mismo catálogo cada vez que se ejecuta.
Fallback determinista explícito. Para el caso específico de clasificación de cumplimiento regulatorio europeo (normativa de cargadores), la instrucción al modelo era precisa: si puedes determinarlo con certeza desde la ficha técnica, extráelo; si hay ambigüedad, usa el valor genérico seguro; no inferir donde no hay evidencia suficiente. Sobre una muestra del 10% del catálogo antes de construir el sistema completo, la tasa de efectividad fue del 98%. Ese número no es un resultado que celebramos — es el umbral que autorizó el desarrollo. Con un 80% no habríamos construido el sistema.
La validación pre-construcción con muestra real y umbral definido es el paso que más equipos omiten. Es también el que más frecuentemente determina si un sistema de IA va a funcionar en producción o solo en condiciones controladas.
Prompt Manager: resiliencia frente a un mercado que cambia rápido
El mercado de modelos de IA tiene una característica que no tiene el mercado de bases de datos o de infraestructura cloud: cambia en ciclos de meses, no de años. Ventanas de contexto que se multiplican, costos que bajan en órdenes de magnitud, modelos que mejoran en tareas específicas mientras otros se quedan estáticos.
Una arquitectura que no puede adaptar su capa de IA sin reescribirse no está diseñada para ese entorno.
Lo que construimos — y que llamamos Prompt Manager internamente — es la capa que desacopla tres variables que en la mayoría de implementaciones están acopladas: la instrucción del sistema, el modelo que la ejecuta, y el proveedor del servicio. Cambiar cualquiera de las tres es una operación de configuración, no de código.
Las consecuencias prácticas son directas. Cuando un proveedor tiene una contingencia de disponibilidad, cambiamos mientras se resuelve. Cuando un modelo nuevo mejora la calidad en un proceso específico sin degradar otros, lo adoptamos de forma selectiva. Cuando los costos de un modelo bajan lo suficiente para que valga la pena migrar, la migración no implica tocar la lógica de negocio.
La dependencia de un único proveedor de LLM no es una deuda técnica menor. En un sistema que depende de inferencia para funcionar, es un riesgo de continuidad operacional.
Agente conversacional: lo que cambia respecto a un pipeline batch
Después de operar pipelines de enriquecimiento en producción durante meses, teníamos algo que ningún framework proporciona: evidencia calibrada sobre cómo se comporta un modelo en un sistema controlado real. Dónde falla, cómo falla, qué tipo de instrucciones producen resultados consistentes. Esa evidencia fue el prerequisito para construir un agente, no un framework ni una certificación.
El caso concreto fue un asistente de compra para e-commerce (beep.es). La decisión de diseño más importante no fue técnica sino conceptual: la web sigue siendo la experiencia principal. El asistente asiste. No reemplaza la navegación dentro de un chat.
La implementación técnica tiene dos componentes que trabajan en paralelo en cada turno de conversación. El primero es inyección de contexto situacional: el modelo recibe en cada mensaje información de lo que está ocurriendo en la web en ese momento exacto — qué página está viendo el usuario, qué producto, qué información está disponible. El segundo es un catálogo de acciones ejecutables sobre la web: navegar a una URL de búsqueda, añadir un producto al carrito, mostrar una ficha de producto. El modelo no adivina la intención del usuario — trabaja con contexto concreto del momento actual y con un conjunto acotado de acciones posibles.
El problema que no existe en pipelines batch y sí aparece en conversación es el crecimiento del contexto. Cada turno añade información al historial. Sin control, ese crecimiento se convierte en un problema de costos y de calidad simultáneamente — los modelos empiezan a perder información relevante que queda enterrada en un historial demasiado extenso.
La solución es un compactador: un proceso secundario que resume el historial acumulado cuando supera un umbral, preservando lo semánticamente relevante y descartando lo redundante. La compresión tiene pérdida asumida. Esa pérdida es una decisión de diseño explícita, no un efecto secundario. La alternativa — dejar crecer el contexto sin límite — tiene un costo mayor y una degradación de calidad que no se puede controlar ni medir.
Construimos este sistema sin frameworks de agentes. No porque sean incorrectos, sino porque llegamos aquí con suficiente contexto propio para saber exactamente qué necesitábamos, y un framework genérico habría añadido complejidad sin añadir control sobre las variables que más importaban.
Seguridad: superficie de ataque específica de sistemas con LLM
Los sistemas de IA tienen una superficie de ataque que no existe en software tradicional: credenciales con acceso a servicios de inferencia que pueden generar costos en tiempo real, a una velocidad que no tiene fricción humana ni límite físico hasta que alguien las detiene activamente.
Tuvimos dos incidentes que documentamos con precisión porque creemos que la industria los infravalora sistemáticamente.
Incidente 1 — API Key sin restricciones, Gemini API. Una credencial creada en 2016 para Google Maps en un dominio público — las credenciales de Maps deben estar expuestas en frontend por diseño del servicio — había perdido sus restricciones de dominio en algún momento durante una migración de plataforma. Esa credencial tenía también acceso a la Gemini API porque cuando se activó ese servicio en el proyecto, heredó el acceso. El resultado: 9.000€ facturados en 35 minutos antes de que pudiéramos reaccionar.
La velocidad del daño en este tipo de incidente no tiene comparación con ningún otro vector de ataque convencional: no hay fricción, no hay intervención humana en el loop, solo llamadas automáticas que se multiplican hasta que se detienen externamente.
Lo que aprendimos sobre las herramientas de protección de las plataformas. Teníamos alertas de presupuesto configuradas y un límite de gasto activo en Google AI Studio. Ninguno de los dos funcionó como esperábamos: la alerta llegó cinco horas después de que el daño estaba hecho, y el límite de gasto no interrumpió el consumo durante el ataque. En la práctica, lo que nos permitió detectar el incidente fue el agotamiento del saldo de la tarjeta de crédito asociada — no los mecanismos de protección de la plataforma.
Hay además un problema estructural que pocas veces se menciona: el presupuesto en Google Cloud se configura por proyecto, no por modelo. Una credencial comprometida puede consumir ese presupuesto usando el modelo más caro disponible sin que exista ningún mecanismo para restringirlo a nivel de key. No hay forma de decirle a una API Key que solo puede acceder a determinados modelos dentro de un proyecto. Si tiene acceso, tiene acceso a todo el catálogo de modelos disponibles.
Lo trasladamos formalmente a Google: un sistema de alertas que notifica después del hecho no es protección operacional, es registro histórico. Una plataforma que no detecta patrones de consumo anómalos en tiempo real deja al equipo de desarrollo sin red de seguridad en el momento que más la necesita.
Incidente 2 — el mismo vector, confirmación del patrón. Un segundo incidente posterior con características similares confirmó que no se trataba de un caso aislado. La superficie de ataque es estructural: cualquier credencial con acceso a un servicio de inferencia, aunque su función principal sea otra, es un vector de riesgo económico.
El proceso de seguridad que implementamos después
Lo que construimos después de esos incidentes no fue reacción emocional. Fue proceso.
Auditoría de superficie expuesta como paso obligatorio antes de cualquier despliegue. Cualquier credencial con acceso a un servicio que tenga capacidad de modelo de lenguaje — aunque su función principal no sea IA — se trata como superficie de ataque. Los servicios en la nube acumulan capacidades con el tiempo. Una credencial creada para Maps puede tener acceso a Gemini sin que nadie lo haya decidido explícitamente.
Restricciones de API Key por servicio, por IP de origen y por dominio HTTP Referer. Las nuevas credenciales están restringidas al conjunto mínimo de servicios necesarios, a los rangos de IP de los entornos que las consumen, y para credenciales de frontend a los dominios autorizados. El principio de mínimo privilegio no es una recomendación — es el estándar de configuración.
Rotación periódica como rutina, no como respuesta a incidentes. Las credenciales tienen una ventana de vida definida. Una clave comprometida en un sistema con rotación mensual tiene una ventana de daño acotada. Una clave que nunca rota tiene una ventana de daño indefinida.
Límites de gasto calibrados por debajo del umbral de daño tolerable. Un límite configurado por encima del gasto esperado no protege — solo registra. El límite tiene que estar por debajo del umbral de daño que la empresa puede absorber sin impacto operacional, con margen suficiente para que la notificación llegue antes de que ese umbral se alcance. Dado el delay real entre consumo y alerta en las plataformas actuales, ese margen tiene que ser conservador.
ReCAPTCHA en todas las interacciones del asistente conversacional. Cada mensaje que un usuario envía al asistente pasa por verificación antes de llegar al modelo. La diferencia entre un endpoint de IA con y sin verificación es la diferencia entre un sistema que puede ser abusado de forma automatizada y uno que no.
Gestión de secretos como estándar de base. Variables de entorno en plataformas con acceso auditado, gestores de secretos para credenciales de backend, acceso mínimo necesario por entorno. Ninguno de estos controles es nuevo en ingeniería de software. La diferencia en sistemas con IA es que el costo de ignorarlos no es un bug silencioso — es una factura que llega antes de que termines el café.
Los criterios que guían hoy cada decisión
Estos son los principios que aplicamos cuando evaluamos si — y cómo — integrar IA en un sistema productivo.
El LLM entra donde el código determinista no llega. Si un problema puede resolverse con lógica condicional, expresiones regulares, o una consulta estructurada, la IA sobra. Un if/else bien escrito es más barato, más rápido y más predecible que cualquier modelo. La IA entra cuando el problema requiere interpretación semántica, generación de contenido con criterio, o extracción de estructura desde texto no estructurado.
La viabilidad se mide antes de construir, con muestra real y umbral definido. Antes de desarrollar cualquier pipeline con IA, necesitas datos reales, un criterio de calidad cuantificado, y la disciplina de cancelar el desarrollo si los números no lo justifican. El coste de construir un sistema que no funciona en producción es mayor que el coste de validar que no funcionará antes de empezar.
La pérdida de contexto es una decisión de diseño, no un accidente. Todo sistema con estado conversacional va a enfrentar el problema de crecimiento de historial. Decidir explícitamente qué se comprime, qué se descarta y qué pérdida es tolerable es ingeniería controlada. Dejar que el contexto crezca sin control hasta que degrada es deuda técnica con interés compuesto.
La resiliencia de proveedor es infraestructura. El mercado de modelos cambia en ciclos de meses. Una arquitectura que no puede cambiar de modelo o de proveedor sin reescribirse no está lista para producción. El desacoplamiento entre instrucción, modelo y proveedor no es una optimización futura — es un requisito desde el primer día.
Los costos son predecibles si la arquitectura es honesta. Todo lo descrito en este artículo opera en producción con un costo de inferencia que no supera los 70€ mensuales. No es resultado de optimización agresiva — es consecuencia directa de que la IA solo interviene donde aporta valor que el código no puede dar, de que no se reprocesa trabajo ya hecho, y de que el contexto se gestiona de forma controlada. La misma arquitectura que te da control sobre la calidad te da control sobre la factura.
La confianza en producción se construye incrementalmente, no se importa. No llegamos a construir un agente conversacional porque éramos valientes ni porque habíamos leído suficiente documentación. Llegamos porque teníamos meses de evidencia sobre cómo se comporta un modelo en un sistema controlado real. Esa evidencia no la proporciona ningún framework ni ningún curso. La proporciona operar sistemas reales con responsabilidad real sobre los resultados.