Cinco normas de la UE que hoy determinan la arquitectura de sistemas

La regulación suele leerse como una lista de deberes que documentar. Los cinco instrumentos de este artículo se leen mejor como una lista de propiedades que un sistema tiene que poder mostrar: por dónde pasa una frontera, qué produce un build, quién puede acceder a un repositorio y desde dónde, adónde tienen que poder ir los datos y quién responde cuando algo sale mal. Cada uno cambió de estado entre septiembre de 2025 y septiembre de 2026, y cada uno fue leído en su fuente primaria el 17 de septiembre de 2026. Las fechas son las de los propios instrumentos, no las de informes secundarios.

Esto es un mapa, no asesoramiento. Si alguno de estos textos se aplica a un sistema concreto es una determinación jurídica que depende del producto, del sector y del papel de la organización, y nada de lo que sigue la sustituye. Lo que hace el artículo es traducir cada instrumento a la pregunta arquitectónica que impone, porque esa pregunta hay que responderla en el diseño, antes de consultar a un abogado.

El Reglamento (UE) 2024/1689, la Ley de IA, no se aplica a los sistemas de IA en la medida en que se introduzcan en el mercado, se pongan en servicio o se utilicen, con o sin modificación, exclusivamente con fines militares, de defensa o de seguridad nacional (artículo 2, apartado 3). La palabra que importa es exclusivamente. Un sistema construido para un uso civil y para un uso de defensa no es exclusivamente militar, así que su uso civil está íntegramente dentro del Reglamento, sea cual sea su uso de defensa.

El calendario se movió este verano. El Reglamento (UE) 2026/1744, el Ómnibus Digital, entró en vigor el 27 de julio de 2026 y recalendarizó el régimen de alto riesgo: las categorías autónomas del anexo III, como las decisiones de empleo y el acceso a servicios esenciales, se aplican desde el 2 de diciembre de 2027, y los sistemas integrados en productos regulados del anexo I desde el 2 de agosto de 2028. Las obligaciones de transparencia del artículo 50 no se aplazaron y se aplican desde el 2 de agosto de 2026, con una transición hasta el 2 de diciembre de 2026 solo para el deber de marcado de los sistemas generativos ya en el mercado. Las prohibiciones del artículo 5 se aplican desde el 2 de febrero de 2025.

Para la arquitectura, el artículo 2, apartado 3, es una frontera que tiene que existir en el sistema, no solo en un contrato. Si un modelo entrenado con datos civiles se reutiliza en un contexto de defensa, o un componente de defensa se reutiliza en un producto civil, los dos usos tienen que poder separarse a demanda: despliegues separados, pipelines que no compartan datos de entrenamiento ni pesos por accidente, y procedencia para cada artefacto que diga a qué lado pertenece y a partir de qué se construyó. Es la lógica del pasaporte digital de producto aplicada a modelos, conjuntos de datos y prompts. Un artefacto que no puede declarar su origen no puede colocarse a ningún lado de la línea.

El Reglamento (UE) 2024/2847, la Ley de Ciberresiliencia, se aplica en su totalidad desde el 11 de diciembre de 2027, pero su deber de notificación llegó primero. Desde el 11 de septiembre de 2026, el artículo 14 exige que un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en un producto con elementos digitales, o de un incidente grave que afecte a su seguridad, lo notifique a través de la plataforma única de notificación operada por ENISA: una alerta temprana en 24 horas, una notificación en 72 horas y un informe final a más tardar 14 días después de que esté disponible una medida correctora, o un mes en el caso de un incidente. Los usuarios afectados deben ser informados sin demora indebida, junto con las medidas que pueden adoptar (artículo 14, apartado 8). El capítulo IV, sobre los organismos que evaluarán los productos, se aplica desde el 11 de junio de 2026.

Un reloj de 24 horas no se cumple con un proceso que empieza cuando alguien abre una hoja de cálculo. Presupone que el fabricante ya sabe qué hay en cada versión entregada, lo que exige una lista de materiales de software producida por el build y no escrita después; que se entera de la explotación desde el terreno, lo que exige telemetría del producto desplegado y un canal para informes de vulnerabilidades; y que puede entregar una versión correctora en días, lo que exige un pipeline de entrega ejercitado de forma rutinaria y no solo en emergencias. En Alemania, la directriz técnica TR-03183 de la Oficina Federal de Seguridad de la Información describe el contenido mínimo que debe tener una lista de ese tipo.

El Reglamento (UE) 2021/821 controla las exportaciones de productos de doble uso, y su definición de exportación no termina en las mercancías que cruzan una frontera. Incluye la transmisión de programas informáticos o tecnología por medios electrónicos y la puesta a disposición de esos programas o tecnología, en forma electrónica, a personas situadas fuera del territorio aduanero de la Unión (artículo 2, punto 2). Quien, fuera de la Unión, recibe acceso a un repositorio, un almacén de objetos o un clúster con tecnología controlada está, según esa definición, recibiendo una exportación, y esta necesita la misma autorización que un envío.

La lista de control, el anexo I, fue actualizada por el Reglamento Delegado (UE) 2025/2003 de la Comisión, en vigor desde el 15 de noviembre de 2025. La actualización incorporó ordenadores cuánticos y sus componentes criogénicos, equipos y materiales para la fabricación de semiconductores avanzados, computación de alto rendimiento, sistemas de fabricación aditiva para metales y los polvos que utilizan, y otros materiales avanzados. Buena parte de esa lista describe aquello para lo que construye una empresa de software industrial, o sobre lo que se ejecuta.

En términos de arquitectura, esto convierte la gestión de identidades y accesos en un instrumento de control de exportaciones. Una decisión de acceso tiene que poder evaluar dónde está la persona y adónde irían los datos antes de conceder nada; cuando hay productos de origen estadounidense, las normas de ese país añaden la nacionalidad como atributo, algo que el derecho europeo no hace. Ambos atributos son datos personales, así que su recogida tiene que justificarse frente a la minimización de datos del artículo 5, apartado 1, letra c), del RGPD, y esa tensión hay que diseñarla, no descubrirla. Y como una clasificación pertenece a un artefacto y no a un equipo, tiene que viajar con el artefacto a lo largo del build: un repositorio, una imagen de contenedor y un checkpoint de modelo llevan cada uno su propia clasificación, y un pipeline que no puede leerla no puede imponerla.

El Reglamento (UE) 2023/2854, la Ley de Datos, se aplica desde el 12 de septiembre de 2025. Da a los usuarios de productos conectados, y de los servicios relacionados con ellos, el derecho a acceder a los datos que esos productos generan y a que se compartan con un tercero de su elección (artículos 4 y 5). Para los productos introducidos en el mercado después del 12 de septiembre de 2026, el propio producto tiene que diseñarse de modo que los datos sean accesibles por defecto, de forma fácil, segura y en un formato completo, estructurado y legible por máquina (artículo 3, apartado 1).

El mismo Reglamento alcanza a los proveedores de nube. Los proveedores de servicios de tratamiento de datos tienen que permitir que un cliente cambie a otro proveedor o a su propia infraestructura, con equivalencia funcional cuando el servicio sea del mismo tipo. Los costes por cambio están reducidos desde el 11 de enero de 2024 y no podrán imponerse en absoluto a partir del 12 de enero de 2027 (artículo 29).

Para una arquitectura industrial o de edge, la consecuencia es que una interfaz de exportación de datos es una funcionalidad del producto con definición legal, y que un despliegue capaz de abandonar a su proveedor de nube es un requisito y no una preferencia. El modelo de datos de una máquina, y los formatos en que los datos la abandonan, forman ahora parte de lo que un diseño tiene que mostrar.

La Directiva (UE) 2022/2555, la NIS2, obligó a los Estados miembros a aplicar sus medidas de transposición desde el 18 de octubre de 2024. Alemania llegó tarde: su ley de transposición, la NIS2UmsuCG, entró en vigor el 6 de diciembre de 2025 y reescribió la ley del BSI. La estimación del gobierno federal que acompañó al proyecto de ley cifró las entidades incluidas en unas 29.500, en dieciocho sectores, con la Oficina Federal de Seguridad de la Información (BSI) como autoridad supervisora.

Dos disposiciones llevan el peso arquitectónico. El deber de notificación de incidentes tiene la misma forma que en la Ley de Ciberresiliencia: una alerta temprana en 24 horas desde que se tiene conocimiento de un incidente significativo, una notificación en 72 horas y un informe final en el plazo de un mes (artículo 23 de la Directiva). Y el § 38 de la nueva ley del BSI hace a los miembros de la dirección de una entidad personalmente responsables de aprobar las medidas de gestión de riesgos, de supervisar su aplicación y de asistir a formación, y no permite renunciar a esa responsabilidad.

Desde el momento en que una dirección responde personalmente, la seguridad deja de ser una función de apoyo y pasa a ser una propiedad que la arquitectura tiene que demostrar: un inventario de lo que se ejecuta, una ruta de incidentes capaz de cumplir un plazo de 24 horas, resiliencia durante un ataque y no solo después de él, y evidencia de que las medidas aprobadas están realmente implantadas. Una medida que existe en un documento de políticas y en ninguna parte del sistema es exactamente aquello por lo que preguntará un supervisor.

Puestos uno junto a otro, los cinco instrumentos piden cinco propiedades arquitectónicas. La Ley de IA pregunta por dónde pasa la frontera entre el uso civil y el de defensa, y pide prueba de a qué lado está cada artefacto. La Ley de Ciberresiliencia pregunta qué produce un build y con qué rapidez puede entregarse una corrección. El control de exportaciones pregunta quién puede acceder a un repositorio y desde dónde. La Ley de Datos pregunta adónde tienen que poder ir los datos y en qué forma. La NIS2 pregunta quién aprobó el riesgo y cómo se demuestra que lo aprobado es lo que se ejecuta.

Lo que los cinco comparten es una exigencia de procedencia y de evidencia al nivel del artefacto individual: un modelo, un build, una imagen de contenedor, un conjunto de datos, el flujo de datos de una máquina, cada uno con su origen, su clasificación y las comprobaciones que superó. Es la propiedad que un pasaporte digital de producto da a un producto físico, y es la propiedad que estos textos piden ahora al software. Un sistema que la lleva responde a las cinco preguntas desde sus propios registros. Un sistema que no la lleva tiene que reconstruir la respuesta cada vez, con un plazo corriendo.

No dice que alguno de estos instrumentos se aplique a un sistema, producto u organización determinados. El ámbito depende de hechos que este artículo no tiene y de definiciones, como producto con elementos digitales, entidad esencial o titular de datos, que cada texto define por sí mismo.

No dice que la arquitectura aquí descrita sea suficiente. Despliegues separados, una lista de materiales, acceso basado en atributos, una interfaz de exportación y una ruta de incidentes son lo que los textos presuponen; cada instrumento pide más, y parte de ello, como la evaluación de productos bajo la Ley de Ciberresiliencia o el registro ante el BSI, es procedimental y no técnico.

Y no dice que las fechas sean definitivas. Tres de los cinco instrumentos ya se han movido una vez. Cada fecha de arriba nombra el instrumento del que procede, para que pueda contrastarse con el texto el día en que importe.