El artículo 72 define el bucle, pero tus paneles no lo cierran

Qué dice exactamente el artículo 72

El artículo 72 del Reglamento (UE) 2024/1689 está en el capítulo de vigilancia poscomercialización y regula qué obligaciones tienen los proveedores de sistemas de IA de alto riesgo desde que el sistema sale al mercado, pasadas ya la evaluación de la conformidad y el marcado CE, y mientras siga en él. Tiene cuatro apartados, y cada uno describe una pieza de un bucle.

El apartado 1 impone la obligación. Los proveedores establecerán y documentarán un sistema de vigilancia poscomercialización proporcionado a la naturaleza de las tecnologías de IA y a los riesgos en juego. Fíjate en documentarán. Lo que se entrega es un sistema documentado, y la simple costumbre de monitorizar no vale. Tiene que poder leerlo una autoridad de vigilancia del mercado, o un organismo notificado si interviene alguno.

El apartado 2 es el motor. El sistema recopilará, documentará y analizará de manera activa y sistemática los datos pertinentes sobre el funcionamiento durante toda la vida útil del sistema, una vida útil que no se acaba en las pruebas de aceptación ni en la última auditoría. Y hay una frase sobre la que gira la mayor parte de esta entrada: «Cuando proceda, la vigilancia poscomercialización incluirá un análisis de la interacción con otros sistemas de IA». En un sistema multiagente procede por definición. La ley recoge el caso multiagente de forma expresa, sin que haga falta deducirlo.

El apartado 3 establece que el sistema se basa en un plan, que a su vez forma parte de la documentación técnica del anexo IV. La Comisión tenía que dar a los proveedores un modelo para ese plan en un acto de ejecución, a más tardar el 2 de febrero de 2026. Quédate con esa fecha, porque más adelante cuento qué fue de ese acto.

El apartado 4 es la cláusula de reutilización. Los proveedores cuyo producto está sujeto a la legislación del anexo I, sección A (productos sanitarios, máquinas) y que ya tienen un sistema y un plan de vigilancia poscomercialización con arreglo a ella pueden integrar en ellos los elementos que piden los apartados anteriores, siempre que la protección sea equivalente. Las entidades financieras pueden hacer lo mismo con sus sistemas del anexo III, punto 5, como los de calificación crediticia.

Entre los cuatro apartados describen un bucle en el que se recopila, se analiza, se documenta en un plan y el resultado vuelve a alimentar el proceso.

Qué se monitoriza hoy en la práctica

Ese es el bucle que describe la ley. Las herramientas de monitorización que un equipo usa de verdad abarcan menos, y el resto de esta entrada trata de esa distancia. La mayoría caben en cuatro grupos, y cada uno responde a una pregunta real.

Detección de deriva. Herramientas como Evidently y NannyML observan las distribuciones de entrada y de salida y avisan cuando cambian. Como no necesita etiquetas, la detección de deriva es lo primero que montan los equipos. Capta justo aquello para lo que está pensada: que los datos de hoy ya no se parecen a los que se usaron para entrenar el modelo.

Métricas por segmento. Desglosan el rendimiento por cohorte, por región o por tipo de entrada y sacan a la luz degradaciones que una cifra agregada esconde. Son útiles y se usan poco.

Plataformas de observabilidad. Con Prometheus, Grafana u OpenTelemetry se miden la latencia, la tasa de errores, el throughput y el coste por petición. Son la columna vertebral de la operación, están maduras y responden a si el sistema está en marcha y a cuánto cuesta mantenerlo así.

Trazas. Registran lo que ha hecho el agente, con un span por cada paso y por cada llamada a una herramienta. Son el grupo más nuevo de los cuatro y el menos asentado.

Las cuatro categorías son legítimas, pero ninguna responde a la pregunta que hace el artículo 72. El desajuste se ve en tres cosas.

La primera es que las cuatro son operativas y ninguna mide el cumplimiento. Te dicen que el sistema está sano, pero no si en uso real se mantiene el nivel adecuado de precisión, solidez y ciberseguridad que los apartados 1 y 3 del artículo 15 te obligan a alcanzar y a declarar. Sano y conforme son afirmaciones distintas, y solo una de ellas está en la ley.

La segunda, que nada relaciona una señal con los artículos. Cuando salta una alerta de deriva, ni una persona ni una herramienta la conectan con el nivel adecuado que el artículo 15, apartado 3, te obliga a declarar, ni con una línea del registro de riesgos del artículo 9. La señal existe, pero falta la correspondencia.

La tercera, que la cláusula de interacción no tiene esquema. Un análisis de la interacción con otros sistemas de IA da por hecho que sabes decir qué sistema influyó en cuál. OpenTelemetry está construyendo spans de agente y multiagente justo para eso, pero las convenciones GenAI siguen marcadas como Development: son un borrador y todavía no un estándar. La cláusula ya está en la ley, mientras que el esquema para cumplirla aún no está terminado.

El mapa del bucle

El gráfico pone seis requisitos, derivados del artículo 72 y de los artículos conexos, frente a lo que ofrecen hoy las herramientas de monitorización.

Hay dos huecos claros. Los demás requisitos se cubren en parte: de todos hay alguna pieza, pero ninguno está completo.

Dónde se quedan cortas las herramientas

La distancia entre el artículo y las herramientas es mayor en cuatro puntos.

Señales de cumplimiento frente a métricas de operaciones. Una alerta de deriva es un evento de operaciones, y solo pasa a ser un evento de cumplimiento cuando alguien la relaciona con el nivel adecuado que el artículo 15, apartado 3, te obliga a declarar y deja constancia de ese juicio en el sistema de gestión de riesgos del artículo 9. Ese paso se hace a mano, o no se hace. Las herramientas hablan el idioma del SRE (latencia, saturación, tasa de errores) y el artículo habla otro, el de la precisión, la solidez y la ciberseguridad mantenidas durante todo el ciclo de vida. Nada traduce automáticamente de un idioma al otro.

El plan es un documento, y un panel no lo sustituye. El apartado 3 pide un plan de vigilancia poscomercialización versionado y fechado, que esté en la documentación técnica del anexo IV y que lea una autoridad de vigilancia del mercado. Un panel de Grafana no cumple nada de eso. Va en directo, es efímero y lo mira un ingeniero a las tres de la madrugada. Los dos son útiles, pero no son lo mismo. Tener el segundo no te exime de la obligación de elaborar el primero.

Causalidad entre sistemas. Es la cláusula a la que dije que volvería. En la entrada sobre el artículo 15 señalé la coordinación multiagente como el hueco al que las herramientas aún no habían llegado. El artículo 72, apartado 2, lo menciona sin rodeos al pedir que, cuando proceda, se analice la interacción con otros sistemas de IA. Para eso tienes que poder decir qué salida de un sistema condicionó la siguiente acción de otro, es decir, establecer causalidad a través de una frontera en la que no hay observabilidad. Pongamos que un agente de triaje rebaja la prioridad de un caso porque un agente de recuperación le ha pasado un documento desfasado. La salida parece normal y la métrica sigue en verde, pero nada deja constancia de que el agente de triaje decidió así por la respuesta del de recuperación. Multiplícalo por una flota de agentes que se llaman entre sí, y la interacción deja de ser algo que puedas auditar a posteriori. Lo más parecido a un esquema son los spans de agente de OpenTelemetry, que siguen en desarrollo. Hasta que estén terminados, la interacción con otros sistemas de IA es una obligación que puedes poner por escrito pero todavía no medir.

Cerrar el bucle con el artículo 9. Una monitorización que nunca actualiza el registro de riesgos deja el bucle abierto. El artículo 72 alimenta el artículo 9 (el sistema de gestión de riesgos, que abarca todo el ciclo de vida), y los dos forman una sola disciplina. Las herramientas llegan hasta el panel y ahí se paran, pero el artículo espera que la señal del panel cambie el registro de riesgos, el plan de pruebas y la próxima versión. Ese último salto, de la observación a una acción que queda registrada en la documentación, es el que ninguna herramienta da por ti.

El acto de ejecución que no llegó

El único apoyo oficial que el artículo daba a los proveedores para el plan era un modelo. El apartado 3 encargaba a la Comisión adoptar, a más tardar el 2 de febrero de 2026, un acto de ejecución con un modelo estándar de plan de vigilancia poscomercialización.

No llegó en esos términos. El Reglamento ómnibus digital sobre IA, el paquete de simplificación que propone la propia Comisión, le quitaría la facultad de adoptar ese modelo obligatorio. La vigilancia poscomercialización sigue siendo obligatoria, pero el modelo pasaría a ser una guía voluntaria, prevista para el 2 de septiembre de 2027 a más tardar. El Parlamento y el Consejo alcanzaron un acuerdo provisional sobre el paquete el 7 de mayo de 2026, aunque todavía no se ha adoptado formalmente. Su adopción se espera antes del 2 de agosto de 2026, y hasta entonces nada de esto es vinculante.

Así que la fecha ha pasado, y el único documento normalizado que te habría dicho cómo es un plan conforme se quedaría en una guía. El plan lo escribes de todos modos, sin modelo, para cumplir una obligación que no ha desaparecido.

También cambiaría el calendario. El mismo paquete aplazaría del 2 de agosto de 2026 al 2 de diciembre de 2027 las obligaciones de alto riesgo para los sistemas del anexo III. Sería un respiro de verdad, aunque no te libraría del trabajo. El sistema de vigilancia tiene que existir igualmente, y construirlo bien se come la mayor parte del tiempo que gana el aplazamiento. Como con todo lo que aún se mueve en este Reglamento, planifica con la ley tal como está hoy, sin contar con la versión que esperas que llegue.

Hay un plazo que no se ha movido, el de dar la alarma. El aplazamiento cambiaría cuándo empieza a apretar el artículo 73, pero no la rapidez con que aprieta. Cuando las obligaciones de alto riesgo se apliquen a tu sistema, el artículo 73 exige notificar un incidente grave en un plazo de 15 días desde que se tiene conocimiento de él, que baja a 10 días si ha fallecido una persona y a 2 en caso de infracción generalizada o de alteración grave e irreversible de infraestructuras críticas. Esos plazos corren tanto si tu monitorización ha detectado el incidente como si no. Un sistema de vigilancia poscomercialización que no puede detectar y escalar dentro de esos plazos no pasa de ser un panel con una etiqueta de cumplimiento.

Qué hacer mientras tanto

Puedes dar cuatro pasos desde ahora, sin esperar a ninguna guía, modelo de plan ni norma armonizada.

Escribe el plan ya y toma prestado un modelo que exista. No va a llegar ningún modelo oficial en los términos originales, pero tampoco necesitas el de la Comisión. La normativa de productos sanitarios lleva años aplicando el seguimiento poscomercialización. Su estructura de plan (el plan de seguimiento poscomercialización del MDR y del IVDR) es el equivalente más maduro y encaja bien con el artículo 72. Parte de ahí, convierte el plan en un documento versionado dentro de la documentación técnica y revísalo cada vez que cambien el modelo de IA, el prompt o las dependencias.

Instrumenta con las convenciones GenAI de OpenTelemetry, aunque estén en borrador. No están terminadas, pero ya definen spans para las operaciones de modelos y de agentes, que es lo más parecido a un esquema para la cláusula de interacción. Si las adoptas ahora, cuando las convenciones se estabilicen tus trazas entre sistemas ya existirán y no tendrás que empezar de cero ese día.

Prepara el protocolo de respuesta a incidentes según los plazos del artículo 73. Encadena detección, triaje y notificación para que los plazos de 15, 10 y 2 días se conviertan en procedimientos que se puedan ejecutar y dejen de ser párrafos de una política que nadie ha probado. Ensáyalo una vez antes de necesitarlo.

Construye el canal de retroalimentación desde el responsable del despliegue. Si eres el proveedor, la mitad de tus datos de vigilancia los tiene el responsable del despliegue, al que el artículo 26 obliga a vigilar el funcionamiento del sistema, conservar los archivos de registro durante al menos seis meses y avisarte cuando algo no cuadre. Esa señal es la que cierra tu bucle, pero solo si hay un canal por el que pueda llegar y un sitio en el registro de riesgos donde quede anotada. Hacen falta los dos.

Nada de esto exige que exista el modelo de plan. La obligación consiste en mantener un bucle en marcha: observar el sistema en uso real, analizar lo que ves, escribirlo en un plan y dejar que eso cambie la próxima versión. Las herramientas te dan la observación, y el resto es ingeniería que te toca a ti.

Una monitorización que nunca actualiza el registro de riesgos deja el bucle abierto. El artículo 72 ha definido el bucle y el ecosistema ha construido la instrumentación. Cerrarlo es el trabajo que queda.