El día que se pone en marcha una automatización se siente como el final del proyecto. Se cierra la tarea, se agradece al equipo y se pasa a la siguiente iniciativa. Tres meses después, nadie sabe con certeza si el proceso sigue corriendo igual que en el go-live, porque nadie quedó mirándolo.

La automatización no se rompe de un día para el otro. Se deteriora en silencio: un campo cambió en el ERP, llegó un tipo de caso nuevo, el proveedor ajustó un formato, el criterio de aprobación se movió un punto. El sistema sigue ejecutando con los criterios viejos, y el problema recién aparece cuando el error ya es visible para alguien.

Este artículo explica por qué se produce ese deterioro y qué conviene vigilar después del go-live para enterarse a tiempo.

Por qué un circuito que funcionaba deja de funcionar

IBM define el deslizamiento de modelo (model drift, o model decay) como la degradación del rendimiento de un modelo debido a cambios en los datos o en la relación entre las variables de entrada y salida. El punto incómodo que remarca es simple: incluso un modelo bien entrenado y sin sesgos puede deslizarse de sus parámetros originales y producir resultados no deseados si nadie lo monitorea con el tiempo. Y sitúa la detección de drift como un componente central de una gobernanza de IA seria.

IBM distingue tres tipos de deterioro, y cada uno tiene una traducción operativa concreta:

Drift de concepto. La relación entre lo que entra y lo que se busca deja de valer: puede ser estacional, súbito o gradual. En un proceso, significa que la definición de lo correcto cambió —una nueva política comercial, un umbral de aprobación movido— y el sistema sigue clasificando con el criterio anterior.
Drift de datos. Cambia la distribución de los datos de entrada: un canal nuevo trae casos más largos que los históricos, se incorporaron productos o segmentos que el circuito nunca vio.
Cambio de datos upstream. Algo cambió en el flujo que alimenta el proceso: una moneda, una unidad de medida, un campo renombrado en el ERP. Es el más silencioso de los tres, porque no falla dentro del modelo; falla mucho antes.

Ninguno de los tres requiere que la IA esté mal hecha. Requiere que el mundo alrededor siga cambiando, que es justamente lo que hace.

Vigilar solo el modelo no alcanza: hay que vigilar el circuito

IBM describe la gobernanza de IA como procesos, estándares y salvaguardas, y señala que sostenerla no es un cumplimiento único sino el mantenimiento de estándares en el tiempo, para lo cual la monitorización continua es una práctica central. Aplicado a un proceso automatizado, eso cambia el objeto de observación: el circuito completo —datos de entrada, reglas, modelo, revisiones humanas—, y no únicamente el modelo.

Del lado práctico, AWS describe la madurez de operación de modelos (MLOps) en tres niveles: en el nivel 0 el trabajo es manual y no existe monitoreo activo de performance; los niveles superiores recolectan estadísticas del servicio desplegado con datos en vivo y usan esas estadísticas como disparador para reentrenar o iniciar un nuevo ciclo. La traducción operativa es directa: el monitoreo no es un tablero decorativo. Es el mecanismo que decide cuándo reabrir el circuito.

Si la automatización es modelo, datos, reglas y gente, vigilar solo el modelo deja los datos, las reglas y a la gente fuera de la pantalla.

Cinco señales que sí conviene vigilar

No hace falta medir todo. Con cinco señales, comparadas contra la línea base del go-live, alcanza para detectar deterioro a tiempo:

Tasa de excepciones y derivaciones. Cuántos casos terminan en una persona porque el sistema no pudo resolverlos. Si sube respecto del go-live, el proceso o los criterios cambiaron.
Correcciones manuales sobre las salidas. Cuánto hay que retocar antes de aprobar. Mide si la automatización sigue ahorrando trabajo o solo lo está desplazando.
Estado de los datos de entrada. Nulos, campos nuevos, formatos y unidades que no existían en el arranque. Es donde empieza el deterioro upstream.
Tiempo de ciclo y volumen por estado. Cuellos de botella nuevos que no estaban en el diseño original.
Señales blandas del equipo. Si el equipo volvió a resolver los casos raros por planilla o correo, la confianza en el circuito ya cayó. Es la señal más temprana y la que menos se mide.

Una cadencia mínima que sí se sostiene

Un centro de control no hace falta. Sí una rutina liviana:

Congelar la línea base en el go-live. Cinco números: volumen, tasa de excepción, tiempo de ciclo, correcciones y errores. Sin ese congelado, más adelante no hay contra qué comparar.
Revisar con frecuencia acorde al riesgo. Semanal el primer mes, mensual después si se mantiene estable. La revisión la preside el dueño del proceso, no el equipo técnico.
Registrar los cambios en un solo lugar. Cada umbral movido, campo renombrado o criterio actualizado queda anotado con fecha. Cuando algo se rompa, ese registro ahorra semanas.
Definir umbral para reabrir el circuito. Cuando dos señales se mueven juntas —suben las excepciones y suben las correcciones, por ejemplo—, se revisa el diseño. No se espera al error visible para el cliente.

El marco de gestión de riesgos de IA de NIST (AI RMF) pide incorporar consideraciones de confiabilidad en el diseño, desarrollo, uso y evaluación de los sistemas de IA. Uso y evaluación son justamente lo que ocurre después del go-live: la etapa que la mayoría de los proyectos cierra antes de tiempo.

El go-live no es el final del proyecto

Ningún proceso se mantiene igual sin que nadie lo mire. La pregunta post go-live no es si el proceso va a cambiar —va a cambiar—, es si la organización se va a enterar a tiempo. Cinco señales, una línea base congelada y una revisión con dueño nombrado son lo suficientemente livianos para sostenerse y lo suficientemente claros para actuar antes del error.

La automatización que nadie monitorea no está terminada. Está esperando su primer error.

Fuentes

NIST - AI Risk Management Framework (AI RMF): incorporación de consideraciones de confiabilidad en diseño, desarrollo, uso y evaluación de sistemas de IA; base del argumento de que la evaluación continúa después del go-live.
IBM - What is model drift?: definición de model drift y model decay; tres tipos de deterioro (drift de concepto, drift de datos, cambio upstream); monitoreo como componente central de la gobernanza de IA.
IBM - What is AI governance?: gobernanza como procesos, estándares y salvaguardas sostenidos en el tiempo; monitorización continua como práctica central, no cumplimiento único.
AWS - What is MLOps?: tres niveles de madurez operativa; ausencia de monitoreo activo en el nivel 0; uso de estadísticas del servicio en vivo como disparador de ciclos de reentrenamiento.