LLMOps: el flujo real para llevar un sistema LLM a producción y mantenerlo vivo

La demo funcionó. El sistema no. Es el patrón que más nos encontramos cuando entramos en un equipo que ya tiene algo con LLM delante de usuarios reales: el prototipo convenció al comité en quince minutos y seis meses después nadie sabe decir si hoy responde mejor o peor que en marzo. No hay una métrica que lo diga. Hay una sensación, y las sensaciones no sostienen un sistema en producción.

LLMOps es la disciplina que cierra ese hueco: el conjunto de prácticas para construir, desplegar, medir y mantener sistemas cuyo comportamiento no está escrito en tu código. No es una plataforma que se compra ni un rol que se contrata. Es un ciclo con etapas, puertas de calidad y responsables — y la mayoría de equipos lo tiene abierto por algún punto sin saberlo.

Este artículo es la versión operativa de ese ciclo: qué versionas de verdad, cuál es el flujo etapa por etapa, dónde van las dos puertas, qué métricas deciden y qué fallos sólo aparecen cuando ya hay tráfico real. Si lo que buscas es la conversación de negocio —qué mide un Head of Product para decidir si una feature de IA sigue viva—, está en cómo medir si la IA de tu producto funciona. Esto de aquí es la capa de ingeniería que hay debajo.

LLMOps no es MLOps con otro modelo

El error de partida más caro es tratar un sistema LLM como un proyecto de machine learning clásico. Comparten la intención —operar software cuyo comportamiento es estadístico, no determinista— pero no comparten el objeto sobre el que se opera. En MLOps el artefacto central son los pesos, las features y el dataset de entrenamiento; el modelo cambia cuando tú decides reentrenarlo. En LLMOps el modelo lo entrena otro, cambia cuando ese otro quiere, y lo que tú controlas es todo lo demás.

Esa diferencia no es filosófica. Reordena el ciclo entero:

La consecuencia práctica es incómoda: puedes tener el sistema congelado, sin un solo commit en tres semanas, y estar sirviendo respuestas peores que hace un mes. En software tradicional eso no pasa. En LLMOps es el escenario base contra el que se diseña.

Qué versionas realmente: el bundle de contexto

Antes de hablar de flujo hay que fijar la unidad de despliegue. Si le preguntas a un equipo qué versiona de su sistema LLM, la respuesta suele ser «el prompt» — y el prompt es entre el 10% y el 20% de lo que determina el comportamiento. Estos son los ocho elementos que forman el bundle de contexto, y todos tienen que vivir en el repositorio:

• Plantillas de prompt: system prompt, ejemplos few-shot, plantillas de tarea. Con versión propia y changelog, no editadas en caliente desde un panel.
• Definiciones de herramientas: nombre, descripción y JSON Schema de cada parámetro. La descripción de una tool no es documentación: es prompt que se envía en cada llamada y que decide si el modelo la usa bien o la ignora.
• Configuración de recuperación: modelo de embeddings, estrategia de chunking y solape, top-k, reranker, filtros de metadatos, umbral de similitud.
• El índice: versión, fecha de ingesta y hash del corpus. Un índice reconstruido es un despliegue, aunque no haya cambiado ni una línea de código.
• Política de enrutado y pin de modelo: qué modelo atiende qué tarea, con identificador de versión explícito. claude-sonnet-5 es un pin; «el último Claude» no lo es.
• Parámetros de muestreo: temperature, top_p, max_tokens, secuencias de parada.
• Guardrails: filtros de entrada y salida, política de PII, listas de rechazo, límites de pasos y de coste por tarea.
• El conjunto de evaluación y sus umbrales: los casos, las rúbricas y el listón que hay que superar para promocionar.

La regla operativa es simple y bastante estricta: un release es la tupla completa. Si subes top-k de 5 a 8, no estás afinando un parámetro — estás desplegando una versión nueva del sistema, y le corresponde el mismo ciclo de evaluación que a un cambio de prompt. Los equipos que tratan la recuperación como configuración y el prompt como código acaban con la mitad de su comportamiento fuera de control de versiones.

El flujo: nueve etapas, dos puertas, un bucle que se cierra

Este es el ciclo que instalamos cuando entramos en un equipo con sistemas LLM ya en producción. No hay nada exótico: la mayoría de las piezas existen en cualquier práctica de ingeniería seria. Lo que casi nunca existe es el orden y, sobre todo, el cierre del bucle.

Etapa 0 · El contrato de tarea es lo primero, no el prompt

Casi todos los sistemas LLM que auditamos empiezan por el prompt. Es el orden equivocado. Antes de escribir una línea hay que fijar por escrito qué cuenta como respuesta correcta, qué formato es obligatorio, qué fuentes son admisibles y —esto es lo que casi nadie escribe— qué debe hacer el sistema cuando no lo sabe. Un sistema sin política de abstención definida siempre inventa, porque generar es exactamente lo que sabe hacer.

El contrato lo firma quien conoce el dominio: el jurista si es contratación, el responsable de soporte si es atención al cliente, el analista si es reporting. No el equipo de IA. Si el contrato sólo existe en conversaciones, la evaluación posterior medirá lo que el equipo técnico cree que es correcto, que rara vez coincide con lo que el negocio necesita.

Etapas 1 y 2 · El golden set y el baseline honesto

El golden set es el activo más subestimado de todo el ciclo. Un prompt bueno lo replica cualquiera en una tarde; un conjunto de 200 casos etiquetados con criterio de dominio es meses de trabajo acumulado y no se puede copiar. Empieza pequeño —30 a 50 casos por capacidad—, estratifica por dificultad e incluye tres tipos de caso adversario: entradas fuera de dominio, preguntas legítimamente ambiguas donde la respuesta correcta es reconocer la ambigüedad, e intentos de inyección de instrucciones ocultas en los documentos que el sistema recupera.

El baseline honesto es la contramedida contra el optimismo. Mide primero el sistema más simple que resuelve la tarea —a menudo una sola llamada con buen contexto— y publica el número. Sin ese punto de referencia, cualquier arquitectura posterior parece una mejora. Con él, muchos equipos descubren que su pipeline de siete pasos rinde igual que la llamada única y cuesta cinco veces más.

Etapa 4 · Puerta 1: la evaluación offline decide, no opina

La primera puerta corre en CI, en cada pull request que toque cualquier elemento del bundle. Y evalúa cuatro cosas a la vez, no una:

• Calidad por capacidad, no agregada. Una media que sube ocultando que la capacidad crítica cayó ocho puntos es peor que no medir.
• Regresión cero en el subconjunto crítico: los casos que no pueden fallar nunca —los que costaron una incidencia— son un bloque aparte con umbral absoluto.
• Coste por tarea útil comparado con el baseline. El coste es criterio de aceptación, no una consecuencia que se descubre en la factura.
• Latencia p95 end-to-end, incluyendo herramientas y recuperación.

Para que esto sea sostenible conviene partir la suite en dos: una fast suite de pocos minutos que corre en cada PR, y una full suite nocturna con el conjunto completo. Una suite única de 400 casos que tarda cuarenta minutos acaba desactivada en tres semanas, y una puerta desactivada es peor que ninguna puerta porque produce falsa confianza.

Etapas 5 y 6 · Puerta 2: el tráfico real es el único juez definitivo

Ningún conjunto de evaluación captura la distribución real de entradas. Por eso la promoción a producción es progresiva y no un interruptor: primero shadow (el sistema nuevo procesa el tráfico real pero su salida no se sirve, sólo se compara), después canary al 5%, 25% y 100%, con una ventana mínima en cada escalón que dependa del volumen —no de la impaciencia.

La condición innegociable es que el criterio de rollback esté escrito antes de abrir tráfico: qué métrica, qué umbral, cuánto tiempo y quién decide. Un rollback discutido en caliente a las once de la noche siempre se retrasa, porque en ese momento todo el mundo tiene una hipótesis de por qué los números son ruido.

Etapa 7 · Observabilidad: la traza es la unidad, no el log

Un log de peticiones y respuestas no sirve para depurar un sistema agéntico. Lo que necesitas es la traza completa de la tarea: cada paso como un span anidado, con el prompt renderizado, los documentos recuperados y sus puntuaciones, las herramientas invocadas con sus argumentos, los tokens de entrada y salida, la latencia y el coste. Las convenciones semánticas gen_ai.* de OpenTelemetry cubren la mayor parte de esos atributos y evitan inventar un esquema propio que nadie más entienda.

El criterio de calidad de la instrumentación es concreto: ante una queja de un usuario, ¿puedes reconstruir exactamente qué contexto vio el modelo cuando produjo esa respuesta? Si la respuesta es no, la observabilidad está incompleta por muy bonitos que sean los dashboards de tokens. Es el mismo hueco que describimos en el gap de calidad que casi nadie mide en agentes en producción: se monitoriza el consumo, no el resultado.

Etapa 8 · La minería de fallos es lo que convierte el ciclo en bucle

Aquí es donde se rompe la mayoría de implementaciones que hemos visto. Se instrumentan trazas, se montan dashboards, se recogen pulgares abajo… y nadie tiene en su semana la tarea de convertir esos fallos en casos de evaluación. El resultado es un sistema que acumula telemetría y no aprende: los mismos errores reaparecen release tras release porque nunca entraron en la suite que los habría detectado.

El ritual mínimo que funciona: una sesión semanal de 45 minutos donde dos personas revisan una muestra de trazas fallidas, clasifican la causa raíz —contexto insuficiente, recuperación mala, instrucción ambigua, herramienta rota, límite del modelo— y promueven a golden set los casos que representan un patrón. Es la etapa más barata del ciclo y la que decide si dentro de seis meses el sistema es mejor o simplemente más viejo.

Métricas: qué decide y qué es sólo ruido bonito

La telemetría por defecto de cualquier proveedor te da tokens, latencia y errores. Las tres son necesarias y ninguna dice si el sistema funciona. Estas son las cuatro familias que sí deciden:

• Calidad: tasa de acierto por capacidad; groundedness (porcentaje de afirmaciones respaldadas por una cita que resuelve de verdad); validez de las llamadas a herramientas (schema correcto y argumentos plausibles); tasa de abstención correcta cuando no hay información suficiente.
• Fiabilidad operativa: latencia p50 y p95 end-to-end; pasos por tarea; tasa de bucles y de timeouts; tasa de error de herramienta.
• Coste: coste por tarea útil —créditos consumidos entre resultados correctos y realmente usados—, ratio de tokens de entrada frente a salida, y coste marginal del contexto acarreado. El coste por token es una métrica de proveedor; el coste por tarea útil es una métrica de negocio.
• Adopción: containment (tareas cerradas sin intervención humana), tasa de escalado, y porcentaje de salidas que el humano edita antes de aceptar — el indicador más honesto de calidad percibida que existe.

De todas ellas, la que más veces cambia una decisión de arquitectura es el coste por tarea útil. Un sistema con un 92% de acierto a 0,40 € por tarea puede ser peor negocio que otro con un 86% a 0,04 € si el 8% restante lo absorbe una cola humana que ya existe. Esa comparación es imposible de hacer si mides tokens. Sobre por qué esa cifra se dispara entre el piloto y la escala, lo desarrollamos en el coste real de poner IA en producción.

Evaluar con LLM: útil, pero hay que calibrar al juez

Usar un modelo como evaluador es lo que hace viable medir calidad a escala, y también la puerta de entrada de la mayoría de autoengaños. Un juez basado en LLM es un clasificador más: antes de confiar en él hay que medir su acuerdo con etiquetas humanas sobre una muestra. Como regla de trabajo, por debajo de un acuerdo sustancial —un kappa en torno a 0,7— el juez está midiendo su propio estilo, no tu calidad.

Cuatro reglas que aplicamos siempre: rúbrica escrita con un único criterio por llamada (no pidas «puntúa del 1 al 10 la calidad global»); modelo juez distinto del evaluado, para no premiar el estilo propio; comparación por pares cuando el criterio es preferencia y puntuación absoluta sólo cuando hay rúbrica objetiva; y un muestreo humano permanente de en torno al 10% para detectar cuándo el juez se desalinea. El juez también deriva, y también necesita su propio golden set.

Cómo se escribe esa rúbrica —y cómo se elige el baseline contra el que comparar, que es la otra mitad del problema— lo desarrollamos en qué significa exactamente que un agente «funciona mejor», con los trabajos que han estudiado el asunto.

Los cuatro fallos que sólo aparecen en producción

Ninguno de estos aparece en desarrollo. Los cuatro aparecen cuando hay tráfico real y tiempo.

1. Drift del proveedor. El modelo se actualiza y tu sistema cambia sin que nadie haya hecho un commit. La contramedida es doble: pin de versión explícito en el bundle y una suite de regresión programada que corre contra producción semanalmente y publica la comparación con el baseline. Es el control más barato de todo el ciclo y el que menos equipos tienen.

2. Degradación silenciosa de la recuperación. El corpus crece, la densidad semántica aumenta, el top-k que funcionaba con 2.000 documentos deja de traer el fragmento correcto con 50.000. El síntoma es traicionero: el modelo sigue respondiendo con total seguridad, sólo que ahora sobre contexto incompleto. Se detecta midiendo la recuperación por separado —precisión y recall del contexto— y no sólo la respuesta final. Es el punto donde más se juega un sistema RAG, y lo tratamos a fondo en RAG para aplicaciones empresariales.

3. Regresión por edición de prompt. Alguien arregla el caso que reportó un cliente y rompe tres que nadie estaba mirando. Es exactamente el fallo que la Puerta 1 existe para bloquear; sin ella, cada arreglo es una apuesta. Y con prompts editables en caliente desde un panel de administración, sin release ni evaluación, es una apuesta que se hace varias veces por semana.

4. Explosión de coste por contexto. El histórico de conversación que se acarrea entero, el fichero completo cuando bastaba una sección, las descripciones de veinte herramientas replicadas en cada llamada. El coste de entrada suele superar al de salida y casi nadie lo separa en su análisis. La contramedida es una auditoría periódica de la composición del contexto, que es ingeniería de contexto aplicada al presupuesto.

Gobernanza: quién firma cada puerta

Un ciclo sin responsables asignados se degrada en dos meses. El reparto mínimo que funciona en equipos de 10 a 100 personas asigna a producto o dominio el contrato de tarea y el golden set; a ingeniería, el bundle, las puertas y la observabilidad; y a un responsable único —normalmente el Tech Lead— la decisión de promocionar y la de hacer rollback. Tres roles, no un comité.

A esto se añade la capa regulatoria, que en Europa ya no es teórica: para sistemas clasificados como de alto riesgo, la trazabilidad y el registro de eventos dejan de ser buenas prácticas de ingeniería y pasan a ser requisito. La buena noticia es que el ciclo que acabamos de describir produce casi toda esa evidencia como subproducto —trazas retenidas, versiones firmadas, evaluaciones archivadas— siempre que se diseñe así desde el principio. Hacerlo después, como retrofit, es donde el coste se multiplica: lo detallamos en Compliance-First AI Design.

Dónde está tu equipo: cuatro niveles

Un modelo de madurez sirve para una sola cosa: decidir cuál es el siguiente movimiento, no para colgarse una medalla.

• Nivel 0 · Demo. Funciona, no se mide, el prompt vive fuera del repositorio. Siguiente movimiento: el contrato de tarea.
• Nivel 1 · Reproducible. Bundle completo versionado, modelo pineado, índice con snapshot. Puedes reconstruir cualquier release. Siguiente movimiento: el golden set y la Puerta 1.
• Nivel 2 · Evaluado. Evaluación offline en CI, despliegue progresivo, trazas completas. Sabes si un cambio mejora o empeora antes de servirlo. Siguiente movimiento: cerrar el bucle con minería de fallos.
• Nivel 3 · Gobernado. Bucle cerrado, coste por tarea como criterio de aceptación, responsables nombrados, evidencia auditable. Aquí el sistema mejora con el uso en lugar de envejecer con él.

La mayoría de equipos con los que trabajamos entra en el nivel 0 o 1 y cree estar en el 2, porque tiene dashboards. Los dashboards son nivel 1; el nivel 2 empieza cuando un número puede bloquear un despliegue. Si quieres situar esta capa dentro del mapa completo de madurez de la empresa —y no sólo del equipo de ingeniería—, la pieza de ingeniería de IA: del piloto a producción la ubica frente a las otras seis.

Las primeras dos semanas

Si tienes un sistema LLM en producción y nada de lo anterior instalado, este es el orden que produce más señal por euro invertido. No requiere plataforma nueva ni reescribir nada.

Semana 1. Escribe el contrato de tarea con la persona de dominio —dos folios, incluida la política de abstención—. Instrumenta trazas completas con atributos gen_ai.* en el flujo principal. Congela el bundle: mete en git todo lo de la lista de ocho elementos y pinea la versión del modelo.

Semana 2. Construye 30 casos golden a partir de tráfico real, incluyendo los cinco fallos que más te han dolido. Mide el baseline y publícalo. Monta la fast suite en CI con dos umbrales: calidad en el subconjunto crítico y coste por tarea. A partir de ahí, cada cambio pasa por la puerta.

En dos semanas no tienes LLMOps maduro, pero tienes lo único que de verdad hace falta para empezar: la capacidad de responder «sí» o «no» a la pregunta de si el cambio de ayer mejoró el sistema. Todo lo demás se construye encima de esa respuesta.

La misma disciplina que ya aplicas al código

Nada de lo anterior es nuevo como principio. Contrato antes que implementación, evaluación automática antes que promoción, despliegue progresivo, telemetría que cierra el bucle: es ingeniería de software normal, aplicada a un componente que no es determinista. Por eso los equipos que ya trabajan con Spec-Driven Development adoptan LLMOps en semanas y no en trimestres — ya tienen el hábito de escribir la especificación antes que el artefacto, y el bundle de contexto no es más que otra especificación versionada.

En los programas onext AI-Accelerated Development este ciclo es parte del harness que dejamos instalado, no un añadido posterior. Los resultados que firmamos con clientes en 2026 —×7 velocidad de entrega, 0 sprints perdidos, −50% time-to-production— no salen de escribir mejores prompts: salen de que los equipos pueden desplegar cambios en sistemas de IA sin miedo, porque hay una puerta que dice si el cambio es bueno antes de que lo vea un usuario.

Preguntas frecuentes

¿LLMOps y MLOps son lo mismo?

Comparten la intención —operar sistemas cuyo comportamiento no está escrito en tu código— pero no el objeto. En MLOps versionas pesos, features y datasets de entrenamiento, y el modelo sólo cambia cuando tú lo reentrenas. En LLMOps versionas un bundle de contexto (prompts, herramientas, recuperación, políticas de enrutado, guardrails y umbrales) sobre un modelo que no controlas y que puede cambiar sin que toques nada. Eso acorta el ciclo de cambio de semanas a horas, convierte la evaluación en el artefacto crítico y desplaza el coste del entrenamiento a la inferencia.

¿Cuántos casos necesita un golden set para empezar a evaluar?

Entre 30 y 50 por capacidad es suficiente para detectar regresiones grandes, que es el 80% del valor. No empieces por 400: un conjunto grande que nadie ejecuta vale menos que uno pequeño que corre en cada pull request. Estratifica por dificultad e incluye casos adversarios —entradas fuera de dominio, ambigüedad legítima donde lo correcto es reconocerla, e inyección de instrucciones en documentos recuperados—. El golden set crece después, alimentado por los fallos reales de producción.

¿Puedo usar el mismo modelo como juez del sistema que evalúo?

Puedes, pero antes hay que calibrarlo contra etiquetas humanas sobre una muestra. Como regla de trabajo, por debajo de un acuerdo sustancial (kappa en torno a 0,7) el juez mide su propio estilo, no tu calidad. Conviene además usar un modelo distinto del evaluado, una rúbrica escrita con un solo criterio por llamada y un muestreo humano permanente de en torno al 10% para detectar cuándo el juez se desalinea.

¿Cada cuánto hay que reevaluar si no cambio nada?

Semanalmente como mínimo, y siempre que el proveedor anuncie actualización de modelo. Un sistema LLM puede degradarse sin un solo commit: el modelo cambia, el corpus indexado crece y el recall cae, o el uso real se aleja del que probaste. Un cron que ejecuta la suite de regresión contra producción y publica la comparación con el baseline es el control más barato del ciclo.

¿Necesito una plataforma específica de LLMOps o me vale mi stack actual?

En la mayoría de casos el stack actual llega más lejos de lo que se cree: git para el bundle, la CI que ya tienes para la Puerta 1, feature flags para el despliegue progresivo y tu backend de trazas para la observabilidad con convenciones gen_ai.*. Una plataforma dedicada aporta sobre todo ergonomía en anotación y comparación de evaluaciones. Comprarla antes de tener contrato de tarea y golden set no acelera nada: añade una superficie más que mantener.