Qué significa monitorizar un sistema de IA
Monitorizar es observar si un sistema sigue cumpliendo su finalidad en condiciones reales y decidir qué hacer ante señales de deterioro. La aprobación inicial no garantiza resultados futuros: cambian los datos, el uso, las personas afectadas y las versiones del producto. Conviene partir del inventario de sistemas, su finalidad y su clasificación jurídica.
Monitorización y vigilancia poscomercialización: diferencias
La monitorización de IA es una práctica organizativa de calidad, seguridad y gobierno de IA que puede aplicarse a sistemas de cualquier clase según su contexto y riesgo. La vigilancia poscomercialización del artículo 72 es una obligación jurídica concreta de los proveedores de sistemas de IA de alto riesgo. Una empresa que utiliza una herramienta no pasa a ser proveedor por el mero hecho de monitorizarla.
Vigilancia poscomercialización en el AI Act
El artículo 72 del Reglamento (UE) 2024/1689 consolidado exige al proveedor de un sistema de alto riesgo establecer y documentar un sistema proporcionado a la naturaleza de la tecnología y sus riesgos. Debe recopilar, documentar y analizar activa y sistemáticamente, durante toda la vida útil, datos relevantes de funcionamiento procedentes de responsables del despliegue y otras fuentes. Su fin es evaluar el cumplimiento continuado de los requisitos del capítulo III, sección 2.
El sistema se basa en un plan de vigilancia poscomercialización integrado en la documentación técnica (anexo IV). Tras la modificación del Reglamento (UE) 2026/1744, el artículo 72.3 prevé directrices de la Comisión, incluido un modelo voluntario, a más tardar el 2 de septiembre de 2027. A septiembre de 2026 no se debe presentar ese modelo como formato obligatorio ya publicado. La aplicación de las disposiciones de alto riesgo tiene plazos escalonados: revisar la categoría y el calendario vigente de cada sistema antes de exigir el cumplimiento.
Qué datos conviene monitorizar
| Área | Señal útil | Posible respuesta |
|---|---|---|
| Rendimiento | Precisión, recall, F1, errores, disponibilidad o latencia | Comparar con la referencia validada |
| Calidad | Falsos positivos, falsos negativos, respuestas incompletas o incoherentes | Revisar muestras y daño potencial |
| Datos | Distribución, representatividad, ausencias o entradas anómalas | Comprobar origen y calidad |
| Riesgos | Nuevos grupos afectados o controles que pierden eficacia | Reevaluar riesgos |
| Personas | Correcciones, anulaciones, escalados y reclamaciones | Revisar instrucciones y supervisión |
| Cumplimiento | Cambios de uso, documentación, obligaciones o incidentes | Actualizar controles y evidencias |
La selección depende de la finalidad y del daño posible; no todas las métricas sirven para todos los modelos.
Drift: cuando el sistema empieza a comportarse de forma diferente
Data drift significa que cambian los datos recibidos; concept drift, que cambia la relación entre datos y resultado; performance drift, que empeoran los resultados medidos. Un aumento de solicitudes de un grupo nuevo puede cambiar la distribución sin probar por sí mismo un fallo. Conviene contrastar muestras, calidad de etiquetas, contexto y efectos antes de concluir. Un drift puede anticipar un problema; no equivale automáticamente a un incidente grave ni a una infracción.
KPIs, KRIs, umbrales y alertas
Los KPIs miden funcionamiento: precisión, latencia, disponibilidad o tasa de automatización. Los KRIs señalan exposición al riesgo: reclamaciones, intervenciones humanas, falsos positivos, resultados fuera de umbral o cambio de distribución. El recurso de KPIs y KRIs ayuda a elegirlos según finalidad, usuarios y personas afectadas.
Una buena práctica es fijar valor de referencia, umbral, responsable y acción antes de que salte la alerta: KRI supera umbral → revisión → análisis de riesgo → decisión documentada. Es un ejemplo de proceso, no un umbral ni una periodicidad impuesta universalmente por el AI Act.
Supervisión humana y trazabilidad
Medir cuántas recomendaciones se revisan, corrigen, anulan o escalan permite comprobar si la supervisión humana funciona y si aparece dependencia excesiva. Las cifras aisladas necesitan interpretación: más anulaciones también pueden reflejar un control más atento.
Los logs y la trazabilidad aportan la secuencia registros → datos → monitorización → detección → evidencia. Hay que distinguir registros técnicamente disponibles, exigencias específicas de los artículos 12 y 26 y evidencias organizativas voluntarias. Ajustar acceso y conservación a protección de datos y al caso concreto.
Monitorización y responsables del despliegue
El artículo 26.5 obliga a los responsables del despliegue de sistemas de alto riesgo a monitorizar su funcionamiento conforme a las instrucciones de uso y, cuando corresponda, informar al proveedor en relación con el artículo 72. Si tienen motivos para considerar que el uso conforme a las instrucciones puede generar un riesgo del artículo 79.1, deben informar sin demora indebida al proveedor o distribuidor y a la autoridad de vigilancia del mercado, y suspender el uso. El artículo 72, en cambio, asigna al proveedor su propio sistema y plan de vigilancia poscomercialización.
Riesgos, cambios e incidentes
El artículo 9 configura la gestión de riesgos de sistemas de alto riesgo como proceso continuo e iterativo durante el ciclo de vida, alimentado también por datos de vigilancia poscomercialización. Operativamente: riesgo inicial → despliegue → señales → reevaluación → controles.
Revisar versión, modelo, proveedor, datos, configuración, prompts, integración, finalidad o población afectada puede llevar a nueva validación, gestión del cambio, clasificación o documentación. Una actualización no constituye automáticamente una modificación sustancial jurídica. La monitorización descubre señales; la gestión de incidentes de IA investiga y actúa. El artículo 73 regula la notificación de incidentes graves por proveedores de sistemas de alto riesgo, cuando procede: una alerta ordinaria no es por sí sola un incidente grave notificable.
Monitorización e ISO/IEC 42001
ISO/IEC 42001 puede estructurar responsables, seguimiento, medición, revisión y mejora continua en un sistema de gestión de IA. ISO/IEC 23894 ofrece orientación para gestionar riesgos de IA a lo largo de su vida útil. Son marcos de apoyo: ninguno convierte la monitorización general en el plan legal del artículo 72 ni crea por sí mismo obligaciones del Reglamento.
Ejemplo empresarial: priorización de solicitudes
Una entidad usa IA para ayudar a ordenar solicitudes, con decisión humana posterior. Tras varios meses baja la precisión validada, aumenta la tasa de corrección de operadores y aparecen más reclamaciones. También cambia la distribución de solicitudes.
| Paso | Actuación ilustrativa |
|---|---|
| Señal e indicador | Comparar KPI de precisión y KRI de reclamaciones y anulaciones con la línea base |
| Umbral | Activar revisión al superar el umbral interno previamente aprobado |
| Investigación | Revisar muestras, datos de entrada, etiquetas, versiones, instrucciones y grupos afectados |
| Riesgo y acción | Reevaluar impacto; reforzar revisión humana, corregir datos o configuración y consultar al proveedor; restringir temporalmente una función si procede |
| Evidencia | Guardar alerta, análisis, decisión, responsables, cambios y resultado de la comprobación posterior |
La entidad confirma por separado su papel jurídico y la clasificación de alto riesgo; el ejemplo no presupone que toda herramienta de priorización esté sometida al artículo 72.
Qué evidencias conservar
Según el caso: métricas y paneles fechados, muestras, logs, umbrales, alertas, reclamaciones, intervenciones humanas, análisis de desviaciones, cambios de versión, comunicaciones con proveedor, reevaluaciones y medidas correctivas. Las obligaciones legales específicas se determinan por rol y categoría; esta lista es una propuesta de buena práctica, no un expediente universal exigido por ley. Vincular cada decisión a una persona responsable y su verificación posterior facilita las evidencias de gobierno.
Frecuencia y responsables
La cadencia puede ser continua, semanal, mensual, trimestral o activada por eventos. Depende de criticidad, volumen, impacto, ritmo de cambio e incidentes; aquí no se fija un plazo legal uniforme. Negocio, Data/ML, IT, seguridad, riesgos, Compliance, Legal, DPO cuando corresponda, auditoría y proveedor pueden intervenir. Definir quién mide, interpreta, escala, decide y registra evita alertas sin respuesta.
Cómo implantar la monitorización
1. Identificar sistema, finalidad, proveedor, rol y requisitos aplicables.
2. Definir riesgos, métricas, fuentes de datos, línea base y umbrales proporcionados.
3. Asignar responsables, acceso a registros, alertas y respuestas.
4. Probar la detección con casos representativos y revisar resultados con personas que conocen el proceso.
5. Registrar decisiones, cambios y reevaluaciones; ajustar el modelo de seguimiento cuando cambie el sistema.
Conclusión
Monitorizar convierte la información de uso real en decisiones verificables. La organización puede adoptar este ciclo por calidad y riesgo; cuando es proveedor de un sistema de alto riesgo, debe examinar además el sistema y plan específicos del artículo 72. Identificar primero roles, clasificación y calendario evita confundir buenas prácticas con obligaciones vigentes.
¿Detectarías si cambia el comportamiento de tu sistema de IA?
Conecta métricas, riesgos, responsables y evidencias con decisiones después del despliegue.
Realizar diagnóstico →
El diagnóstico de Céntrika te ayuda a evaluar tu punto de partida.