LLMOps: qué es, por qué lo necesitas y cómo montarlo sin quemar dinero

El problema que nadie quiere ver

Hay una escena que se repite en casi todas las empresas que dan el salto a la IA generativa. El equipo técnico monta un prototipo con la API de OpenAI en dos semanas. La demo funciona. El CEO se emociona. Se aprueba presupuesto para “ponerlo en producción”.

Y ahí empieza el desastre.

Tres meses después, la factura de tokens se ha triplicado. Nadie sabe por qué el modelo responde peor que en la demo. Un cambio en la API del proveedor rompe todo un viernes por la tarde. Y el equipo que montó el prototipo lleva semanas apagando fuegos en lugar de construir producto.

Esto no es una anécdota. Según Gartner, el 30% de los proyectos de IA generativa se abandonan después del prototipo antes de llegar a producción. No por falta de talento. Por falta de operaciones.

Ahí es donde entra LLMOps.

Qué es LLMOps (y qué no es)

LLMOps son las prácticas, herramientas y procesos para gestionar modelos de lenguaje en producción. Punto. No es un producto que compras. No es un framework mágico. Es la disciplina de operar LLMs como lo que son: sistemas críticos de negocio que necesitan monitorización, control de costes, evaluación continua y gobernanza.

Si vienes del mundo del machine learning clásico, piensa en LLMOps como la evolución de MLOps para el mundo de los modelos fundacionales. Pero con diferencias importantes que hacen que no puedas simplemente reutilizar lo que ya tenías.

Red Hat lo define de forma bastante directa: LLMOps es el equivalente de MLOps adaptado a las características únicas de los LLMs — su tamaño, sus complejos requisitos de entrenamiento y sus elevadas demandas de computación. Google Cloud añade un matiz importante: mientras MLOps gestiona el ciclo de vida completo de modelos que tú entrenas, LLMOps se centra en modelos que normalmente no has entrenado tú, pero que necesitas adaptar, orquestar y controlar.

MLOps vs LLMOps: las 5 diferencias que importan

Mucha gente trata LLMOps como “MLOps con más GPUs”. Error. Las diferencias son estructurales y afectan a cómo montas toda tu infraestructura.

1. No entrenas, adaptas. En MLOps clásico, el ciclo empieza con datos etiquetados y un proceso de entrenamiento. En LLMOps, el modelo ya existe. Tu trabajo es adaptar su comportamiento mediante prompts, RAG (retrieval-augmented generation) o, en casos avanzados, fine-tuning. Esto cambia radicalmente el flujo de trabajo.

2. La evaluación es subjetiva. Un modelo de clasificación tiene F1-score, precisión, recall — métricas duras. Un LLM que genera texto no tiene nada parecido. ¿Cómo mides si una respuesta es “buena”? Necesitas evaluadores automáticos (LLM-as-judge), rúbricas humanas y datasets de referencia específicos de tu dominio. Es más arte que ciencia, y ninguna herramienta lo resuelve automáticamente.

3. Los costes son variables y explosivos. En ML clásico, el coste principal es el entrenamiento (una vez) y la inferencia (predecible). Con LLMs, cada llamada tiene un coste proporcional a los tokens de entrada y salida. Un prompt mal diseñado que mete 4.000 tokens de contexto innecesario puede multiplicar tu factura por 10 sin que cambie nada visible.

4. El vendor lock-in es real. Si usas GPT-4o hoy y mañana OpenAI sube precios un 40% o depreca la versión, tienes un problema. En MLOps, tú controlas el modelo. En LLMOps, dependes de un proveedor externo en la mayoría de casos. La estrategia multi-modelo no es un lujo — es supervivencia.

5. La seguridad tiene capas nuevas. Prompt injection, data leakage en el contexto, alucinaciones presentadas como hechos, jailbreaks… Los LLMs introducen vectores de ataque que simplemente no existen en modelos clásicos. Proofpoint advierte que las empresas necesitan normas estrictas de AI governance y herramientas especializadas para controlar cómo se usan los modelos en producción.

Las 6 capas de un stack LLMOps real

Después de trabajar con varias empresas en la implementación de LLMs, hemos destilado el stack en seis capas. No necesitas todas desde el día uno, pero sí necesitas saber que existen.

Capa 1: Gateway y routing de modelos

El punto de entrada. Todas las llamadas a LLMs pasan por aquí. Es donde implementas:

Routing multi-modelo: envía consultas al modelo más eficiente según la tarea. No uses GPT-4o para clasificar un email cuando Haiku lo hace en 200ms por una centésima del coste.
Rate limiting y colas: protege tu presupuesto y gestiona picos.
Failover automático: si OpenAI cae (y cae), redirige a Anthropic o un modelo local.
Caché semántica: si la misma pregunta se hace 50 veces al día, no pagues 50 veces la inferencia.

Herramientas: LiteLLM (open source, excelente), Portkey, o un proxy propio si tienes equipo.

Capa 2: Gestión de prompts

Los prompts son código. Trátalo como tal.

Versionar prompts en un documento de Google o en variables hardcodeadas es la receta para el desastre. Necesitas:

Versionado: cada cambio de prompt es un commit con diff visible.
Templates parametrizados: separar la estructura del prompt de las variables dinámicas.
Testing A/B: comparar versiones de prompts contra datasets de evaluación antes de desplegar.
Rollback inmediato: si un prompt nuevo degrada la calidad, volver al anterior en segundos.

Herramientas: LangSmith tiene probablemente la mejor experiencia de debugging de prompts del mercado. Agenta y Humanloop son alternativas sólidas.

Capa 3: Evaluación continua

La capa más descuidada y, probablemente, la más importante.

No puedes mejorar lo que no mides. Y con LLMs, medir es especialmente difícil porque las salidas son texto libre. Lo que funciona en la práctica:

Evals automáticas con LLM-as-judge: usas un modelo (a menudo más potente) para evaluar las respuestas de otro. No es perfecto, pero escala.
Golden datasets: conjuntos de pares pregunta-respuesta que representan el comportamiento esperado. Los construyes a mano al principio y los vas ampliando.
Métricas proxy: latencia, coste por consulta, tasa de fallback, porcentaje de respuestas que activan guardrails.
Feedback de usuarios: el dato más valioso y el más difícil de recoger sistemáticamente.

Herramientas: Braintrust (evaluación humana + automatizada), LangSmith, W&B Weave si ya usas Weights & Biases.

Capa 4: Observabilidad y trazabilidad

Cuando algo falla en producción — y va a fallar — necesitas poder reconstruir exactamente qué pasó: qué prompt se envió, qué contexto se inyectó, qué modelo respondió, cuántos tokens consumió y cuánto tardó.

Tracing end-to-end: cada interacción trazada desde el input del usuario hasta la respuesta final, incluyendo pasos intermedios (RAG retrieval, tool calls, cadenas de agentes).
Dashboards de coste en tiempo real: saber cuánto estás gastando por usuario, por feature, por modelo. No esperar a la factura de fin de mes.
Alertas: degradación de latencia, spike de costes, aumento de tasa de error.

Herramientas: Langfuse (open source, muy bueno para startups), LangSmith, Helicone para dashboards de costes.

Capa 5: Guardrails y seguridad

Esto no es opcional. Es lo que separa un prototipo divertido de un sistema en el que un CTO puede confiar.

Input validation: detectar y bloquear prompt injections, PII en las consultas, intentos de jailbreak.
Output validation: verificar que las respuestas no contienen información confidencial, contenido dañino o alucinaciones flagrantes.
Data Loss Prevention (DLP): asegurarte de que datos sensibles no se envían al proveedor del modelo.
Audit trail: quién usó qué modelo, cuándo y qué datos se procesaron. Imprescindible para compliance.

AWS Bedrock, Azure OpenAI y Google Vertex AI ofrecen guardrails nativos para sus modelos. Para una capa independiente del proveedor, Guardrails AI (open source) y NeMo Guardrails de NVIDIA son las opciones más maduras.

Capa 6: CI/CD para LLMs

Sí, necesitas pipelines de despliegue para tus aplicaciones LLM. Pero no son los mismos que para software tradicional.

Un pipeline de LLMOps incluye:

Cambio de prompt o configuración de RAG
Ejecución automática de evals contra golden dataset
Comparación de métricas vs versión anterior
Aprobación (automática si pasa umbral, manual si no)
Despliegue gradual (canary)
Monitorización post-despliegue

ZenML trata toda tu aplicación agéntica como un pipeline de pasos, integrándose con LangChain, LangGraph o cualquier otro framework. Es probablemente la opción más completa para esta capa si quieres algo open source.

Cuánto cuesta esto (de verdad)

Vamos a hablar de dinero, que es lo que importa cuando te sientas con dirección.

Equipo mínimo para LLMOps serio: 1 ML engineer + 1 platform engineer que dediquen al menos el 50% de su tiempo. No, no puedes pedirle al “chico de los datos” que lo haga en sus ratos libres.

Stack de herramientas (rango mensual):

Opción bootstrap (todo open source): Langfuse + LiteLLM + Guardrails AI + ZenML → 0€ en software, solo compute.
Opción startup: LangSmith Team ($39/user/mes) + Helicone ($50-200/mes) → 300-600€/mes para un equipo de 5.
Opción enterprise: Databricks ML + guardrails nativos cloud → 2.000-10.000€/mes dependiendo del volumen.

El coste que nadie presupuesta: tokens. Una aplicación RAG empresarial que procesa 10.000 consultas/día con contextos de 3.000 tokens puede gastar entre 500€ y 5.000€/mes solo en API calls, dependiendo del modelo. GPT-4o mini vs GPT-4o es la diferencia entre 500€ y 5.000€. Por eso el routing inteligente de la Capa 1 es probablemente la inversión con mejor ROI de todo el stack.

Los 3 errores que hunden proyectos LLMOps

Después de ver cómo varios equipos pasan por esto, los patrones de fallo son claros:

Error 1: Empezar con el stack completo. No montes las 6 capas el primer día. Empieza por observabilidad (saber qué pasa) y gestión de prompts (controlar qué envías). El resto lo vas añadiendo cuando duele.

Error 2: No presupuestar tokens desde el diseño. El prompt engineering no es solo “que responda bien”. Es “que responda bien gastando los tokens justos”. Un prompt de sistema de 2.000 tokens que podrías reducir a 500 te está costando 4x más en cada llamada. Multiplica por miles de llamadas diarias.

Error 3: Tratar la evaluación como algo “para después”. Si no tienes evals antes de producción, estás volando a ciegas. No necesitas un sistema sofisticado — empieza con 20 pares pregunta-respuesta que representen los casos importantes y corre las evals en cada cambio de prompt.

Por dónde empezar mañana

Si estás leyendo esto y tu empresa ya tiene un prototipo con LLMs funcionando (o va a tenerlo pronto), este es el plan mínimo viable:

Semana 1: Pon Langfuse o LangSmith. Empieza a ver qué está pasando realmente en tus llamadas a modelos.
Semana 2: Versiona tus prompts. Sácalos del código y ponlos en un sistema donde puedas hacer diff y rollback.
Semana 3: Crea tu primer golden dataset (20-50 ejemplos) y escribe evals básicas.
Semana 4: Implementa un gateway con caché y routing. LiteLLM te lleva 2 horas de setup.

Cuatro semanas. Cero coste en licencias si usas herramientas open source. Y la diferencia entre un proyecto que aguanta seis meses y uno que aguanta seis años.

LLMOps no es sexy. No sale en demos de producto ni impresiona en keynotes. Pero es lo que separa a las empresas que realmente operan IA de las que solo juegan con ella.

En Arqont ayudamos a empresas a diseñar y operar infraestructura de IA que funciona en producción. Si tu equipo está pasando del prototipo al sistema real y necesita un plan, hablemos.