Cómo mantener un modelo de IA funcionando en producción (LLMOps)

El proyecto no termina cuando la demo funciona, ahí recién empieza

En casi todos los proyectos de IA que he visto de cerca, el momento de mayor entusiasmo es la demo. El sistema responde bien, la gerencia lo ve con casos reales y el proyecto se da por entregado. Pero una demo corre en condiciones controladas: casos elegidos, datos limpios, un modelo que ese día se portó bien. La producción es otra cosa. Es el mismo sistema todos los días, con los casos raros que nadie probó, con datos sucios y con un proveedor que actualiza su modelo cuando le conviene a él.

Lo que pasa después tiene un patrón que se repite: los primeros meses nadie revisa nada porque ya está andando, después llegan las quejas sueltas, nadie las junta ni las mide, y en algún momento alguien mira la factura o un cliente reclama en público. Recién ahí la empresa descubre que el sistema lleva meses degradándose sin un solo indicador que lo hubiera anticipado. La causa de fondo no es técnica, es de encuadre: se presupuestó un proyecto de implementación cuando lo que se compró fue un sistema vivo que depende de un tercero. Un ERP se comporta igual el año que viene salvo que alguien lo toque; un modelo de IA puede cambiar por debajo sin que tu equipo mueva una línea.

Qué es LLMOps de verdad, y por qué no es solo monitoreo

El término viene de MLOps, la disciplina armada para operar modelos entrenados por la propia empresa. La idea de fondo es la misma, pero el problema cambia de forma cuando el modelo no es tuyo. En MLOps clásico tú entrenas, tú versionas y tú decides cuándo cambia. Con un modelo de un proveedor externo, el modelo cambia por decisión ajena y tú controlas otras piezas: el contexto que le das, las instrucciones, las herramientas que puede tocar, las validaciones de salida y las reglas de cuándo escalar a un humano.

Por eso LLMOps no es un tablero de disponibilidad. Que la API responda con código 200 no dice nada sobre la calidad de lo que respondió. Un sistema puede estar disponible al cien por ciento y entregar peores respuestas cada semana. Ahí se nota la diferencia: una empresa detecta la caída de calidad sin que un cliente se lo diga, la otra solo tiene logs que dicen que todo funcionó. Conviene marcar el límite con la parte organizacional: la rutina de revisión, quién es el dueño y cuándo se decide rediseñar es gestión, y está tratado aparte en la guía de mantener y actualizar un sistema de IA en producción. Acá va la capa técnica.

Las tres cosas que se rompen con el tiempo y no aparecen en ningún log

Un sistema de IA en producción no falla como falla un software tradicional. Rara vez hay una excepción, una pantalla en blanco o un error visible. Lo que hay es degradación silenciosa, y viene de tres fuentes que conviene separar porque se detectan y se resuelven distinto.

1. El proveedor mueve el modelo debajo de tus pies

Los proveedores publican versiones nuevas y retiran las viejas con calendario propio. Si tu sistema apunta genéricamente a la última versión disponible, el comportamiento cambia de un día para otro: respuestas más largas, un formato de salida que ya no calza con el sistema que lo consume, un criterio distinto en los casos límite. Nada de eso genera un error, genera resultados que tu operación absorbe a mano. Fijar la versión y probar antes de migrar es lo mínimo, y aun así llega el día en que la versión vieja deja de existir.

2. Cambian los datos que entran

El sistema se diseñó contra los datos del mes de la implementación: ese formato de factura, ese vocabulario comercial, ese volumen de consultas. La operación real se mueve. Entra una línea de producto con nombres nuevos, un proveedor cambia el layout de sus documentos, una campaña triplica las consultas. El modelo sigue respondiendo con seguridad, solo que sobre entradas que ya no se parecen a las que se probaron. En sistemas con recuperación de información es peor: la base de conocimiento envejece y el sistema responde con confianza usando la política del año pasado.

3. El proceso de negocio cambia y nadie avisa

Este es el más caro y el menos técnico. La empresa cambia una regla de descuento, actualiza un flujo de aprobación o reorganiza quién atiende qué, y nadie piensa en el sistema de IA porque no está en la lista de a quién hay que avisar. Sigue operando con las reglas viejas durante semanas, dando respuestas que eran correctas en su momento y ahora contradicen la política vigente. Cuando alguien lo descubre, ya hay decisiones tomadas y clientes atendidos con criterio desactualizado.

Qué hay que monitorear cuando el sistema ya está vivo

Instrumentar un sistema de IA no es agregar más logs. Es capturar señales que respondan tres preguntas sin depender de la impresión de nadie: está respondiendo bien, cuánto está costando, y cambió algo respecto de la semana pasada.

• Trazas completas de cada interacción: qué entró, qué contexto se recuperó, qué herramientas se llamaron y qué salió. Sin esto, depurar un caso malo es adivinar.
• Set fijo de casos de prueba (evals) corriendo automáticamente: casos reales con respuesta esperada, ejecutados ante cada cambio de modelo, instrucciones o base de conocimiento. Es la única forma objetiva de comparar antes y después, y debe crecer con cada caso que salió mal en producción.
• Tasa de corrección humana: qué porcentaje de las salidas alguien tuvo que arreglar antes de usarlas. Es la métrica de calidad más honesta, porque la produce la operación real y no una prueba de laboratorio.
• Tasa de escalamiento a persona: si sube sin que suba el volumen, cambió la calidad o el tipo de casos que entran.
• Costo por interacción, no costo total: si el costo unitario sube sin más volumen, cambió el modelo, el largo del contexto o el tipo de tarea.
• Deriva de la entrada: volumen, largo de las consultas y aparición de términos o formatos que antes no existían. Es la alerta temprana de que los datos se movieron.
• Frescura de la base de conocimiento: cuándo se actualizó cada fuente que el sistema consulta. Un documento vencido produce respuestas seguras y equivocadas.
• Tasa de fallo silencioso: respuestas entregadas como válidas que una revisión por muestreo marcó como incorrectas. Es la métrica que casi nadie tiene y la que más duele no tener.

El muestreo manual no se reemplaza con métricas automáticas. Revisar a mano una muestra pequeña de casos cada semana, siempre con el mismo criterio, detecta problemas que ningún indicador agregado muestra. Es trabajo aburrido y es lo primero que se abandona cuando aprieta otra prioridad.

Qué no resuelve LLMOps (y por qué se compra mal)

Hay una tentación clara de comprar una herramienta de observabilidad de IA, conectarla y declarar resuelto el problema. Vale la pena decir qué no arregla esa compra.

• No arregla un caso de uso mal elegido: vas a tener métricas impecables de un sistema que a nadie le importa. La operación mide si funciona bien, no si sirve para algo.
• No reemplaza el criterio humano: la herramienta te avisa que la latencia subió, no que las respuestas empezaron a citar una política derogada.
• No elimina la dependencia del proveedor: lo que reduce el golpe de una migración forzada no es el monitoreo, es haber diseñado el sistema para que cambiar de modelo no signifique reconstruirlo entero.
• No compensa una arquitectura acoplada: si la lógica de negocio vive dentro de un prompt gigante que nadie se atreve a tocar, ninguna herramienta te salva el día que haya que cambiar una regla.
• No se instala una vez: el set de pruebas envejece y los umbrales de alerta se desajustan cuando cambia el uso. La instrumentación también se mantiene.

Y una precisión de vocabulario que evita conversaciones confusas con proveedores: monitorear no es evaluar. Monitorear es observar lo que pasa en producción; evaluar es correr casos conocidos contra un resultado esperado. Necesitas los dos. Un equipo que solo monitorea se entera tarde; uno que solo evalúa no ve lo que la realidad le está mandando.

El costo de mantenimiento que casi nunca entra al presupuesto

En la mayoría de propuestas que reviso, el presupuesto cubre diseño, construcción y puesta en marcha. La operación aparece como una línea vaga de soporte o directamente no aparece. Después la empresa descubre que operar cuesta dinero todos los meses y lo vive como sobrecosto, cuando es el costo normal de tener un sistema vivo. Estas son las partidas que existen siempre y conviene poner por escrito antes de firmar.

• Consumo de modelo o infraestructura: el gasto variable de la API o del cómputo propio. Es el único que casi todos presupuestan, y suele ser el más chico de la lista.
• Horas de un dueño técnico: tiempo asignado para revisar señales, atender alertas y mantener el set de pruebas. Es carga mensual estable, no tiempo residual.
• Mantenimiento de la base de conocimiento: actualizar documentos, políticas y catálogos que el sistema consulta. Es trabajo de negocio, no de tecnología, y por eso nadie lo asume.
• Migraciones forzadas por el proveedor: cada retiro de versión implica probar, ajustar y volver a validar. Toma días de trabajo, no horas.
• Revisión humana por muestreo y ampliación del set de pruebas: cada incidente en producción debería convertirse en un caso nuevo, y eso es tiempo de alguien del área usuaria.
• Observabilidad y almacenamiento de trazas: licencias o infraestructura para guardar y consultar el historial de interacciones.
• Transferencia de conocimiento: documentar el porqué de cada decisión de diseño y lograr que más de una persona pueda operar el sistema.

No voy a dar un porcentaje sobre el costo del proyecto porque depende demasiado del caso y cualquier cifra se usaría mal. Lo que sí sostengo como criterio: si al aprobar un proyecto de IA nadie puede decir quién lo va a operar, con cuántas horas al mes y con qué presupuesto de consumo, el proyecto no está aprobado, está apostado. Y el momento de discutirlo es antes de construir.

Errores típicos que veo en empresas con IA en producción

• Apuntar siempre a la última versión sin fijar nada: cuando algo se rompe, nadie puede decir si fue un cambio propio o ajeno.
• No tener set de casos de prueba: cada cambio de modelo o de instrucciones es una migración a ciegas y la discusión se resuelve por opinión.
• Medir uso y llamarlo éxito: cuántas consultas atendió el sistema no dice nada sobre cuántas resolvió bien.
• Guardar solo la respuesta final: sin la traza del contexto recuperado y las herramientas llamadas, depurar un caso malo se vuelve arqueología.
• Meter toda la lógica de negocio en el prompt: funciona hasta que hay que cambiar una regla y nadie sabe qué más se rompe al tocarla.
• Dejar el mantenimiento como tarea de quien lo construyó, cuando pueda: sin horas ni presupuesto, el sistema queda huérfano en cuanto esa persona tiene otra prioridad.
• No cerrar el ciclo de retroalimentación: los usuarios reportan casos malos por chat interno, nadie los junta, y esa información se pierde en vez de volverse casos de prueba.

Cómo saber si tu operación de IA está sana

La pregunta correcta no es si el sistema está funcionando hoy. Es si te enterarías rápido en caso de que dejara de funcionar bien. Estas son las señales que uso para juzgar si una empresa tiene control real sobre su IA en producción.

• Alguien puede responder, sin abrir una investigación, qué versión exacta del modelo está corriendo y desde cuándo.
• Existe un set de casos de prueba que se corrió la última vez que cambió algo, y el resultado quedó registrado en un lugar consultable.
• La tasa de corrección humana se mide y se compara contra la de hace tres meses. Si solo tienes el dato de hoy, no tienes tendencia.
• El costo por interacción tiene alerta contra el promedio histórico propio, no contra una referencia genérica de internet.
• Cuando el proveedor anunció su último cambio de versión, el equipo se enteró por el canal del proveedor y no por la queja de un usuario.
• Los casos malos reportados por usuarios entran a un lugar único y se convierten en casos de prueba.
• Al menos dos personas pueden operar y ajustar el sistema, y una de ellas no es quien lo construyó.