Controles técnicos: el mapeo cruzado ENS × ISO 42001 × EU AI Act sobre la arquitectura LLM on-premise

Tercer post de la trilogía de gobernanza IA del blog. El primero — ISO/IEC 42001 — descompuso el sistema de gestión certificable. El segundo — EU AI Act — descompuso el reglamento legal directamente aplicable. Este cubre el tercer marco que aparece cuando el cliente es Administración Pública española o entidad de servicios esenciales: el ENS (Esquema Nacional de Seguridad, Real Decreto 311/2022). El reto editorial: el cumplimiento triple no es la suma aritmética de los tres trabajos; es un solo conjunto de evidencias técnicas etiquetadas para tres lentes. Este post desmonta cómo se construyen esas evidencias por medida ENS.

TL;DR

El Real Decreto 311/2022 actualizó el Esquema Nacional de Seguridad (ENS) español alineándolo con NIS2 y con el panorama de ciberamenazas moderno. Aplica obligatoriamente a todo el sector público español (administración general, autonómica, local, universidades, organismos autónomos) y a proveedores que les presten servicios IT. La norma define 74 medidas de seguridad organizadas en tres bloques (marco organizativo org, marco operacional op, medidas de protección mp), tres categorías de aplicación (Básica / Media / Alta) según valoración de las cinco dimensiones (Confidencialidad, Integridad, Trazabilidad, Autenticidad, Disponibilidad), y un anexo II con la matriz medida × categoría que dicta qué se exige en cada nivel. Este post mapea las medidas técnicas relevantes para sistemas LLM (las del bloque op planificación / control acceso / explotación / servicios externos / continuidad / monitorización, y las del bloque mp comunicaciones / aplicaciones / información / servicios) contra el Annex A de ISO/IEC 42001 y los artículos operativos del EU AI Act (Arts. 9 a 15, 17, 72 y 73), y muestra que el solapamiento es masivo: un único artefacto técnico del stack OSS del blog —los spans OTel del tracing, los datasets versionados con DVC, los scanners de LLM Guard, las decisiones de guardrail, los incidentes del retrain— satisface simultáneamente medidas ENS, controles 42001 y artículos del AI Act, siempre que se etiquete con los códigos correctos desde su captura. La tesis editorial: la diferencia entre un sistema que pasa los tres audits y uno que sufre tres certificaciones separadas no es presupuesto, es etiquetado disciplinado y vocabulario común. El post construye la tabla maestra de cumplimiento triple, recorre el caso del chatbot multi-tenant para Administración Pública Categoría Alta como checklist vivo, y cierra con las cinco trampas del cumplimiento triple.

La analogía: la inspección triple del edificio crítico

Un edificio crítico —el centro de control de la red eléctrica de una autonomía, un hospital de referencia, un centro de respuesta de emergencias 112— pasa tres inspecciones distintas sobre los mismos elementos físicos:

• La inspección autonómica revisa licencia urbanística, normativa contra incendios local, accesibilidad según legislación regional.
• La inspección europea revisa marcado CE de equipamiento, conformidad con directivas EU sobre eficiencia energética.
• La inspección de calidad ISO revisa procesos y mantenimiento bajo norma de gestión.

Los tres inspectores miran el mismo detector de incendios colgado del techo. La autonómica quiere ver el certificado de instalación con número de empresa instaladora; la europea quiere ver la marca CE estampada en la carcasa; la ISO quiere ver el registro de mantenimiento mensual con firmas. El detector es uno solo. La evidencia que cada inspector necesita es distinta. Si el equipo de gestión del edificio guardara una carpeta por inspector, el certificado de instalación, la foto de la marca CE y la hoja de mantenimiento vivirían en tres sitios y el día de la auditoría se descubrirían inconsistencias entre las tres carpetas. La forma profesional de operar: un solo expediente por activo, con etiquetas que apuntan a las tres legislaciones.

El sistema LLM on-premise es ese edificio crítico. Los spans OTel del tracing son el detector de incendios: una sola pieza técnica que satisface la medida ENS op.exp.8 (registro de actividad), el control 42001 A.8.2 (información a partes interesadas), y el artículo EU AI Act 12 (record-keeping) si los spans llevan la metadata correcta: traceparent propagado, gen_ai.* semantic conventions, retención WORM, PII redactada por LLM Guard Vault. Sin etiquetado consistente desde la captura, el día de la auditoría hay tres carpetas que no cuadran.

La analogía importa porque acota una decisión arquitectónica: el etiquetado de evidencia no es un tema de compliance, es un tema de diseño técnico. Se decide cuando se monta el OTel Collector, cuando se diseña el schema del Vault, cuando se acuerda el formato de los incidentes de retrain. Si se posterga, la deuda compounds.

ENS en 15 segundos

• Marco regulatorio: Real Decreto 311/2022, de 3 de mayo, vigente desde el 5 de mayo de 2022. Sustituye al RD 3/2010. Implementa la actualización del Esquema con NIS2, NCS (Estrategia Nacional de Ciberseguridad) y la realidad post-2020.
• Ámbito obligatorio: sector público español (administración general, autonómica, local, universidades, organismos autónomos), entidades del sector público con personalidad jurídica propia, proveedores privados que les presten servicios IT (cláusula muy importante en consultoría: si tu cliente es Junta de Andalucía, Comunidad de Madrid o Ayuntamiento de Bilbao, tú estás bajo ENS por extensión contractual).
• Aplicabilidad operativa 2026: cualquier proyecto IA financiado con fondos europeos NextGenerationEU + cualquier proyecto con datos públicos + cualquier integración con sistemas administrativos electrónicos.
• Categorización: tres categorías Básica / Media / Alta según valoración de las cinco dimensiones (C, I, T, A, D). La categoría dicta qué medidas se exigen y con qué profundidad.
• Certificación: para Categoría Media y Alta, auditoría formal por entidad acreditada. Para Categoría Básica, autoevaluación. Ciclo de certificación bienal.
• Autoridad: Centro Criptológico Nacional (CCN-CERT), dependiente del CNI. Mantiene el portal ens.ccn.cni.es con guías STIC (Series 800).
• Número total de medidas: 74 organizadas en tres bloques + anexo II con matriz medida × categoría que define qué aplica en cada nivel.

Las cinco dimensiones de seguridad y su mapeo IA

Para clasificar el sistema en categoría Básica / Media / Alta, el ENS pide valorar cada dimensión en una escala (no aplicable / bajo / medio / alto). La categoría final es la más alta de las cinco. Para sistemas LLM, la valoración típica:

Resultado típico: Categoría Media para sistemas LLM internos sin datos sensibles, Alta si manejan PII o datos sectoriales regulados (sanidad, fiscal, judicial). La categoría dispara controles distintos.

Los tres bloques de medidas

Marco organizativo (org) — 4 medidas que aplican siempre, transversales:

• org.1 Política de seguridad
• org.2 Normativa de seguridad
• org.3 Procedimientos de seguridad
• org.4 Proceso de autorización

Marco operacional (op) — 31 medidas en 6 subgrupos, son el cómo se opera:

• op.pl Planificación (5)
• op.acc Control de acceso (6)
• op.exp Explotación (10)
• op.ext Servicios externos (4)
• op.cont Continuidad del servicio (4)
• op.mon Monitorización del sistema (2)

Medidas de protección (mp) — 39 medidas en 7 subgrupos, son qué se protege:

• mp.if Protección instalaciones (7)
• mp.per Gestión personal (4)
• mp.eq Protección equipos (4)
• mp.com Protección comunicaciones (4)
• mp.si Protección soportes información (5)
• mp.sw Protección aplicaciones (2)
• mp.info Protección información (6)
• mp.s Protección servicios (4)

De estas 74, las que importan operativamente para sistemas LLM son aproximadamente 25. Las restantes son bien transversales (políticas, gestión personal, instalaciones físicas), bien específicas de otras capas (telefonía, soportes físicos en sentido literal). El resto del post baja a las 25 relevantes.

Mapeo técnico: medidas ENS clave × controles 42001 × artículos EU AI Act

A continuación, por subgrupo ENS, las medidas relevantes para LLM con su mapeo cruzado. La columna Evidencia técnica del blog apunta al artefacto operativo que materializa la medida.

Marco operacional — planificación (op.pl)

Marco operacional — control de acceso (op.acc)

Marco operacional — explotación (op.exp)

Es el subgrupo más denso y el que más solapa con la arquitectura LLM.

Marco operacional — servicios externos (op.ext)

Crítico cuando el sistema integra GPAI (Llama, Mistral) hospedado fuera o cuando el deployer es tercero.

Marco operacional — continuidad (op.cont)

Marco operacional — monitorización (op.mon)

Medidas de protección — comunicaciones (mp.com)

Medidas de protección — aplicaciones (mp.sw)

Medidas de protección — información (mp.info)

Medidas de protección — servicios (mp.s)

Tabla maestra de cumplimiento triple — los 25 controles relevantes consolidados

La lectura clave del cuadro: una sola fila por capacidad técnica. La organización no construye tres soluciones para “log de actividad” (ENS) + “información partes interesadas” (42001) + “record-keeping” (AI Act). Construye una sola pieza de tracing OTel con la metadata correcta y la presenta etiquetada según el inspector.

El etiquetado se materializa típicamente en tres mecanismos:

1. Tags en los pipelines CI/CD: cada artefacto producido lleva tags ens:op.exp.8, iso42001:A.8.2, aia:art.12 en su metadata Helm / Argo CD.
2. Atributos OTel semánticos: gen_ai.compliance.ens = "op.exp.8", gen_ai.compliance.iso42001 = "A.8.2" como custom attributes en los spans relevantes (no estándar todavía, pero útil interno).
3. Mapping table en wiki: documento vivo medida ENS → control 42001 → artículo AI Act → runbook técnico + dueño + última verificación. Es el artefacto que el auditor consulta.

Caso aplicado: chatbot multi-tenant para Administración Pública

Variante del chatbot multi-tenant del post forense — ahora el cliente es una Junta autonómica española que ofrece asistencia ciudadana sobre trámites administrativos. Las tres miradas:

• ENS: aplica obligatoriamente por ser sector público + servicio a ciudadanos. Categoría Alta (PII de ciudadanos + servicio crítico).
• ISO 42001: la Junta solicita certificación al proveedor como requisito contractual.
• EU AI Act: si el chatbot informa sobre trámites pero no decide nada por el ciudadano, riesgo limitado (Art. 50 transparencia). Si automatiza decisiones (admisión a programa, denegación de ayuda), alto riesgo.

Asumimos alto riesgo para el recorrido más exigente.

Las 25 capacidades técnicas clave del chatbot consolidadas

Resultado: las 25 capacidades técnicas son comunes a los tres marcos. Solo dos exigen evidencia de un solo marco aisladamente: mp.info.4-5 (firma y sello cualificados — ENS-específico, no exigido tan literalmente por 42001 o AI Act) y Art. 50 (transparencia banner — AI Act-específico). El resto son la misma pieza técnica con tres etiquetas. Un equipo bien organizado certifica los tres en serie con incremento marginal de trabajo entre el segundo y el tercero.

Las cinco trampas del cumplimiento triple

Trampa 1 — Medir tres veces lo mismo. Equipos novatos crean tres dashboards distintos (uno para ENS, otro para 42001, otro para AI Act) con las mismas métricas duplicadas. Resultado: tres fuentes de verdad que divergen, tres equipos auditores con cifras distintas, tres correcciones para resolver una misma desviación. La regla: una métrica, tres etiquetas.

Trampa 2 — Perder el control que solo cubre una norma. El mp.info.4 (firma electrónica) es ENS-específico y se olvida cuando el equipo está concentrado en 42001 + AI Act. El día del audit ENS aparece el hueco. Solución: la tabla maestra mantiene visibles todos los controles, incluidos los huérfanos.

Trampa 3 — Sesgo hacia la norma más reciente. El equipo dedica el 80% del esfuerzo al AI Act por ser el más nuevo y olvida el rigor del ENS que lleva 14 años en vigor. Las medidas ENS son más prescriptivas técnicamente que el AI Act (que es legalmente más estricto pero deja libertad implementativa). Subir un nivel a Cat. Alta ENS introduce exigencias específicas (HSM, sellos cualificados, vigilancia 24×7) que el AI Act no detalla. Hay que respetar el ENS por su detalle técnico, no por su estatura legal.

Trampa 4 — Mezclar Cat. Media y Alta del ENS. La matriz del Anexo II del RD 311/2022 dicta qué medidas se exigen y con qué profundidad por categoría. Subir de Media a Alta cambia 15-20 controles (no es marginal). La categoría se decide al inicio del proyecto y se documenta; cambiarla a mitad fuerza reauditoría completa.

Trampa 5 — Audit fatigue dentro del equipo técnico. Tres auditorías al año (ENS bienal + 42001 anual seguimiento + AI Act ad-hoc por autoridad) agota al equipo si no se planifican y reutilizan evidencias. La forma profesional: un solo ciclo de auditoría interna trimestral con scope rotativo, que produce evidencia consumible por los tres auditores externos. La diferencia entre 30 días/año y 90 días/año de trabajo perdido en auditorías es la disciplina de evidencia única + etiquetado disciplinado.

Lo que no hemos cubierto (próximos posts)

• Las series STIC del CCN-CERT aplicables a sistemas IA: STIC 800-159 (operación servicios web), STIC 800-105 (criptografía), STIC 800-150 (entornos cloud). Cada una añade detalle técnico sobre cómo materializar las medidas ENS.
• El RGPD como cuarta lente: privacidad y protección de datos personales. Solapa con mp.info.1 y con A.7.6 de 42001 + Art. 10 del AI Act. Material para una pasada análoga sobre LOPDGDD + RGPD + AEPD vs los tres marcos vistos.
• Plantillas concretas de evidencia técnica con campos mínimos: log entry con todos los atributos requeridos por las tres miradas, incident report con todos los campos exigidos por las tres normas, declaración de conformidad ENS / AI Act / 42001 unificada.
• Caso fondos NextGenerationEU: requisitos compliance específicos para proyectos IA financiados con fondos europeos, donde el AI Act + ENS son obligatorios contractualmente.
• 42001 + ENS Categoría Alta combinados con DORA (Digital Operational Resilience Act, Reg. 2022/2554) para entidades financieras españolas que despliegan IA.

Referencias

• RD 311/2022 — por el que se regula el Esquema Nacional de Seguridad. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191.
• CCN-CERT — Portal ENS: https://ens.ccn.cni.es/. Guías STIC Series 800.
• CCN-STIC 803 — Valoración de los sistemas y de la información. Metodología para asignar categoría ENS.
• CCN-STIC 804 — Esquema Nacional de Seguridad. Guía de implantación.
• CCN-STIC 824 — Informe del estado de seguridad. Plantilla para auditoría ENS.
• MAGERIT v3 — Metodología de Análisis y Gestión de Riesgos del Ministerio de Asuntos Económicos. Insumo de op.pl.1.
• ISO/IEC 42001:2023 — Sistema de gestión IA. Norma certificable que solapa con ENS.
• Regulation (EU) 2024/1689 (EU AI Act) — texto consolidado.
• NIS2 (Dir. 2022/2555) — directiva de ciberseguridad que el ENS implementa parcialmente en su versión 2022.

Ver también

• ISO/IEC 42001: el manual de operaciones del sistema de IA — el primer post de la trilogía de gobernanza, sistema de gestión certificable.
• EU AI Act: el expediente técnico artículo por artículo — el segundo post, reglamento legal directo UE.
• El pipeline LLMOps de seis etapas — la arquitectura operativa de referencia que sostiene los tres marcos.
• Tracing LLM con OpenTelemetry GenAI — la pieza canónica que materializa op.exp.8 + .10 ENS + A.8.2 ISO 42001 + Arts. 12 + 19 AI Act simultáneamente.
• Guardrails y safety en LLMs — la pieza que materializa op.mon.1 + mp.s.4 ENS + A.9.2 ISO 42001 + Art. 15 AI Act.
• LLM Guard: el traductor jurado con cuaderno de equivalencias — la pieza que materializa mp.info.1 + .6 ENS + A.7.6 ISO 42001 + Art. 10 AI Act.
• Data versioning con DVC y lakeFS y RAG corpus curation — las piezas que materializan mp.info.1-2 ENS + A.7 ISO 42001 + Art. 10 AI Act.
• Retrain: cerrar el bucle feedback → dataset → adapter — la pieza que materializa op.exp.7 + .9 ENS + cláusula 10 ISO 42001 + Art. 73 AI Act.
• Evals: la capa después del tracing — la pieza que materializa mp.sw.2 ENS + A.6.2.5 ISO 42001 + Art. 15 AI Act.
• Siete capas del stack y siete fases del despliegue — el material directo para op.pl.2 arquitectura.
• El catálogo paralelo OSS vs hyperscalers — insumo para op.ext.1 + .3 análisis proveedores + Art. 53 GPAI.
• El catálogo OSS para LLMOps — inventario de componentes con licencias para op.exp.1.
• Anatomía de una petición LLM en producción — el caso forense recorrido con la triple lente en este post.
• Runbooks de incident response para LLM con Keep + Kafka — la pieza concreta que materializa op.exp.7-10 ENS + A.8.2 ISO 42001 + Art. 73 EU AI Act simultáneamente: workflows Keep declarativos + Kafka audit.actions WORM + plazos NIS2 24/72h/1mes.