NIS2 tiene dientes: cómo la directiva cambia el manejo de datos en IA

NIS2 en 30 segundos

La Directiva NIS2 ((UE) 2022/2555) sustituye a la NIS original y se aplica a dos niveles de organizaciones en 18 sectores: entidades esenciales (energía, transporte, banca, infraestructuras del mercado financiero, sanidad, agua potable, aguas residuales, infraestructura digital, gestión de servicios TIC, administración pública, espacio) y entidades importantes (servicios postales, gestión de residuos, química, alimentación, fabricación de dispositivos médicos y electrónica, proveedores digitales, investigación). Los Estados miembros tenían hasta el 17 de octubre de 2024 para transponerla. España la transpuso mediante Real Decreto-ley antes de la fecha límite, designando al INCIBE-CERT y al CCN-CERT como CSIRT de referencia y al Centro Criptológico Nacional como autoridad competente. Alemania no aprobó el NIS2UmsuCG hasta 2025. Bélgica, Países Bajos, Polonia e Irlanda se retrasaron. La Comisión Europea abrió procedimientos de infracción en noviembre de 2024.

Que la transposición nacional vaya tarde no le exime: la propia directiva es vinculante desde octubre de 2024 y las autoridades de supervisión ya están redactando sus guías de aplicación. Las fugas de datos hacia herramientas de IA encajan plenamente en las nuevas obligaciones de notificación, y la mayoría de los equipos de seguridad aún no las han modelado.

Quién está realmente dentro del alcance

Importan dos umbrales. La regla de tamaño: cualquier organización con más de 50 empleados o más de 10 M€ de facturación anual que opere en un sector cubierto está incluida por defecto. Eso atrapa a muchas empresas medianas que pensaban que NIS solo afectaba a operadores de servicios esenciales. La regla sectorial obligatoria: ciertos proveedores digitales están dentro del alcance con independencia de su tamaño. Todo proveedor de DNS, registro de TLD, proveedor cloud, operador de centro de datos, CDN, MSP y MSSP entra, por pequeño que sea. Una MSP de 12 personas en Madrid está dentro. Una consultora de ciberseguridad boutique en Barcelona, también.

Si opera herramientas de IA para un cliente cubierto bajo contrato de servicios gestionados, hereda obligaciones de notificación para los incidentes en ese perímetro. Muchos integradores de IA descubren esto cuando ya es tarde.

El calendario de notificación que coge a todos a contrapié

NIS2 introduce un reloj de tres etapas para cualquier incidente significativo. Fallar una etapa le expone.

El reloj de 24 horas arranca en el momento en que la organización tiene conocimiento del incidente, no cuando este se produjo. La distinción pesa enormemente cuando el incidente es un empleado pegando una lista de clientes en ChatGPT a las 23:14 de un viernes. Si su DLP lo detecta el lunes a las 09:00, su reloj de 24 horas arranca a las 09:00. Si no tiene DLP y se entera tres semanas después por una queja de cliente, prepárese para preguntas incómodas sobre la madurez de su detección.

Qué cuenta como incidente significativo en el manejo de datos de IA

La directiva define el incidente significativo por su impacto, no por su mecanismo. Un incidente es significativo si ha causado o puede causar una perturbación operativa grave, pérdida financiera o daño material o inmaterial a otras personas. Para fugas de IA, tres patrones cruzan ese umbral de manera fiable:

• Datos personales de más de 100 personas saliendo del control organizativo, ya sea un CSV de clientes pegado en Claude o un transcript de soporte enviado a un resumidor de terceros. Esto también dispara en paralelo la notificación RGPD de 72 horas del artículo 33, supervisada por la AEPD.
• Datos confidenciales de negocio con impacto operativo o financiero — modelos de precios, documentos de M&A, código fuente de sistemas en producción, actas del consejo — saliendo del perímetro vía cualquier herramienta de IA, sancionada o no.
• Credenciales que habilitan brechas posteriores — claves API, JWT, cadenas de conexión de base de datos, claves privadas, tokens OAuth — exfiltradas en un prompt LLM cuyos registros del proveedor quedan ya fuera de su alcance.

Un ejemplo real: un miembro del equipo financiero pega 500 registros de clientes en ChatGPT para que le reformatee un informe. Eso es incidente significativo bajo NIS2, brecha de datos personales bajo RGPD ante la AEPD, y muy probablemente incumplimiento contractual con los clientes afectados. Tres regímenes, un solo pegado.

Las pruebas que pedirá el regulador

Los CSIRT están convergiendo en un paquete de pruebas estándar para incidentes relacionados con IA. Prepárese para entregar:

1. Marca de tiempo del prompt y de la detección, con huso horario.
2. Identidad del usuario y contexto de autenticación (sesión SSO, dispositivo, geolocalización).
3. Herramienta de destino — ¿ChatGPT, Claude, Gemini, Copilot, Perplexity, Mistral, DeepSeek o una herramienta shadow no autorizada?
4. Vista previa enmascarada del contenido filtrado — habitualmente los primeros 200 caracteres con PII oculta, lo justo para caracterizar el tipo de dato.
5. Clasificación de datos — credit_card, IBAN, DNI/NIE, api_key, password, JWT, source_code, etc.
6. Acción tomada — bloqueado, anonimizado, solo monitorizado.
7. Evaluación del alcance — cuántos registros, qué interesados, qué procesador externo retiene ahora los datos.
8. Remediación — credenciales rotadas, clientes notificados, procesador contactado para borrado.

El registro de incidentes de Zeuslock se diseñó contra esta lista exacta. Cada evento en la consola del operador en app.zeuslock.ai captura estos campos por defecto y se exporta como un único CSV que mapea uno a uno sobre la plantilla del CSIRT. Cuando el regulador pida pruebas a las 72 horas, no debería estar redactándolas desde cero.

Quién presenta el informe y cómo fluye el proceso

NIS2 no nombra un rol único, pero la práctica converge en una tríada: el CISO es dueño del informe técnico, el DPO gestiona la notificación RGPD paralela ante la AEPD cuando hay datos personales en juego, y la asesoría jurídica revisa la exposición antes del envío. En segundo plano, el informe va al CSIRT nacional.

• España: INCIBE-CERT cubre sectores no críticos, CCN-CERT cubre el sector público, y el Centro Criptológico Nacional ejerce de autoridad. La notificación se canaliza por la plataforma LUCIA.
• Francia: ANSSI opera el CERT-FR; la notificación va por MonServiceSécurisé.
• Alemania: BSI recibe las notificaciones a través del Meldeportal bajo NIS2UmsuCG.
• Países Bajos, Bélgica, Italia: NCSC-NL, CCB CERT.be, CSIRT Italia respectivamente.
• El Reino Unido queda fuera del alcance tras el Brexit pero mantiene un régimen paralelo (NIS Regulations 2018) supervisado por NCSC e ICO.

Si el incidente tiene impacto transfronterizo — una organización española filtra datos de residentes alemanes hacia un LLM alojado en EE. UU. — el CSIRT líder informa a las autoridades homólogas a través de la red EU-CyCLONe. Usted notifica una sola vez, a su CSIRT líder, pero prepárese para preguntas de otros.

Sanciones y responsabilidad personal

Las cifras de titular son fáciles de encontrar pero conviene repetirlas porque han subido bruscamente:

El cambio mayor está en el artículo 32. Por primera vez a nivel europeo, NIS2 establece explícitamente la responsabilidad personal de los órganos de dirección. Consejeros y altos directivos pueden ser considerados personalmente responsables de los fallos en la implementación de medidas de gestión de riesgos de ciberseguridad. Los Estados miembros pueden suspender a ejecutivos de funciones directivas e imponer multas individuales. Por eso su consejo le pregunta de repente por las fugas de IA en cada revisión trimestral. No están paranoicos: están leyendo la directiva.

Qué hacer este trimestre

Si no hace nada más, haga estas tres cosas antes del cierre del próximo trimestre.

1. Inventaríe su superficie IA. Liste todas las herramientas de IA en uso en la organización, autorizadas y shadow. ChatGPT, Claude, Gemini, Copilot, Cursor, Aider, Claude Code, Copilot CLI, DeepSeek, pipelines RAG internos, agentes conectados por MCP. Una extensión de navegador Zeuslock más un agente de escritorio más la CLI de Zeuslock para terminales de desarrollador hará aflorar aproximadamente el 95 % en dos semanas de telemetría. Lo que no ve, no puede notificarlo.
2. Monte un pipeline de incidentes que dispare en menos de 24 horas. Detección → triaje → notificación al CSIRT tiene que ser un único flujo con un responsable nombrado y un suplente. Webhook del DLP a Slack y PagerDuty con verificación HMAC, enrute incidentes significativos a un canal dedicado, y prerellene la plantilla del CSIRT desde el registro de incidentes. Ensáyelo de principio a fin. Si su primer simulacro tarda 36 horas, tiene un problema de 24 horas.
3. Haga un tabletop sobre una fuga por prompt. Una vez por trimestre, juegue un escenario donde un ingeniero preventa pega una tabla de clientes de 2.000 filas en Gemini a las 22:30 de un viernes. Legal, DPO, CISO y un responsable de comunicación en la mesa. Redacte la alerta al CSIRT. Redacte la notificación RGPD del artículo 33 a la AEPD. Redacte el aviso al cliente. Cronometre todo. La primera vez que lo haga en serio no debería ser cuando ocurra de verdad.

NIS2 no se aplicará con suavidad. La primera oleada de sanciones ya está cayendo en Alemania y Países Bajos por falta de notificación bajo el régimen anterior. Tome en serio el reloj de 24 horas, diseñe su manejo de datos de IA en torno a él, y mantenga un paquete de pruebas que estaría cómodo entregando a un regulador a las 09:00 de la mañana siguiente.