Hay un momento en casi todos los proyectos con IA que sigue el mismo patrón.
El piloto funciona. El equipo está entusiasmado. La demo impresiona. Se aprueba el presupuesto para producción.
Y tres meses después llega una factura que nadie esperaba, o peor, el sistema se cae porque el proveedor de IA tiene una incidencia y no hay ningún plan B.
Estos no son errores de ingeniería. Son errores de arquitectura. Y se cometen antes de escribir una sola línea de código.
El error que más se repite: diseñar para la demo, no para la producción
Cuando un equipo integra IA por primera vez, el foco está en que funcione. En que el resultado sea bueno. En que la demo convenza.
Lo que nadie está calculando en ese momento es cuánto va a costar hacer esa misma llamada un millón de veces. O qué pasa cuando el endpoint del proveedor devuelve un error 503 a las 3 de la mañana.
En producción, la IA no es solo un componente técnico. Es una dependencia externa con coste variable y disponibilidad no garantizada. Y si la arquitectura no está diseñada para tratarla como tal, el sistema es frágil por construcción.
El problema de los costes de inferencia
Los costes de los modelos grandes parecen razonables cuando haces pruebas. Unos pocos euros por miles de llamadas en desarrollo no alarman a nadie.
El problema es que esos costes escalan de forma que muy pocos equipos anticipan correctamente.
Un modelo que procesa documentos, responde consultas o genera contenido en producción puede hacer decenas de miles de llamadas al día. Con tokens de entrada y salida que se acumulan. Con contextos que crecen cuando la conversación es larga. Con picos de uso que multiplican el coste base en momentos concretos.
El resultado es un sistema que funciona perfectamente y que genera un coste mensual que nadie había presupuestado realmente.
La solución no es evitar los modelos grandes. Es tomar decisiones de arquitectura conscientes antes de depender de ellos.
Tres preguntas que todo arquitecto debería hacerse antes de integrar un LLM en producción:
¿Qué volumen de llamadas espero en el peor caso, no en el caso medio? Los costes se diseñan para el pico, no para la media.
¿Qué parte de ese coste es realmente necesaria? No todas las llamadas necesitan el modelo más potente. Un sistema bien diseñado usa el modelo adecuado para cada tarea, no el más capaz para todo.
¿Tengo visibilidad real del gasto en tiempo real? Sin alertas de coste y límites configurados, el problema aparece en la factura, no antes.
El argumento para los LLMs open source que pocos están haciendo
Hay una conversación que debería ocurrir en más proyectos y que casi nunca ocurre: ¿realmente necesitamos GPT-4 para esto?
La respuesta honesta, en muchos casos, es no.
Existe una categoría de modelos que cambia completamente la ecuación de costes y dependencias: los LLMs open source de tamaño reducido que pueden ejecutarse dentro de tu propia infraestructura, incluso embebidos en el core de tu aplicación.
Modelos como Mistral, Phi, Llama en sus versiones más ligeras, o Gemma pueden resolver perfectamente tareas de clasificación, extracción de información, generación estructurada, resumen de documentos cortos o respuestas acotadas a un dominio concreto.
No son sustitutos de GPT-4 para razonamiento complejo. Pero para el 60-70% de los casos de uso reales en producción, no necesitas razonamiento complejo. Necesitas consistencia, velocidad y coste controlado.
Las ventajas son concretas:
Coste predecible. El modelo corre en tu infraestructura. El coste es computación, no tokens. Puedes dimensionarlo, optimizarlo y presupuestarlo con precisión.
Sin dependencia externa. Si el modelo está embebido en tu sistema, no depende de la disponibilidad de ningún proveedor. El sistema funciona aunque OpenAI tenga una caída.
Control total sobre los datos. Para casos de uso con información sensible, no salir de tu infraestructura no es una ventaja competitiva, es un requisito.
La decisión no debería ser «¿usamos IA o no?» sino «¿qué tipo de modelo es el adecuado para este caso de uso concreto?»
El plan B que nadie diseña hasta que lo necesita
La disponibilidad de los proveedores de IA grandes es alta. Pero no es del 100%. Y cuando un componente de IA está en el camino crítico de tu sistema, una caída del proveedor es una caída de tu sistema.
Un arquitecto que integra IA en producción tiene que responder una pregunta incómoda: ¿qué hace el sistema cuando la IA no está disponible?
Las opciones son varias según el caso de uso, pero el principio es el mismo: la IA debe ser un componente que mejora el sistema, no uno del que el sistema no puede funcionar sin él.
Algunas aproximaciones concretas:
Degradación controlada. El sistema funciona con capacidades reducidas cuando la IA no está disponible. El usuario lo sabe, pero el sistema no se cae.
Fallback a modelo local. Si tienes un modelo open source embebido, puedes usarlo como fallback cuando el proveedor principal falla. La calidad puede ser menor, pero el sistema sigue operativo.
Cola y reintento. Para tareas no síncronas, encolar las peticiones y procesarlas cuando el servicio se recupera es suficiente. No todo necesita respuesta en tiempo real.
Ninguna de estas opciones es compleja de implementar. Lo que es complejo es recordar diseñarlas antes de que el sistema esté en producción.
Lo que separa una arquitectura con IA que aguanta de una que no
No es la calidad del modelo elegido. No es la sofisticación del prompt. No es el número de agentes en el pipeline.
Es haber tomado decisiones conscientes sobre tres cosas antes de llegar a producción: cuánto va a costar, qué pasa cuando falla y si realmente necesitas el modelo más grande para lo que estás haciendo.
La IA en producción es ingeniería, no magia. Y la ingeniería bien hecha empieza por las preguntas incómodas, no por las demos bonitas
Si te gusta este contenido no olvides compartirlo y, si quieres ser de esos ingenieros que saquen provecho de la IA, suscríbete a la newsletter, es GRATIS 😉