Sus modelos de IA tienen fecha de vencimiento

Un modelo de machine learning que funcionaba bien en enero puede estar tomando decisiones equivocadas en julio —y nadie en la empresa lo sabe. No porque el modelo esté roto técnicamente, sino porque el mundo cambió y el modelo no se actualizó para seguirle el paso.

Este fenómeno tiene nombre: data drift. Y tiene consecuencias de negocio que los equipos de datos raramente comunican con suficiente claridad a quienes toman decisiones.

El modelo que "funciona" pero ya no sirve

Imagine que su empresa de retail implementó un modelo de pronóstico de demanda en octubre de 2024. Fue entrenado con patrones de compra regionales, datos de inflación y comportamiento del consumidor colombiano de ese momento. En pruebas alcanzó 89% de precisión. Excelente.

Doce meses después, los patrones de compra cambiaron por una nueva dinámica cambiaria, dos competidores entraron al mercado y el consumidor aprendió a comprar diferente. El modelo sigue corriendo. Nadie lo tocó. Pero su precisión real ahora es 71%. Nadie lo midió.

Ese 18% de diferencia no aparece en un dashboard. Aparece en inventario sobrante, en quiebres de stock, en decisiones de compra equivocadas. El costo no llega etiquetado como "modelo degradado".

De medicina a MLOps: el aporte del análisis de supervivencia

El análisis de supervivencia es una familia de técnicas estadísticas que nació en epidemiología para responder preguntas como: ¿cuánto tiempo sobrevive un paciente tras un diagnóstico? ¿Cuándo falla una pieza de maquinaria industrial?

La pregunta central no es si algo va a fallar, sino cuándo. Y bajo qué condiciones ese tiempo se acorta o se extiende.

Aplicado a modelos de ML, el razonamiento es el siguiente: cada modelo tiene una vida útil antes de que su desempeño caiga por debajo de un umbral aceptable. Ese tiempo no es aleatorio. Depende de cuánto cambia el entorno de datos —su velocidad de drift—, de la robustez del modelo y de la estabilidad del dominio de negocio.

Tratar la degradación como un problema de tiempo hasta el fallo cambia fundamentalmente cómo se gestiona un modelo en producción:

• En lugar de revisar modelos "cuando alguien se queja", se define un ciclo de vida esperado.
• En lugar de monitorear de forma reactiva, se modela cuándo el riesgo de degradación supera el umbral de negocio.
• En lugar de redeploys de pánico, se planean mantenimientos preventivos.

Es la diferencia entre tener un plan de mantenimiento para su maquinaria crítica y esperar a que se rompa para llamar al técnico.

Qué medir y por qué importa

Para que esto funcione en la práctica, los equipos de datos necesitan instrumentar al menos tres dimensiones:

1. Distribución de los datos de entrada (feature drift) ¿Las variables que el modelo recibe hoy tienen la misma distribución estadística que cuando fue entrenado? Si su modelo de scoring crediticio en México fue calibrado con datos de ingresos formales y ahora recibe un porcentaje mayor de trabajadores independientes, las entradas ya no corresponden al universo original. El modelo no lo sabe. Usted tampoco, a menos que lo mida activamente.

2. Distribución de las predicciones (prediction drift) ¿El modelo sigue distribuyendo sus salidas de manera similar? Un modelo de churn que antes predecía 12% de clientes en riesgo alto y ahora predice 31% puede estar capturando una realidad real —o puede estar fallando en silencio. Sin contexto estadístico de referencia, es imposible saberlo.

3. Desempeño en producción (performance drift) Cuando se tienen etiquetas reales —el resultado que efectivamente ocurrió— se puede comparar con lo que el modelo predijo. En muchos casos esto llega con rezago: saber si un cliente hizo churn toma semanas o meses. El análisis de supervivencia ayuda precisamente ahí: a estimar cuándo el desempeño habrá cruzado un umbral, antes de que las etiquetas reales lo confirmen.

El problema de la censura en datos de negocio

Uno de los conceptos más útiles del análisis de supervivencia —y más ignorados en MLOps— es el de censura. En medicina, un paciente censurado es aquel del que se perdió el seguimiento antes de que ocurriera el evento de interés. En modelos de ML, es el análogo de no tener aún la etiqueta real para saber si el modelo falló.

Métodos como el estimador de Kaplan-Meier o los modelos de riesgo proporcional de Cox fueron diseñados para trabajar con esa incertidumbre. En lugar de ignorar los casos sin etiqueta, los incorporan correctamente en el cálculo del riesgo.

Para una empresa argentina con un modelo de scoring de crédito que tarda 90 días en confirmar el resultado de una solicitud, esto significa poder estimar la confiabilidad actual del modelo sin esperar esos tres meses. La ventana para actuar se abre mucho antes.

Lo que esto cambia para quien toma decisiones

Si usted es CEO o director de operaciones, la pregunta que debería hacerle a su equipo de datos no es "¿el modelo está funcionando?". Esa pregunta casi siempre recibe como respuesta "sí" —porque nadie quiere decir que no, y porque técnicamente puede ser verdad aunque el modelo sea ya poco útil.

La pregunta correcta es: ¿cuánto tiempo le queda a este modelo antes de que necesite ser reentrenado?

Si su equipo no puede responderla con un número o un rango razonable, hay un problema de instrumentación que vale la pena resolver.

Algunas señales de alerta concretas:

• Modelos que llevan más de seis meses en producción sin evaluación de drift. En mercados con alta volatilidad macroeconómica —como los de LATAM en los últimos años— ese es un período largo.
• Ausencia de umbrales de rendimiento mínimo definidos. Si nadie estableció cuándo el modelo "dejó de ser útil", nadie lo va a retirar a tiempo.
• Monitoreo limitado a errores técnicos. Un modelo puede no arrojar ningún error de sistema y estar produciendo predicciones con una precisión inaceptable para el negocio.

El mantenimiento de modelos como decisión estratégica

Un modelo de demanda degradado en una empresa de manufactura en Monterrey tiene el mismo impacto que una banda transportadora mal calibrada: no detiene la planta de golpe, pero erosiona la productividad en silencio durante meses.

La diferencia es que para la banda transportadora existe un plan de mantenimiento preventivo con fechas, indicadores y responsables. Para el modelo de ML, en la mayoría de las empresas medianas de la región, ese plan no existe todavía.

Implementar ciclos de revisión basados en señales estadísticas de drift —no en calendario fijo ni en quejas del área usuaria— es uno de los cambios de madurez operativa más rentables que puede hacer un equipo de datos hoy. No requiere reemplazar infraestructura ni incorporar decenas de herramientas: requiere definir qué medir, cuándo actuar y quién es responsable de ese ciclo.

Si su empresa ya tiene modelos en producción y quiere saber en qué punto del ciclo de vida están, ese diagnóstico es el primer paso concreto.