Inteligencia artificial y su tratamiento bajo el ENS

La incorporación de sistemas con inteligencia artificial en entornos sujetos al ENS plantea una pregunta recurrente: ¿cómo se integran? La respuesta corta es que el ENS ya sirve como marco general de seguridad, pero exige matices específicos cuando hay IA en juego. Este artículo ordena los puntos clave y explica qué hacer si tu sistema incorpora componentes inteligentes (propios o de terceros).

La IA es un activo más, pero con particularidades

Un sistema con IA se trata como cualquier otro sistema de información dentro del ENS: entra en el inventario, se categoriza, se analiza el riesgo y se le aplican las medidas del Anexo II. La diferencia está en dos cosas:

1. Amenazas propias que los modelos clásicos del catálogo MAGERIT no recogen con suficiente detalle: poisoning, prompt injection, evasion attacks, model inversion, membership inference.
2. Amenazas sobre terceros (personas afectadas por las decisiones) más fuertes de lo habitual por el carácter opaco y escalable del modelo.

Ignorar estas particularidades y tratarlo como “otro servicio web” es el error más frecuente en 2026.

Categorización: qué dimensiones suben

Al categorizar un sistema con IA, estas dimensiones tienden a subir respecto a un sistema equivalente sin IA:

• Integridad: si el modelo se manipula, el daño afecta a todas las decisiones posteriores. Un modelo corrupto en producción es peor que un registro corrompido individual.
• Trazabilidad: exigida por el AI Act para sistemas de alto riesgo. Decisiones automatizadas deben poder reconstruirse.
• Confidencialidad: los modelos memorizan datos de entrenamiento. Extracción de ejemplos por inversión del modelo es real.
• Disponibilidad: sistemas críticos que dependen de un modelo que se degrada silenciosamente pueden fallar sin que nadie se entere.

La recomendación práctica: si tenías clasificado el sistema en Media sin IA, revisa si las dimensiones de integridad y trazabilidad deben subir a Alta al incorporar IA relevante.

Medidas del Anexo II reforzadas

La Instrucción Técnica del CCN publicada en 2026 desarrolla refuerzos específicos. Resumen:

op.pl — Planificación

• Inventario específico de modelos y datasets, no solo de infraestructura.
• Gobierno del ciclo de vida: entrenamiento, validación, despliegue, reentrenamiento, retirada.
• Responsable del modelo claramente designado (tipo RSI pero del modelo).

op.exp — Operación

• Aislamiento de entornos de entrenamiento vs. inferencia.
• Separación estricta de datos de producción y de entrenamiento.
• Gestión de versiones del modelo como artefacto controlado.

op.mon — Monitorización

• Métricas de deriva (drift) del modelo.
• Alertas por cambios significativos en distribución de entradas o salidas.
• Detección de patrones adversariales en inferencia.

mp.info — Protección de la información

• Sanitización de datos sensibles en datasets.
• Técnicas de privacidad diferencial si aplica.
• Control sobre lo que el modelo memoriza.

mp.per — Personal

• Formación específica en seguridad de IA para el equipo que opera el modelo.

mp.com — Comunicaciones

• Control de entradas/salidas del modelo especialmente cuando es conversacional (riesgo de prompt injection, filtraciones).

Decisiones automatizadas y explicabilidad

El ENS por sí solo no obliga a explicabilidad, pero el AI Act sí lo exige en sistemas de alto riesgo. Prácticamente, esto se traduce en:

• Capacidad de reconstruir por qué el modelo emitió una decisión.
• Logs de inputs, outputs y versión del modelo usada.
• Trazas que permiten auditoría posterior.
• Interfaz para que el usuario afectado pueda recibir explicación comprensible.

La auditoría ENS de un sistema con IA pregunta: “¿puedes mostrarme una decisión tomada hace 3 meses y reconstruir por qué el modelo decidió eso?”. Si no puedes, hay hallazgo.

Modelos propios vs. modelos de terceros

Modelo propio

Si entrenas tu propio modelo, controlas el ciclo de vida completo. Te toca todo el trabajo pero tienes toda la información. Las medidas anteriores aplican directamente.

Modelo de terceros (API)

Si consumes un modelo vía API (OpenAI, Anthropic, Google, Azure AI), la mayoría de las medidas técnicas las tiene el proveedor. Tu responsabilidad:

• Clasificar al proveedor como crítico.
• Exigir contrato con compromisos (RGPD, residencia de datos, seguridad).
• Control sobre qué datos envías (evitar PII innecesaria).
• Logs de consumo y de prompts (con cuidado para no almacenar contenido sensible innecesariamente).
• Plan de contingencia si el proveedor cambia condiciones o sufre incidente.

Modelo propio sobre modelo base (fine-tuning)

Modelo híbrido: recibes un modelo pre-entrenado y lo ajustas. Requiere:

• Trazabilidad del modelo base utilizado.
• Documentación del fine-tuning (qué datos, qué hiperparámetros).
• Control sobre el resultado.

RAG y bases de conocimiento

Los sistemas RAG (Retrieval-Augmented Generation) son cada vez más comunes. Añaden consideraciones:

• Base de conocimiento como activo clasificado.
• Control de acceso al vector store: no todo usuario puede recuperar todo documento.
• Filtrado de outputs para que el modelo no cite documentos que el usuario no debería ver.
• Actualización controlada de la base de conocimiento (quién añade, con qué criterio).

El riesgo típico: indexar documentos sin depurar PII o sin controles y que luego el modelo los reproduzca.

Prompt injection y salidas dañinas

El prompt injection ya es un vector real de ataque. Controles:

• Sanitización de entradas de usuarios.
• Separación entre instrucciones del sistema y datos de usuario.
• Filtros de salida para detectar contenido peligroso.
• Límites de acción: no dar al modelo acceso directo a ejecutar operaciones irreversibles sin revisión humana.
• Rate limiting para mitigar ataques escalados.

El auditor 2026 pregunta por estos controles si el sistema es conversacional y público.

Governance: Comité de IA

Las organizaciones maduras crean un Comité de IA paralelo o integrado con el Comité de Seguridad. Funciones:

• Aprobar nuevos usos de IA.
• Revisar riesgos.
• Aprobar modelos a desplegar.
• Monitorizar métricas.
• Gestionar incidentes específicos.

Para ENS + AI Act, esta estructura formal ayuda enormemente.

Incidentes en sistemas con IA

Un incidente en un sistema con IA puede ser:

• Modelo emite salidas inapropiadas (bias detectado, información peligrosa).
• Modelo ha sido envenenado durante entrenamiento.
• Prompt injection exitosa que ha filtrado datos.
• Deriva significativa sin detectar (decisiones degradadas sin alerta).
• Compromiso del proveedor del modelo.

Los procedimientos de respuesta del ENS se extienden: rollback del modelo, comunicación a usuarios afectados, análisis forense específico del modelo.

Relación con el AI Act

El AI Act clasifica sistemas en categorías de riesgo:

• Prohibidos: social scoring, manipulación subliminal.
• Alto riesgo: empleo, educación, infraestructura crítica, administración justicia, migración, aplicaciones de la ley.
• Riesgo limitado: chatbots, deep fakes.
• Riesgo mínimo: resto.

Los sistemas de la AAPP suelen caer en alto riesgo (acceso a servicios, decisiones administrativas). Eso implica obligaciones del AI Act: gestión de riesgos, calidad de datos, documentación, trazabilidad, supervisión humana, robustez.

Cumplir ENS + AI Act en paralelo es coherente pero requiere mapeo explícito. La buena noticia: muchas medidas ENS ya cubren AI Act. La mala: hay requisitos específicos AI Act (especialmente calidad de datos y evaluación de impacto en derechos fundamentales) que no están todos en el ENS.

Documentación específica

Si tu sistema usa IA, añade a la documentación ENS:

• Ficha del modelo (model card): propósito, datos de entrenamiento, métricas, limitaciones conocidas.
• Análisis de riesgos del modelo complementario al AR del sistema.
• Política de IA interna: cuándo se puede usar, qué controles, quién aprueba.
• Procedimiento de gestión del modelo a lo largo del ciclo de vida.
• Procedimiento de gestión de incidentes específico para IA.
• Registro de decisiones automatizadas cuando aplica.

Errores frecuentes

• No incluir la IA en el alcance “porque es experimental”. Si afecta decisiones, está en alcance.
• Tratar API externas como si no existieran: son proveedores críticos.
• No documentar modelo ni dataset: auditoría lo pide.
• Confiar en que el proveedor cubre todo: la responsabilidad final es tuya.
• Saltarse la evaluación de impacto: obligatoria en alto riesgo.

Recomendación final

La IA no es un apéndice del ENS: exige tratamiento específico y gobernanza dedicada. Las organizaciones que anticipen estos refuerzos en 2026 evitarán sustos en auditoría y construirán sistemas de IA realmente fiables. Posponer el tema hasta que “alguien obligue” significa pagar más en remediación que en implantación planificada.