La Ley de IA de la UE para ciberseguridad: por qué la IA de tu SOC normalmente no es de alto riesgo, y dónde está la exposición real
La detección de amenazas, el SOC y la IA antiphishing no suelen ser de alto riesgo. Dónde muerden de verdad el artículo 15 y el anexo III en seguridad.
Tu modelo de detección de amenazas casi con seguridad no es de alto riesgo. Tampoco lo es tu motor de triaje de alertas del SOC, tu clasificador de phishing ni tus reglas de correlación del SIEM, y ese es el punto de partida honesto que la mayoría de los equipos de ciberseguridad nunca escucha. La Ley de IA de la UE (Reglamento (UE) 2024/1689) es una regulación de tipo seguridad de productos con una lista cerrada de usos regulados, y las herramientas de seguridad defensiva no están en ella. La exposición real va en sentido contrario: el artículo 15 hace de la ciberseguridad un requisito obligatorio de cualquier IA de alto riesgo que tu organización construya. Esta página traza esa línea y las trampas que arrastran un sistema de «seguridad» al otro lado.
La IA de seguridad defensiva en su mayoría no es de alto riesgo: empieza por ahí
La suposición contraria está muy extendida y malgasta presupuesto. La detección de amenazas, la detección de anomalías de red y de endpoint, el triaje de alertas del SOC, la clasificación de phishing y de seguridad del correo, el triaje de vulnerabilidades y la correlación del SIEM no figuran en el anexo III, y no son componentes de seguridad de un producto del anexo I. Eso los sitúa en el nivel de riesgo mínimo: sin sistema de gestión de riesgos del artículo 9, sin expediente técnico del anexo IV, sin evaluación de la conformidad.
Los cuatro niveles de riesgo, aplicados a una pila de seguridad
La Ley de IA de la UE ordena los sistemas en cuatro niveles: prácticas prohibidas (artículo 5), alto riesgo (artículo 6 y anexo III), transparencia de riesgo limitado (artículo 50) y todo lo demás, riesgo mínimo. Es dirigida, no una regla general: no regula detectar malware, puntuar una alerta o correlacionar registros, así que una plataforma de SOC que ingiere telemetría y ordena incidentes no toca ninguno de los casos de uso regulados. Riesgo mínimo significa que hoy no se adhieren las obligaciones de los artículos 8 a 15: sin expediente de conformidad, sin marcado CE, sin organismo notificado, aunque la alfabetización en IA del artículo 4 sigue aplicándose a toda organización que ponga IA en operación.
Por qué la herramienta defensiva queda fuera del anexo III
El anexo III enumera ocho categorías: biometría, infraestructura crítica, educación, empleo, servicios esenciales, aplicación de la ley, migración y justicia. La analítica ordinaria de TI y de operaciones de seguridad no aparece en ninguna. Los redactores regularon la IA que decide cosas sobre las personas —quién es contratado, quién obtiene crédito, quién es vigilado—, no la IA que defiende una red. Tratar un clasificador de malware como un modelo de selección de alto riesgo es un exceso de cumplimiento que la Ley no pide.
Dónde la IA de seguridad puede cruzar al alto riesgo: las excepciones estrechas
Hay excepciones reales. Son estrechas, y dependen de la función, no de lo importante que sea el activo protegido.
La prueba del «componente de seguridad» según el anexo III, punto 2
El anexo III, punto 2 cubre la IA usada como componente de seguridad en la gestión y operación de infraestructura crítica: infraestructura digital crítica, tráfico rodado y el suministro de agua, gas, calefacción y electricidad. Una IA de seguridad puede caer aquí, pero solo cuando su fallo podría poner en peligro la salud, la seguridad o la integridad del servicio esencial de esa infraestructura. El listón es la función de componente de seguridad, no el prestigio del activo. Traza la distinción con nitidez: un SOC que defiende la TI corporativa de una empresa de aguas está protegiendo a una empresa importante, lo que en general no es anexo III, punto 2. La IA que gestiona la seguridad operativa del proceso de tratamiento, ordenando paradas o gobernando umbrales de dosificación peligrosos, es otra cosa. La página dedicada IA como componente de seguridad en infraestructura crítica (anexo III, punto 2) deriva esa mecánica.
Caso límite: respuesta autónoma que toca funciones de seguridad de OT
La vía del artículo 6(1) y el anexo I —IA como componente de seguridad de un producto con marcado CE que necesita evaluación de la conformidad por tercero— es en gran medida irrelevante para el software de SOC autónomo, que no va integrado en tal producto. La zona gris genuina es la respuesta autónoma que acciona físicamente un sistema de seguridad de OT, como un manual de SOAR que puede disparar un bucle de control industrial: eso amerita una evaluación caso por caso.
La exposición real: el artículo 15 hace de la ciberseguridad un requisito de cualquier IA de alto riesgo que construyas
La Ley muerde a tu equipo más a menudo no porque la IA de seguridad esté regulada, sino porque el artículo 15 hace de la ciberseguridad un requisito de diseño obligatorio de todo sistema de IA de alto riesgo que tu organización suministre, incluidos los sistemas construidos por otros equipos de la empresa.
Exactitud, solidez y ciberseguridad como un único deber combinado del artículo 15
El artículo 15 agrupa exactitud, solidez y ciberseguridad en una única obligación para los sistemas de alto riesgo. Así, cuando la empresa construye un cribador de selección del anexo III (anexo III, punto 4, letra a) o un modelo de solvencia (anexo III, punto 5, letra b), las funciones de seguridad y de AppSec asumen un deber de cumplimiento aunque no haya ningún producto de seguridad en el ámbito: deben endurecer, probar y documentar su resiliencia. Los requisitos de exactitud, solidez y ciberseguridad del artículo 15 caen de lleno sobre la mesa del CISO.
Las amenazas que el artículo 15 nombra, y quién posee la evidencia
El artículo 15 es inusualmente específico. Exige que los sistemas de alto riesgo sean resilientes frente a los intentos de alterar su uso, salidas o rendimiento explotando vulnerabilidades, y nombra las amenazas: envenenamiento de datos, envenenamiento de modelos, ejemplos adversarios (evasión) y ataques a la confidencialidad, exactamente la superficie de ataque que un equipo de seguridad está equipado para probar, medir y mitigar. El expediente de conformidad debe demostrar que esos requisitos se cumplieron, y los autores naturales de esa evidencia son las personas que ejecutaron las pruebas de solidez adversarial y las evaluaciones de resistencia al envenenamiento. Eso convierte a la organización de seguridad en una parte interesada de primer orden en la conformidad de la IA de alto riesgo, no en un espectador que recibe un ticket a toro pasado.
Solidez adversarial e inyección de instrucciones para la GPAI que despliegas
La mayoría de los equipos de seguridad encontrarán la Ley a través de IA de uso general integrada en sus propias herramientas, no de sistemas de alto riesgo a medida.
La inyección de instrucciones como problema de solidez del artículo 15
La inyección de instrucciones (prompt injection), los jailbreaks y la inyección indirecta a través de contenido recuperado son riesgos vivos de solidez adversarial. Cuando la GPAI afectada forma parte de un sistema de alto riesgo, la resiliencia frente a ellos se proyecta directamente sobre los deberes de solidez y ciberseguridad del artículo 15; para todo lo demás, siguen siendo diligencia de seguridad general. El manual de inyección de instrucciones y solidez adversarial lo trata como una clase de ataque, tal como lo encuadra el artículo 15.
Dónde el despliegue de GPAI crea obligaciones
Los modelos de IA de uso general llevan su propio régimen según los artículos 51 a 55, con deberes a nivel de modelo distintos de la pila de alto riesgo. Despliega GPAI dentro de un copiloto de seguridad y puedes heredar obligaciones por ese régimen, además de por el artículo 15 cuando el copiloto forma parte de un sistema de alto riesgo; trata el cumplimiento de proveedor de GPAI como algo que delimitar, no como una casilla resuelta. Por separado, si un producto de seguridad muestra un chatbot de IA o un asistente de analista a los usuarios, el artículo 50 exige que informe de la interacción con IA y que marque la salida sintética de forma legible por máquina, deberes de marcado de contenido que llegan el 2 de diciembre de 2026 bajo el Ómnibus Digital, ya está adoptado, pendiente de publicación en el Diario Oficial de la UE. Consulta la guía de obligaciones de transparencia del artículo 50.
La trampa: no despliegues un sistema genuinamente de alto riesgo bajo una etiqueta de «seguridad»
La advertencia central para los responsables de SOC y de seguridad: un caso de uso no queda exento porque viva en la organización de seguridad. La etiqueta no cambia la clasificación.
Sistemas de «seguridad» biométricos y conductuales que en realidad son del anexo III, punto 1
La identificación biométrica (anexo III, punto 1, letra a) y la categorización biométrica (anexo III, punto 1, letra b) conservan su clasificación tanto si la placa de la puerta dice «seguridad física» como si dice «control de acceso». La identificación biométrica remota en tiempo real y el rastreo no selectivo de reconocimiento facial llevan sus propias prohibiciones del artículo 5 que un encuadre de seguridad no rescata.
Monitorización de amenazas internas frente a las prohibiciones del artículo 5(1)(f)/(g)
Aquí es donde el encuadre de seguridad puede cruzar accidentalmente una línea prohibida. El artículo 5(1)(f) prohíbe el reconocimiento de emociones en el lugar de trabajo, así que una herramienta de «amenaza interna» que infiere la fatiga, el estrés o el estado emocional del personal está prohibida de plano, no es meramente de alto riesgo. El artículo 5(1)(g) prohíbe la categorización biométrica que infiere atributos sensibles. Ambos se aplican desde el 2 de febrero de 2025, y la monitorización de empleados usada de formas afines a RR. HH. también puede caer bajo el anexo III, punto 4. Despliega una herramienta de amenaza interna prohibida bajo una etiqueta de seguridad y la multa se calcula contra el nivel más alto —35 millones de euros o el 7 % del volumen de negocios anual total mundial, lo que sea mayor, según el artículo 99(3)—, no contra el nivel de herramienta operativa que asumías.
Roles, plazos y sanciones para equipos de seguridad
La mayoría de los SOC son responsables del despliegue; algunos se convierten en proveedores.
Proveedor, responsable del despliegue, importador, distribuidor y el giro del artículo 25
Un proveedor construye un sistema o lo introduce en el mercado bajo su propio nombre. Un responsable del despliegue opera la herramienta de un proveedor según sus instrucciones —la mayoría de los SOC, regidos por el artículo 26—; el artículo 23 fija los deberes del importador y el artículo 24 los del distribuidor. Crucialmente, el artículo 25 convierte a un responsable del despliegue, importador o distribuidor en proveedor por tres detonantes —rebautizar bajo su propio nombre o marca, modificación sustancial, o reutilización a un uso de alto riesgo—, arrastrando la pila completa del proveedor según el artículo 16.
Fechas clave que rastrea una organización de seguridad
Las prohibiciones del artículo 5 y la alfabetización del artículo 4 se aplican desde el 2 de febrero de 2025, y las obligaciones de GPAI según los artículos 51 a 55 desde el 2 de agosto de 2025. Los sistemas de alto riesgo autónomos del anexo III se aplican desde el 2 de diciembre de 2027, fecha fijada por el Ómnibus Digital, adoptado en junio de 2026 —voto del Parlamento Europeo el 16 de junio, adopción del Consejo el 29 de junio—, pendiente solo de su publicación en el Diario Oficial de la UE. Los sistemas integrados en productos del anexo I se aplican desde el 2 de agosto de 2028. El marcado de contenido del artículo 50 aplica desde el 2 de diciembre de 2026.
Niveles de sanción y el límite de proporcionalidad para pymes
Los artículos 99(3), 99(4) y 99(5) aplican cada uno el mayor entre el importe fijo o el porcentaje: 35 millones de euros o el 7 % (99(3)), 15 millones de euros o el 3 % (99(4)), y 7,5 millones de euros o el 1 % por suministrar información incorrecta o engañosa (99(5)). Solo el artículo 99(6) lo invierte al menor de los dos, y solo para pymes y empresas emergentes: una gran empresa nunca obtiene ese límite.
Tabla de clasificación de la IA de seguridad
La tabla tría los casos de uso habituales de IA de seguridad. Lee primero la columna de clasificación: la mayoría se resuelve en riesgo mínimo. Las filas que exigen una segunda mirada son las de puntuación de empleados, biometría y copiloto de GPAI.
| Caso de uso | Clasificación típica | Artículo / anexo que rige | ¿Deber del art. 15 si es alto riesgo? | Notas |
|---|---|---|---|---|
| Detección de anomalías de red / endpoint | Riesgo mínimo | No está en el anexo III | No | Defensa operativa; no es un uso regulado |
| Triaje / correlación de alertas del SIEM | Riesgo mínimo | No está en el anexo III | No | Puntuar alertas no es una decisión que afecte a personas |
| Clasificación de phishing / BEC | Riesgo mínimo | No está en el anexo III | No | Filtrado de contenido, no anexo III |
| Priorización de vulnerabilidades | Riesgo mínimo | No está en el anexo III | No | Puntuación interna de riesgo de activos, no de personas |
| SOAR / respuesta autónoma | Normalmente riesgo mínimo | Anexo III pt 2 si acciona la seguridad de infraestructura crítica | Sí, en ese caso | Evaluar caso por caso cuando se toca la seguridad de OT |
| Puntuación UEBA de amenaza interna sobre empleados | Alto riesgo o prohibido | Anexo III pt 4; art. 5(1)(f)/(g) | Sí, si es alto riesgo | La inferencia de emociones/atributos sensibles está prohibida |
| Control de acceso físico por reconocimiento facial | Alto riesgo o prohibido | Anexo III pt 1; art. 5 | Sí, si es alto riesgo | La ID remota en tiempo real lleva prohibiciones del art. 5 |
| Asistente / chatbot de seguridad con IA | Solo transparencia | Artículo 50 | No | Informar de la interacción con IA; marcar la salida sintética |
| Copiloto de GPAI de terceros en la herramienta | Transparencia + régimen de GPAI | Artículo 50; artículos 51-55 | Sí, si forma parte de un sistema de alto riesgo | Delimita los deberes de GPAI; no asumas una sola casilla |
Ejemplo práctico: un proveedor de MDR/SOC de tamaño medio delimita su exposición
Considera Northgate Detect, un proveedor ficticio de detección y respuesta gestionadas (MDR) con sede en la UE y 180 personas, que opera una plataforma de SOC asistida por IA. Con menos de 250 empleados, podría aplicarse el límite de proporcionalidad para pymes del artículo 99(6).
El triaje de la cartera en la práctica
Northgate tría en tres cubos. Sus modelos de detección de anomalías y de triaje de alertas son de riesgo mínimo: ningún caso de uso del anexo III, ningún componente de seguridad del anexo I. Su chatbot de analista con IA de cara al cliente es solo transparencia: una información del artículo 50, con la salida sintética marcada de forma legible por máquina. Un módulo UEBA previsto que puntuaría a los empleados de un cliente en un índice de «riesgo» es un párate-y-evalúa: activa el anexo III, punto 4, y arriesga de plano la prohibición de reconocimiento de emociones del artículo 5(1)(f), así que Northgate lo aparca a la espera de una revisión de derechos fundamentales.
Cuándo el trabajo de seguridad se convierte en la evidencia del artículo 15 de un cliente
Después se contrata a Northgate para endurecer el modelo de selección de alto riesgo de un cliente. Sus pruebas de penetración y su trabajo de solidez adversarial se convierten en la evidencia del artículo 15 del cliente, alimentando un expediente de conformidad de un sistema de alto riesgo que no construyó. Una pregunta contractual final: si Northgate rebautiza un motor de detección de terceros bajo su propio nombre, o reutiliza una herramienta hacia un uso de alto riesgo, el artículo 25 puede convertirlo de responsable del despliegue en proveedor, arrastrando la pila completa del artículo 16, incluido el sistema de gestión de riesgos del artículo 9 y la documentación del anexo IV. Audita esto antes de operativizar cualquier cambio de marca blanca o de reutilización.
Cómo ayuda Confir a los equipos de seguridad y de cumplimiento
Los equipos de seguridad afrontan un panorama dividido: la mayor parte de su IA es de riesgo mínimo, un conjunto estrecho cruza al territorio de alto riesgo o prohibido, y la mayor exposición es el deber inverso del artículo 15 sobre sistemas construidos en otras partes de la empresa. El motor de clasificación de Confir es determinista y basado en reglas —sin inferencia de modelo, sin alucinación—, de modo que las mismas entradas producen siempre el mismo resultado documentado. Recorre cada caso de uso por las pruebas del anexo III, el anexo I y el artículo 5 en secuencia y registra una justificación que un CISO o un auditor pueden seguir y cuestionar.
Para la exposición inversa del artículo 15, Confir estructura el paquete de evidencia de alto riesgo —el sistema de gestión de riesgos del artículo 9, la documentación técnica del artículo 11 y el anexo IV, y los registros de exactitud, solidez y ciberseguridad del artículo 15—, de modo que el trabajo de endurecimiento de un equipo de seguridad aterriza donde el expediente de conformidad lo necesita. Saca a la luz la cuestión del rol (proveedor frente a responsable del despliegue, y el giro del artículo 25) y rastrea los plazos en toda la cartera. El flujo de proveedor de GPAI (artículos 51 a 55) es parcial y está en la hoja de ruta, presentado como apoyo de delimitación más que como una afirmación de cumplimiento completa.
Preguntas frecuentes
¿Es de alto riesgo la IA de detección de amenazas o de anomalías según la Ley de IA de la UE? En general, no. La detección de anomalías de red, endpoint y conducta, la correlación del SIEM y el triaje de alertas no figuran en el anexo III y no son componentes de seguridad de un producto del anexo I, así que se sitúan en el nivel de riesgo mínimo, sin obligaciones obligatorias de alto riesgo según el Reglamento (UE) 2024/1689. La excepción es estrecha: si tal sistema actúa como componente de seguridad en la gestión y operación de infraestructura crítica según el anexo III, punto 2 —donde su fallo podría poner en peligro la seguridad—, puede ser de alto riesgo. Defender una empresa importante no es lo mismo que gestionar la seguridad de la infraestructura.
¿Por qué importa el artículo 15 a un equipo de seguridad si nuestra IA de seguridad no es de alto riesgo? Porque el artículo 15 hace de la exactitud, la solidez y la ciberseguridad un requisito obligatorio de todo sistema de IA de alto riesgo que tu organización suministre, incluso cuando no hay ningún producto de seguridad en el ámbito. La Ley exige expresamente resiliencia frente a los intentos de alterar el uso, las salidas o el rendimiento de un sistema explotando vulnerabilidades, incluido el envenenamiento de datos, el envenenamiento de modelos, los ejemplos adversarios y los ataques a la confidencialidad. Tus funciones de seguridad y de AppSec son los dueños naturales de ese endurecimiento, prueba y documentación. En la práctica, la Ley alcanza a los equipos de seguridad más por este deber inverso que por regular las herramientas de seguridad en sí.
¿Puede un SOC desplegar un sistema de monitorización de empleados o biométrico mientras se encuadre como seguridad? No. Un caso de uso no cambia su clasificación porque viva en la organización de seguridad. La identificación y la categorización biométricas caen bajo el anexo III, punto 1, y la monitorización de trabajadores puede caer bajo el anexo III, punto 4. Más grave aún, el artículo 5(1)(f) prohíbe el reconocimiento de emociones en el lugar de trabajo y el artículo 5(1)(g) prohíbe la categorización biométrica que infiere atributos sensibles: están prohibidos de plano desde el 2 de febrero de 2025, no meramente son de alto riesgo. Una herramienta de «amenaza interna» que infiere el estrés del personal o rasgos sensibles puede infringir estas prohibiciones, con multas de hasta 35 millones de euros o el 7 % del volumen de negocios anual total mundial según el artículo 99(3).
¿Cómo se relaciona la inyección de instrucciones con las obligaciones de la Ley de IA de la UE? La inyección de instrucciones, los jailbreaks y la inyección indirecta a través de contenido recuperado son riesgos de solidez adversarial. Cuando la GPAI afectada forma parte de un sistema de IA de alto riesgo, la resiliencia frente a ellos se proyecta sobre los deberes de solidez y ciberseguridad del artículo 15. Para todo lo demás, siguen siendo diligencia de seguridad general. Por separado, los modelos de IA de uso general llevan su propio régimen según los artículos 51 a 55. Si despliegas GPAI dentro de herramientas de seguridad, delimita tanto las implicaciones del artículo 15 como cualquier deber a nivel de GPAI, en lugar de asumir que una sola casilla lo cubre.
¿Se convierte mi SOC en «proveedor» si personalizamos una herramienta de detección de terceros? Potencialmente. La mayoría de los SOC son responsables del despliegue según el artículo 26: operan el sistema de un proveedor según sus instrucciones. Pero según el artículo 25 un responsable del despliegue se convierte en proveedor si introduce el sistema en el mercado bajo su propio nombre o marca, lo modifica sustancialmente o cambia su finalidad prevista a un uso de alto riesgo. Ese giro arrastra la pila completa del proveedor según el artículo 16. Los proveedores de detección y respuesta gestionadas que rebautizan un motor subyacente, o reutilizan una herramienta hacia un uso del anexo III, deberían auditar esto antes de operativizar el cambio.
¿Cuándo se aplican de verdad estas obligaciones a la IA de seguridad? Las prohibiciones del artículo 5 y la alfabetización en IA del artículo 4 se aplican desde el 2 de febrero de 2025. Las obligaciones de GPAI según los artículos 51 a 55 se aplican desde el 2 de agosto de 2025. Los sistemas de alto riesgo autónomos del anexo III se aplican desde el 2 de diciembre de 2027, fecha fijada por el Ómnibus Digital, adoptado en junio de 2026 —voto del Parlamento Europeo el 16 de junio, adopción del Consejo el 29 de junio—, pendiente solo de su publicación en el Diario Oficial de la UE. Los sistemas integrados en productos del anexo I se aplican desde el 2 de agosto de 2028. Los deberes de marcado de contenido del artículo 50 se aplican desde el 2 de diciembre de 2026.
¿Cuáles son las sanciones, y hay alivio para los proveedores de seguridad más pequeños? Las sanciones son escalonadas. Infringir las prohibiciones del artículo 5 alcanza 35 millones de euros o el 7 % del volumen de negocios anual total mundial según el artículo 99(3); infringir las obligaciones de alto riesgo alcanza 15 millones de euros o el 3 % según el artículo 99(4); suministrar información incorrecta o engañosa alcanza 7,5 millones de euros o el 1 % según el artículo 99(5). Cada una es el mayor entre el importe fijo o el porcentaje. Solo el artículo 99(6) lo invierte al menor de los dos, y solo para pymes y empresas emergentes (menos de 250 empleados y facturación igual o inferior a 50 millones de euros, o balance igual o inferior a 43 millones de euros). Una gran empresa nunca obtiene ese límite.
Guías relacionadas
- Requisitos de exactitud, solidez y ciberseguridad del artículo 15
- inyección de instrucciones y solidez adversarial
- obligaciones de transparencia del artículo 50
- clasificación de riesgo limitado y mínimo
- IA como componente de seguridad en infraestructura crítica (anexo III, punto 2)
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 →