MLOps: lo que pasa el día después de que el modelo funcione

MLOps es el conjunto de prácticas que hacen que un modelo de machine learning siga funcionando seis meses después de que alguien lo enseñara en una presentación. No es una herramienta ni un producto que se compra: es la parte aburrida —versionado, despliegue, monitorización, reentrenamiento y responsabilidades— que separa un experimento bonito de un sistema del que depende el negocio.

La escena se repite. Un proveedor entrega un modelo de previsión con buena precisión sobre el histórico. Dirección lo aprueba. Pasan tres meses y nadie sabe decir si sigue acertando, quién lo revisa, con qué datos se entrenó ni qué pasa si mañana devuelve un disparate. El modelo no se ha roto de golpe: se ha quedado solo.

Esta guía es para responsables de sistemas, dirección y equipos de datos que ya tienen un modelo —o están a punto de encargarlo— y quieren saber qué hay que montar alrededor para que no se convierta en deuda técnica. Si todavía estás antes de ese punto, empieza por machine learning en empresas.

¿Qué es MLOps y en qué se diferencia de DevOps?

DevOps resuelve cómo llevar código a producción de forma repetible: controlas el código, lo pruebas, lo despliegas, lo observas. MLOps añade dos cosas que el software clásico no tiene:

• El comportamiento depende de los datos, no solo del código. El mismo código, entrenado con datos de enero y con datos de octubre, da resultados distintos. Versionar el código no basta: hay que versionar los datos y el modelo entrenado.
• No hay «correcto» o «incorrecto», hay «cuánto me equivoco». Un endpoint devuelve 200 OK y aun así la predicción puede estar sistemáticamente mal. Las alertas tradicionales de disponibilidad no lo detectan.

De ahí la definición práctica: MLOps es DevOps más la trazabilidad de los datos más la vigilancia de la calidad de la predicción. Todo lo demás son herramientas.

Un detalle que ahorra discusiones: MLOps no exige una plataforma cara. Un modelo que se ejecuta una vez al día sobre 40.000 filas se puede operar con un repositorio git, un contenedor, un planificador y una tabla de resultados. Lo que no se puede es operarlo sin saber qué versión está corriendo.

¿Qué cambia cuando el modelo pasa de la demo a producción?

En el portátil del científico de datos, el dato llega limpio, en un fichero, de una sola vez y sin prisa. En producción cambian las cuatro condiciones a la vez.

| En la demo | En producción | |---|---| | Un CSV preparado a mano | Datos que llegan del ERP, con campos nuevos y nulos inesperados | | Entrenamiento y predicción en el mismo sitio | Entrenamiento mensual, predicción cada hora, código distinto en cada lado | | El error se mide una vez | El error hay que medirlo cada semana contra lo que pasó de verdad | | Si falla, se vuelve a ejecutar | Si falla, alguien de operaciones ve un hueco en su pantalla y no sabe a quién llamar | | Nadie pregunta por qué | Un cliente o un auditor pregunta por qué se tomó esa decisión |

La diferencia más cara de todas es la tercera fila. Medir el error en producción obliga a guardar cada predicción con su fecha y, cuando llega el resultado real, a emparejarlos. Si no se diseñó desde el principio, reconstruirlo a posteriori es un trabajo de semanas.

Si no puedes responder «¿cuánto se equivocó el modelo el mes pasado?» con una consulta, no tienes un modelo en producción: tienes un script en ejecución.

El segundo cambio silencioso es el training-serving skew: la transformación del dato en el entrenamiento y en la predicción se escriben dos veces, en dos sitios, y acaban divergiendo. Es la causa número uno de modelos que rinden peor en real que en pruebas. Se evita de una sola forma: el mismo código de preparación de datos sirve para entrenar y para predecir.

¿Qué piezas de MLOps necesitas de verdad?

No hace falta la plataforma completa. Hace falta que estas cinco preguntas tengan respuesta escrita.

| Pieza | La pregunta que responde | Mínimo viable | |---|---|---| | Versionado de modelo y datos | ¿Qué versión está corriendo y con qué se entrenó? | Un registro con: id de versión, fecha, rango de datos de entrenamiento, métricas | | Reproducibilidad | ¿Puedo volver a entrenar esto igual dentro de un año? | Código en git + dependencias fijadas + snapshot del dataset | | Despliegue y vuelta atrás | ¿Cómo publico una versión nueva y cómo la revierto en 10 minutos? | Dos versiones conviviendo y un interruptor | | Monitorización | ¿Está la predicción degradándose? | Métrica de error semanal + alerta de deriva en las entradas | | Gobierno | ¿Quién aprueba un reentrenamiento y quién responde de un fallo? | Un nombre por cada cosa, escrito |

Si tienes que empezar por una, empieza por la monitorización: es la que convierte un problema invisible en un problema con fecha. Lo demás se puede ir montando encima.

Nada de esto funciona si el dato de entrada es basura. MLOps no arregla un ERP con el campo de cliente duplicado; lo pone en evidencia más rápido. Antes de invertir aquí, revisa calidad de datos.

¿Cómo se detecta que un modelo se está degradando?

Un modelo no avisa. Sigue devolviendo números con toda la confianza del mundo mientras el mundo que aprendió deja de existir. Hay tres señales y conviene vigilar las tres, porque llegan en momentos distintos.

1. Deriva en los datos de entrada (llega primero). La distribución de lo que entra cambia: aparece un producto nuevo que no existía en el entrenamiento, el 30% de las filas trae un canal de venta desconocido, la media del importe sube un 40% porque se subieron precios. Se detecta comparando la distribución de cada variable de la última semana contra la del entrenamiento. No prueba que el modelo falle, pero es la alerta más temprana que vas a tener.

2. Deriva en la predicción (llega después). El reparto de lo que el modelo predice se mueve. Un scoring que marcaba al 8% de los leads como calientes empieza a marcar al 22%. Puede ser real o puede ser que el modelo esté perdido. Es barato de vigilar porque no necesitas el resultado real.

3. Caída de rendimiento (llega tarde y es la única que importa de verdad). El error real sube. Solo se puede medir cuando llega el resultado: en una previsión de demanda, al cerrar el mes; en un modelo de churn, tres o seis meses después. Por eso las dos primeras señales no son opcionales: son lo único que tienes mientras esperas.

Un montaje razonable para una empresa mediana: un informe semanal automático con las distribuciones de entrada y la predicción, y un informe mensual con el error real contra lo ocurrido. Dos destinatarios: quien mantiene el modelo y quien usa el resultado. Si el informe lo lee solo el técnico, la degradación se discute tarde.

Define el umbral antes de necesitarlo. «Si el error medio supera el 18% dos meses seguidos, se reentrena y se avisa a operaciones.» Escrito. Sin umbral escrito, cada mes se decide por sensación y la sensación siempre dice que aguanta un mes más.

¿Cada cuánto hay que reentrenar un modelo?

La respuesta honesta: depende de la velocidad a la que cambia tu negocio, y se descubre midiendo, no decidiendo en una reunión. Tres patrones que cubren casi todos los casos:

• Por calendario. Reentrenar cada mes o cada trimestre, pase lo que pase. Es lo más simple y suficiente para demanda estable, mantenimiento o segmentación. Ventaja: predecible y se puede planificar. Inconveniente: reentrenas cuando no hace falta y llegas tarde cuando sí.
• Por disparador. Reentrenar cuando la monitorización cruza el umbral. Más eficiente, pero exige que la monitorización sea fiable y que haya alguien que responda a la alerta.
• Por evento de negocio. Cambio de catálogo, fusión, nueva línea, cambio de precios, campaña grande. Estos no los detecta ninguna métrica a tiempo: los sabe el negocio antes que el sistema. Hay que pedir que avisen.

Y una advertencia poco popular: reentrenar no siempre mejora. Si el dato nuevo está contaminado —porque el propio modelo influyó en él, porque hubo un mes atípico, porque cambió la forma de registrar un campo— el modelo reentrenado puede ser peor. Por eso todo reentrenamiento pasa por la misma puerta: se evalúa contra un conjunto de validación estable, se compara con la versión en producción y solo se despliega si gana. Si no gana, se queda la vieja y se investiga.

El patrón que mejor funciona es aburrido: modelo nuevo entrenado, evaluado en sombra durante una o dos semanas (predice pero nadie actúa sobre ello), comparación con el que está en producción, y relevo con posibilidad de vuelta atrás inmediata.

¿Quién responde cuando el modelo falla?

Esta es la pregunta que hunde más proyectos que cualquier detalle técnico. Un modelo en producción tiene al menos cuatro responsabilidades distintas y casi nunca están asignadas:

• El dato de entrada. Quien responde de que el ERP siga entregando los campos acordados. Normalmente sistemas o el dueño del proceso.
• La ejecución. Quien responde de que el proceso corra y de que alguien se entere si no corre. Operaciones o sistemas.
• La calidad de la predicción. Quien mira el informe mensual, decide si se reentrena y da la cara si el número está mal. Es el rol que más se olvida.
• La decisión. Quien usa el resultado y puede ignorarlo. Comercial, compras, producción. El modelo recomienda; la persona decide y responde de la decisión.

Escríbelo en una tabla de cuatro filas con un nombre en cada una. No un departamento: un nombre. Y un procedimiento de degradación: si el modelo no está disponible o sus números no son creíbles, ¿qué se hace mientras tanto? Casi siempre la respuesta es «se vuelve a la regla manual de antes», y eso hay que tenerlo escrito y probado, no improvisado a las ocho de la mañana de un lunes.

Si el proveedor que te entrega el modelo no te entrega también estas cuatro filas, te ha entregado medio proyecto. Es la misma lógica con la que conviene elegir consultora de IA: quien construye tiene que responder de lo que pasa después.

¿Cuánto cuesta mantener un modelo vivo?

Nadie presupuesta esto y es la grieta por la que se cuela el sobrecoste. Una regla de campo razonable: el mantenimiento anual de un modelo en producción ronda entre un 15% y un 30% de lo que costó construirlo, y se reparte en tres sitios:

• Infraestructura. Normalmente lo más barato. Un modelo tabular que corre una vez al día cuesta decenas de euros al mes. Los costes se disparan con la inferencia en tiempo real y con modelos grandes.
• Personas. La partida de verdad. Horas de revisión mensual, reentrenamientos, investigar una alerta, actualizar dependencias. Entre media jornada y dos jornadas al mes por modelo, según criticidad.
• Cambios del entorno. El ERP cambia un campo, el proveedor de datos modifica un formato, hay que migrar la versión de una librería. Es trabajo imprevisible pero recurrente: presupuéstalo aunque no sepas en qué se gastará.

De aquí sale la pregunta incómoda y útil: si el modelo aporta menos valor al año que su coste de mantenimiento, lo correcto es apagarlo. Tener un modelo apagado no es un fracaso; tener tres modelos zombis que nadie mira y que siguen alimentando informes sí lo es. Para poner números a esto, medir el ROI de la IA va primero.

Preguntas frecuentes

¿MLOps es lo mismo que tener un científico de datos?

No. Un científico de datos construye el modelo; MLOps es lo que permite operarlo cuando esa persona está de vacaciones o ya no trabaja contigo. Muchos proyectos fallan precisamente porque todo el conocimiento del modelo vive en una cabeza y en un cuaderno sin versionar.

¿Necesito una plataforma de MLOps para empezar?

No para el primer o segundo modelo. Con git, contenedores, un planificador de tareas y una tabla donde guardar predicciones y métricas se opera un modelo con garantías. Las plataformas compensan cuando tienes varios modelos, varios equipos y necesitas gobierno centralizado.

¿Cada cuánto hay que revisar un modelo en producción?

Como mínimo una revisión mensual de métricas y una revisión trimestral más a fondo que incluya si el caso de uso sigue teniendo sentido. En modelos que tocan decisiones diarias o dinero, la vigilancia automática debería ser semanal.

¿Qué pasa con los modelos de lenguaje, aplica lo mismo?

Aplica el marco y cambian las métricas. No hay un error numérico claro, así que se evalúa con un conjunto fijo de casos de prueba y revisión humana por muestreo. Lo que no cambia es lo esencial: versionar lo que está en producción, medir con regularidad y tener a alguien que responda.

Por dónde empezar

Si ya tienes un modelo funcionando, el primer paso no es montar una plataforma: es responder por escrito a cinco preguntas —qué versión corre, con qué datos se entrenó, cómo se mide su error, cuándo se reentrena y quién responde—. Las que te dejen en blanco son exactamente tu plan de trabajo.

En adask montamos esta capa sobre lo que ya tiene la empresa, sin cambiar de pila por gusto, y dejamos escrito quién hace qué. Si quieres saber en qué estado está lo que ya tienes en producción, pide la auditoría; si prefieres contarlo en una llamada, hablemos.