Vigilancia poscomercialización de IA: cómo convertir señales de uso en controles verificables

Qué exige la vigilancia poscomercialización

La vigilancia poscomercialización es el sistema mediante el cual el proveedor recoge y analiza información relevante sobre el rendimiento de un sistema de IA de alto riesgo una vez que está en el mercado o en servicio. Su propósito no es acumular registros por sí mismos: es permitir que el proveedor compruebe si el sistema sigue cumpliendo los requisitos aplicables y si han aparecido problemas que requieren investigación o actuación.

El artículo 72 del Reglamento de IA atribuye al proveedor la responsabilidad de establecer y documentar ese sistema. Debe ser proporcionado a la naturaleza de la tecnología y a los riesgos del sistema. El proveedor también debe disponer de un plan de vigilancia poscomercialización como parte de la documentación técnica. En la práctica, el plan explica cómo se obtendrán y analizarán los datos, qué señales pueden revelar una desviación y cómo se decidirá si hay que intervenir.

La obligación se refiere a los sistemas de IA de alto riesgo. No significa que todos los proveedores deban vigilar cualquier producto con la misma intensidad ni que tengan que recoger todos los datos disponibles. La proporcionalidad importa: las fuentes, indicadores y frecuencia de revisión deben tener una relación razonable con el uso previsto, el contexto de despliegue y los riesgos que el sistema puede generar.

Conviene separar dos planos. El requisito legal es disponer de un sistema y un plan adecuados y documentados. Los indicadores, umbrales y rutinas que se proponen en esta guía son opciones de diseño para hacer operativa esa obligación; no son una lista universal impuesta por el Reglamento.

Qué observar y de dónde pueden proceder los datos

El Reglamento contempla datos relevantes aportados por los responsables del despliegue y datos obtenidos por otras fuentes. Esto deja margen para que cada proveedor diseñe un sistema ajustado a su producto, pero no elimina la necesidad de justificar por qué una fuente es pertinente ni cómo se interpretará. Los datos deben servir para evaluar el rendimiento del sistema durante su vida útil y detectar cambios que puedan afectar al cumplimiento o a los riesgos.

Un inventario inicial puede incluir métricas de funcionamiento, resultados anómalos, incidencias técnicas, reclamaciones, comentarios estructurados de usuarios, solicitudes de asistencia y cambios en las condiciones de uso. Según el sistema, también puede ser relevante observar cambios en la población usuaria, en los datos de entrada o en los procesos con los que el sistema se integra. No todas estas señales son obligatorias para todos los casos: su utilidad depende del contexto y del riesgo que se pretende vigilar.

La interacción con otros sistemas de IA merece atención cuando resulte pertinente para comprender el rendimiento o los riesgos. Por ejemplo, una herramienta puede recibir resultados de otro sistema o alimentar con sus salidas un proceso automatizado. En esos casos, un cambio en el sistema conectado, en el formato de los datos o en el flujo de trabajo puede alterar el comportamiento observado sin que haya cambiado el modelo vigilado. El plan debería indicar qué dependencias son relevantes y cómo se detectarán cambios en ellas.

La cooperación con el responsable del despliegue es importante porque el proveedor quizá no observe directamente todas las condiciones reales de uso. Un acuerdo operativo puede concretar qué categorías de datos se comparten, quién las prepara, con qué periodicidad, mediante qué canal y a quién se comunican las señales urgentes. Es una recomendación práctica: el Reglamento no convierte esa lista concreta en un formulario obligatorio. El intercambio debe limitarse a lo necesario para la finalidad de vigilancia y respetar las demás obligaciones aplicables.

Diseñar un plan que pueda aplicarse

Un plan operativo comienza con el uso previsto y los riesgos que el sistema puede plantear en ese contexto. A partir de ahí, identifica qué datos pueden mostrar un cambio relevante y qué decisiones podrían derivarse de ellos. Una tabla de métricas sin responsables, criterios de revisión ni vías de actuación es difícil de utilizar y ofrece poca claridad sobre cómo se gestionó una señal.

Es útil asignar responsabilidades diferenciadas. Un equipo técnico puede validar la calidad de los datos y analizar el comportamiento; producto puede valorar cambios en funciones o condiciones de uso; cumplimiento puede comprobar las obligaciones aplicables y la documentación; y una persona o equipo con autoridad definida puede decidir si corresponde escalar el caso. En organizaciones pequeñas, una misma persona puede cubrir varias funciones, pero las decisiones y sus fundamentos deben quedar identificables.

Los indicadores deben formularse de manera que permitan una revisión consistente. Pueden incluir tasas de error, indisponibilidad, cambios en la distribución de entradas, diferencias entre grupos relevantes para la evaluación del sistema o aumento de resultados que necesitan revisión humana. Un indicador solo es útil si se define cómo se calcula, qué periodo se observa y qué limitaciones tiene. No se debe presentar una métrica como prueba concluyente si únicamente constituye una señal para investigar.

El proveedor puede establecer niveles internos de alerta. Por ejemplo, un cambio por encima de un umbral acordado puede activar una revisión técnica; la repetición del cambio o su presencia en varios despliegues puede justificar una evaluación más amplia. Estos umbrales son herramientas de gestión recomendadas, no valores fijados de forma general por el artículo 72. Deben revisarse si cambia el uso, la evidencia disponible o el perfil de riesgo.

Investigar señales y dejar constancia de las decisiones

Una señal no equivale automáticamente a un incumplimiento. Puede deberse a datos incompletos, un cambio en el proceso del cliente, una incidencia temporal o una degradación real. La investigación debe distinguir estas posibilidades y registrar qué información se revisó. Si la señal afecta a varios despliegues, conviene comprobar si existe una causa común, como una versión concreta, una dependencia compartida o un cambio en las condiciones de entrada.

Un registro de decisiones útil incluye la fecha de detección, la fuente, el sistema y la versión afectados, la descripción de la señal, la persona responsable de la evaluación, la evidencia revisada, la conclusión y los pasos posteriores. Si no se adopta una medida, el registro debería explicar por qué la información disponible no justificaba actuar y qué condiciones harían reabrir el caso. Este nivel de detalle es una buena práctica documental, no un formato cerrado prescrito por el Reglamento.

Las medidas posibles dependen del hallazgo. Pueden consistir en corregir un defecto, actualizar instrucciones, modificar una integración, reforzar controles humanos, limitar temporalmente determinados usos o iniciar una revisión técnica más amplia. La elección debe guardar relación con el problema observado y quedar documentada. Si la señal sugiere que el sistema ya no satisface requisitos aplicables o que aparecen riesgos no considerados, el proveedor debe conectar el hallazgo con sus procesos de evaluación y gestión de riesgos, en lugar de tratarlo como una incidencia aislada de atención al cliente.

El responsable del despliegue también necesita saber qué información es importante para utilizar el sistema de forma adecuada y comunicar problemas relevantes. Por eso el plan debe prever un canal de escalado y un mecanismo para devolver información al proveedor. En productos con varios clientes, definir una vía consistente evita que señales similares queden dispersas en equipos de soporte distintos.

Vigilancia, gestión de riesgos, evaluaciones de impacto e incidentes

La vigilancia poscomercialización no sustituye a la gestión de riesgos. La gestión de riesgos es un proceso más amplio de identificación, análisis y tratamiento de riesgos que debe acompañar al sistema. La vigilancia aporta información de su funcionamiento real y puede revelar que una hipótesis anterior ya no se sostiene, que ha surgido un riesgo nuevo o que una medida de control no funciona como se esperaba. El plan debe permitir que esas señales lleguen a quienes pueden revisar las evaluaciones y las medidas existentes.

Tampoco es lo mismo que una evaluación de impacto previa al despliegue. Una evaluación previa examina posibles efectos en un contexto y antes de una utilización concreta, cuando resulte aplicable. La vigilancia observa información durante el ciclo de vida del sistema y ayuda a detectar cambios que solo se hacen visibles en uso. Son actividades complementarias: una no demuestra por sí sola que el sistema seguirá comportándose igual después del despliegue.

La notificación de incidentes graves prevista en el artículo 73 tiene otro desencadenante y otra finalidad: se refiere a incidentes que deben comunicarse conforme a las reglas aplicables. La vigilancia, en cambio, debe funcionar de forma sistemática y no esperar a que ocurra un incidente grave. Una señal puede justificar investigación y medidas preventivas aunque todavía no haya alcanzado el umbral de incidente notificable. Y, si se identifica un incidente que debe notificarse, el proceso de vigilancia no reemplaza la comunicación exigida.

Para evitar confusiones, las organizaciones pueden vincular los procesos sin fusionarlos: un mismo suceso puede abrir una investigación de vigilancia y, de manera separada, activar la evaluación de notificación de incidentes. El registro debería mostrar qué vía se consideró, quién tomó la decisión y qué acciones se iniciaron. Esta separación ayuda a no infravalorar una señal temprana ni a tratar cada desviación menor como si fuera automáticamente un incidente grave.

Casos específicos y calendario normativo

El artículo 72 establece una cautela específica para determinados sistemas de alto riesgo del ámbito de la aplicación de la ley: el sistema de vigilancia no abarca los datos operativos sensibles que obran en poder de las autoridades policiales. La exclusión es concreta. No debe interpretarse como una exención general de vigilancia para cualquier sistema utilizado por una autoridad ni como permiso para ignorar otras señales pertinentes que puedan tratarse conforme a las reglas aplicables.

La reforma normativa de 2026 modificó el apartado relativo a la orientación de la Comisión. El Reglamento prevé que la Comisión publique orientación y una plantilla voluntaria para el plan de vigilancia poscomercialización antes del 2 de septiembre de 2027. Por tanto, la plantilla no debe describirse como una herramienta ya disponible ni como un requisito obligatorio en sí mismo. Mientras no se publique, los proveedores pueden estructurar su documentación a partir de las obligaciones legales vigentes y de sus necesidades operativas.

El calendario de aplicación para los sistemas de alto riesgo también fue modificado. El texto consolidado establece fechas distintas según la categoría: para los sistemas de alto riesgo incluidos en el anexo III, la aplicación de las obligaciones pertinentes comienza el 2 de diciembre de 2027; para los sistemas de alto riesgo regulados por la legislación de armonización enumerada en el anexo I, comienza el 2 de agosto de 2028. La clasificación y la fecha aplicable deben comprobarse para cada sistema; no conviene extrapolar una fecha a todos los productos de IA.

Estas fechas no alteran el valor de preparar el ciclo de vigilancia con antelación. Diseñar fuentes, acuerdos de intercambio y responsables suele requerir coordinación entre proveedor y cliente. Sin embargo, la preparación operativa no debe confundirse con afirmar que una obligación ya es aplicable a un sistema concreto antes de la fecha que corresponda.

Lista de comprobación para revisar el plan

La prueba práctica de un plan no es su extensión, sino si permite reconstruir cómo se vigila el sistema y qué ocurre cuando aparece una señal. Las preguntas siguientes sirven para una revisión interna. No sustituyen el análisis jurídico del sistema, su clasificación o sus obligaciones particulares.

Un plan sólido identifica el sistema y sus usos relevantes, explica qué fuentes de información emplea y por qué, asigna responsables y define una rutina de análisis. También contempla cómo se comunican las señales entre proveedor y responsable del despliegue, cómo se conservan las decisiones y cómo se conectan los hallazgos con una revisión de riesgos o una medida correctora.

La revisión debería comprobar además si las métricas son interpretables, si las alertas conducen a acciones concretas y si el equipo puede distinguir una anomalía de datos de una degradación del sistema. Si un cambio de versión, una nueva integración o una modificación del contexto puede alterar el rendimiento, el plan debe indicar cómo se detectará y cómo se reexaminará la vigilancia.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.