Deriva de modelos: cuando un buen modelo empieza a fallar

Un modelo de detección de fraude puede superar todas las pruebas antes del lanzamiento y, meses después, empezar a omitir operaciones que antes habría identificado. El código puede no haber cambiado. Sí cambió el contexto: nuevos canales de pago, otra mezcla de clientes, patrones estacionales distintos o adversarios que aprendieron a comportarse de otra manera.

Ese es el problema práctico de la deriva de modelos. Un modelo no conserva automáticamente su validez porque haya sido aprobado una vez. Su desempeño depende de que las condiciones en producción sigan siendo suficientemente parecidas a aquellas bajo las que fue diseñado, entrenado y validado.

Para auditoría interna, la pregunta importante no es si existe un tablero con métricas. Es si la organización puede detectar a tiempo que el modelo se está alejando de su comportamiento esperado, interpretar qué significa ese cambio y ejecutar una respuesta previamente definida.

El go-live valida un momento. El control real empieza cuando el modelo entra en contacto con un entorno que seguirá cambiando.

La deriva es una brecha entre el modelo y la realidad

En términos simples, la deriva aparece cuando cambian las condiciones que sustentaban el comportamiento esperado del modelo. Puede observarse de varias formas.

La deriva de datos ocurre cuando cambia la distribución de las entradas. Un modelo de crédito entrenado con cierto perfil de clientes puede empezar a recibir una población distinta. La deriva de concepto aparece cuando cambia la relación entre las variables de entrada y el resultado que se quiere predecir. En fraude, por ejemplo, una combinación de variables que antes distinguía operaciones sospechosas puede perder poder cuando los patrones de ataque evolucionan.

La consecuencia que más interesa al negocio es la degradación del desempeño: más falsos positivos o negativos, peor calibración, decisiones menos estables, resultados injustos o menor utilidad para el proceso. No todo cambio estadístico es material ni toda pérdida de desempeño es visible de inmediato; en algunos casos, la “verdad” necesaria para comprobar una predicción llega semanas después.

Por eso, un programa maduro vincula las señales técnicas con el daño que el modelo puede causar si deja de funcionar como se esperaba.

Monitorear no es mirar un dashboard

El NIST AI Risk Management Framework trata el monitoreo como parte del ciclo de gestión del riesgo. En su función Measure, el resultado 2.4 establece que la funcionalidad y el comportamiento del sistema y sus componentes deben monitorearse en producción. El AI RMF Playbook desarrolla esa idea y señala expresamente que los sistemas pueden encontrarse con nuevos riesgos cuando el entorno cambia, un efecto que denomina drift. La respuesta no termina en medir: la función Manage también contempla mecanismos para sustituir, desconectar o desactivar sistemas cuyo desempeño o resultados dejan de ser coherentes con su uso previsto.

La ISO/IEC 42001:2023 llega al mismo problema desde la lógica de un sistema de gestión. Sus requisitos de operación y evaluación del desempeño obligan a definir qué se monitorea y mide, con qué método, cuándo y cómo se analizan los resultados, conservando información documentada. También exige reevaluar riesgos cuando se proponen u ocurren cambios significativos. Su guía de implementación aborda expresamente que el desempeño puede cambiar por data drift o concept drift y que el monitoreo puede revelar la necesidad de reentrenar el sistema. La ISO/IEC 23894:2023, por su parte, aporta orientación específica para integrar la gestión de riesgos de IA en las actividades de la organización.

El patrón común es claro: desempeño esperado → monitoreo → umbral → decisión → evidencia. Una organización que solo conserva gráficos históricos, pero no puede explicar cuándo debe intervenir y quién toma la decisión, todavía no tiene un control completo.

Los umbrales deben representar riesgo, no comodidad técnica

Una práctica débil consiste en fijar un número porque “parece razonable”: por ejemplo, intervenir si la precisión cae por debajo de 90 %. Ese umbral puede ser irrelevante si el riesgo real está en los falsos negativos, en una subpoblación concreta o en la estabilidad de decisiones de alto impacto.

Un diseño más sólido parte de cuatro elementos:

Una línea base aprobada. Qué desempeño se aceptó al validar el modelo, bajo qué población, periodo, supuestos y condiciones de uso.
Métricas vinculadas al riesgo. Precisión puede ser útil, pero también sensibilidad, tasa de falsos positivos, calibración, estabilidad, indicadores de equidad, calidad de datos o métricas operativas, según el caso.
Umbrales y niveles de respuesta. No todo desvío exige retirar el modelo. Puede haber un nivel de observación, otro de investigación y un punto de intervención obligatoria.
Disparadores de cambio. Una nueva fuente de datos, un cambio de población, una actualización del proveedor, un reentrenamiento, una modificación del uso previsto o un incidente material pueden requerir revalidación aunque el tablero todavía parezca estable.

Las herramientas de apoyo publicadas por The IIA para su AI Auditing Framework refuerzan esta lógica. El Management AI Risk and Control Questionnaire de 2026 pregunta cómo se monitorean en producción la deriva, la degradación y los cambios en las distribuciones de datos, y presenta como práctica de referencia que los umbrales estén vinculados a respuestas definidas, incluida la revalidación, el ajuste o el retiro del modelo. El propio documento aclara que estas prácticas son ejemplos para apoyar el juicio de auditoría, no requisitos prescriptivos.

La evidencia debe permitir reconstruir qué ocurrió

Una auditoría de deriva no debería cerrarse con una captura de pantalla del dashboard. Las Normas Globales de Auditoría Interna exigen en la Norma 14.1 que los auditores recopilen información relevante, fiable y suficiente para sus análisis y evaluaciones. En modelos de IA, eso implica poder rastrear la métrica desde la fuente hasta la decisión de gestión.

Área de control	Evidencia esperada	Prueba de auditoría	Señal de alerta
Línea base y criterios	Informe de validación, métricas aprobadas, población de referencia, tolerancias	Comparar el desempeño en producción con la línea base y confirmar que las métricas responden al riesgo del caso de uso	Umbrales sin aprobación o definidos después de una desviación
Monitoreo en producción	Lógica de cálculo, fuentes, frecuencia, dashboards, registros de alertas	Recalcular una métrica para un periodo y reconciliarla con datos o logs de origen	Indicadores no trazables o datos incompletos
Respuesta a alertas	Tickets, análisis, escalaciones, decisiones, revalidaciones	Muestrear alertas y seguir cada una hasta su cierre y aprobación	Alertas cerradas sin análisis o sin propietario
Gestión del cambio	Registro de versiones, cambios de datos, actualizaciones de proveedor, aprobaciones	Rastrear cambios significativos hasta su evaluación de riesgo, prueba y autorización	Cambios en producción que el proceso de gobierno no detectó

La evidencia más persuasiva conecta varias fuentes: registro de versión, logs, señal de monitoreo, investigación, revalidación y aprobación de la decisión sobre el riesgo residual.

Auditoría interna no tiene que convertirse en validación de modelos

Una gran parte de este trabajo puede realizarla un auditor con buena alfabetización en IA. Puede evaluar la propiedad del modelo, la existencia de criterios de riesgo, la calidad del inventario, el diseño del monitoreo, la gobernanza de umbrales, la gestión de cambios, la escalación de alertas y la trazabilidad de las decisiones.

El límite aparece cuando la conclusión depende de comprobar técnicamente si un método de detección de deriva es estadísticamente adecuado, si los intervalos de confianza son correctos, si la calibración se deterioró de manera material o si una prueba de equidad está bien diseñada. Ahí puede ser necesario apoyo de especialistas en ciencia de datos, riesgo de modelos o estadística.

El papel de auditoría sigue siendo esencial: formular la pregunta de aseguramiento, evaluar el trabajo del especialista junto con el resto de la evidencia y traducir el resultado a una conclusión sobre riesgo y control.

Un modelo que deriva no demuestra por sí solo un fallo de control

Los modelos operan en entornos cambiantes. Que una métrica se deteriore no significa automáticamente que el sistema de gobierno falló. El fallo de control aparece cuando la organización no detecta, no comprende o no responde a un cambio material dentro del tiempo que exige el riesgo.

Esa distinción cambia la auditoría. En lugar de preguntar “¿el modelo sigue teniendo la misma precisión?”, conviene preguntar: ¿qué evidencia haría que la organización investigara, revalidara, ajustara, limitara o retirara este modelo, y podemos demostrar que esa respuesta ocurriría a tiempo?

Cuando esa respuesta está definida, monitoreada y documentada, la gestión de la deriva deja de ser una actividad técnica aislada y se convierte en un control de negocio auditable.