Plan de vigilancia poscomercialización para agentes de IA: qué exige el Artículo 72 del Reglamento Europeo de IA

Empiece por la clasificación, no por las etiquetas

Los agentes de IA no constituyen una categoría jurídica separada en el Reglamento. Lo que activa el Artículo 72 no es la palabra agente, sino que el sistema esté clasificado como alto riesgo o forme parte de un sistema de alto riesgo.

Un asistente interno que redacta notas de reuniones no se trata igual que un agente utilizado en evaluación crediticia, triaje de reclamaciones, contratación, verificación de identidad, apoyo a decisiones del sector público u otros casos del Anexo III. Si todavía no ha realizado ese análisis, empiece por Clasificar la IA de alto riesgo según el Reglamento Europeo de IA y Cumplimiento de agentes de IA según el Reglamento Europeo de IA. Una vez que el sistema entra en alcance, la vigilancia poscomercialización pasa a formar parte del modelo operativo, no de una buena práctica opcional.

Qué exige realmente el Artículo 72

El Artículo 72 exige a los proveedores de sistemas de IA de alto riesgo establecer y documentar un sistema de vigilancia poscomercialización proporcionado a la naturaleza de la tecnología de IA y a los riesgos del sistema. La monitorización debe seguir activa durante toda la vida útil del sistema.

En la práctica, la obligación tiene cinco piezas. Debe recopilar, documentar y analizar activamente y de manera sistemática datos relevantes posteriores al despliegue; evaluar el cumplimiento continuo de los requisitos de la Sección 2 del Capítulo III; incluir la interacción con otros sistemas de IA cuando sea pertinente; basar el sistema de monitorización en un plan de vigilancia poscomercialización; y mantener ese plan dentro del conjunto documental del Anexo IV. Los procesos sectoriales existentes pueden reutilizarse cuando el Derecho de la Unión ya exija una gobernanza equivalente, pero solo si el resultado integrado mantiene el mismo nivel de protección.

• Recopilar datos relevantes posteriores al despliegue de forma sistemática, no ocasional.
• Revisar esos datos frente a los requisitos de cumplimiento continuo, no solo frente a KPI de producto.
• Capturar interacciones con otros sistemas de IA y herramientas externas cuando importen.
• Documentar el plan dentro del Anexo IV para que un revisor pueda inspeccionar cómo funciona realmente la monitorización.
• Integrar procesos sectoriales existentes solo cuando el nivel de protección siga siendo equivalente.

Un panel no es un plan

El fallo más habitual consiste en confundir observabilidad con cumplimiento. Un panel puede mostrar latencia, tasa de éxito, coste o consumo de tokens. Un plan de vigilancia poscomercialización debe poder decir a un revisor qué riesgos se están vigilando, qué señales demuestran que los controles siguen funcionando, qué umbrales desencadenan escalado, quién revisa qué y cómo se documenta la acción correctiva.

Por eso la vigilancia poscomercialización está estrechamente vinculada a Checklist del Artículo 17 del Reglamento Europeo de IA, Trazas de auditoría para agentes de IA: de los registros a la evidencia y su paquete subyacente de evidencias. Si no puede mostrar cómo la telemetría se convierte en evidencia revisada, todavía no tiene un modelo operativo del Artículo 72.

• Qué riesgos se monitorizan: vinculados al registro de riesgos del Artículo 9.
• Qué señales importan: no solo salidas, sino llamadas a herramientas, aprobaciones, anulaciones y efectos posteriores.
• Qué umbrales importan: qué es meramente informativo, qué exige revisión el mismo día y qué congela producción.
• Qué registros sobreviven a una auditoría: incidentes, razonamiento del revisor, acciones correctivas y exportaciones de evidencia vinculadas a versiones.

Por qué el Artículo 72 importa más para los agentes de IA

Los sistemas de predicción estáticos pueden fallar de forma silenciosa. Los agentes fallan a través de sistemas. Recuperan datos, llaman herramientas, disparan flujos de trabajo, ceden tareas a otros modelos y operan con distintos niveles de autonomía. Por eso la monitorización de agentes debe ser a nivel de flujo de trabajo, no solo a nivel de modelo.

La lógica de la vigilancia poscomercialización es especialmente relevante para sistemas agentivos incluso cuando el modelo no se reentrena de forma continua. El riesgo emergente puede venir de cambios en prompts, actualizaciones de políticas, sustituciones de modelo, ampliación del acceso a herramientas, cambios en recuperación, deriva de integraciones o modificaciones del flujo por parte del desplegador. El sistema puede volverse más arriesgado sin que exista un ciclo clásico de entrenamiento.

• Ejecución de herramientas: acciones fallidas, reintentos, efectos colaterales e intentos no autorizados.
• Señales de control de políticas: denegaciones, casi-denegaciones, colas de aprobación y motivos de anulación.
• Comportamiento entre sistemas: qué ocurre cuando el agente depende de otros servicios de IA o automatizaciones externas.
• Resultados relevantes para derechos: disparidades, quejas, recursos y efectos perjudiciales materiales aguas abajo.

Qué debe incluir un plan defendible conforme al Artículo 72

Un plan defendible no debe ser largo para parecer serio. Debe ser lo bastante específico como para que un revisor entienda cómo detecta degradación, quién investiga anomalías y cómo la evidencia retroalimenta la conformidad y el control de cambios.

En agentes de IA, el plan suele necesitar al menos los siguientes bloques. Aquí es también donde muchos equipos combinan el requisito legal con la Plantilla de plan de vigilancia poscomercialización, el Manual de procedimientos de supervisión humana y la Checklist del paquete de evidencias, de modo que el proceso sea utilizable por ingeniería y operaciones, no solo por jurídico.

• Identificación del sistema y finalidad prevista: nombre exacto del sistema, versión, entidad proveedora, alcance de la versión, contexto de despliegue, usuarios afectados, límites y lógica de clasificación de alto riesgo.
• Objetivos de monitorización vinculados al registro de riesgos: cada riesgo material debería tener al menos una señal monitorizada, un responsable y una vía de escalado.
• Fuentes de datos y métodos de recogida: registros de ejecución, trazas de herramientas, eventos de aprobación, registros de anulación, quejas, salidas muestreadas, tickets de incidente y cambios de integración.
• Métricas, umbrales y niveles de severidad: tasa de fallos de tarea, tasa de error de herramientas, tasa de alucinación o de acciones no sustentadas cuando proceda, frecuencia de anulaciones, indicadores de disparidad, eventos de rollback y lógica de consecuencias ligada a umbrales.
• Política de muestreo y cadencia de revisión: telemetría siempre activa, revisión del 100 % para acciones críticas, muestreo base para salidas de menor riesgo y revisión intensificada tras releases, cambios de modelo o incidentes.
• Datos de supervisión humana e intervención: qué se escaló, quién lo revisó, qué contexto vio, qué cambió y si el mismo patrón de fallo se repite.
• Gestión de incidentes y enlace con el Artículo 73: quién investiga, qué se convierte en incidente, qué plazos ante autoridades aplican y cómo se identifica y documenta el inicio del reloj de notificación.
• Acción correctiva y control de cambios: quién puede pausar, desactivar, revertir o retirar el sistema y cómo los hallazgos poscomercialización vuelven al sistema de gestión de riesgos del Artículo 9 y al sistema de gestión de calidad del Artículo 17.
• Retención de evidencia y preparación para auditoría: cómo se conservan, protegen, vinculan a versiones y exportan los registros, notas de revisión, incidentes y acciones correctivas.

Cuándo la monitorización se convierte en notificación del Artículo 73

Su plan de monitorización debe indicar claramente cuándo una alerta se convierte en incidente, quién es responsable del triage y cuándo se activa la notificación del Artículo 73. Ese reloj no debe dejarse a la improvisación.

Bajo el marco actual del Artículo 73, el plazo máximo general es de 15 días desde que el proveedor o desplegador tiene conocimiento de un incidente grave. El plazo máximo es de 2 días en caso de infracción generalizada de obligaciones destinadas a proteger derechos fundamentales o de interrupción grave e irreversible de infraestructuras críticas, y de 10 días cuando una persona ha fallecido una vez establecida la causalidad o una sospecha razonable de causalidad. El punto operativo es sencillo: sus umbrales y reglas de escalado deben sacar a la luz esos supuestos con suficiente rapidez para que la notificación siga siendo posible.

• Muerte o daño grave para la salud exige el triage más rápido y una ruta de decisión sobre causalidad claramente documentada.
• Interrupción grave e irreversible de infraestructuras críticas debe saltarse las colas lentas de revisión interna.
• Infracciones de derechos fundamentales no son abstracciones jurídicas; necesitan disparadores operativos vinculados a quejas, anulaciones, recursos y resultados perjudiciales posteriores.
• La acción correctiva del Artículo 20 debe estar conectada al mismo flujo para que la mitigación no espere al cierre del trámite de notificación.

Los proveedores son responsables del Artículo 72, pero los desplegadores alimentan el sistema

El Artículo 72 es una obligación del proveedor, pero el proveedor a menudo no controla todo el contexto operativo. Los desplegadores pueden custodiar las quejas, notas de revisión humana, tickets de incidente en primera línea o datos de resultados posteriores que hacen que la monitorización sea significativa.

En sistemas agentivos, los contratos proveedor-desplegador deberían especificar qué datos debe devolver el desplegador, con qué rapidez se escalan incidentes graves y casi-incidentes, cómo se retienen los registros de anulación y cómo se comunican los cambios en flujos o integraciones. Si no diseña esta interfaz, el plan parecerá completo sobre el papel y fallará en producción.

• Obligaciones de devolución de datos para quejas, anulaciones, recursos y métricas de resultado.
• Canales de notificación de incidentes con contactos nominados y mapeo jurisdiccional.
• Notificaciones de cambio cuando el desplegador modifica prompts, herramientas, flujos o controles de entorno.
• Reglas de retención y exportación para evitar que la evidencia de poscomercialización se fragmente entre sistemas.

La posición sobre plantilla y calendario en marzo de 2026

La formulación más segura conforme al derecho vigente es esta: la cuestión de la plantilla sigue abierta; la obligación del proveedor no. El texto actual del Artículo 72 sigue remitiendo a un acto de ejecución de la Comisión para una plantilla del plan. Pero el 19 de noviembre de 2025 la Comisión propuso sustituir esa prescripción por orientaciones, en lugar de un formato armonizado obligatorio. Esa propuesta sigue en tramitación y, por tanto, no cambia la ley vigente hoy.

La misma cautela se aplica al calendario. Conforme al Reglamento Europeo de IA vigente, la mayoría de las obligaciones de alto riesgo se aplican a partir del 2 de agosto de 2026, mientras que determinados sistemas de IA de alto riesgo integrados en productos disponen de una transición más larga hasta el 2 de agosto de 2027. La Comisión ha propuesto cambios de calendario, pero esos cambios aún no son derecho aplicable. El paso práctico es construir ahora un plan revisable y ajustar el formato más adelante si la Comisión finaliza orientaciones o enmiendas legislativas sobre la plantilla.

• Texto actual del Artículo 72: Resumen del Artículo 72 en AI Act Service Desk
• Plazos actuales de incidentes graves: Resumen del Artículo 73 en AI Act Service Desk
• FAQ de la Comisión sobre implantación: Navigating the AI Act
• FAQ de la Comisión sobre normalización: Understanding the standardisation of the AI Act
• Propuesta de la Comisión en tramitación: COM(2025) 811 final

Errores habituales que hacen fracasar los planes del Artículo 72 en revisión

Los fallos suelen ser operativos, no teóricos. Los equipos redactan el plan como si fuera un memorando, pero los reguladores y auditores lo tratarán como evidencia de una capacidad operativa viva.

Si quiere una prueba práctica, pregúntese si un tercero podría mirar su plan y entender cómo se monitoriza el sistema, quién investiga anomalías, cómo afectan los cambios en producción al muestreo y qué se notifica o revierte cuando se superan los umbrales.

• Tratar la vigilancia poscomercialización como un panel y no como un procedimiento operativo.
• Monitorizar solo la calidad del modelo e ignorar el uso de herramientas, aprobaciones, anulaciones y efectos posteriores.
• Enumerar métricas sin umbrales, responsables nominados, lógica de severidad ni tiempos de respuesta.
• Olvidar las interacciones con otros sistemas de IA en flujos agentivos.
• Conservar registros en bruto, pero no decisiones sobre incidentes, razonamiento del revisor o evidencia de acciones correctivas.
• Desconectar la monitorización del control de cambios, de modo que cada release reinicia el riesgo sin una revisión más estricta.
• Asumir que la documentación del proveedor del modelo sustituye la monitorización a nivel de sistema por parte del proveedor.