El cumplimiento no termina en la entrada al mercado. El Art. 72 exige a los proveedores de sistemas de IA de alto riesgo mantener un sistema activo de vigilancia poscomercialización, recopilar datos de rendimiento y notificar incidentes graves. Aquí se explica qué debe hacer — y cuándo.
¿Qué Es la Vigilancia Poscomercialización?
La evaluación de la conformidad y el marcado CE son el billete de entrada al mercado de la UE para un sistema de IA de alto riesgo — no la línea de llegada. El Artículo 72 del Reglamento de IA de la UE impone una obligación continua: los proveedores deben establecer y operar un sistema de vigilancia poscomercialización (VPC) que recoja, analice y actúe activamente sobre los datos de rendimiento en el mundo real durante toda la vida útil operativa del sistema.
El fundamento es sencillo. Un sistema de IA validado sobre un conjunto de datos fijo puede desviarse a medida que las entradas del mundo real cambian, a medida que la población de usuarios cambia o a medida que el entorno en el que opera evoluciona. Las instantáneas de cumplimiento estáticas no pueden capturar esto. La VPC es el mecanismo que convierte el cumplimiento en un proceso continuo en lugar de un evento puntual.
El sistema de VPC debe ser proporcional a la naturaleza y los riesgos del sistema de IA de alto riesgo afectado. Un modelo de puntuación crediticia desplegado a escala en millones de consumidores requerirá una supervisión más intensa que una herramienta estrecha de clasificación de documentos utilizada internamente por una empresa regulada.
¿Quién Debe Establecer un Sistema de VPC?
Obligatorio para:
- Proveedores de sistemas de IA de alto riesgo independientes del Anexo III — sistemas enumerados en el Anexo III que no son componentes de seguridad de un producto (p. ej., IA utilizada en decisiones de empleo, acceso a la educación, aplicación de la ley, evaluación de la solvencia crediticia, gestión de infraestructuras críticas)
- Proveedores de sistemas de IA integrados en productos del Anexo I — componentes de seguridad de IA integrados en productos cubiertos por la legislación de armonización de la UE existente (dispositivos médicos, maquinaria, vehículos)
No requerido para:
- Proveedores de sistemas de IA de riesgo mínimo (sin obligación formal de VPC, aunque se aplican las buenas prácticas)
- Proveedores de sistemas de IA de solo transparencia (las obligaciones del Art. 50 no se extienden a la VPC)
- Proveedores de modelos GPAI — estos están sujetos a un régimen separado en virtud del Art. 61–62, que incluye la notificación de incidentes para los modelos de riesgo sistémico, pero está estructurado de forma diferente a la VPC del Art. 72
El papel del operador es de apoyo pero no opcional. Los operadores deben operar el sistema de IA de acuerdo con las instrucciones del proveedor, activar y retener la funcionalidad de registro incorporada en el sistema y — fundamentalmente — notificar al proveedor cualquier incidente grave del que tengan conocimiento sin demora injustificada. Un operador que observa un incidente grave y no notifica al proveedor no es conforme.
El Plan de Vigilancia Poscomercialización (Anexo IV, Punto 12)
El plan de VPC es un componente obligatorio de la documentación técnica (Anexo IV). No puede ser un documento genérico: debe ser específico para el sistema, su contexto de despliegue y sus riesgos identificados. Como mínimo, debe definir:
- Recopilación de datos — qué métricas de rendimiento se capturan (exactitud, tasas de error, resultados de decisiones), cómo se recopilan los datos (telemetría automatizada, informes de operadores, comentarios de usuarios) y con qué frecuencia
- Bucles de retroalimentación — el mecanismo por el que los operadores pueden notificar problemas de rendimiento, anomalías o incidentes al proveedor de manera estructurada y oportuna
- Supervisión de la exactitud — cómo se rastrea el rendimiento del sistema frente al benchmark validado utilizado durante la evaluación de la conformidad, incluida cualquier metodología de detección de desviación
- Supervisión del sesgo — para los sistemas en los que los resultados demográficos son materiales (contratación, crédito, aplicación de la ley), supervisión continua de las disparidades estadísticas entre grupos protegidos, con metodología y umbrales definidos
- Desencadenantes de actualización — los umbrales cuantitativos o cualitativos específicos que impulsan la acción correctiva, incluido el reentrenamiento del modelo, el ajuste de parámetros o la suspensión del despliegue
- Calendario de revisión — con qué frecuencia se revisa y actualiza el propio plan de VPC, garantizando que siga siendo adecuado para el propósito a medida que evoluciona el contexto de despliegue
El plan de VPC debe mantenerse actualizado. Un plan desactualizado que ya no refleja la metodología de supervisión real no satisface el Art. 72.
Notificación de Incidentes Graves (Art. 73)
¿Qué constituye un incidente grave?
El Artículo 73 define un incidente grave como cualquier incidente o mal funcionamiento de un sistema de IA de alto riesgo que lleva directa o indirectamente a:
- Muerte o daño grave a la salud (físico o psicológico)
- Una interrupción grave e irreversible de la gestión u operación de infraestructuras críticas
- Una violación grave de los derechos fundamentales (privacidad, no discriminación, debido proceso)
- Una situación en que una persona estuvo a punto de sufrir cualquiera de los anteriores
Es importante destacar que el Reglamento de IA no requiere que se establezca un vínculo causal con el sistema de IA antes de notificar. Una sospecha razonable de que el sistema de IA contribuyó a o no pudo prevenir el daño es suficiente para desencadenar la obligación. Los proveedores que esperan a tener certeza antes de notificar corren el riesgo de incumplir.
Plazos de notificación
| De | A | Plazo |
|---|---|---|
| Operador | Proveedor | Sin demora injustificada (al tener conocimiento) |
| Proveedor | Autoridad nacional de vigilancia del mercado | En un plazo de 15 días naturales a partir de tener conocimiento |
| Proveedor (riesgo para la seguridad pública) | Autoridad nacional de vigilancia del mercado | En un plazo de 24 horas a partir de tener conocimiento |
| Proveedor (patrón de riesgo sistémico emergente) | Autoridad nacional de vigilancia del mercado | Sin demora injustificada (no se requiere un incidente específico) |
El plazo de 15 días comienza cuando el proveedor tiene conocimiento del incidente — lo que, en la práctica, significa cuando el operador les notifica. Los proveedores deben diseñar sus procedimientos de notificación del operador de modo que la información les llegue con suficiente rapidez para cumplir el plazo de notificación posterior.
Qué debe contener un informe de incidente
Un informe de incidente conforme a la autoridad nacional de vigilancia del mercado debe incluir:
- Identificación del sistema: nombre, versión, número de registro en la base de datos de la UE
- Descripción del incidente: qué ocurrió, qué daño se produjo o estuvo a punto de producirse, fecha y lugar
- Personas afectadas: número y categorías de usuarios o terceros afectados (anonimizados donde sea necesario en virtud del RGPD)
- Análisis causal preliminar: la comprensión actual del proveedor de cómo surgió el incidente, claramente etiquetado como preliminar
- Medidas correctivas o de seguridad inmediatas adoptadas: cualquier paso ya dado para limitar el daño o el riesgo adicional (p. ej., suspensión de la funcionalidad afectada, notificaciones a los operadores)
- Punto de contacto: la persona o el equipo responsable de la correspondencia de seguimiento con la autoridad
El informe debe ser factual y proporcionado. Los informes preliminares pueden complementarse con informes de seguimiento a medida que avanza la investigación.
Registro Obligatorio (Art. 12)
El Artículo 12 exige que los sistemas de IA de alto riesgo estén diseñados y construidos con la capacidad de generar registros automáticamente con un nivel de granularidad suficiente para permitir:
- La vigilancia poscomercialización de acuerdo con el Art. 72
- El rastreo de eventos que conducen a un incidente grave
- La investigación por las autoridades nacionales
Este es un requisito de diseño impuesto al proveedor. El proveedor debe incorporar la capacidad de registro en el sistema antes de que sea comercializado.
La obligación de activar y retener esos registros recae en el operador. Los operadores no deben deshabilitar la funcionalidad de registro y deben retener los registros durante el período especificado en las instrucciones del proveedor y la documentación técnica. Cuando no se define ningún período de retención específico, los registros deben conservarse durante un período acorde con el ciclo de vida operativo del sistema y cualquier requisito sectorial específico aplicable (p. ej., normas de mantenimiento de registros de servicios financieros en virtud de DORA o MiFID II).
Modificaciones Sustanciales y Reevaluación
No todos los cambios en un sistema de IA desplegado desencadenan una nueva evaluación de la conformidad. El Reglamento distingue entre actualizaciones menores y modificaciones sustanciales.
Una modificación es sustancial — y requiere una nueva evaluación de la conformidad y documentación técnica actualizada — cuando:
- Cambia el fin previsto del sistema (incluso parcialmente)
- Implica un cambio significativo en la arquitectura o la metodología de entrenamiento
- Usa nuevos datos de entrenamiento que afectan materialmente el rendimiento del sistema de maneras que podrían afectar el comportamiento relevante para el cumplimiento
- Degrada el rendimiento más allá de los umbrales definidos en la documentación de gestión de riesgos de maneras que afectan a la seguridad o los derechos fundamentales
Las actualizaciones menores — parches de seguridad, correcciones de errores que corrigen defectos claramente identificados sin alterar el comportamiento relevante para el cumplimiento, cambios estéticos en la interfaz — no requieren una reevaluación completa. Sin embargo, deben documentarse, y el proveedor debe conservar una evaluación escrita que confirme que la modificación no constituye una modificación sustancial. Ese registro está sujeto a inspección por parte de las autoridades de vigilancia del mercado.
Lista de Verificación Práctica de Implementación
La siguiente lista de verificación refleja los requisitos operativos mínimos en virtud del Art. 72, el Art. 73 y el Art. 12. No es un sustituto del asesoramiento jurídico, pero proporciona un punto de partida para el análisis de brechas.
- [ ] Plan de VPC documentado en el expediente técnico (Anexo IV, punto 12), específico para el sistema y su contexto de despliegue
- [ ] Capacidad de registro automático diseñada e incorporada en el sistema antes de la comercialización
- [ ] Las instrucciones del operador incluyen un procedimiento de notificación de incidentes claro, escrito, con contacto de escalado
- [ ] Punto de contacto interno de notificación de incidentes establecido y notificado a la autoridad nacional de vigilancia del mercado pertinente
- [ ] Procesos o paneles de supervisión de sesgos y exactitud definidos, con metodología y umbrales documentados
- [ ] Umbrales de escalado para la acción correctiva documentados y vinculados al sistema de gestión de riesgos
- [ ] Procedimiento de evaluación de modificaciones sustanciales en vigor, con una plantilla de registro de decisión para cada actualización
- [ ] Política de retención de registros definida, comunicada a los operadores y alineada con las normas de retención específicas del sector
Referencias cruzadas: Documentación técnica — Sistemas de IA de alto riesgo del Anexo III — Proveedores vs. Operadores
Official AI Act Compliance Deadline Calendar
Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.
| Obligation | Applies to | Original date | New date | Status | Countdown | Legal basis |
|---|---|---|---|---|---|---|
| Prohibited Practices (Art. 5) | All providers and deployers | active | — | AI Act Art. 5 | ||
| GPAI Rules (Chapter 5) | GPAI model providers | active | — | AI Act Art. 51-56 | ||
| High-risk AI — Annex III (standalone) | Providers of standalone Annex III systems | deferred | — | AI Omnibus 2026 Art. 6(2) | ||
| High-risk AI — Annex I (embedded) | AI embedded in Annex I regulated products | deferred | — | AI Omnibus 2026 Art. 6(1) | ||
| AI-Generated Content Marking | Providers of generative GPAI systems | active | — | AI Act Art. 50(2) | ||
| Regulatory Sandboxes | National competent authorities | active | — | AI Act Art. 57 |
⬇ Download JSON · CC BY 4.0
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.
Explore regulation-dora.eu ↗Frequently Asked Questions
Las obligaciones de vigilancia poscomercialización en virtud del Art. 72 se aplican exclusivamente a los proveedores de sistemas de IA de alto riesgo (Anexo I y Anexo III). Los proveedores de modelos GPAI tienen obligaciones paralelas pero distintas que incluyen la notificación de incidentes para los modelos de riesgo sistémico. Los sistemas de riesgo mínimo y de solo transparencia no tienen ningún requisito formal de vigilancia poscomercialización.
Un incidente grave es cualquier incidente o mal funcionamiento que lleva directa o indirectamente a: muerte, daño grave a la salud, una interrupción grave e irreversible de la infraestructura o la propiedad, o una violación grave de los derechos fundamentales. También incluye los casos en que una persona estuvo a punto de sufrir alguno de los anteriores. El Reglamento de IA no requiere que se establezca un vínculo causal: una sospecha razonable es suficiente para desencadenar la notificación.
Los proveedores deben notificar los incidentes graves a la autoridad nacional de vigilancia del mercado pertinente sin demora injustificada y en cualquier caso dentro de los 15 días siguientes a tener conocimiento. Para los incidentes que supongan un riesgo para la seguridad pública, el plazo es de 24 horas. Los operadores deben notificar a los proveedores los incidentes graves sin demora injustificada.
Sí. Si una actualización constituye una 'modificación sustancial' — cambia el fin previsto, degrada significativamente el rendimiento o altera las medidas de gestión de riesgos — requiere una nueva evaluación de la conformidad. Las correcciones menores de errores y los parches de seguridad generalmente no lo hacen. El proveedor debe documentar todas las actualizaciones y evaluar si desencadenan una reevaluación.
Stay ahead of AI Act changes
Get compliance alerts when deadlines or obligations change.
No spam. One-click unsubscribe.