Un modelo de machine learning entra en producción haciendo predicciones excelentes. Durante los primeros meses acierta casi siempre, el equipo gana confianza y las decisiones empiezan a apoyarse en sus resultados. Un año después, sin que nadie haya tocado una sola línea de código, las predicciones fallan más de lo que deberían. Y lo más peligroso es que casi nadie se da cuenta: no hay errores en pantalla ni excepciones en los registros. El modelo sigue respondiendo — solo que responde peor.
Este fenómeno tiene nombre: deriva de modelo (en inglés, model drift). Es una de las causas más subestimadas de que un proyecto de IA deje de generar valor, y es traicionera precisamente por ser silenciosa. A diferencia de un servicio que se cae, un modelo que deriva no grita: se degrada poco a poco, y la factura aparece en las decisiones equivocadas que se acumulan sin ninguna alarma.
Entender qué es la deriva, por qué ocurre y cómo vigilarla es lo que distingue a un equipo que lanza modelos de uno que los mantiene. A lo largo de este artículo vemos los tipos de deriva, las señales a las que prestar atención y una rutina de monitorización que no exige una plataforma cara para empezar.
Qué es la deriva de modelo
Un modelo aprende una relación entre lo que observa — las variables de entrada — y lo que quiere predecir. Esa relación se estima a partir de datos históricos, capturando el mundo tal como era en un periodo concreto. El problema es que el mundo no espera: los clientes cambian de hábitos, los precios suben, entran nuevos competidores, cambia la estacionalidad, oscila la economía. Cuando la realidad se aleja de lo que el modelo vio durante el entrenamiento, la calidad de las predicciones cae. A ese alejamiento lo llamamos deriva.
Conviene separar dos conceptos que se confunden a menudo. Un bug es un defecto en el código que produce, de forma consistente, un comportamiento erróneo. La deriva no es un defecto: el código es correcto y el modelo hace exactamente aquello para lo que fue entrenado — solo que el objetivo se ha movido. Corregir un bug es reparar; lidiar con la deriva es mantener. Son disciplinas distintas, y tratarlas como lo mismo es el primer error.
Por qué un modelo empeora si nadie lo ha tocado
Quien viene del software tradicional trae una intuición sólida: si el código no cambia, el comportamiento no cambia. Con los modelos, esa intuición falla, porque el comportamiento no depende solo del código — depende de los datos que entran en cada predicción. Un informe que suma ventas devuelve siempre el mismo valor para los mismos datos. Un modelo que estima la probabilidad de que un cliente cancele depende de patrones de comportamiento que sí cambian con el tiempo.
Por eso, mantener un modelo no es opcional ni es señal de que se construyó mal. Es una consecuencia natural de vivir en un mundo dinámico. La pregunta útil no es si un modelo va a derivar, sino cuándo y a qué ritmo — y si la organización se dará cuenta a tiempo.
Los tipos de deriva: datos, concepto y aguas arriba
No toda la deriva es igual, y distinguir los tipos ayuda a elegir la respuesta adecuada.
La deriva de datos (data drift) ocurre cuando cambia la distribución de las variables de entrada. El modelo sigue recibiendo los mismos campos, pero sus valores se desplazan: la edad media de los clientes sube, el ticket medio cambia, una región pasa a pesar más en las ventas. La relación que el modelo aprendió puede seguir siendo válida, pero ahora opera en un terreno que conoce mal.
La deriva de concepto (concept drift) es más profunda: cambia la propia relación entre las entradas y el resultado. Lo que en el pasado señalaba a un buen cliente deja de señalarlo. Un ejemplo clásico es la detección de fraude: a medida que los defraudadores cambian de tácticas, los patrones que antes delataban un fraude se vuelven inofensivos, y viceversa. Aquí, aunque las distribuciones de entrada no cambien mucho, el modelo pierde poder predictivo.
Existe además la deriva aguas arriba (upstream drift), a menudo olvidada: cambios en los propios pipelines de datos. Una unidad que pasa de euros a miles de euros, un campo que cambia de formato, una categoría nueva que aparece sin aviso. No es el mundo el que cambió — fue la forma en que los datos llegan al modelo. Es la causa más fácil de corregir y, curiosamente, una de las más comunes.
Señales de que tu modelo está derivando
La deriva rara vez llega con un aviso claro, pero deja rastro. Vale la pena vigilar de forma sistemática:
- Caída en las métricas de rendimiento — el error de predicción sube (por ejemplo, el MAPE de un modelo de demanda) o la precisión de una clasificación baja, en comparación con el periodo de referencia.
- Cambio en la distribución de las entradas — variables que pasan a tener medias, dispersiones o proporciones distintas de las del entrenamiento.
- Cambio en la distribución de las predicciones — el modelo empieza a predecir mucho más (o mucho menos) de una clase de lo que solía.
- Aumento de las quejas o correcciones manuales — cuando los equipos de negocio empiezan a corregir a mano lo que el modelo sugiere, es una señal temprana y barata.
- Divergencia entre lo previsto y lo real — siempre que el resultado real acaba por conocerse, compararlo con lo que se predijo es la prueba más honesta.
Cómo monitorizar la deriva en la práctica
No hace falta una plataforma costosa para empezar. Lo esencial es elegir un periodo de referencia (normalmente los datos con los que el modelo fue entrenado y validado) y comparar, de forma recurrente, los datos nuevos con esa referencia.
Para las variables de entrada, una métrica muy usada es el Population Stability Index (PSI), que cuantifica cuánto se ha alejado una distribución de otra:
PSI = Σ (perc_nuevo − perc_referencia) × ln(perc_nuevo / perc_referencia)
Como regla práctica, un PSI por debajo de 0,1 sugiere estabilidad, entre 0,1 y 0,2 un cambio moderado que merece atención, y por encima de 0,2 un cambio significativo que justifica investigación. Para el rendimiento, lo ideal es seguir la métrica que importa al negocio — MAPE, MAE, precisión, recall, según el caso — siempre que el resultado real esté disponible. Y, sobre todo, definir umbrales y alertas antes de que haya problema, para que la deriva la detecte un panel y no un cliente insatisfecho.
Cuándo (y cómo) reentrenar el modelo
Detectar la deriva es la mitad del trabajo; la otra mitad es responder. Existen dos filosofías, y los mejores equipos las combinan. La primera es el reentrenamiento por calendario: actualizar el modelo con una cadencia fija (mensual, trimestral), independientemente de que haya deriva. Es simple y previsible, pero puede reentrenar de más o de menos. La segunda es el reentrenamiento por disparador: actualizar solo cuando la monitorización muestra que el rendimiento ha caído por debajo de un umbral. Es más eficiente, pero exige que esa monitorización funcione.
Reentrenar no es la única respuesta posible, y no siempre es la correcta. Si la causa es deriva aguas arriba, lo correcto es reparar el pipeline, no reentrenar sobre datos corruptos. Si la deriva de concepto es abrupta — un cambio regulatorio, un choque económico — puede ser necesario repensar las variables, y no solo realimentar el mismo modelo. Reentrenar a ciegas sobre datos recientes puede incluso consolidar un patrón indeseado.
Errores comunes en la gestión de la deriva
El error más frecuente es no monitorizar en absoluto: lanzar el modelo y asumir que sigue tan bueno como el día de la presentación. El segundo es confundir la estabilidad de las entradas con la calidad de las predicciones — las distribuciones pueden mantenerse y el rendimiento caer igualmente (deriva de concepto). El tercero es reentrenar por reflejo, sin investigar la causa, lo que enmascara problemas de datos en lugar de resolverlos. Y el cuarto, más organizativo, es no tener un responsable: un modelo sin nadie a cargo de su salud es un modelo que, tarde o temprano, nadie se da cuenta de que ha dejado de servir.
Minicaso: cuando la demanda dejó de obedecer al modelo
Una empresa de retail usaba un modelo de previsión de demanda para planificar compras y reposición. Durante más de un año, el error medio (MAPE) rondó el 8%, y los equipos de compras confiaban en las previsiones. A lo largo de unos meses, un cambio en el comportamiento de compra — mayor sensibilidad al precio, en un contexto de subida de costes — modificó los patrones que el modelo había aprendido. Sin ningún cambio en el código, el MAPE subió a cerca del 19%, y el modelo empezó a sobrestimar la demanda de varias categorías, generando un exceso de stock del orden del 14%.
Lo que salvó la situación no fue suerte, fue vigilancia. Un panel sencillo seguía el MAPE mensual y la distribución de dos variables clave; cuando el error superó el umbral definido y el PSI de una de esas variables pasó de 0,2, saltó una alerta. El equipo investigó, confirmó que se trataba de deriva de concepto y no de un problema de pipeline, y reentrenó el modelo con datos recientes, ajustando también una variable de precio. El MAPE volvió a cerca del 10% y el exceso de stock se normalizó en los meses siguientes. Sin monitorización, la misma corrección habría llegado meses más tarde — y mucho más cara.
En la práctica
Un modelo en producción no es un producto acabado; es una relación con un mundo que cambia. La deriva de modelo es la forma en que ese mundo pasa la factura, y la única defensa realista es asumir que ocurrirá y prepararse para detectarla pronto. Empieza pequeño: elige una métrica de rendimiento, una o dos variables críticas, define umbrales y monta un panel que alguien mire con regularidad. Decide, de entrada, quién es el responsable de la salud del modelo y cuál es la política de reentrenamiento.
La buena noticia es que gestionar la deriva no exige herramientas caras para arrancar — exige disciplina y claridad sobre lo que se está vigilando. Las organizaciones que tratan el mantenimiento de los modelos como parte del trabajo, y no como un extra, son las que siguen extrayendo valor de la IA mucho después de que el entusiasmo del lanzamiento haya pasado.
