DevOps vs MLOps vs LLMOps: cómo la IA generativa llegó a producción

La imagen habitual compara tres pipelines como si fueran generaciones sucesivas. Es útil para orientarse, pero oculta la idea decisiva: DevOps, MLOps y LLMOps no son productos rivales ni escalones que se sustituyen. Son respuestas operativas a artefactos cada vez más difíciles de definir y comprobar. El software añadió automatización; el aprendizaje automático añadió datos y comportamiento estadístico; los modelos fundacionales añadieron contexto, lenguaje natural, proveedores externos, herramientas y riesgo semántico.

Esta es la historia documentada de ese cambio y, sobre todo, una guía para entender qué debe operar realmente un equipo de LLMOps. No hay una fecha de nacimiento universalmente aceptada para MLOps o LLMOps; por eso la cronología usa hitos verificables y evita atribuir el término a una sola persona.

Tres nombres, tres artefactos que mantener

La tabla no dibuja fronteras organizativas rígidas. Un producto con LLM sigue necesitando CI/CD, secretos, redes, rollbacks y SLO. Si usa un modelo propio, también necesita linaje de datos y registro de modelos. LLMOps amplía DevOps y MLOps; no los elimina.

2009: DevOps y el problema del traspaso

En Velocity 2009, John Allspaw y Paul Hammond presentaron 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.^[flickr] El título ya contenía la tesis: desplegar con frecuencia no dependía de un héroe que arrojaba un paquete por encima de una pared, sino de cooperación y automatización. Ese mismo año se celebró en Gante el primer DevOpsDays.^[devopsdays]

Anécdota documentada: diez despliegues diarios parecían provocadores cuando muchas organizaciones publicaban cada trimestre. La historia no trata de perseguir el número diez; trata de reducir el tamaño de cada cambio, acortar el feedback y hacer que desarrollo y operaciones compartan el sistema. Años después, DORA formalizó métricas de entrega y mostró que velocidad y estabilidad no tenían por qué ser opuestas.^[dora]

DevOps convirtió el pipeline en producto: código versionado, pruebas automáticas, artefactos reproducibles, despliegue gradual, telemetría y rollback. Pero una prueba podía seguir afirmando de forma bastante determinista si una función devolvía el resultado esperado.

2015–2017: cuando el artefacto empezó a aprender

Con ML, el comportamiento ya no salía solo del código. Dependía de datos, transformaciones, hiperparámetros y del mundo al que se aplicaba. El artículo de Google sobre deuda técnica oculta popularizó dos imágenes potentes: el código del modelo es una fracción pequeña del sistema real y, en un sistema acoplado, cambiar algo puede cambiarlo todo.^[debt]

Ahí nace la necesidad que hoy llamamos MLOps: reproducir datasets y features, validar esquemas, registrar experimentos y modelos, impedir que entrenamiento y servicio calculen atributos distintos, vigilar drift y decidir cuándo reentrenar. El ML Test Score de 2017 propuso 28 pruebas y controles de monitorización para pasar de demo a producción.^[mltest]

Otra historia medible: el paper de TFX describe cómo Google estandarizó componentes que antes eran scripts frágiles. En un despliegue para Google Play, el sistema entrenaba con datos nuevos; los autores informaron de ciclos más rápidos, paso a producción de meses a semanas y un aumento del 2 % en instalaciones asociado a mejor análisis de datos y modelos.^[tfx] No es una promesa universal: es un resultado de ese caso concreto.

La contribución conceptual de MLOps fue la entrega continua del pipeline y el entrenamiento continuo, además de CI/CD. La guía de Google Cloud distingue precisamente proceso manual, automatización del pipeline ML y automatización completa de CI/CD.^[mlops]

2020–2022: del modelo aislado al sistema fundacional

Tres cambios prepararon LLMOps. Primero, RAG combinó memoria paramétrica con un índice externo para aportar conocimiento actualizable y procedencia; el trabajo de Lewis y colaboradores apareció en 2020.^[rag] Segundo, el informe de Stanford de 2021 consolidó el término foundation model: un modelo entrenado ampliamente que se adapta a muchas tareas, con el beneficio —y el riesgo— de que muchos productos hereden la misma base.^[foundation]

Tercero, el producto dejó de ser solo el peso del modelo. InstructGPT mostró en 2022 que el ajuste con feedback humano podía cambiar de forma sustancial la utilidad: en la distribución evaluada por sus autores, el modelo de 1,3 mil millones de parámetros fue preferido al GPT‑3 de 175 mil millones, aunque todavía cometía errores sencillos.^[instruct] HELM, también en 2022, defendió una evaluación multidimensional y transparente en vez de un único benchmark.^[helm]

Desde entonces se popularizó la etiqueta LLMOps. No designa “MLOps con un prompt” ni exige entrenar un modelo fundacional. Muchas aplicaciones nunca entrenan pesos: operan APIs, prompts, RAG, herramientas y reglas. Su unidad de cambio es el sistema LLM compuesto.

Qué opera LLMOps de verdad

1. Un bundle versionado, no un prompt suelto

Una versión desplegable debe identificar, como mínimo: proveedor y versión del modelo; parámetros de inferencia; mensajes de sistema y plantillas; esquema de herramientas; corpus, parser, chunking, embeddings e índice de RAG; políticas de seguridad; conjunto de evaluación; y código de orquestación. Dos ejecuciones con el mismo prompt visible pueden ser productos distintos si cambió cualquiera de esas piezas.

La promoción debe ser inmutable: app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id. Si no puedes reconstruir esa combinación, tampoco puedes explicar un incidente ni hacer rollback.

2. Evaluación antes de optimización

En software se prueba una salida esperada. En lenguaje hay respuestas correctas con formas diferentes y respuestas elegantes que son falsas. Por eso LLMOps empieza con un dataset de evaluación extraído de tareas reales, casos límite y abusos previsibles. Cada ejemplo necesita criterio, no solo una “respuesta dorada”.

• Calidad de tarea: exactitud, completitud, formato y cumplimiento de instrucciones.
• RAG: recall del recuperador, relevancia del contexto, fidelidad de la respuesta y calidad de las citas. Evaluar solo la respuesta esconde si falló la búsqueda o el generador.
• Seguridad: inyección directa e indirecta, fuga de datos, abuso de herramientas y contenido no permitido.
• Operación: latencia extremo a extremo, tokens, coste, reintentos, tasa de errores y saturación de cuotas.

Los jueces basados en LLM ayudan a escalar, pero también son modelos: deben calibrarse frente a revisiones humanas, registrar su propia versión y permitir desacuerdo. Una puerta de release seria combina métricas deterministas, jueces, pruebas adversariales y muestreo humano.

3. RAG como pipeline de datos en línea

RAG no es “conectar una base vectorial”. Es una cadena: autorización de documentos → extracción → limpieza → chunking → embeddings → indexación → recuperación → reranking → construcción de contexto → generación → citas. Cada flecha puede degradarse.

Hay que versionar el corpus y el índice, medir frescura, impedir que un usuario recupere documentos que no puede ver, conservar los identificadores de fragmento en la traza y probar el sistema con preguntas cuya fuente sea conocida. RAG puede mejorar el anclaje, pero no convierte la salida en verdad ni elimina la inyección de prompt; OWASP lo señala explícitamente.^[owasp]

4. Observabilidad semántica y FinOps

Un HTTP 200 no significa que la respuesta haya sido útil. La traza debe recorrer entrada, política, recuperación, reranking, llamadas al modelo, herramientas, reintentos y salida final. OpenTelemetry ya define convenciones para modelo, tokens, mensajes y llamadas a herramientas; la captura de contenido debe ser opcional porque puede contener datos sensibles.^[otel]

Los paneles útiles cruzan calidad con operación: éxito de tarea y groundedness por versión; latencia p50/p95/p99; tokens de entrada/salida; coste por tarea completada, no solo por llamada; hit rate de caché; profundidad del agente; fallos de herramienta; y escalados a humano. Un agente barato por token puede ser caro si entra en bucles.

Conviene definir SLO desde lo que percibe el usuario, como recomienda la ingeniería SRE: disponibilidad, latencia y corrección.^[sre] Para LLMOps, un ejemplo sería: “el 95 % de consultas de política autorizadas responde en menos de 6 segundos, con cita válida y sin fuga entre tenants”.

5. Seguridad, gobierno y límites de agencia

El modelo procesa datos e instrucciones en el mismo canal; esa ambigüedad hace que la inyección de prompt sea un problema arquitectónico, no un filtro que se instala al final. OWASP mantiene un catálogo específico de riesgos LLM, mientras que el perfil de IA generativa de NIST organiza acciones de gobierno, medición y gestión del riesgo.^{[nist][owasp]}

• Trata el texto recuperado, páginas web y resultados de herramientas como entrada no confiable.
• Aplica mínimo privilegio y permisos por herramienta; separa leer, proponer y ejecutar.
• Valida salidas antes de SQL, shell, correo, pagos o cambios de infraestructura.
• Exige aprobación humana para acciones irreversibles o de alto impacto.
• Define retención, redacción de PII, residencia y acceso a prompts y trazas.
• Incluye kill switch, límites de pasos y presupuesto, timeouts y rollback.

Un pipeline LLMOps de producción, paso a paso

1. Define la tarea y el riesgo. Qué decisión apoya, qué puede hacer, quién responde y qué no debe ocurrir.
2. Crea el conjunto de evaluación. Casos normales, bordes, idiomas, grupos relevantes y ataques; congela una línea base.
3. Selecciona por restricciones. Calidad por tarea, latencia, privacidad, región, contexto, herramientas y coste; no por un leaderboard general.
4. Construye el contexto. RAG solo si aporta conocimiento o trazabilidad; conserva ACL, procedencia y frescura.
5. Instrumenta antes de lanzar. IDs de versión y correlación, spans, tokens, costes y resultados de evaluación.
6. Ejecuta gates offline. Regresión, seguridad, carga y presupuesto. Ninguna mejora media debe ocultar un fallo crítico.
7. Despliega en sombra o canary. Compara con tráfico real sin conceder agencia completa al candidato.
8. Muestrea producción. Señales automáticas, feedback contextual y revisión humana con reglas de privacidad.
9. Promueve o revierte el bundle completo. Modelo, prompt, índice, herramientas y políticas viajan juntos.

Tres anécdotas que dejaron reglas operativas

Flickr, 2009: “diez despliegues al día” quedó en la memoria, pero la parte duradera era “cooperación entre Dev y Ops”. La frecuencia fue el efecto visible de acortar feedback y compartir responsabilidad.^[flickr]

TFX, 2017: el equipo no resolvió producción con un algoritmo mejor, sino sustituyendo pegamento ad hoc por una plataforma repetible. Esa es la transición de “tenemos un modelo” a “podemos operar modelos”.^[tfx]

Tay, 2016: era anterior a los LLM modernos, así que no debe presentarse como un fallo de LLM. Sí fue una advertencia operacional. Microsoft explicó que, durante las primeras 24 horas, un ataque coordinado explotó una vulnerabilidad no prevista y el bot quedó fuera de línea.^[tay] La regla que llega hasta LLMOps es clara: pruebas de laboratorio, red teaming, observación en vivo y capacidad de retirada son partes del producto.

Errores frecuentes al implantar LLMOps

• Llamar “plataforma” a un catálogo de prompts. Sin evaluación, linaje, permisos, trazas y rollback solo hay almacenamiento.
• Medir únicamente hallucination rate. La utilidad, la abstención, el formato, la seguridad, la latencia y el coste también determinan éxito.
• Registrar todos los prompts sin política. La observabilidad puede convertirse en una copia clandestina de datos sensibles.
• Cambiar de modelo directamente en producción. Incluso un modelo “mejor” altera estilo, tool calling, longitud y coste.
• Dar herramientas con permisos del servicio. El agente debe actuar con identidad y alcance del usuario o de una función mínima.
• Convertir feedback positivo en reentrenamiento automático. Un pulgar arriba no explica corrección, seguridad ni representatividad.

La evolución real: ampliar el objeto de responsabilidad

DevOps hizo operable el cambio de software. MLOps añadió el cambio de datos y comportamiento predictivo. LLMOps añade el cambio de contexto, intención y acción. La disciplina madura no consiste en dibujar más cajas, sino en poder responder cinco preguntas para cada salida: qué versión la produjo, con qué contexto, cómo fue evaluada, qué pudo hacer y cuánto costó.

Si esas respuestas existen, el sistema puede mejorar sin depender de fe. Si no existen, el “pipeline LLMOps” sigue siendo una demo con una ruta de red hacia producción.

Fuentes y lecturas adicionales

Artículos científicos, documentación oficial y relatos de incidentes de primera mano utilizados para esta entrada.

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives