El artículo 15 ya fija los requisitos, pero las herramientas van por detrás

Qué dice exactamente el artículo 15

El artículo 15 del Reglamento (UE) 2024/1689 se titula Precisión, solidez y ciberseguridad y regula lo que deben lograr los sistemas de IA de alto riesgo y lo que tienen que demostrar los proveedores. Tiene cinco apartados, y cada uno dice algo concreto.

El apartado 1 da el marco general. Pide que los sistemas de IA de alto riesgo alcancen un nivel adecuado de precisión, solidez y ciberseguridad y «funcionen de manera uniforme en esos sentidos durante todo su ciclo de vida». Merece la pena leer dos veces la cláusula del ciclo de vida. Para el artículo no basta con aprobar un benchmark el primer día: hace falta mantener el rendimiento mientras el sistema siga en servicio. Es una diferencia importante que la mayor parte de la infraestructura de evaluación pasa por alto.

«Nivel adecuado» es un criterio cualitativo. Como el artículo no fija umbrales numéricos, es el proveedor quien justifica en la documentación técnica (anexo IV) qué es adecuado para la finalidad prevista del sistema. Lo que se entrega es precisamente esa justificación.

El apartado 2 parte de que las metodologías para medir la precisión y la solidez aún no existen a gran escala, y encarga a la Comisión que fomente, en cooperación con las autoridades de metrología y de evaluación comparativa, el desarrollo de parámetros de referencia (benchmarks) y metodologías de medición. El propio artículo reconoce el hueco.

El apartado 3 exige indicar en las instrucciones de uso los niveles reales de precisión y los parámetros pertinentes para medirla, es decir, las métricas. En eso se apoya la transparencia, en saber qué precisión has conseguido y con qué métricas. El artículo 13, apartado 3, letra b), inciso ii), extiende esa obligación a la solidez y la ciberseguridad.

El apartado 4 se ocupa de la solidez y del comportamiento después del despliegue. Los sistemas de IA de alto riesgo deben ser lo más resistentes posible a los errores, fallos e incoherencias, y contar con medidas técnicas y organizativas para ello. Si un sistema sigue aprendiendo tras el despliegue, el artículo exige que los bucles de retroalimentación (resultados sesgados que influyen en las entradas futuras) se aborden con medidas de reducción de riesgos. Es la cláusula del aprendizaje en línea, recogida de forma explícita en el Reglamento. Entran en este apartado los sistemas de alto riesgo que ajustan el modelo en producción, y se puede defender que también los que usan las interacciones de los usuarios para moldear su comportamiento futuro, tanto si quienes los construyen los consideran «sistemas del Reglamento de IA» como si no.

El apartado 5 trata de la ciberseguridad, y es ahí donde el artículo entra en detalles técnicos. Los sistemas de IA de alto riesgo deben resistir los intentos no autorizados de alterar su uso, sus resultados de salida o su funcionamiento. El artículo enumera cinco vulnerabilidades específicas de la IA (cuatro clases de ataque más los defectos en el modelo) que el proveedor debe, según corresponda, prevenir, detectar, combatir, resolver y controlar:

1. Envenenamiento de datos del conjunto de entrenamiento
2. Envenenamiento de modelos en los componentes preentrenados
3. Ejemplos adversarios / evasión de modelos en la inferencia
4. Ataques a la confidencialidad
5. Defectos en el modelo

Son cinco categorías y figuran en el propio texto de la ley.

Qué se prueba hoy en la práctica

Si pones los cinco apartados del artículo 15 al lado de las herramientas de evaluación actuales, enseguida ves que las categorías no encajan.

La mayoría de esas herramientas caben en cuatro grupos, y cada uno cubre una parte distinta de lo que recoge el artículo.

Los benchmarks de inyección de prompts y de jailbreak comprueban si se puede conseguir que el modelo se salte sus instrucciones de seguridad o que anteponga las instrucciones de un atacante a las del desarrollador. Exploran lo que el artículo llama ejemplos adversarios y evasión de modelos, sobre todo en la frontera del modelo y de forma puntual. No cubren el requisito del ciclo de vida, y solo las baterías más recientes, pensadas para agentes, prueban qué pasa cuando al modelo se le añaden llamadas a herramientas y memoria.

Los benchmarks de capacidades miden lo que el modelo sabe y puede hacer en distintos dominios, normalmente con preguntas de opción múltiple o de respuesta abierta. Sirven como una pieza más para justificar la precisión que pide el apartado 1, pero por sí solos no bastan como prueba de solidez ni de ciberseguridad. Con saber que el modelo contesta a una pregunta no se llega a lo que exige el artículo.

El red teaming de seguridad consiste en generar escenarios adversarios, a menudo a mano o casi, y cubre en parte la vertiente de ciberseguridad del apartado 5. Lo que abarca depende de la imaginación del red team, sin un recorrido sistemático por las cinco vulnerabilidades que enumera la ley. Dos organizaciones que hacen red teaming del mismo sistema rara vez llegan a la misma cobertura.

Los guardrails en tiempo de ejecución y el filtrado de salidas actúan al atender cada petición, fuera de la fase de pruebas. Son una defensa de la fase de despliegue y ayudan a justificar el cumplimiento del apartado 4, pero no son pruebas. Limitan lo que hace el sistema en producción, y el rendimiento a lo largo del ciclo de vida es otra cuestión.

De este mapa salen tres observaciones.

La primera es que todas las categorías trabajan sobre todo en la capa del modelo. La cobertura para agentes está en pañales (desde mediados de 2024 han aparecido benchmarks como AgentDojo, AgentHarm y Agent Security Bench), y los pipelines de evaluación habituales todavía no la han incorporado. El nivel adecuado de precisión, solidez y ciberseguridad del artículo se aplica al sistema de IA de alto riesgo en su conjunto, mientras que las herramientas miden solo un fragmento.

La segunda, que todas son actividades puntuales. Pasas un benchmark de jailbreak antes de sacar una versión, la publicas y en la siguiente ya no lo relanzas porque las pruebas de regresión salen demasiado caras. Ninguna de estas categorías acredita un funcionamiento uniforme durante todo el ciclo de vida. Lo que dan es una instantánea, y una instantánea no es lo que pide el apartado 1.

La tercera, que las vulnerabilidades del apartado 5 no están cubiertas por igual. De los ejemplos adversarios y la evasión de modelos se ocupan bien los benchmarks de inyección de prompts. El envenenamiento de datos y el de modelos tienen cada vez más cobertura durante el entrenamiento, aunque menos cuando el sistema ya está desplegado y entra en juego el fine-tuning incremental. Para los ataques a la confidencialidad existen herramientas en la capa del modelo (inferencia de pertenencia y extracción en el Adversarial Robustness Toolbox de IBM, sondas de reproducción de datos de entrenamiento en garak), pero hay poca cobertura en la del sistema, por ejemplo para la exfiltración a través de herramientas o las fugas entre agentes. Los defectos en el modelo, por último, quedan casi sin cubrir con las herramientas actuales.

El artículo 15 dice qué hay que probar, y el ecosistema solo prueba una parte. Dónde se queda corto lo explico a continuación.

Dónde se quedan cortas las herramientas

Hay otros huecos, pero en estos cuatro es donde más se separa lo que exige el artículo de lo que prueba hoy el ecosistema.

Solidez frente a ataques, también en la capa del agente. El apartado 5 enumera vectores de ataque que los benchmarks actuales abordan en la capa del modelo, como los ejemplos adversarios o la evasión de modelos en la inferencia y el envenenamiento de datos durante el entrenamiento. Con agentes, esa frontera se amplía. La selección de herramientas, la construcción del plan, la memoria y la comunicación entre sistemas son superficies por las que una entrada adversaria puede moldear el comportamiento sin que al modelo le llegue nunca nada que parezca un ataque. Una salida de herramienta manipulada que influye en el siguiente paso del plan es una entrada adversaria en la capa del agente, y lo mismo vale para una entrada de memoria envenenada que sesga las decisiones futuras. El artículo 15 está redactado pensando en el sistema, pero las herramientas trabajan sobre todo con el modelo.

De la prueba puntual al ciclo de vida. El apartado 1 pide un funcionamiento uniforme durante todo el ciclo de vida del sistema. Las herramientas, en cambio, producen instantáneas, como los benchmarks antes de publicar una versión, los relanzamientos ocasionales o los ejercicios de red team ad hoc. Ninguna de ellas acredita el comportamiento a lo largo del ciclo de vida. Una instantánea de hace seis meses no demuestra nada si desde entonces se ha sustituido el modelo, se ha retocado la plantilla del prompt o un servicio aguas abajo ha cambiado la API. El ecosistema aún no ha construido la infraestructura de tests de regresión que permitiría comprobar el apartado 1 en cada versión, frente a cada cambio y mientras el sistema siga en marcha.

Recuperación ante fallos. El apartado 4 exige resistencia y admite como vía para lograrla la redundancia técnica y los planes de prevención contra fallos. Sin embargo, casi ningún harness de evaluación prueba hoy qué hace el sistema cuando algo falla, como recuperarse de una llamada fallida a una herramienta, recurrir a un respaldo cuando la confianza del modelo es baja o degradarse de forma controlada cuando un servicio aguas arriba está caído. Son propiedades operativas del sistema y también las que menciona el apartado 4. Las herramientas tratan el éxito como el caso normal y pasan por alto los modos de fallo que le importan al artículo. De un sistema que nunca se ha probado en condiciones de fallo no se puede afirmar que sea resistente.

Coordinación multiagente. El requisito de resistencia del apartado 4, que menciona los errores derivados de la interacción con otros sistemas, y el vector de ataques a la confidencialidad que recoge el apartado 5 pesan todavía más cuando el sistema se compone de varios agentes que se pasan salidas entre sí. Si además los agentes siguen aprendiendo, se suma la cláusula de los bucles de retroalimentación del apartado 4. Los fallos en cascada (cuando la salida de un agente se convierte en la entrada de otro sin observabilidad entre ellos) empiezan a preocupar en la literatura académica, y las herramientas actuales rara vez los prueban. Volveré sobre este hueco en otras entradas. Aquí me basta con señalar que las cláusulas del artículo ya cubren el caso multiagente y que las herramientas no se han puesto al día.

Las normas armonizadas podrían cerrar parte de estos huecos, pero todavía no están listas.

Normas armonizadas aún en redacción

Las normas armonizadas desarrollan el detalle técnico de lo que pide el Reglamento. Cumplir una de ellas da presunción de conformidad con el requisito correspondiente. Sin una norma publicada, el proveedor tiene que demostrar el cumplimiento por su cuenta, y eso cuesta más, tarda más y se presta más a discusión.

En mayo de 2026 el panorama es bastante peor de lo que da a entender el discurso en torno al Reglamento. Ni una sola norma armonizada del Reglamento de IA tiene publicada su referencia en el Diario Oficial de la Unión Europea (DOUE).

El borrador más avanzado de CEN-CENELEC JTC 21, prEN 18286 (Quality Management System), no superó en enero de 2026 la votación de la encuesta pública (Enquiry), y en abril, con los comentarios ya resueltos, estaba listo para el voto formal. Y esa es la norma de procedimiento.

Las normas técnicas pertinentes para el artículo 15 (precisión y solidez, ciberseguridad) van más retrasadas, y ninguna de las dos ha llegado todavía a la encuesta pública.

Aun con el procedimiento acelerado de JTC 21, la publicación está prevista para el cuarto trimestre de 2026. La referencia en el DOUE es un paso aparte, así que, siendo realistas, las normas que afectan al artículo 15 no llegarán antes de mediados o finales de 2027.

La Comisión ya se ha dado cuenta. El 19 de noviembre de 2025 propuso el Reglamento ómnibus digital sobre IA, que liga la aplicación de las obligaciones de alto riesgo a que haya normas técnicas disponibles, con fechas tope en diciembre de 2027 y agosto de 2028. Mientras escribo esto, la propuesta está en fase de trílogos. Hasta que se adopte, la fecha legal de aplicación de las obligaciones de alto riesgo sigue siendo el 2 de agosto de 2026 para los sistemas del anexo III (el 2 de agosto de 2027 para los del anexo I). Planifica con la fecha que fija hoy la ley, aunque esperes otra.

Qué hacer mientras tanto

Hay cuatro cosas que puedes hacer sin esperar a las normas armonizadas. Lo que sigue da por hecho que eres el proveedor, es decir, el ingeniero que construye un sistema de IA de alto riesgo y no el equipo que lo usa. Los requisitos de la sección 2 (artículos 8 a 15) se aplican a los proveedores. Los responsables del despliegue, por su parte, tienen su propia lista de obligaciones en el artículo 26.

Documenta lo que pruebas, lo que dejas sin probar y por qué. El artículo 15, apartado 1, exige un nivel adecuado de precisión, solidez y ciberseguridad, y ese nivel es cualitativo, depende del contexto y se justifica sistema a sistema. Lo que se entrega es la justificación. El artículo 11, a través del anexo IV, punto 2, letra g), deja claro que los archivos de registro y los informes de las pruebas, fechados y firmados, son parte obligatoria de esa documentación técnica. Escribe qué mides, qué umbral has superado, qué has decidido no probar y con qué razonamiento técnico. Una autoridad de vigilancia del mercado puede exigir esa documentación, y en algunos casos (biometría, productos del anexo I) la evalúa un organismo notificado. Escríbela pensando en que alguien la va a leer línea a línea.

Lleva un registro de riesgos continuo, porque una auditoría puntual no basta. El artículo 9 exige un sistema de gestión de riesgos que funcione de forma iterativa durante todo el ciclo de vida del sistema, y el artículo 72, una vigilancia poscomercialización. Trátalos como una sola disciplina. El registro de riesgos se actualiza cada vez que cambia algo, sea el modelo, la plantilla del prompt, una herramienta o una dependencia. Una auditoría de riesgos que se hace una sola vez, en la aceptación, no es lo que pide el artículo.

Empieza por las cinco vulnerabilidades que enumera el apartado 5. Monta primero la cobertura de red team sobre esa lista: envenenamiento de datos, envenenamiento de modelos, ejemplos adversarios o evasión de modelos, ataques a la confidencialidad y defectos en el modelo. Asegura lo que fija la ley antes de pasar a amenazas afines. La lista del artículo marca por dónde empezar y no pone ningún techo.

Diversifica las herramientas de pruebas. Las normas aún se están redactando, la oferta comercial cambiará y los métodos madurarán. Un harness de pruebas atado a una sola batería de benchmarks o a una sola empresa es un riesgo en sí mismo, y el motivo principal tiene poco que ver con el cumplimiento normativo: en los próximos tres años los cambios van a reordenar el panorama. La infraestructura debería sobrevivir a esa reordenación.

Ese es el trabajo de ingeniería que de verdad exige el artículo.

Si ya has empezado con esto, me gustaría saber qué has encontrado. El hueco entre lo que exige el artículo 15 y lo que ofrece hoy el ecosistema es tan grande que ningún equipo le saca mucha ventaja a otro. Los métodos que acabarán inspirando las normas armonizadas se están construyendo ahora mismo en los equipos que no se quedan esperando.