Cómo crear un plan de vigilancia poscomercialización conforme al artículo 72

Guía7 de agosto de 2026· 17 min de lectura

Crea un plan de vigilancia poscomercialización del art. 72: métricas, umbrales de alerta y escalado, cadencia, responsables, estructura y ejemplo.

Salta una alerta de deriva en un modelo de selección de personal en producción. ¿Quién la lee, frente a qué umbral, con qué cadencia y qué documento se lo indicó? Si no puedes responder de un tirón, todavía no tienes un plan de vigilancia poscomercialización: tienes un sistema de vigilancia sin base documentada, que conforme al artículo 72(3) del Reglamento (UE) 2024/1689 es la parte que los reguladores leen primero. Esta guía construye el artefacto, sección a sección, para los proveedores de sistemas de IA de alto riesgo.

Este es el manual para construir el plan, no un repaso del deber. Para la obligación completa —alcance, el bucle del artículo 9, la integración con la legislación sectorial— lee la obligación de vigilancia poscomercialización del artículo 72 explicada. Aquí te llevas un esqueleto rellenable, las decisiones de métricas y umbrales, y un ejemplo trabajado que conecta la detección con la notificación y la acción correctiva.

Qué es un plan de vigilancia poscomercialización y qué construye esta guía

La distinción importa porque la ley divide el deber. El artículo 72(1)-(2) exige al proveedor establecer y operar un sistema de vigilancia que recopile y analice de forma activa y sistemática los datos de rendimiento a lo largo de toda la vida útil del sistema de alto riesgo. El artículo 72(3) exige que esa actividad se base en un plan documentado. El sistema es la capacidad operativa; el plan es su base escrita. Esta guía construye el plan.

El deber es del proveedor (artículo 16) y solo se aplica a los sistemas de alto riesgo. Los responsables del despliegue aportan datos conforme al artículo 26 —conservan logs y te notifican incidentes—, pero no construyen el plan. La línea puede moverse: una parte que ponga su nombre o marca comercial en un sistema de alto riesgo, lo modifique sustancialmente o cambie su finalidad prevista se convierte en proveedor conforme al artículo 25 y hereda íntegramente el deber del artículo 72.

¿Dónde vive el plan? No en un archivo independiente. Forma parte de la documentación técnica del anexo IV a través del artículo 11 —la sección 9 de esa documentación. La Comisión debe emitir una plantilla (artículo 72(3)); hasta que lo haga, redacta frente a la ley y alinéate más tarde. Construye el plan antes de la evaluación de la conformidad, no después del lanzamiento.

Los siete bloques que necesita todo plan del artículo 72

Cada bloque siguiente se corresponde con una decisión que debes tomar y registrar: la lista de comprobación de construcción que el resto del artículo desarrolla.

Indicadores de rendimiento ligados a la finalidad prevista

Los indicadores deben rastrearse hasta la finalidad prevista del sistema y su caso de uso del anexo III, no una cifra genérica de «exactitud». Para la selección de personal (anexo III, punto 4(a)), haz seguimiento de la paridad de la tasa de selección entre grupos de candidatos. Para la solvencia crediticia (anexo III, punto 5(b)), haz seguimiento de la tasa de impago por cohorte de aprobación. La métrica debe significar algo para el perfil de daño de este sistema.

Umbrales y condiciones de activación

Cada indicador necesita un número que haga algo cuando se rebasa. Define dos bandas, detalladas más abajo.

Fuentes de datos y mecanismo de recopilación

Nombra de dónde procede cada dato —tu propia infraestructura, los logs del responsable del despliegue, la telemetría de la API— y el derecho por el cual lo recopilas.

Cadencia y metodología de revisión

Indica con qué frecuencia y con qué método analizas los datos. «Periódicamente» no es una cadencia.

Roles y responsabilidad (RACI)

Nombra a un único responsable rendidor de cuentas y la vía de decisión desde el hallazgo hasta la acción.

Bucle de retroalimentación hacia la gestión de riesgos del artículo 9

El plan debe describir cómo los hallazgos reabren la evaluación de riesgos del artículo 9 y desencadenan actualizaciones del anexo IV.

Vínculos de escalado con el artículo 73 y el artículo 20

El plan debe definir cuándo un hallazgo se convierte en un incidente grave notificable (artículo 73) y cuándo desencadena una acción correctiva (artículo 20).

La proporcionalidad (artículo 72(1)) gobierna lo pesado que es cada bloque. El plan registra el razonamiento de proporcionalidad —«cada resultado es revisado por una persona y el volumen es de 200 casos por trimestre»—, no la afirmación «somos pequeños».

Elegir métricas y fijar umbrales

Derivar las métricas de la finalidad prevista y del anexo IV

Ancla cada métrica a una afirmación que ya documentaste. Tu expediente del anexo IV declara los niveles de rendimiento, solidez y ciberseguridad validados conforme al artículo 15; la vigilancia existe para verificar que esas afirmaciones se mantienen en producción. Así que las métricas no se inventan de cero: son el reflejo, del lado de la producción, de lo que la evaluación de la conformidad ya prometió. Cubre la deriva del modelo y el rendimiento dispar entre grupos demográficos, porque ambos se degradan en silencio.

Fijar una línea de base en la evaluación de la conformidad

La línea de base de lanzamiento es la conclusión sobre el riesgo residual del artículo 9: el nivel de rendimiento con el que juzgaste aceptable el riesgo residual. Regístralo. Todo lo que midas después se mide frente a esa línea, por lo que la línea de base debe escribirse en el plan en lugar de reconstruirse tras un incidente.

Definir los umbrales de alerta frente a los de escalado

Fija dos bandas, no una. Una banda de alerta interna desencadena un análisis y una revisión documentada: algo se ha movido, investígalo. Una banda de escalado indica que el sistema puede haber dejado de ser conforme o que un hallazgo podría ser un incidente grave. La banda de escalado es el cable hacia el artículo 73 y el artículo 20. Registra el razonamiento de cada número para que sea defendible, no arbitrario.

Sobre el alcance de los datos: los datos agregados por categoría —grupo, jurisdicción, escenario de caso de uso— suelen bastar para detectar el riesgo sistémico y evitan poner en marcha una nueva operación de datos personales con mucha carga de RGPD por sí misma.

Fuentes de datos, cadencia de recopilación y responsabilidad

Asegurar por contrato los datos aportados por el responsable del despliegue

El artículo 72(2) contempla expresamente los datos aportados por el responsable del despliegue. Si vendes a muchas organizaciones que despliegan, la condición previa es contractual: obligaciones de registro, conservación y compartición de datos, además de formatos de datos acordados, escritos en los contratos de suministro antes del lanzamiento. No puedes vigilar datos que no tienes derecho a recopilar, y «ya lo pediremos» no es un mecanismo.

Fijar una cadencia de revisión (por evento frente a periódica)

La cadencia es una decisión de diseño que el plan debe indicar de forma explícita. Un patrón viable combina tres capas: telemetría continua donde sea factible, una revisión periódica fija (mensual o trimestral) y un análisis por evento en el momento en que se rebasa un umbral de alerta. «Revisado periódicamente» no es un plan; «revisado trimestralmente, más en un plazo de cinco días hábiles tras cualquier superación de alerta» sí lo es.

Asignar el responsable del plan y la vía de decisión

Nombra a un responsable rendidor de cuentas y una vía de decisión escrita desde el hallazgo hasta la acción. Los auditores buscan pruebas de que el bucle realmente se cerró —un hallazgo analizado, una decisión registrada, una acción tomada—, no de que se describiera un bucle sobre el papel. La responsabilidad sin una vía de decisión es decoración.

Conectar el plan con los incidentes (artículo 73) y la acción correctiva (artículo 20)

La vía detectar → notificar del artículo 73

Define, dentro del plan, el umbral interno a partir del cual un hallazgo de vigilancia se convierte en un posible incidente grave. Una vez rebasado ese umbral y en cuanto tengas conocimiento, corren los plazos del artículo 73: a más tardar 15 días por defecto, 10 días cuando el incidente haya causado un fallecimiento y 2 días ante una infracción generalizada o una perturbación grave e irreversible de infraestructuras críticas. El plan decide de antemano quién clasifica el hallazgo y pone en marcha el reloj.

La vía detectar → corregir del artículo 20

Notificar no es corregir. Cuando la vigilancia muestre que el sistema no es conforme, el artículo 20 exige al proveedor adoptar una acción correctiva —ponerlo en conformidad, retirarlo, desactivarlo o recuperarlo— e informar a los distribuidores, los responsables del despliegue, el representante autorizado y los importadores. El plan debe predefinir quién está autorizado a desencadenar esto y cómo se notifica a las partes posteriores.

Por qué un plan activo arregla el reloj del «tener conocimiento»

Un sistema operativo del artículo 72 establece cuándo el proveedor tuvo conocimiento: el momento en que arranca el reloj del artículo 73. Un umbral de detección documentado convierte «nos dimos cuenta con el tiempo» en un evento fechado y trazable. Los hallazgos retroalimentan después la evaluación del artículo 9 y cualquier actualización del anexo IV, cerrando el bucle que los auditores siguen desde la detección hasta la documentación.

Una estructura (tabla) de plan de vigilancia poscomercialización que puedes rellenar

Usa este esqueleto. Cada fila empareja el contenido exigido con su base legal y una indicación de redacción de una línea, de modo que te lleves una estructura en lugar de un conjunto de conceptos.

Sección del plan	Base legal	Qué va aquí (indicación de redacción)
Identidad del sistema y finalidad prevista	Anexo IV §1	Nombra el sistema, la versión, la finalidad prevista y el caso de uso del anexo III.
Objetivos de la vigilancia y proporcionalidad	Artículo 72(1)	Indica qué debe detectar la vigilancia y justifica lo pesado del aparato.
Indicadores de rendimiento y líneas de base	Artículo 15 / Anexo IV	Enumera cada métrica y su línea de base de lanzamiento, ligada a una afirmación documentada.
Umbrales: alerta frente a escalado	Artículo 72(2)	Da dos números por métrica y el razonamiento de cada uno.
Fuentes de datos y obligaciones del responsable del despliegue	Artículo 72(2), Artículo 26	Nombra cada fuente y el derecho contractual que la asegura.
Cadencia y metodología de revisión	Artículo 72(3)	Indica el intervalo periódico, la telemetría continua y los disparadores por evento.
Roles y responsabilidad	Artículo 16	Nombra al responsable rendidor de cuentas y la vía de decisión del hallazgo a la acción.
Retroalimentación a la gestión de riesgos	Artículo 9	Describe cómo los hallazgos reabren la evaluación de riesgos.
Escalado de incidentes	Artículo 73	Define el umbral de un incidente grave notificable y quién lo clasifica.
Disparadores de acción correctiva	Artículo 20	Predefine quién desencadena la retirada/recuperación y a quién se informa.

El plan se sitúa en la sección 9 de la documentación técnica del anexo IV (artículo 11) y debe alinearse con la plantilla de la Comisión una vez emitida.

Ejemplo trabajado: un proveedor de tecnología de RR. HH. de 180 personas construye el plan

Tomemos a Talvera, un proveedor de unos 180 empleados de un sistema automatizado de cribado de currículums vendido a empleadores del mercado medio. El cribado para la selección de candidatos es de alto riesgo conforme al anexo III, punto 4(a), así que Talvera es el proveedor y es dueña del plan del artículo 72. Recorramos una fila —indicadores de rendimiento y umbrales— hasta valores concretos.

El plan de Talvera enumera: ratio de paridad de la tasa de selección entre proxies de atributos protegidos (alerta si el ratio cae por debajo de una banda acordada; escalado por debajo de una banda inferior), tasa de aceptación de recomendaciones, tasa de revocación de recursos y exactitud medida frente a los resultados de contratación posteriores. Cadencia: revisión trimestral más análisis por evento ante cualquier superación de alerta. Datos: los contratos con los responsables del despliegue exigen logs de resultados agregados trimestrales, de modo que Talvera nunca toca registros individuales de candidatos que no tiene derecho a conservar.

Ahora la cadena se dispara. Una revisión trimestral muestra que el ratio de paridad va a la deriva; al mes siguiente rebasa la banda de escalado. Talvera reabre su evaluación del artículo 9, juzga si la deriva es un incidente grave notificable conforme al artículo 73 y —al constatar que el sistema no es conforme— aplica una acción correctiva del artículo 20 desactivando la vía de puntuación afectada a la espera de una corrección. Si Talvera no hubiera tenido ningún sistema documentado, el fallo recaería en el artículo 99(4): hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial total, la cifra que sea más alta. Como pyme —menos de 250 empleados, con un volumen de negocios dentro del umbral—, Talvera se beneficia del artículo 99(6), que limita su multa a la menor de esas dos cifras: protección, no un motivo para saltarse el plan.

Del plan al sistema operativo: mantenerlo auditable

El plan es un documento vivo. Actualízalo siempre que la vigilancia muestre que una hipótesis previa de riesgo o de rendimiento era errónea, y refleja el cambio en la documentación técnica del anexo IV (artículo 11). Un plan que no cambia tras un año de funcionamiento es un plan que nadie está leyendo.

Matiza el plazo con precisión. El Ómnibus Digital, que aplaza el alto riesgo autónomo del anexo III al 2 de diciembre de 2027, está adoptado: voto final del Parlamento Europeo el 16 de junio de 2026, adopción del Consejo el 29 de junio de 2026, y entrada en vigor con la publicación en el Diario Oficial, prevista antes del 2 de agosto de 2026. El alto riesgo integrado en productos del anexo I se sitúa en el 2 de agosto de 2028.

Cómo ayuda Confir

Confir traslada el plan de vigilancia poscomercialización a la sección 9 de tu documentación técnica del anexo IV y vincula cada sistema de alto riesgo con sus plazos de notificación del artículo 73. El motor de síntesis es determinista y basado en reglas —sin inferencia de modelos, sin alucinaciones—, de modo que los mismos insumos producen el mismo plan estructurado cada vez, que es lo que hace que el resultado sea defendible ante una auditoría. La sección del plan se entrega preestructurada según los requisitos del artículo 72 y lista para alinearse con la plantilla de la Comisión una vez emitida.

Preguntas frecuentes

¿Cuál es la diferencia entre un sistema de vigilancia poscomercialización y el plan de vigilancia?

El sistema es la capacidad operativa —las personas, los flujos de datos y el análisis que un proveedor ejecuta de forma continua conforme al artículo 72(1)-(2). El plan es la base documentada de ese sistema conforme al artículo 72(3): indica las métricas, los umbrales, las fuentes de datos, la cadencia, la responsabilidad y las vías de escalado. El plan es lo que lee un auditor; el sistema es lo que produce los registros que prueban que el plan es real. El plan forma parte de la documentación técnica del anexo IV a través del artículo 11, así que se redacta antes del lanzamiento y se mantiene actualizado mientras el sistema opera.

¿Qué métricas pertenecen a un plan de vigilancia poscomercialización del artículo 72?

No hay una lista legal fija: las métricas deben rastrearse hasta la finalidad prevista del sistema y las afirmaciones de rendimiento, solidez y ciberseguridad documentadas conforme al artículo 15 y el anexo IV. Para una herramienta de selección de personal del anexo III, punto 4(a), eso significa paridad de la tasa de selección, tasas de aceptación de recomendaciones y de revocación de recursos, y exactitud frente a los resultados de contratación. Para una herramienta de solvencia crediticia del anexo III, punto 5(b), significa tasas de impago por cohorte de aprobación y disparidad de la tasa de aprobación por categoría de solicitante. Haz seguimiento de la deriva y el rendimiento dispar; los datos agregados por categoría suelen bastar y evitan una huella de RGPD más pesada.

¿Cómo fijo los umbrales en el plan?

Parte de la línea de base que tu evaluación de riesgos del artículo 9 usó para concluir que el riesgo residual era aceptable en la evaluación de la conformidad. Después define dos bandas. Un umbral de alerta interno desencadena un análisis más detallado y una revisión documentada. Un umbral de escalado indica que el sistema puede haber dejado de ser conforme o que un hallazgo podría ser un incidente grave. La banda de escalado es lo que conecta el plan con la notificación del artículo 73 y la acción correctiva del artículo 20. Registra el razonamiento de cada umbral para que sea defendible en lugar de arbitrario.

¿Cómo se conecta el plan con la notificación de incidentes del artículo 73?

El plan debe predefinir el umbral interno a partir del cual un hallazgo de vigilancia se convierte en un posible incidente grave que exige notificación externa. Una vez rebasado ese umbral y en cuanto el proveedor tenga conocimiento, corren los plazos del artículo 73: a más tardar 15 días por defecto, 10 días cuando el incidente haya causado un fallecimiento y 2 días ante una infracción generalizada o una perturbación grave e irreversible de infraestructuras críticas. Un sistema operativo del artículo 72 también ayuda a establecer cuándo el proveedor «tuvo conocimiento», que es el momento en que arranca el reloj de la notificación.

¿Qué ocurre después de que la vigilancia detecte un problema; basta con notificar?

No. Notificar conforme al artículo 73 y corregir conforme al artículo 20 son pasos distintos. Si la vigilancia muestra que el sistema de alto riesgo no es conforme, el artículo 20 exige al proveedor adoptar una acción correctiva —ponerlo en conformidad, retirarlo, desactivarlo o recuperarlo— e informar a los distribuidores, los responsables del despliegue, el representante autorizado y los importadores. El plan debe nombrar quién desencadena la acción correctiva y cómo. Los hallazgos también retroalimentan la evaluación de riesgos del artículo 9 y cualquier actualización necesaria del anexo IV, cerrando el bucle que los auditores siguen.

¿Quién es dueño del plan de vigilancia poscomercialización, y puede construirlo un responsable del despliegue?

El proveedor es su dueño: el actor que desarrolla o introduce el sistema de alto riesgo en el mercado bajo su propio nombre o marca comercial (artículo 16). Los responsables del despliegue son una fuente de datos conforme al artículo 26: usan el sistema según sus instrucciones, conservan logs y notifican incidentes al proveedor, pero no diseñan ni ejecutan el sistema de vigilancia. La línea puede moverse: un responsable del despliegue que cambie la marca o modifique sustancialmente el sistema se convierte en proveedor conforme al artículo 25 y hereda el deber del artículo 72. Dentro del plan, nombra a un único responsable rendidor de cuentas y una vía de decisión escrita.

¿Cuándo debe estar listo el plan, y cuál es la sanción por no tener uno?

El plan debe formar parte de la documentación técnica del anexo IV en la evaluación de la conformidad, antes de introducir el sistema en el mercado: no puedes lanzar primero y redactarlo después. Los sistemas autónomos de alto riesgo del anexo III se rigen por el 2 de diciembre de 2027, la fecha del Ómnibus Digital, ya adoptado (Parlamento Europeo, 16 de junio de 2026; Consejo, 29 de junio de 2026; entrada en vigor con la publicación en el Diario Oficial, prevista antes del 2 de agosto de 2026). No establecer ni documentar el sistema se sanciona conforme al artículo 99(4) con hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial, la cifra que sea más alta; para las pymes, el artículo 99(6) aplica la cifra inferior.

Guías relacionadas

Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar

Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.

Empieza la prueba gratuita →