prEN 18282 — ciberseguridad de sistemas de IA (borrador armonizado)

prEN 18282 es el borrador de estándar armonizado elaborado por CEN/CENELEC JTC 21 para la ciberseguridad de sistemas de IA. Operacionaliza principalmente el EU AI Act Art. 15(5): la resiliencia frente a la explotación maliciosa del sistema —envenenamiento de datos o del modelo (data/model poisoning), ejemplos adversarios (adversarial examples/evasión), ataques a la confidencialidad del modelo y fallos de control de acceso.

Estado del borrador — sin presunción hasta la cita en el DOUE

prEN 18282 es un borrador armonizado confidencial de CEN-CENELEC JTC 21. Su texto íntegro no es público. Cuando sea adoptado como EN definitivo y citado en el Diario Oficial de la UE, conferirá presunción de conformidad con Art. 15. Hasta entonces, su aplicación es una buena práctica técnica sin efecto de presunción. Los plazos del AI Act para Anexo III se han aplazado al 2 de diciembre de 2027.

IP — por qué los ids de cláusula son semánticos

El texto de prEN 18282 es confidencial (norma de pago). Los identificadores en el motor son semánticos (cyber.*) y se anclan en el texto público y vinculante del Art. 15 del Reg. UE 2024/1689, no en los números de cláusula del borrador.

---

Tres capas que no se deben confundir

prEN 18282 cubre la ciberseguridad específica de IA per-sistema (Art. 15(5): amenazas maliciosas propias del modelo). Es distinta de otras dos capas:

Capa	Ámbito	Estándar de referencia
ISMS organizacional	Gestión de la seguridad de la información de la organización	ISO/IEC 27001 / ENS (línea QMS)
Robustez formal (no maliciosa)	Perturbaciones no intencionales del modelo: ruido, distribución-shift	ISO/IEC 24029-2 / prEN 18229-2 (Art. 15(4))
Ciberseguridad IA per-sistema	Explotación maliciosa del modelo: poisoning, evasión, extracción, confidencialidad	prEN 18282 (Art. 15(5))

El motor gobierna la tercera capa. El ISMS organizacional vive en el QMS (hamazazpigarrena). La robustez formal (ISO 24029-2) es una línea futura.

---

Qué cubre prEN 18282

prEN 18282 exige que el proveedor de un sistema de IA de alto riesgo:

1. Modele las amenazas ciber-específicas de IA: envenenamiento de datos y pesos del modelo, evasión mediante entradas adversarias, ataques de confidencialidad (extracción del modelo, inversión, inferencia de pertenencia) y fallos de control de acceso a nivel de API/herramienta.
2. Proteja la integridad del artefacto (código, pesos, dataset de entrenamiento) frente a modificaciones no autorizadas.
3. Garantice la confidencialidad del modelo y los datos de entrenamiento frente a ataques de extracción e inferencia.
4. Implemente control de acceso con principio de mínimo privilegio, especialmente relevante para sistemas agénticos.
5. Evalúe el riesgo residual de ciberseguridad tras los controles.
6. Monitorice incidentes y amenazas post-comercialización.
7. Documente el proceso en un expediente de ciberseguridad firmado.

---

Catálogo de cláusulas

El fichero crates/froga-core/resources/standards/pren-18282-clauses.yaml declara las cláusulas modeladas.

Modelado de amenazas (Art. 15(5))

Cláusula	Título resumido	satisfied_by
cyber.threat_modeling	Estimación completa de los riesgos declarados, incluido el registro de amenazas ciber-específicas cuando se declara	criterion: risk_estimation

El criterio risk_estimation verifica que todo riesgo declarado en el AssuranceProgram tenga likelihood e impact asignados. La cláusula queda CUBIERTA en vacío (si no se declaran amenazas ciber, no hay nada que verificar) — un estado honesto que el motor documenta explícitamente.

Integridad del artefacto (Art. 15(5): data/model poisoning)

Cláusula	Título resumido	satisfied_by
cyber.data_model_integrity	Integridad y autenticidad del artefacto, datos y pesos: anti data/model poisoning	measures_citing: true

Esta cláusula queda cubierta solo si existe una medida firmada que la cita y cuyo control pasa (p. ej. una verificación de integridad del artefacto en el pipeline). El bundle firmado por sí solo no cubre esta cláusula — ese rol lo tiene cyber.security_file.

Resiliencia adversaria (Art. 15(5): adversarial examples)

Cláusula	Título resumido	satisfied_by
cyber.adversarial_robustness	Resiliencia frente a ejemplos adversarios / evasión del modelo	measures_citing: true

Hueco honesto — el SDK no mide adversarial todavía

El SDK de medición (venturalitica-sdk) no incluye aún pruebas de robustez adversaria. Sin una medida citante, esta cláusula emite HUECO en todo sistema. La robustez adversaria (Art. 15(5)) es distinta de la robustez formal estadística (Art. 15(4), ISO 24029-2): no son intercambiables.

Control de acceso (Art. 15(5))

Cláusula	Título resumido	satisfied_by
cyber.access_control	Minimización de privilegios y control de acceso a nivel de API / invocación de herramientas	measures_citing: true

Hueco honesto — least-privilege agentic no medido aún

Ningún escenario demo mide el principio de mínimo privilegio en sistemas agénticos. Sin medida citante, esta cláusula es HUECO. Esto es relevante para sistemas que invocan herramientas externas o APIs.

Confidencialidad del modelo (Art. 15(5))

Cláusula	Título resumido	satisfied_by
cyber.confidentiality	Protección de la confidencialidad del modelo: anti extracción, inversión e inferencia de pertenencia	measures_citing: true

Hueco honesto — sin proxy declarativo suficiente aún

No existe un proxy declarativo honesto para la confidencialidad del modelo sin una medida específica. Sin medida citante, esta cláusula es HUECO.

Residual, monitorización y expediente

Cláusula	Título resumido	satisfied_by
cyber.residual_evaluation	Evaluación del riesgo residual de ciberseguridad tras los controles	measures_citing: true
cyber.monitoring	Monitorización post-comercialización de incidentes/amenazas de ciberseguridad	measures_citing: true, evidence: monitoring_plan
cyber.security_file	Expediente de ciberseguridad firmado: medidas, resultados y superficie de ataque versionados	evidence: signed_bundle

---

Estado actual de cobertura

🟡 Parcial — El motor cubre el modelado de amenazas, la integridad del artefacto, el residual y el expediente. Las cláusulas de robustez adversaria, control de acceso y confidencialidad son huecos honestos hasta que el SDK implemente las mediciones correspondientes.

Resumen de cobertura actual por familia de amenaza:

Familia	Cláusula	Estado típico
Modelado de amenazas	cyber.threat_modeling	CUBIERTA (si los riesgos tienen likelihood+impact)
Integridad del artefacto	cyber.data_model_integrity	CUBIERTA si existe medida de integridad citante; HUECO si no
Robustez adversaria	cyber.adversarial_robustness	HUECO (SDK no mide aún)
Control de acceso	cyber.access_control	HUECO (no medido aún)
Confidencialidad	cyber.confidentiality	HUECO (no medido aún)
Residual ciber	cyber.residual_evaluation	CUBIERTA si una medida cita la cláusula (residual ciber tratado)
Monitorización	cyber.monitoring	CUBIERTA si hay plan de monitorización citante
Expediente	cyber.security_file	CUBIERTA (el bundle firmado es el expediente)

---

Cómo usar froga conformance con prEN 18282

# Evaluar conformidad con prEN 18282 desde el bundle firmado
froga conformance --standard eu/pren-18282@2026

# Con historial por iteración RDD
froga conformance --standard eu/pren-18282@2026 --history

# Exportar a .froga/conformance/
froga conformance --standard eu/pren-18282@2026 --out

El informe emite CUBIERTA / PARCIAL / HUECO por cláusula, agrupada por fase del ciclo de ciberseguridad.

---

Relación con otros estándares

• EU AI Act Art. 15 — la obligación legal que prEN 18282 operacionaliza; ver EU AI Act.
• ISO/IEC 27001 — el ISMS organizacional (no per-sistema); vive en el QMS, no en el motor.
• ISO/IEC 24029-2 / prEN 18229-2 — robustez formal (perturbación no maliciosa, Art. 15(4)); línea futura en el motor.
• DORA — en entidades financieras, la resiliencia frente a amenazas TIC per-sistema también cubre obligaciones de DORA Art. 9. Ver DORA.
• ISO 23894 — el proceso de gestión de riesgos subyacente; risk_estimation es el criterio primario del modelado de amenazas. Ver ISO 23894.