Saltar al contenido principal
Borrador de trabajoVersión no oficial en revisión, con limitaciones conocidas.
← Mapa normativo

Criterios

Edición 04-10-2026 · corte 27-07-2026 · revisión jurídica de las fichas por el comité editorial no acreditada

Vista agregada de los enunciados clasificados del Informe y del marco normativo cartografiado: qué dice cada fuente, con qué naturaleza jurídica, en qué estado se encuentra, qué fechas la condicionan y dónde verificarla. Los totales agrupan criterios O/I/S/R/P y no equivalen a obligaciones.

Fichas
29
Criterios visibles
12
Fecha de corte
27-07-2026
  • O Obligación normativa expresa
  • I Interpretación jurídica basada en riesgo
  • S Estándar técnico
  • R Recomendación no vinculante
  • P Propuesta de política o buena práctica

El filtro por sector muestra las fichas que cita cada guía sectorial. Es una asociación editorial y orientativa: no determina que una norma se aplique a todas las entidades del sector.

Se muestran 3 de 29 fichas y 12 criterios.

Fichas que cita la guía «Salud». Ver la guía sectorial →

RGPD Reglamento (UE) 2016/679 — Reglamento General de Protección de Datos

Norma en vigor y aplicable en sus condiciones

Protección de datos · reglamento · https://eur-lex.europa.eu/eli/reg/2016/679/oj

  • Los responsables y encargados deben aplicar medidas técnicas y organizativas apropiadas para garantizar una seguridad adecuada al riesgo, incluida la protección frente al tratamiento no autorizado o ilícito y frente a pérdida, destrucción o daño accidental, mediante medidas como confidencialidad, integridad, disponibilidad, resiliencia, seudonimización, cifrado y procesos periódicos de verificación cuando proceda. En contexto cuántico, esta obligación no se traduce automáticamente en un mandato universal de criptografía poscuántica, sino en un análisis de seguridad conforme al riesgo, al estado de la técnica, a los costes, a la naturaleza, al alcance, al contexto y a los fines del tratamiento. El fundamento se encuentra en los artículos 5.1.f y 32 RGPD. (responsable, encargado)
  • La transición progresiva a criptografía poscuántica debe formularse como medida interpretativa de gestión del riesgo HNDL, priorizable cuando la criticidad de los datos, su vida útil de confidencialidad, la exposición criptográfica y el estado de la técnica lo justifiquen. El RGPD no impone, por sí mismo, una obligación automática y universal de migración PQC para todo responsable o encargado. (responsable, encargado)
  • El responsable debe aplicar protección de datos desde el diseño y por defecto al determinar los medios del tratamiento y durante el propio tratamiento. En sistemas con exposición criptográfica relevante, esa obligación puede justificar inventario criptográfico, cripto-agilidad, minimización y controles de seguridad si resultan proporcionados al riesgo, pero esas medidas concretas deben mantenerse como desarrollo interpretativo y no como requisito uniforme para todos los tratamientos. El fundamento de diseño y defecto se encuentra en el artículo 25 RGPD. (responsable)
  • La evaluación de impacto relativa a la protección de datos debe realizarse antes del tratamiento cuando sea probable que un tipo de tratamiento, en particular con nuevas tecnologías, entrañe un alto riesgo para los derechos y libertades de las personas físicas. El uso de tecnología cuántica o de técnicas de machine learning cuántico no activa por sí solo la EIPD si no concurre la probabilidad de alto riesgo exigida por el artículo 35 RGPD. (responsable)
  • La reidentificación de datos anonimizados mediante técnicas cuánticas debe describirse como hipótesis técnica que exige evaluación con evidencia y con los medios razonablemente utilizables, y no como capacidad general demostrada ni como consecuencia jurídica automática. Se mantiene la distinción entre datos anónimos fuera de los principios de protección de datos y datos seudonimizados o reidentificables que siguen pudiendo vincularse a una persona física mediante información adicional. (responsable)

Capítulo del Informe: §4.3, §3.1, §5.5 · Fecha de ficha: 27-07-2026

RIA Reglamento (UE) 2024/1689 — Inteligencia Artificial, modificado por Reglamento (UE) 2026/1744

En vigor con fechas de aplicación por fases

Inteligencia artificial · reglamento · https://eur-lex.europa.eu/eli/reg/2024/1689/oj

  • Verificar primero la definición de sistema de IA del artículo 3.1 y el ámbito del RIA; después, su clasificación y el rol efectivo del proveedor o responsable del despliegue. Para el artículo 6.1 deben concurrir tanto el vínculo con un producto o componente de seguridad del Anexo I como la exigencia de evaluación de conformidad por tercero. Para los usos del Anexo III, comprobar la excepción del artículo 6.3: ausencia de riesgo importante de perjuicio y una de sus condiciones de tarea limitada, mejora de actividad humana previa, detección de patrones con revisión humana adecuada o tarea preparatoria; si el sistema elabora perfiles de personas físicas, permanece clasificado como alto riesgo. En servicios financieros, precisar que Anexo III 5.b se refiere a solvencia o puntuación crediticia de personas físicas y excluye detección de fraude financiero, y 5.c a evaluación de riesgos y precios de seguros de vida y salud. Una decisión financiera genérica o usar QML no acredita por sí solo alto riesgo. Determinar las obligaciones y su fecha a partir del rol y régimen aplicables, incluidas las reglas sectoriales y transitorias pertinentes. La reforma añade al artículo 6 los apartados 1 bis, 1 ter y 1 quater: los sistemas usados únicamente para aspectos no relacionados con seguridad en asistencia al usuario, optimización del rendimiento, eficiencia del servicio, automatización, comodidad o control de calidad no se consideran componentes de seguridad; no obstante, sí se consideran tales aquellos cuyo fallo pueda poner en peligro salud/seguridad; la evaluación por tercero debida únicamente a riesgos distintos de salud/seguridad no satisface 6.1.b. Aplicar estas precisiones cuando corresponda, sin clasificar por una etiqueta tecnológica. (proveedor, desplegador)
  • La introducción en el mercado, puesta en servicio o utilización de IA está prohibida cuando concurra un supuesto del artículo 5, con las condiciones y excepciones propias de cada letra y modalidad. Incluye la puntuación social del artículo 5.1.c cuando la evaluación o clasificación de personas o grupos por su comportamiento social o características personales produzca un trato perjudicial o desfavorable en contextos ajenos a los de obtención de los datos, o un trato injustificado o desproporcionado. No equiparar todo análisis de datos, vigilancia o uso cuántico a esas prácticas. Las prohibiciones ya existentes son aplicables desde el 02-02-2025; las nuevas letras 5.1.b bis y b ter y apartados 1 bis y 1 ter tienen aplicación desde el 02-12-2026. La política interna puede prohibir otros usos, pero esa ampliación debe identificarse separadamente como política propuesta y no atribuirse al artículo 5. (todos los operadores)
  • Para el proveedor de IA de alto riesgo efectivamente comprendido, cumplir requisitos de arts. 9–15 y QMS art. 17 según rol, sistema, régimen sectorial y calendario. Capítulo III, secciones 1–3, exceptuado 6.5: desde 02-12-2027 para 6.2/Anexo III y 02-08-2028 para 6.1/Anexo I, sin perjuicio de art. 111. A 03-10-2026, preparar esos controles no equivale a exigibilidad general actual. (proveedor de alto riesgo)
  • EIDF/FRIA del art. 27 para responsables del despliegue de alto riesgo del art. 6.2 que sean organismos de Derecho público, entidades privadas prestadoras de servicios públicos o responsables de usos Anexo III 5.b–c; excluir Anexo III 2. Verificar solvencia/puntuación crediticia de personas físicas (no detección de fraude financiero), riesgos/precios de seguros de vida/salud y excepciones 6.3. Será previa al despliegue desde fecha aplicable 02-12-2027 para estos sistemas, con régimen transitorio pertinente; QML no basta ni la FRIA es obligación inmediata universal. Art. 27.4 modificado permite referencias cruzadas/inclusión de partes EIPD pertinentes a obligaciones coincidentes, sin eliminar el resto de FRIA. (desplegadores comprendidos)
  • La opacidad cuántica no exime de documentar límites de validez, incertidumbre, ruido y tasas de error con el detalle exigible al sistema y rol; no se exige explicabilidad completa universal. La interpretación se vincula a obligaciones concretas y calendario aplicable; no presume certificación QT-QMS ni conformidad automática. (proveedor)

Fechas clave

  • 13-06-2024Disposición original RIA
  • 12-07-2024Publicación original RIA en DOUE
  • 01-08-2024Entrada en vigor original, art. 113
  • 08-07-2026Disposición Reglamento 2026/1744
  • 24-07-2026Publicación Reglamento 2026/1744
  • 27-07-2026Entrada en vigor Reglamento 2026/1744, art. 4
  • 02-08-2026Aplicación general del RIA, con excepciones (art. 113 modificado por el Reglamento (UE) 2026/1744)pendiente de revisión editorial P0-02
  • 02-12-2026Aplicación de las nuevas prohibiciones añadidas al art. 5 por el Reglamento (UE) 2026/1744pendiente de revisión editorial P0-02
  • 02-12-2027Capítulo III, secciones 1–3 (salvo art. 6.5), sistemas 6.2/Anexo III: aplicación 02-12-2027, conforme Reglamento 2026/1744 publicadoTexto del Informe con una actualización posterior al corte, pendiente de revisión: P0-02
  • 02-12-2027Alto riesgo: capítulo III, secciones 1 a 3, salvo art. 6.5, para sistemas del art. 6.2 y del Anexo III (art. 113 modificado por el Reglamento (UE) 2026/1744, art. 1.40)pendiente de revisión editorial P0-02
  • 02-08-2028Capítulo III, secciones 1–3 (salvo art. 6.5), sistemas 6.1/Anexo I: aplicación 02-08-2028, conforme Reglamento 2026/1744 publicadoTexto del Informe con una actualización posterior al corte, pendiente de revisión: P0-02
  • 02-08-2028Alto riesgo: capítulo III, secciones 1 a 3, salvo art. 6.5, para sistemas del art. 6.1 y del Anexo I (art. 113 modificado por el Reglamento (UE) 2026/1744, art. 1.40)pendiente de revisión editorial P0-02

Capítulo del Informe: §4.4, §3.3, §5.5, §6.1 · Fecha de ficha: 27-07-2026

EHDS Reglamento (UE) 2025/327 — Espacio Europeo de Datos de Salud

En vigor con fechas de aplicación por fases

Protección de datos · reglamento · https://eur-lex.europa.eu/eli/reg/2025/327/oj

  • Los sistemas cuánticos o híbridos que traten datos de salud electrónicos personales deben alinearse con el EHDS cuando entren en su ámbito y resulten aplicables sus disposiciones por fase, sujeto y categoría, y deben operar junto con una base jurídica del artículo 6 RGPD y una excepción del artículo 9 RGPD cuando se traten categorías especiales de datos. El EHDS complementa derechos del RGPD y establece un marco jurídico y técnico para datos de salud electrónicos, pero no sustituye las bases de licitud ni las garantías de protección de datos. El Reglamento de Ejecución (UE) 2026/2098 desarrolla los metadatos mínimos de descripciones de conjuntos de datos para uso secundario: los tenedores y, en su caso, participantes autorizados en DatosSalud@UE utilizan HealthDCAT-AP según arts. 1–3 y anexo. Se refiere a descripciones y vocabularios, no a publicación universal del contenido de los datos ni autorización de uso. Publicado 21.09.2026, vigor 11.10.2026 y aplicación 26.03.2029 (art. 4); al 03.10.2026 no es una obligación actual general. El Reglamento de Ejecución (UE) 2026/2099 establece identificación y autenticación para intercambio transfronterizo a través de MiSalud@UE. Publicado 22.09.2026, vigor 12.10.2026 y aplicación general 26.03.2027; art. 3.2 exige notificar conjuntos nacionales de atributos a más tardar el 26.03.2028 y arts. 3.3/5.2 aplican 26.03.2029 para emisión a petición y aceptación de atributos mediante cartera EUDI, tanto en solicitudes presenciales como en línea. Art. 4.2 exige nivel al menos sustancial en solicitudes en línea y alto desde 26.03.2030; art. 6.3 exige al menos sustancial para profesionales y alto desde 26.03.2032. No impone PQC universal, una nueva categoría de servicio cualificado ni una fecha general de migración EUDI. (responsables y encargados en salud)
  • La priorización criptográfica en salud debe formularse como interpretación de gestión del riesgo HNDL por la sensibilidad de los datos de salud y sus largos periodos de conservación. La migración poscuántica puede ser prioritaria en salud por vida útil de confidencialidad y criticidad, pero el EHDS no convierte por sí solo esa priorización en obligación inmediata de PQC para todos los agentes sanitarios. El análisis y las medidas proporcionadas se encuadran en los artículos 25 y 32 RGPD y en el régimen sectorial pertinente cuando sea aplicable. (responsables y encargados en salud)

Fechas clave

  • 21-09-2026Publicación del Reglamento de Ejecución (UE) 2026/2083 sobre MiSalud@UEpendiente de revisión editorial P1-07
  • 21-09-2026Publicación del Reglamento de Ejecución (UE) 2026/2098: metadatos de conjuntos para uso secundariopendiente de revisión editorial
  • 22-09-2026Publicación del Reglamento de Ejecución (UE) 2026/2099: identificación y autenticación MiSalud@UEpendiente de revisión editorial
  • 11-10-2026Entrada en vigor del Reglamento de Ejecución (UE) 2026/2083 (art. 19)pendiente de revisión editorial P1-07
  • 11-10-2026Entrada en vigor 2026/2098; no aplicación anticipada de sus requisitospendiente de revisión editorial
  • 12-10-2026Entrada en vigor 2026/2099; obligaciones sujetas a su calendariopendiente de revisión editorial
  • 26-03-2027Aplicación del Reglamento de Ejecución (UE) 2026/2083 (MiSalud@UE)pendiente de revisión editorial P1-07
  • 26-03-2027Aplicación general del EHDS (art. 105, con excepciones)pendiente de revisión editorial P1-08
  • 26-03-2027Aplicación general 2026/2099, excepto arts. 3.3/5.2 y escalones futuros expresospendiente de revisión editorial
  • 26-03-2028Fecha límite para Estados miembros: notificar conjuntos nacionales de atributos de asistencia sanitariapendiente de revisión editorial
  • 26-03-2029Principales derechos, intercambio y sistemas de HCE para las primeras categorías de datos; regla general del uso secundario, con excepciones (art. 105)pendiente de revisión editorial P1-08
  • 26-03-2029Aplicación de 2026/2098 a descripciones de conjuntos de datos por sujetos de su ámbitopendiente de revisión editorial
  • 26-03-2029Aplicación arts. 3.3/5.2: emisión de atributos a petición y aceptación EUDI en intercambios sanitariospendiente de revisión editorial
  • 26-03-2030Nivel alto para identificación/autenticación de personas en solicitud sanitaria transfronteriza en líneapendiente de revisión editorial
  • 26-03-2031Derechos, intercambio y sistemas de HCE para las categorías de datos restantes (art. 105)pendiente de revisión editorial P1-08
  • 26-03-2032Nivel alto para medios de autenticación electrónica de profesionales sanitarios en MiSalud@UEpendiente de revisión editorial
  • 26-03-2035Aplicación del art. 75.5 (art. 105)pendiente de revisión editorial P1-08

Capítulo del Informe: §3.4 · Fecha de ficha: 27-07-2026

Herramientas asociadas

El Manual QT-QMS es un modelo de referencia no certificable. Las cláusulas tipo son borradores orientativos sujetos a adaptación jurídica caso a caso; no son un clausulado listo para firma ni sustituyen asesoramiento legal. [Naturaleza registrada: QT-QMS: modelo de referencia beta no certificable; no es norma técnica, esquema de certificación ni presunción de cumplimiento.]

Cláusulas contractuales patrón (orientativas)

  • 1. Seguridad criptográfica poscuántica y cripto-agilidad
  • 2. Uso ético y limitación de finalidad
  • 3. Protección de datos y confidencialidad cuántica
  • 4. Auditorías, transparencia y cooperación regulatoria
  • 5. Exportación, PI y soberanía tecnológica
  • 6. Ciberresiliencia y cadena de suministro (CRA)
  • 7. Portabilidad y cambio de proveedor (Ley de Datos)
  • 8. Prestación de servicios TIC a entidades financieras (DORA)
  • 9. Autodeclaración de conformidad con la hoja de ruta NIS de transición PQC
  • 10. Adhesión a un código de buenas prácticas cuánticas voluntario

Checklist PQC

  • 1. Nombrar equipo PQC con patrocinio de dirección, líder CISO o Crypto Officer, equipo multidisciplinar y mandato documentado.
  • 2. Inventariar criptografía vulnerable, incluyendo RSA, Diffie-Hellman, ECC, IoT, VPN, tarjetas, PKI, firmas de firmware y escaneo TLS automatizado, sin registrar secretos ni claves.
  • 3. Clasificar y priorizar por vida útil de confidencialidad, exposición HNDL, impacto y tiempo de migración, con prioridad para secretos de más de cinco a diez años y sistemas de alto riesgo. Las bandas internas crítico <2 años, medio 3–5 y bajo >5 son propuestas P, no plazos legales ni equivalencia automática con los horizontes CCN. No basta que un dato sea público o efímero para descartar riesgo de autenticidad, integridad o disponibilidad.
  • 4. Seleccionar familias, función y parámetros por caso de uso: ML-KEM para establecimiento de secreto y ML-DSA o SLH-DSA para firma, según estándar final y guías aplicables; valorar construcción híbrida estandarizada y pruebas. Distinguir algoritmo, protocolo, módulo validado y servicio completo. No tratar FALCON/FIPS 206 en desarrollo como estándar final ni a HQC seleccionado como FIPS final. Conservar versión, modelo de amenaza, interoperabilidad, límites y prescripción ENS concreta. En un pliego público describir prestaciones verificables, equivalencias y prueba admisible cuando proceda.
  • 5. Inventariar y actualizar PKI, HSM, bibliotecas, dependencias y SBOM con versiones soportadas y política de parches. La referencia OpenSSL 3.x+ es insuficiente: OpenSSL 3.5 incorpora ML-KEM, ML-DSA y SLH-DSA; comprobar rama, versión, proveedor criptográfico, parámetros, soporte y configuración efectivos. Las pruebas deben acreditar negociación y conexión interoperable, además de autenticación y firmas/certificados que correspondan; tener la biblioteca o un KEM híbrido no prueba que todo el canal sea poscuántico. FIPS 140-3 es validación de módulo/configuración y entorno concretos, distinta de FIPS 203–205; comprobar certificado y alcance cuando el régimen o contrato lo requiera, sin afirmarlo para todo módulo PQC ni imponerlo universalmente. En pliegos, justificar requisitos y alternativas conforme a LCSP y ENS aplicable.
  • 6. Ejecutar pilotos en entorno controlado, con compatibilidad hacia atrás, métricas de rendimiento, interoperabilidad, coste operativo, reversión y criterios de parada.
  • 7. Formar y comunicar internamente a TI, desarrollo, compras, dirección, jurídico y privacidad; en entidades financieras DORA, incluir al proveedor tercero TIC en formación cuando proceda conforme al art. 30.2.i.
  • 8. Migrar por fases con opción de rollback, documentación de cada cambio, control de versiones y evidencia que permita auditoría posterior.
  • 9. Monitorizar continuamente latencias, errores, compatibilidad, degradación, incidencias y sistemas inviables, con reevaluación formal del riesgo.
  • 10. Cerrar cada caso con evaluación final de eslabones débiles, políticas actualizadas, evidencia trazable ante DORA cuando aplique y proceso de mejora continua. No se declara cierre sin eslabones débiles a partir de una checklist; registrar alcance, ensayos, resultados, limitaciones y aceptación reales.
  • 11. Puntuar cada caso de uso con matriz de riesgo cuántico y tiempo de migración, considerando vida útil del dato, exposición, severidad, disponibilidad de solución, coste y dependencias externas. QSFF/Europol y G7 son referencias sectoriales de priorización R; no metodología legal obligatoria para todo sector ni fecha nueva de migración.
  • 12. Catalogar mecanismos y prácticas vulnerables o mal gestionados con evidencia: protocolos obsoletos según versión/configuración, claves o credenciales embebidas, gestión manual sin control de ciclo de vida y certificados wildcard con exposición relevante. No prohibir universalmente todo certificado manual o wildcard por su etiqueta. Documentar riesgo, excepciones justificadas, responsable, remediación proporcional, fecha y medida de efectividad; las prohibiciones derivarán de norma, política aprobada o contrato identificados. Evitar almacenar secretos en el inventario.
  • 13. Cuando sea pertinente EUCC, contrastar mecanismos con la versión ENISA designada aplicable: la página consultada mantiene ACM v2 de 06-05-2025. La v3 de 02-06-2026 es borrador cuya consulta terminó en julio; no se invita a participar ni se presenta como versión final. Separar el informe ENISA de hibridación PQC publicado 30-04-2026 como referencia técnica complementaria, sin convertirlo en certificación de una implementación ni obligación PQC universal. Registrar versión, productos y ámbito que efectivamente se evalúan.
Blochy