)
¿Se aplica la Ley de Ciberresiliencia a las aplicaciones de IA, y qué exige realmente el cumplimiento de la CRA? Sí. Si tu producto de IA tiene elementos digitales y llega al mercado de la UE, queda sujeto a la Ley de Ciberresiliencia (Reglamento UE 2024/2847). Pero el reglamento está redactado en lenguaje jurídico, no en especificaciones técnicas. Te dice que gestiones las vulnerabilidades, protejas frente al acceso no autorizado y registres los eventos de seguridad. No te dice cómo hacer nada de eso para un sistema que puede ser secuestrado por una frase escondida en un documento. Esta guía traduce los requisitos esenciales de la CRA a los controles de seguridad concretos que los sistemas de IA y agénticos realmente necesitan.
TL;DR
- La CRA (Reglamento UE 2024/2847) es la primera ley de la UE que convierte el secure-by-design en una obligación legal para cualquier producto con elementos digitales. Las aplicaciones de IA y los agentes de IA están dentro de su ámbito.
- Dos fechas deciden tu hoja de ruta: las obligaciones de notificación del Artículo 14 se aplican desde el 11 de septiembre de 2026, y las disposiciones principales se aplican desde el 11 de diciembre de 2027.
- La obligación de notificación de septiembre de 2026 se aplica incluso a productos que ya están en el mercado, con una alerta temprana exigida en un plazo de 24 horas desde que se tiene conocimiento de una vulnerabilidad explotada activamente.
- La CRA es deliberadamente neutral desde el punto de vista tecnológico. Nunca nombra la inyección de prompts, el abuso de herramientas ni los servidores MCP, y sin embargo sus requisitos implican claramente controles para todos ellos cuando tu producto es un sistema de IA.
- Las sanciones alcanzan hasta 15 millones de euros o el 2,5 % de la facturación anual mundial.
- El cumplimiento de la CRA para IA es un esfuerzo de ingeniería, no de papeleo: red teaming de IA, monitorización en tiempo de ejecución, ejecución de herramientas con privilegios mínimos, validación de la cadena de suministro y registro inmutable que pueda alimentar un informe de 24 horas.
La Ley de Ciberresiliencia está lista. La mayoría de los productos de IA no.
La mayoría de los equipos que construyen aplicaciones de IA asumen que tienen hasta finales de 2027 para preocuparse por la Ley de Ciberresiliencia. Esa suposición es cara. Las obligaciones de notificación de la CRA entran en vigor el 11 de septiembre de 2026, y se aplican a productos ya distribuidos, no solo a los nuevos. A partir de esa fecha, si un atacante está explotando activamente una vulnerabilidad en tu sistema, tienes 24 horas para presentar una alerta temprana ante ENISA y el CSIRT nacional correspondiente.
)
Aquí está la pregunta incómoda para cualquiera que ejecute hoy un producto basado en LLM en producción: si alguien convirtiera en arma una inyección indirecta de prompts contra tu agente ahora mismo, ¿te enterarías siquiera? Y si lo supieras, ¿podrías producir en 24 horas un informe que diga qué ocurrió, qué componente se vio afectado y qué hiciste al respecto?
Para la mayoría de las aplicaciones de IA, la respuesta honesta es no. No porque los equipos sean descuidados, sino porque la CRA se redactó pensando en software determinista, y los sistemas de IA rompen varias de sus suposiciones silenciosas.
Qué exige realmente la Ley de Ciberresiliencia
La CRA establece sus requisitos esenciales en el Anexo I, dividido en dos partes. La Parte I cubre propiedades que el producto debe tener. La Parte II cubre procesos que el fabricante debe ejecutar a lo largo del período de soporte.
En el lado del producto, los productos dentro del ámbito deben comercializarse sin vulnerabilidades explotables conocidas y con una configuración segura por defecto. Deben garantizar la protección frente al acceso no autorizado mediante mecanismos de control adecuados, incluidos sistemas de autenticación, identidad o gestión de accesos. Deben proteger la confidencialidad y la integridad de los datos, minimizar la superficie de ataque y proporcionar información relacionada con la seguridad registrando y monitorizando la actividad interna relevante, incluido el acceso a datos, servicios o funciones, o su modificación.
En el lado del proceso, los fabricantes deben identificar y documentar los componentes, abordar y remediar las vulnerabilidades sin demora, aplicar pruebas y revisiones eficaces y regulares de la seguridad del producto, y aplicar una política de divulgación coordinada de vulnerabilidades.
Fíjate en lo que falta. El texto nunca nombra una sola amenaza de IA. Eso es intencionado. La CRA es intencionadamente neutral desde el punto de vista tecnológico: define resultados de seguridad y obligaciones del ciclo de vida en lugar de prescribir herramientas o técnicas concretas. Lo que significa que la carga de la traducción recae sobre ti. "Protege frente al acceso no autorizado" es una frase en el reglamento. Para un agente autónomo con acceso a herramientas, memoria y sistemas externos, es toda una arquitectura.
Por qué los sistemas de IA rompen las suposiciones de la CRA
El software tradicional tiene una frontera limpia entre código y datos. Las instrucciones vienen del desarrollador; todo lo demás es entrada que se procesa. El marco de la CRA se apoya en esa frontera.
Los sistemas de IA la borran. En un LLM, una frase dentro de un mensaje de usuario, un documento recuperado o una respuesta de una herramienta puede convertirse en una instrucción que el modelo sigue. El OWASP Top 10 para Aplicaciones LLM (2025) clasifica la inyección de prompts como el riesgo número uno precisamente porque los modelos procesan instrucciones y datos en el mismo canal, sin separación fiable entre ambos. Esa única propiedad desmonta varios controles convencionales:
- La entrada no confiable se vuelve ejecutable. La inyección de prompts significa que la superficie de ataque es cada fragmento de texto que tu sistema ingiere, no solo sus parámetros de API.
- El comportamiento es no determinista. La misma entrada puede producir salidas diferentes. "Vulnerabilidad explotable conocida" se vuelve difusa cuando la vulnerabilidad es una tendencia probabilística en lugar de un fallo fijo en una línea de código.
- La cadena de suministro es nueva y opaca. Tus dependencias ahora incluyen pesos de modelos, datos de entrenamiento, ajustes finos, servidores MCP y herramientas de terceros. Un SBOM que solo lista paquetes de Python pierde la mayor parte de la superficie de riesgo real.
- Los agentes actúan en el mundo. Cuando un modelo puede llamar a herramientas, enviar correos o mover dinero, una inyección exitosa deja de ser una fuga de información. Es acción no autorizada con consecuencias reales, lo que OWASP llama agencia excesiva.
Un programa de CRA construido solo sobre prácticas clásicas de AppSec marcará casillas mientras deja estas brechas abiertas de par en par. Los requisitos siguen aplicándose. La implementación hay que repensarla.
Mapeando los requisitos de la CRA a controles de seguridad de IA
Aquí es donde el reglamento se convierte en una hoja de ruta de ingeniería. Cada requisito esencial del Anexo I se mapea a controles específicos y construibles para sistemas de IA.
| Requisito esencial de la CRA (Anexo I) | Implementación técnica para IA |
|---|---|
| Seguro por diseño | Modelado de amenazas de IA (STRIDE más OWASP GenAI Top 10), SDLC seguro, aplicación de políticas en el gateway |
| Seguro por defecto | Ámbitos de herramientas con privilegios mínimos, configuración conservadora del modelo, sin acceso ilimitado al sistema de fábrica |
| Protección frente al acceso no autorizado | Identidad para agentes y cargas de trabajo, permisos de herramientas con ámbito definido, mTLS entre servicios |
| Confidencialidad e integridad de los datos | Prevención de fugas de secretos y PII, protección de la memoria, aislamiento de contexto entre sesiones |
| Minimizar la superficie de ataque | Un gateway de IA como único punto de estrangulamiento, guardrails de entrada y salida, catálogo de herramientas restringido |
| Gestión de vulnerabilidades | Red teaming de IA, un proceso de divulgación que cubra hallazgos a nivel de modelo, actualizaciones gestionadas del modelo |
| Registro y monitorización | Registros de auditoría inmutables, monitorización en tiempo de ejecución, detección de anomalías de comportamiento |
| Actualizaciones seguras | Actualizaciones firmadas de modelos y prompts, capacidad de rollback, seguimiento de cambios |
| Seguridad de la cadena de suministro | Comprobaciones de procedencia del modelo, validación de servidores MCP, un SBOM ampliado a componentes de IA |
Tres de estos merecen una mirada más cercana, porque es donde la IA se aparta más drásticamente del modelo mental original del reglamento.
Gestión de vulnerabilidades, redefinida. Para una aplicación LLM, ¿qué cuenta como vulnerabilidad? Un jailbreak que evade tu política de seguridad. Un patrón de inyección de prompts que exfiltra las instrucciones del sistema. Una secuencia de llamadas a herramientas que escala privilegios. Ninguna de estas aparecerá en una base de datos CVE, y sin embargo cada una es una debilidad explotable genuina que la CRA espera que encuentres, corrijas y divulgues. Por eso el red teaming de IA no es un pulido opcional. Es como satisfaces el requisito de probar y remediar, aplicado a un sistema cuyos modos de fallo son lingüísticos en lugar de sintácticos. En NeuralTrust tratamos el red teaming de IA continuo como la capa de descubrimiento para exactamente este tipo de vulnerabilidad a nivel de modelo.
Monitorización en tiempo de ejecución para agentes. La CRA exige registrar y monitorizar la actividad interna relevante. Para una app determinista, eso es registro de peticiones. Para un agente, significa observar las decisiones reales: qué herramientas se llamaron, con qué argumentos, en respuesta a qué entradas, y si ese patrón parece el comportamiento previsto del agente o algo que lo está desviando de su rumbo. Sin monitorización del comportamiento en tiempo de ejecución, no puedes detectar una explotación activa, y si no puedes detectarla, no puedes cumplir la ventana de notificación de 24 horas.
Cadena de suministro que ya no puedes ignorar. El reglamento espera que identifiques y documentes los componentes de tu producto. Para la IA, ese inventario tiene que alcanzar el modelo al que llamas, de dónde vino, los servidores MCP a los que se conecta tu agente y las herramientas que puede invocar. Cada uno es un punto de entrada. Un servidor MCP no verificado es, funcionalmente, un componente de terceros con acceso de escritura al comportamiento de tu agente.
)
La CRA y los agentes de IA: el caso más difícil
Las llamadas LLM de un solo disparo ya son bastante difíciles. Los agentes autónomos elevan considerablemente lo que está en juego, y aquí es donde la brecha entre el texto de la CRA y la realidad operativa es más amplia.
Los agentes introducen amenazas que el reglamento nunca anticipó por su nombre: inyección indirecta de prompts a través de contenido recuperado, abuso de herramientas en el que una capacidad legítima se desvía hacia un fin malicioso, comunicación agente a agente que propaga un compromiso, y envenenamiento de memoria o contexto que corrompe decisiones futuras mucho después del ataque inicial.
Mapea estas amenazas de vuelta a la CRA y los controles se vuelven claros. "Protección frente al acceso no autorizado" se convierte en un modelo real de permisos de herramientas, donde un agente solo puede invocar lo que su tarea requiere y nada más. "Integridad de los datos y los comandos" se convierte en ejecución segura de herramientas y validación de lo que fluye hacia la memoria del agente. "Monitorización de la actividad interna relevante" se convierte en monitorización continua del comportamiento del flujo de acciones del agente. Esta es la capa que un gateway de IA está diseñado para aplicar: un único punto de control donde la política, la identidad y la inspección se aplican a cada llamada al modelo y cada invocación de herramienta.
Para ser precisos: ninguno de estos controles está nombrado en la CRA. Son medidas técnicas concretas que contribuyen a satisfacer sus requisitos generales, adaptadas a la realidad de los sistemas agénticos. El reglamento te da la obligación. La ingeniería te da la implementación. Esa traducción es todo el trabajo.
Una lista de verificación práctica de preparación para la CRA para IA
Si construyes aplicaciones de IA, así es como se ve la preparación para la CRA en la práctica:
- ✅ Permisos de herramientas con privilegios mínimos aplicados por agente y por tarea
- ✅ Monitorización en tiempo de ejecución de las acciones del agente, no solo registros de peticiones
- ✅ Detección de inyección de prompts en entradas, contenido recuperado y respuestas de herramientas
- ✅ Prevención de fugas de secretos y PII en las salidas del modelo
- ✅ Validación de la cadena de suministro para modelos, ajustes finos, librerías y herramientas
- ✅ Conexiones MCP seguras con servidores verificados y con ámbito definido
- ✅ Registro inmutable que pueda reconstruir un incidente a posteriori
- ✅ Red teaming de IA ejecutado con regularidad, no una sola vez antes del lanzamiento
- ✅ Respuesta a incidentes capaz de producir un informe en menos de 24 horas
Si no puedes marcar la mayoría de estos hoy, no tienes un problema de documentación. Tienes un backlog de ingeniería, y el reloj está corriendo.
Los plazos de la CRA que deciden tu hoja de ruta
La Ley de Ciberresiliencia se implanta por fases, y cada fecha debería impulsar una decisión técnica específica.
Para el 11 de septiembre de 2026, se aplican las obligaciones de notificación del Artículo 14, incluso a productos que ya están en el mercado. Para cumplir una ventana de alerta temprana de 24 horas, necesitas tener la detección y el registro activos en producción mucho antes de esa fecha. No puedes construir un proceso de respuesta a incidentes durante el incidente.
Para el 11 de diciembre de 2027, se aplica el conjunto completo de requisitos esenciales, y el marcado CE se convierte en una condición previa para comercializar nuevos productos en el mercado de la UE. Eso cubre el secure-by-design, la gestión de vulnerabilidades a lo largo del período de soporte y el SBOM ampliado.
Algo que vale la pena señalar específicamente para los constructores de IA: la CRA y la Ley de IA de la UE están diseñadas para engranar entre sí. Los productos con elementos digitales considerados sistemas de IA de alto riesgo bajo la Ley de IA se considerarán conformes con sus requisitos de ciberseguridad si cumplen los requisitos de la CRA. Acertar con los controles de seguridad de la CRA hace doble trabajo.
La conclusión es simple. La Ley de Ciberresiliencia no es un ejercicio jurídico que se entrega a los abogados y se olvida. Es un problema de ingeniería de seguridad para cualquiera que construya IA, y los sistemas que necesitan protección ya están en producción.
Preguntas frecuentes
¿Se aplica la Ley de Ciberresiliencia a las aplicaciones y agentes de IA? Sí. La CRA cubre los productos con elementos digitales comercializados en el mercado de la UE, y las aplicaciones de IA cualifican. El reglamento no excluye la IA; aplica los mismos requisitos esenciales de ciberseguridad, que luego tienes que implementar para los riesgos específicos que introduce la IA, como la inyección de prompts y el abuso de herramientas.
¿Cuál es el primer plazo de la CRA que me debe preocupar? El 11 de septiembre de 2026, cuando entran en vigor las obligaciones de notificación del Artículo 14. Estas se aplican incluso a productos ya en el mercado, y exigen una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento de una vulnerabilidad explotada activamente o de un incidente grave. El cumplimiento completo de los requisitos esenciales sigue el 11 de diciembre de 2027.
¿Menciona la CRA específicamente la inyección de prompts u otras amenazas de IA? No. La CRA es neutral desde el punto de vista tecnológico y define resultados de seguridad en lugar de técnicas. La inyección de prompts, el abuso de herramientas y la seguridad MCP no se nombran, pero los requisitos del reglamento sobre control de acceso, integridad de datos y monitorización implican claramente controles para ellos en los sistemas de IA.
¿Qué cuenta como vulnerabilidad en una aplicación LLM bajo la CRA? Cualquier cosa que constituya una debilidad explotable: jailbreaks que evaden la política de seguridad, patrones de inyección que filtran prompts del sistema, o secuencias de llamadas a herramientas que escalan privilegios. Estas no aparecerán en una base de datos CVE, pero aun así caen bajo las obligaciones de gestión de vulnerabilidades de la CRA y deberían aflorarse mediante el red teaming de IA.
¿Necesito un SBOM para componentes de IA? En la práctica, sí. La CRA exige que identifiques y documentes los componentes de tu producto. Para los sistemas de IA, ese inventario debería alcanzar modelos, ajustes finos, servidores MCP y herramientas, no solo las dependencias de software tradicionales.
¿Cuáles son las sanciones por incumplimiento de la CRA? Hasta 15 millones de euros o el 2,5 % de la facturación anual mundial total, lo que sea mayor, por incumplimiento de los requisitos esenciales. Los productos que no superen la evaluación de conformidad también pueden perder el acceso al mercado de la UE.
¿Cumplir con la CRA ayuda con el cumplimiento de la Ley de IA de la UE? Para los sistemas de IA de alto riesgo, sí. Cumplir con los requisitos de ciberseguridad de la CRA puede satisfacer las obligaciones de ciberseguridad correspondientes bajo la Ley de IA, de modo que el trabajo no se duplica.
Conclusiones clave
- La Ley de Ciberresiliencia se aplica a las aplicaciones y agentes de IA. No hay exención para la IA.
- El primer plazo real es el 11 de septiembre de 2026 para la notificación, no diciembre de 2027, y se aplica a productos que ya están en producción.
- El reglamento es neutral desde el punto de vista tecnológico, por lo que la carga de traducir los requisitos legales a controles específicos de IA recae sobre el constructor.
- La IA rompe la suposición central de la CRA de que el código y los datos están separados, razón por la cual la inyección de prompts convierte cada entrada en parte de la superficie de ataque.
- El cumplimiento de la CRA para IA es un esfuerzo de ingeniería: red teaming, monitorización en tiempo de ejecución, ejecución de herramientas con privilegios mínimos, validación de la cadena de suministro y registro inmutable.
- Los sistemas agénticos elevan lo que está en juego, convirtiendo una inyección exitosa de una fuga de información en una acción no autorizada.
- Acertar con los controles de la CRA también hace avanzar el cumplimiento de la Ley de IA de la UE para los sistemas de alto riesgo.
Sobre el autor
Alessandro Pignati es Lead AI Security Researcher en NeuralTrust, donde lidera la investigación sobre seguridad de IA y agéntica, avanzando técnicas para evaluar y asegurar grandes modelos de lenguaje y sistemas de IA autónomos. Está especializado en aprendizaje automático adversario, red teaming de IA, seguridad de LLM y seguridad de IA, contribuyendo al desarrollo de una IA segura y confiable.
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en la Gartner 2025 Market Guide for Guardian Agents. Con sede en Barcelona y certificación ISO 27001.
)