NIS2 y su stack de IA: ¿quién responde cuando un agente actúa?

La directiva NIS2 amplió la red de ciberseguridad europea de unos cientos de operadores a decenas de miles de «entidades esenciales e importantes» — y desplazó la responsabilidad hacia arriba: los órganos de dirección deben aprobar las medidas de riesgo y pueden responder personalmente por negligencia grave. Eso cambia la conversación sobre IA. Un agente autónomo que lee tickets, redacta correos y llama a APIs no es una herramienta de productividad en términos de NIS2; es a la vez parte de su superficie de ataque y de su cadena de suministro.

Tres preguntas que hará su auditor de NIS2 sobre la IA

• ¿Quién autorizó a este agente, y para qué? Un prompt no es una autorización. Necesita un registro duradero de qué herramientas puede invocar un agente, con qué presupuesto y en qué ámbito — y la prueba de que no puede exceder esa autoridad.
• ¿Qué ocurre si resulta comprometido? La inyección de prompts es el ataque a la cadena de suministro de la era de la IA. El artículo 21 espera medidas documentadas contra exactamente esta clase de incidente — y evidencia de que una entrada secuestrada no puede convertirse en una acción secuestrada.
• ¿Puede mostrar el rastro? Los plazos de notificación de NIS2 son brutales — alerta temprana en 24 horas. Si su actividad de IA está dispersa en logs SaaS que usted no controla, no podrá reconstruir los hechos a tiempo.

La respuesta arquitectónica

La gobernanza que vive en documentos de políticas suspende estas preguntas; la que vive en la ruta de ejecución las aprueba. Contratos de autoridad firmados y aplicados en cada ejecución, una defensa de dos puertas que examina contenido y acciones por separado, egreso denegado por defecto en cada conector y un registro de auditoría inmutable que ningún administrador puede reescribir — así la respuesta a NIS2 deja de ser arqueología y pasa a ser una consulta a la base de datos.

La lista práctica

• Inventaríe cada punto donde un sistema de IA puede actuar, no solo responder.
• Vincule cada agente a una autoridad explícita y revocable: herramientas, presupuesto, ámbito, caducidad.
• Exija comportamiento fail-closed donde la seguridad esté en juego, y estado veraz cuando no se esté aplicando.
• Mantenga la evidencia dentro de su perímetro — el regulador no aceptará «los logs los tiene nuestro proveedor».