Hay un momento de euforia cuando un modelo por fin funciona en el notebook: buenas métricas, predicciones que dan en el clavo. Es fácil creer que el trabajo terminó. En realidad, apenas empieza. Un modelo en un notebook no le sirve a nadie: es una maqueta preciosa que solo tú puedes ver. Ponerlo en producción —que reciba datos reales, entregue respuestas a un sistema o a personas, y siga funcionando meses después— es un problema distinto, y es donde la mayoría de los proyectos de ciencia de datos se caen. La disciplina que se ocupa de esto se llama MLOps.
Del notebook al servicio
Entrenar un modelo y servir un modelo son dos mundos. En el entrenamiento tienes todo el tiempo y todos los datos; en producción, alguien espera una respuesta ahora. Poner el modelo a disposición del mundo suele tomar una de dos formas:
- En línea (online): el modelo vive detrás de una API. Llega una solicitud —"¿este correo es spam?"— y responde en milisegundos. Es lo que necesita una app o una web.
- Por lotes (batch): el modelo procesa grandes volúmenes cada cierto tiempo —recalcular de noche el riesgo de todos los clientes— y guarda los resultados para usarlos después.
En ambos casos aparece un requisito que en el notebook no existía: los mismos pasos de procesamiento de datos —escalar, codificar, imputar— tienen que ejecutarse idénticos sobre el dato nuevo. Si en el entrenamiento normalizaste con cierto promedio y en producción usas otro, el modelo recibe datos que no reconoce. Ese descalce, el training-serving skew, es una de las fuentes de error más comunes y más difíciles de detectar.
El modelo se echa a perder solo: la deriva
Aquí está la diferencia más importante con el software tradicional. Un programa que funciona hoy funcionará igual en un año. Un modelo, no. El mundo cambia, y como el modelo aprendió de un pasado que se va quedando viejo, su desempeño se degrada solito con el tiempo. Es la deriva (drift):
- Deriva de datos: los datos de entrada cambian de forma. Llegan clientes de un perfil nuevo, un sensor se recalibra, cambia la moda de consumo.
- Deriva de concepto: cambia la relación misma que el modelo aprendió. Un detector de fraude entrenado antes de una nueva táctica de estafa deja de verla.
La pandemia fue el ejemplo masivo: modelos de demanda, de tráfico, de compras entrenados con datos de 2019 se volvieron inservibles en semanas, porque el comportamiento que predecían dejó de existir.
Monitoreo: no puedes arreglar lo que no ves
Como el modelo se degrada en silencio —sigue entregando predicciones, solo que cada vez peores—, la única defensa es vigilarlo. Un sistema en producción monitorea, como mínimo:
- Salud técnica: ¿responde? ¿en cuánto tiempo? ¿se está cayendo?
- Los datos de entrada: ¿se parecen a los del entrenamiento, o están derivando?
- La calidad de las predicciones: cuando llega el resultado real (se supo si el cliente pagó, si el correo era spam), ¿el modelo acertó? Aquí vuelven las métricas de siempre —matriz de confusión, RMSE— pero calculadas en vivo, sobre lo que está pasando ahora.
El ciclo que no termina
Por todo esto, un modelo en producción no es un entregable, es un ciclo de vida:
entrenar → desplegar → monitorear → detectar deriva → reentrenar → volver a desplegar
Cuando el monitoreo muestra que el desempeño cayó bajo cierto umbral, se reentrena con datos frescos y se despliega la nueva versión —idealmente de forma automatizada y con la posibilidad de volver atrás si la nueva versión resulta peor—. Esa capacidad de versionar, comparar y revertir modelos es el corazón de MLOps.
La moraleja, para cualquiera que trabaje con datos: un modelo desplegado es un compromiso, no un final. El valor no está en el que acertó una vez en el notebook, sino en el que sigue acertando, vigilado y mantenido, mucho después de que la euforia inicial pasó. Es exactamente el trecho entre "tener un modelo" y "llevar la IA a producción".