CRA y Reglamento de IA: solapamiento de ciberseguridad para IA de alto riesgo

Fabricas un controlador de seguridad con IA para una red eléctrica. Es un producto con elementos digitales, así que el Reglamento de Ciberresiliencia (CRA) se aplica. Es también un sistema de IA de alto riesgo, así que el Reglamento de IA de la UE se aplica. ¿Dos reglamentos, dos evaluaciones de conformidad, dos declaraciones? No para la parte de ciberseguridad.

Al terminar este artículo sabrás tres cosas: si el solapamiento afecta siquiera a tu producto, qué evidencia de ciberseguridad puedes reutilizar en los dos reglamentos, y qué trabajo del Reglamento de IA sigue siendo independiente. La versión corta: el artículo 12 del CRA te permite reutilizar la evidencia de ciberseguridad en los dos reglamentos, con condiciones. No fusiona el cumplimiento del CRA y del Reglamento de IA en un único régimen.

Resumen

• El solapamiento es concreto. Solo importa cuando un mismo producto está a la vez dentro del ámbito del CRA y es un sistema de IA de alto riesgo conforme al Reglamento de IA.
• El CRA ofrece un puente en un solo sentido, con condiciones. Cumple los requisitos de ciberseguridad del CRA, acredita ese nivel de protección en tu Declaración UE de Conformidad del CRA, y el producto se considera conforme al requisito de ciberseguridad del Reglamento de IA.
• El puente cubre solo ciberseguridad. La exactitud y la robustez del Reglamento de IA quedan excluidas y permanecen en ese reglamento.
• Para la mayoría de los productos, ejecutas una única evaluación de conformidad, mantienes un solo conjunto de documentación técnica y llevas un único marcado CE. Los productos importantes y críticos del CRA son la excepción.
• Todo lo demás sigue siendo independiente. La gobernanza de datos, el registro y la supervisión humana permanecen en el Reglamento de IA. El SBOM, la gestión de vulnerabilidades, el periodo de soporte y la notificación en 24 horas permanecen en el CRA.

¿Estás siquiera en el solapamiento?

La mayoría de la IA no está en el ámbito, y la mayoría de los productos CRA no son IA. Tres preguntas lo deciden.

• ¿Es un producto con elementos digitales? El CRA cubre hardware y software que se conecta a un dispositivo o una red. Un proceso solo en papel o una herramienta completamente offline queda fuera.
• ¿Es también un sistema de IA de alto riesgo? En el Reglamento de IA, un sistema es de alto riesgo cuando es un componente de seguridad de un producto que ya necesita pruebas independientes, o cuando realiza uno de los usos de alto riesgo que enumera el Reglamento de IA, como la identificación biométrica remota. La lista es específica, y algunos usos se filtran de vuelta como de menor riesgo. Un chatbot de propósito general normalmente no es de alto riesgo.
• ¿Lo excluye la legislación sectorial? El CRA cede terreno a los productos ya regulados por sus propias normas: productos sanitarios, diagnósticos in vitro, vehículos con homologación de tipo, aeronaves certificadas y equipos marinos. Un dispositivo médico con IA gestiona su seguridad bajo las normas de productos sanitarios, no bajo el CRA.

Si alguna compuerta falla, el puente no se aplica. Eso también es útil: puedes dejar de intentar reutilizar evidencia de ciberseguridad del CRA para el Reglamento de IA y planificar los dos flujos de trabajo por separado.

La respuesta corta: demuestra la ciberseguridad una vez

Cuando las tres compuertas pasan, el puente hace el trabajo, con tres condiciones. El producto cumple los requisitos de ciberseguridad del CRA, los procesos del fabricante cumplen las obligaciones de gestión de vulnerabilidades del CRA, y la Declaración UE de Conformidad del CRA muestra el nivel de protección de ciberseguridad que el Reglamento de IA exige. Cumple esas condiciones y el producto se considera conforme al requisito de ciberseguridad del Reglamento de IA. Construyes la evidencia de seguridad una sola vez para el CRA, y también cuenta para el Reglamento de IA.

Esa última condición importa. La presunción no es automática. Depende de una declaración que realmente indique el nivel de protección, no de marcar una casilla.

Qué no cubre el puente

El puente transporta ciberseguridad y nada más. El Reglamento de IA también exige exactitud y robustez, y el lado del CRA no aporta nada para eso. Tampoco toca las obligaciones más amplias de IA de alto riesgo: datos y gobernanza de datos, mantenimiento de registros y registro, supervisión humana e información clara para las personas que usan el sistema. Si ya has completado el CRA, esa lista es lo que queda para el Reglamento de IA. Planifica el trabajo del Reglamento de IA en torno a ella, no en torno a repetir el trabajo de seguridad que ya terminaste para el CRA.

Tres límites merece la pena fijar en tu cabeza. Un certificado europeo de ciberseguridad también puede satisfacer el requisito de ciberseguridad del Reglamento de IA, en la medida en que lo cubra, de modo que la certificación es una segunda vía al mismo destino. Un modelo de IA de propósito general por sí solo no es el solapamiento, pero un producto, aplicación o dispositivo construido sobre ese modelo puede seguir siendo un producto CRA si supera la prueba de ámbito. Y si tu IA está dentro de maquinaria, vigila esa interfaz: el Ómnibus Digital enrutaría las normas de salud y seguridad de la IA para maquinaria a través del Reglamento de Máquinas, con actos delegados previstos para el 2 de agosto de 2028.

Qué evidencia cruza el puente

El puente trata de la reutilización. Esto es lo que construyes para el CRA y lo que responde en el lado del Reglamento de IA.

La tercera fila es la que los equipos pasan por alto. La evaluación de riesgos del CRA tiene que contemplar ataques dirigidos al propio modelo, no solo al software que lo rodea. El envenenamiento de datos ataca los datos de entrenamiento, y las entradas adversariales atacan lo que el modelo ve en tiempo de ejecución, de modo que ambas pertenecen a la misma evaluación. Ese mismo trabajo es lo que el requisito de ciberseguridad del Reglamento de IA espera, así que hacerlo una sola vez cubre los dos.

Una evaluación, un expediente técnico, un marcado CE

Para la mayoría de los productos en el solapamiento, ejecutas una única evaluación de conformidad por la vía del Reglamento de IA, y un organismo notificado que evalúa el sistema de IA puede cubrir también la verificación de ciberseguridad del CRA, siempre que sea competente para el lado del CRA. Mantienes un único conjunto de documentación técnica que sirve a los dos reglamentos, y el producto terminado lleva un marcado CE, no dos. El Reglamento de IA está diseñado para esto: redactas una sola Declaración UE de Conformidad que cubre todos los reglamentos aplicables, y el marcado CE único indica que cumples también ese otro reglamento.

Dos cosas cambian ese escenario. Los productos importantes y críticos del CRA conservan la vía de evaluación propia del CRA para la parte de seguridad cuando el Reglamento de IA permitiría de otro modo que el sistema de IA se autoevalúe, de modo que un organismo notificado competente en CRA sigue participando. Y la vía de evaluación única cubre ciberseguridad, no el resto del Reglamento de IA. Consulta las vías de evaluación de conformidad para el lado del CRA.

Qué sigue exigiendo el CRA por su cuenta

El puente funciona en un solo sentido y cubre solo seguridad. Tus obligaciones del CRA no se reducen porque el producto sea también IA. Para el producto, sigues debiendo:

• un inventario de componentes de software y un registro de los componentes que contiene
• gestión y notificación de vulnerabilidades, incluida la alerta temprana de 24 horas para vulnerabilidades explotadas activamente
• un periodo de soporte definido con actualizaciones de seguridad
• configuración segura por defecto y las demás propiedades del producto CRA

El Reglamento de IA añade una instrucción que el CRA no detalla por su cuenta. Tu evaluación de riesgos de seguridad tiene que cubrir ataques específicos de IA, como el envenenamiento de datos y las entradas adversariales. Reutilizar ese trabajo no te permite omitirlos. Lo que espera es que los integres en el mismo trabajo de evaluación de riesgos.

Dos obligaciones de notificación, no una

El puente reutiliza tu evidencia de seguridad. No fusiona la notificación de incidentes. Un producto en el solapamiento puede tener dos obligaciones de notificación independientes que no se fusionan entre sí. Una nota terminológica: el CRA te llama fabricante y el Reglamento de IA te llama proveedor. Para un producto que construyes y vendes bajo tu propio nombre, es la misma empresa, no dos partes distintas.

• La obligación del CRA. Notificas una vulnerabilidad explotada activamente o un incidente grave de seguridad a tu CSIRT coordinador y a ENISA, a través de la plataforma única de notificación. El plazo es breve: una alerta temprana de 24 horas, una actualización a las 72 horas, y un informe final.
• La obligación del Reglamento de IA. El proveedor notifica un incidente grave, como un perjuicio grave para la salud, una violación de derechos fundamentales o una perturbación grave de infraestructuras críticas, a la autoridad de vigilancia del mercado donde ocurrió. El plazo llega hasta 15 días, y tan rápido como 2 días en los casos más graves.

Los detonantes apenas se cruzan. La notificación del CRA trata de la seguridad del producto. La notificación del Reglamento de IA trata de daños a la seguridad y a los derechos. Un evento puede activar las dos, así que asigna cada tipo de incidente al canal correcto antes de que algo salga mal. El Reglamento de IA reduce la duplicación en un caso: para un sistema de alto riesgo independiente cuyo proveedor ya tiene obligaciones de notificación equivalentes bajo otro reglamento de la Unión, el informe del Reglamento de IA se limita a los incidentes relacionados con derechos fundamentales.

Los equipos habitualmente construyen el proceso de notificación de 24 horas del CRA y dan por cubierto el lado del Reglamento de IA. No lo está. El informe de incidente grave a la autoridad de vigilancia del mercado es un trabajo independiente, y necesita su propio responsable y su propio procedimiento.

Si tu organización es también una entidad esencial o importante bajo NIS2, eso añade una tercera vía de notificación a nivel de empresa, no de producto. Consulta cómo se solapan el CRA y la NIS2 para ese aspecto.

Cómo se alinean los plazos

Hay una advertencia temporal que conviene seguir. La fecha original del Reglamento de IA para los sistemas de alto riesgo integrados en productos era el 2 de agosto de 2027. El Ómnibus Digital sobre IA trasladaría los sistemas de alto riesgo independientes al 2 de diciembre de 2027 y los integrados en productos al 2 de agosto de 2028. Los colegisladores acordaron el cambio el 7 de mayo de 2026, y el Parlamento Europeo lo aprobó el 16 de junio de 2026. A 24 de junio de 2026 no es todavía derecho vinculante. Aún necesita la adopción del Consejo y la publicación en el Diario Oficial. La orientación de la Comisión sobre la clasificación de alto riesgo también sigue en borrador, con directrices definitivas previstas para finales de 2026. Trata las nuevas fechas como el punto de aterrizaje probable, no como derecho consolidado.

Para un producto en el solapamiento, el CRA avanza primero, con notificación desde septiembre de 2026 y aplicación plena en diciembre de 2027. Las obligaciones de alto riesgo del Reglamento de IA llegan hacia diciembre de 2027 para los sistemas independientes y en agosto de 2028 para los integrados en productos, conforme al calendario propuesto.

Qué tener en cuenta

Algunas cosas cambian la versión simple de esta historia.

• La presunción es condicional. Solo se sostiene si tu Declaración CRA de Conformidad muestra realmente el nivel de protección de ciberseguridad que el Reglamento de IA exige. Una declaración superficial rompe el puente.
• Los productos importantes y críticos son distintos. Cuando el Reglamento de IA permitiría de otro modo la autoevaluación, la vía de evaluación propia del CRA rige la parte de seguridad, de modo que un organismo notificado con competencia CRA sigue en el proceso.
• Una única autoridad de vigilancia del mercado. Para un producto en el solapamiento, la autoridad que supervisa tu sistema de IA también supervisa el lado del CRA, y trabaja con los CSIRT y ENISA en la notificación del CRA.
• El puente es solo de seguridad. No hace nada por la exactitud, la robustez, la gobernanza de datos, el registro ni la supervisión humana. Presupuesta esos como trabajo independiente del Reglamento de IA.
• Las fechas no están consolidadas. Las fechas de alto riesgo de 2027 y 2028 están pendientes de la adopción del Ómnibus Digital por el Consejo.
• La maquinaria tiene su propio camino. La maquinaria con IA se encamina hacia el Reglamento de Máquinas para sus normas de salud y seguridad de la IA.

Nuestra valoración

El puente es real y útil, pero trata «evaluado una sola vez» como un objetivo de planificación, no como una garantía. La ventaja es la reutilización de evidencia. Construye un expediente de seguridad CRA sólido y un único conjunto de documentación técnica, y apunta los dos regímenes a él.

La trampa que vemos es que los equipos lean el puente como «la casilla de seguridad del Reglamento de IA está marcada» y omitan el trabajo de amenazas específicas de IA que la evaluación del CRA igualmente tiene que cubrir. El envenenamiento de datos y las entradas adversariales son donde un producto de IA realmente recibe daño, y es lo que los dos reglamentos esperan que gestiones.

Nuestro consejo es claro. Define el ámbito del producto primero, construye el expediente de seguridad CRA a un nivel exigente, redacta una declaración que indique el nivel de protección, y ejecuta el trabajo de exactitud, robustez y supervisión del Reglamento de IA en su propia vía. Haz eso y el solapamiento te ahorra duplicación real. Léelo como un atajo y te perjudica en la evaluación.

Este artículo tiene únicamente fines informativos y no constituye asesoramiento jurídico. Para orientación específica sobre cumplimiento normativo, consulta con asesoría jurídica cualificada.