LLMOps en la práctica: evaluación, observabilidad, costes y gobernanza para la IA

Un fin de semana basta para montar una app RAG sobre los datos de la empresa, añadir llamadas a herramientas, envolver un agente en una interfaz decente y hacer la demo. Todos quedan impresionados. Lo difícil es que siga siendo fiable seis meses después. Entonces empiezan las preguntas. ¿Cómo sabemos si las respuestas están empeorando? ¿Qué pasó cuando cambió el modelo el martes pasado? ¿Por qué subió un 40 % la factura de IA? Seguridad quiere saber qué información recibe el modelo. E ingeniería plantea la pregunta que no le gusta a nadie: ¿podemos reproducir la respuesta que recibió realmente el cliente?

Ese es el terreno de LLMOps. DevOps dio a los equipos una disciplina para construir, desplegar y operar software corriente. LLMOps aplica la misma mentalidad a sistemas cuyo comportamiento depende de modelos, prompts, contexto, recuperación y salida probabilística, y esa diferencia lo cambia casi todo.

Es más que vigilar un endpoint de LLM

Mucha gente cree que LLMOps son dashboards alrededor de un endpoint de OpenAI o Azure OpenAI. Eso es una porción pequeña. Una aplicación de IA en producción es un montón de piezas móviles: el modelo fundacional con sus prompts e instrucciones de sistema, pipelines RAG con modelos de embeddings e índices vectoriales, herramientas y agentes, datasets de evaluación, políticas de seguridad, código de aplicación normal y feedback de los usuarios.

Una forma de tenerlo presente es sumar gestión del ciclo de vida, evaluación, observabilidad, gobernanza y control de costes. La palabra que más importa ahí es ciclo de vida. Un sistema de IA no está terminado cuando el modelo llega a producción. Es ahí donde empieza el ciclo de vida real.

Un ciclo de vida que nunca se detiene

El software clásico gira en un bucle de programar, probar, desplegar, vigilar y mejorar. Las aplicaciones LLM recorren un bucle parecido, con una gran diferencia. En el software corriente, cambiar una línea de código suele cambiar el comportamiento de forma predecible. En una app LLM, la salida puede verse afectada por un cambio en la versión del modelo, la temperatura, el prompt, los documentos recuperados, el modelo de embeddings, la estrategia de chunking, las definiciones de herramientas o el orden del contexto. Por eso la gestión del ciclo de vida hace falta en varias capas. No despliegas un modelo de IA. Despliegas un sistema de IA.

El prompt es configuración de producción

Al principio del proyecto, alguien escribe un prompt como este:

You are a helpful assistant...

Luego no deja de crecer. Unos meses después lleva lógica de negocio, formato de salida, límites de seguridad, respuestas de ejemplo y excepciones, y alguien lo está editando en vivo en producción. Eso es un problema. Un prompt de producción merece un trato cercano al del código fuente, versiones incluidas:

customer-support-v1
customer-support-v2
customer-support-v3

Cada versión necesita un responsable, un historial de cambios, resultados de evaluación, un estado de despliegue y una opción de rollback. Un cambio de prompt es un cambio en producción. Si la versión 17 mejora la relevancia de las respuestas un 12 % pero duplica las alucinaciones, conviene descubrirlo antes de que llegue a todos los usuarios. Aquí LLMOps toma mucho de la ingeniería de software: versiona todo lo que pueda alterar el comportamiento del modelo.

La evaluación es la capa de CI/CD que falta

Para los ingenieros que llegan a la IA, este puede ser el mayor cambio de mentalidad. Supón que editas un prompt, pruebas cinco preguntas a mano, ves mejores respuestas y despliegas. No basta. Mantén en su lugar un dataset de evaluación:

Question
Expected behavior
Reference answer
Relevant source
Safety expectation

Y pasa por él cada cambio relevante. Qué métricas importan depende de la aplicación. En un sistema RAG pueden interesarte la calidad de la recuperación, la fundamentación, la precisión de las citas y la relevancia de la respuesta. En un agente, si elige la herramienta correcta y la llama bien, si completa la tarea, si evita pasos innecesarios y si se recupera de los fallos. En un asistente de cara al cliente, corrección, seguridad, latencia y satisfacción del usuario. El principio es que cada cambio en un sistema de IA necesita una forma de mostrar si lo mejoró o lo empeoró. Es el equivalente en IA de las pruebas automatizadas.

Por qué no bastan las pruebas unitarias

Toma la petición «Explica por qué falló mi pipeline». Podría haber cinco respuestas igual de buenas, así que una prueba como esta no sirve:

assert response == expected_response

Prueba propiedades en su lugar:

Did the answer contain the correct root cause?
Did it use the right evidence?
Did it avoid unsupported claims?
Did it cite the correct source?

Eso apunta a varias capas de pruebas de IA:

• Las pruebas unitarias comprueban que la recuperación devuelve los documentos esperados.
• Las pruebas de integración comprueban que todo el pipeline RAG produce respuestas basadas en las fuentes.
• Las pruebas de evaluación contrastan los resultados con umbrales de calidad fijados de antemano.
• Las pruebas de red team sondean entradas adversarias o inseguras.
• Las pruebas de regresión detectan escenarios que antes funcionaban y se rompieron tras un cambio de modelo o de prompt.

Las pruebas tradicionales no desaparecen. Crecen.

Haz medibles las alucinaciones

Todo equipo con IA en producción se topa con esto: una respuesta suena segura y es falsa. Las alucinaciones no siempre son evidentes, y un modelo puede inventarse una política de la empresa, una cifra, una referencia, la salida de una llamada a una API, una fila de la base de datos o una explicación técnica entera. Así que sigue ese comportamiento de forma sistemática. En RAG, pregunta si la respuesta estaba respaldada por la evidencia recuperada. En un agente, si afirmó algo que no aparece en los resultados de las herramientas. En un asistente de datos, si la explicación coincidía con el resultado de la consulta subyacente. Por eso la fundamentación y la fidelidad se están convirtiendo en dimensiones estándar de evaluación. El objetivo no es fingir que las alucinaciones pueden llegar a cero. Es medirlas, saber dónde aparecen y reducirlas paso a paso.

Observabilidad más allá de los logs

La monitorización clásica puede decirte esto:

HTTP 500
Latency: 1.8 sec
Database error

Útil, sí. Pero imagina una respuesta errónea de la IA sobre una infraestructura sana: la API devolvió 200, el modelo terminó con normalidad, todo está en verde y aun así el cliente recibió información falsa. La observabilidad de IA necesita una traza más profunda, que registre el recorrido de la petición y no solo su punto final. Equivale a trazabilidad de la inteligencia: partiendo de una mala respuesta, recorres la petición hacia atrás hasta encontrar el paso que falló. ¿Falló la recuperación? ¿El contexto estaba incompleto? ¿El prompt tenía fallos? ¿El modelo interpretó mal la evidencia o una herramienta devolvió datos erróneos? Sin esa vista, depurar IA es adivinar.

Monitoriza todo el sistema

Un dashboard de producción no debería quedarse en el recuento de tokens y la latencia del modelo. Cubre estos grupos:

• Calidad: qué tan fundamentadas y relevantes son las respuestas, si las tareas salen bien, con qué frecuencia alucina el modelo, qué dicen los usuarios
• Rendimiento: latencia, tiempo hasta el primer token, throughput y timeouts
• Fiabilidad: peticiones fallidas, fallos de herramientas y de recuperación, y tasas de reintento
• Coste: tokens de entrada y salida, qué modelos se usan y el gasto por petición, por usuario y por flujo de trabajo
• Seguridad: infracciones de políticas, exposición de datos sensibles, peticiones bloqueadas y actividad rara de las herramientas

Con eso puedes informar de algo mejor que una API sana: la infraestructura está bien, pero la calidad de las respuestas cayó en cuanto se publicó el último prompt. Esa es la visibilidad que necesita una plataforma de IA empresarial.

El coste se convierte en un problema de ingeniería

Las aplicaciones corrientes tienen costes de infraestructura. Las aplicaciones LLM añaden otra dimensión: cada decisión consume tokens o recursos del modelo. Imagina un agente que normalmente hace:

1 model call

y que, tras un cambio de prompt, empieza a hacer:

8 model calls

Puede que siga funcionando perfectamente, pero el coste se ha disparado. Por eso compensa seguir esto:

Cost per request
Cost per successful task
Cost per customer
Cost per workflow

El trabajo con los costes pasa entonces a ser ingeniería. Usa modelos más pequeños donde encajen, cachea las operaciones repetidas, recorta el contexto, controla los bucles de los agentes, manda las tareas sencillas a modelos más baratos y reserva los caros para las tareas que los necesitan. El objetivo no es «usar el modelo más barato». Es gastar inteligencia cara solo donde crea valor.

Gobernanza

Esta es la parte de LLMOps que más debería importar a los ingenieros de datos. Toda organización tiene ya políticas de acceso a datos, datos personales, retención, registros de auditoría, seguridad, cumplimiento e identidad, y el sistema de IA tiene que respetarlas. Si un empleado no puede ver un registro de cliente en la aplicación normal, la IA no debería saltarse ese límite solo porque puede consultar la base de datos. La autorización debe llegar a la capa de IA desde la configuración corporativa, y la IA no debe tener un sistema de permisos propio y aparte. También necesitas registros de qué modelo procesó la petición, qué datos recibió, qué herramientas se invocaron, qué respuesta generó y quién inició la acción. Eso es más que observabilidad. Es gobernanza.

La producción retroalimenta el sistema

Los buenos sistemas de IA nunca quedan terminados de una vez. Aprenden del tráfico de producción. Supón que los usuarios hacen una y otra vez preguntas que el sistema RAG responde mal. Investigas y puede que la causa no esté en el modelo. Los documentos pueden estar mal troceados, puede faltar metadata, la recuperación puede ser floja, se puede estar tratando como autorizada la fuente equivocada o el prompt puede no manejar la ambigüedad. Corriges el problema de fondo y vuelves a pasar la suite de evaluación. Eso es ingeniería.

Dónde llevan ventaja los ingenieros de datos

La ingeniería de datos y LLMOps se solapan de formas interesantes. Muchas ideas conocidas se trasladan tal cual:

• La calidad de los datos es calidad de la IA
• El linaje de datos es trazabilidad de la IA
• La monitorización de pipelines es monitorización de flujos de IA
• Los cambios de esquema equivalen a cambios de prompt y de modelo
• Las pruebas de ETL equivalen a pipelines de evaluación
• El control de acceso es autorización de la IA
• La optimización de costes es optimización de tokens y modelos

Las herramientas cambian, pero la forma de pensar es la misma. Una IA fiable sigue necesitando datos fiables, pipelines bajo control y resultados medibles. El LLM no elimina esas necesidades, las hace más importantes.

¿LLMOps es solo DevOps para la IA?

Sí, como punto de partida, pero la definición se queda corta. El software normalmente no decide qué decir. Los LLM sí, y eso añade incertidumbre. Así que LLMOps tiene dos preguntas que responder. ¿Funciona el sistema correctamente? Eso es operación tradicional. ¿Se comporta correctamente? Esa es la parte nueva, y necesitas ambas. Un servicio de IA perfectamente sano puede dar respuestas pésimas, y uno que parece inestable a veces da respuestas excelentes, por eso las métricas de disponibilidad por sí solas no bastan.

Seis preguntas para cualquier diseño de IA empresarial

Surgen en cuanto una aplicación de IA importa lo suficiente como para que la gente dependa de ella:

1. ¿Están versionados los prompts y los modelos? Sin eso, reproducir un resultado se vuelve penoso.
2. ¿Se evalúa cada cambio antes de publicarlo? Sin eso, cada release es una apuesta.
3. ¿Se puede rastrear una mala respuesta hasta su origen? Sin eso, la depuración se arrastra.
4. ¿Se miden las alucinaciones y la fundamentación? Sin eso, la calidad es una suposición.
5. ¿Se pueden explicar los costes de la IA? Sin eso, el crecimiento traerá una sorpresa desagradable.
6. ¿Puedes mostrar qué datos tocó la IA y por qué? Sin eso, la gobernanza se complica.

El cambio que viene

La primera IA generativa se preguntaba si se podía lograr que un modelo hiciera una tarea siquiera. La pregunta ahora es si puede hacerla de forma fiable, una y otra vez, con seguridad y a un precio razonable. Eso es LLMOps. El modelo es una parte. La ingeniería difícil está en todo lo que lo rodea: versionado, evaluación, pruebas, observabilidad, gobernanza, seguridad y costes.

A los ingenieros de datos y de software con experiencia les resultará familiar, porque hace tiempo que aprendieron a operar sistemas que no controlan del todo. Ahora esos sistemas generan sus propias respuestas. El objetivo no es que la IA sea predecible en cualquier situación. Es construir la disciplina de ingeniería suficiente para que, cuando algo falle, puedas detectarlo, entenderlo, arreglarlo y demostrar que el arreglo funcionó. Eso convierte una demo impresionante en un sistema empresarial.