El CISO frente a la IA: riesgos nuevos, controles conocidos

La IA generativa entró en la organización por varias puertas a la vez: asistentes que los empleados activan por su cuenta, funciones de IA dentro de herramientas SaaS ya contratadas, proyectos internos que conectan un modelo de lenguaje con documentos y, cada vez más, agentes que consultan sistemas y ejecutan acciones. Para el CISO, la pregunta inmediata es si necesita un programa de seguridad nuevo.

La respuesta corta es no. Hay riesgos que sí son nuevos, con mecanismos que los controles clásicos no ven. Pero casi todos se gestionan con las mismas funciones que ya organizan el programa de seguridad: gobernar, identificar, proteger, detectar, responder y recuperar. El trabajo consiste en ubicar cada riesgo nuevo en esa estructura, ajustar los controles existentes y cubrir unos pocos vacíos reales. Este artículo propone ese mapeo con el NIST Cybersecurity Framework (CSF) 2.0 como columna vertebral.

Cinco riesgos que sí son nuevos

Conviene separar lo nuevo de lo que solo cambió de escala. Un correo de phishing redactado con IA es más convincente, pero el control sigue siendo el mismo. Los cinco riesgos siguientes, en cambio, tienen un mecanismo propio. Los cuatro primeros figuran en el OWASP Top 10 for LLM Applications 2025, publicado en noviembre de 2024; el quinto es un problema de gobierno más que de tecnología.

Inyección de instrucciones

Un modelo de lenguaje no distingue de forma fiable entre las instrucciones de quien diseñó la aplicación y el texto que procesa. La inyección directa la escribe el propio usuario para saltarse restricciones. La indirecta llega escondida en un correo, una página web o un documento que el sistema lee como contexto. Es el primer riesgo de la lista de OWASP y no tiene hoy una solución completa: se reduce con varias capas, no se elimina con un filtro.

Envenenamiento de datos y de modelos

Quien logra alterar los datos de entrenamiento, los de ajuste fino o la base documental que alimenta una aplicación de generación aumentada por recuperación (RAG) puede cambiar el comportamiento del sistema sin tocar una línea de código. El efecto puede ser sutil: respuestas sesgadas sobre un tema concreto, o una puerta trasera que solo se activa con una frase específica.

Fuga de información por las salidas

El modelo puede revelar datos sensibles que estaban en su contexto, en los documentos a los que tiene acceso o en sus propias instrucciones de sistema. El riesgo crece cuando la aplicación consulta repositorios con permisos más amplios que los del usuario que pregunta: el modelo responde con lo que encuentra, no con lo que ese usuario tiene derecho a ver.

Cadena de suministro de modelos

Los modelos preentrenados, los adaptadores, los conjuntos de datos y las bibliotecas que los cargan son componentes de terceros. Un modelo descargado de un repositorio público puede venir alterado, y algunos formatos de serialización permiten ejecutar código en el momento de cargarlo. A esto se suman los proveedores de modelos como servicio, que procesan datos de la organización bajo sus propias condiciones contractuales.

Uso no autorizado de IA

Empleados que pegan contratos, código o datos de clientes en servicios públicos de IA, o equipos que activan funciones de IA en una plataforma SaaS sin revisión. No es un riesgo técnico del modelo, pero suele ser el que antes se materializa, porque no necesita ningún atacante.

Dónde encaja cada riesgo en el CSF 2.0

El CSF 2.0, publicado por NIST en febrero de 2024, organiza la gestión del riesgo de ciberseguridad en seis funciones. Gobernar, la función que añadió esta versión, orienta a las otras cinco. Esa estructura sirve para la IA sin modificaciones: lo que cambia es el contenido de cada función.

El mapeo no es exclusivo. La inyección de instrucciones, por ejemplo, también se detecta y se responde; el diagrama ubica cada riesgo donde está su control principal. Para el detalle de cómo se presenta Gobernar ante el comité, puedes ver la función Gobernar del NIST CSF 2.0.

Una precisión: el CSF no es un catálogo de controles específicos de IA. Para eso NIST publicó en julio de 2024 el perfil de IA generativa del AI RMF (NIST AI 600-1), que describe doce riesgos propios o agravados por la IA generativa, entre ellos la seguridad de la información, la privacidad de los datos y la integridad de la cadena de valor y de los componentes, y propone acciones para gestionarlos. El CSF da la estructura; el perfil de NIST y la lista de OWASP dan el detalle.

De riesgo nuevo a control conocido

La tabla traduce cada riesgo a controles que un programa de seguridad maduro ya opera, con el ajuste que exige la IA. Es una orientación de partida, no una lista cerrada.

Riesgo nuevo	Función principal	Control conocido	Ajuste para IA
Uso no autorizado de IA	Gobernar	Política de uso aceptable, gestión de aplicaciones SaaS, control de navegación	Lista de servicios de IA aprobados, qué datos admite cada uno y una alternativa interna autorizada
Cadena de suministro de modelos	Identificar	Gestión de riesgo de terceros, inventario de activos, análisis de componentes	Inventario de modelos con versión y procedencia, condiciones de uso de datos del proveedor, formatos de modelo seguros
Inyección de instrucciones	Proteger	Validación de entradas, segmentación, mínimo privilegio	Todo contenido externo se trata como no confiable; se limita lo que el modelo puede hacer aunque lo engañen
Fuga de datos por las salidas	Detectar	Prevención de pérdida de datos (DLP), monitoreo de eventos	Filtro de salidas, permisos del usuario aplicados al recuperar documentos, registro de entradas y respuestas
Agente con acciones indebidas	Responder	Playbooks de incidentes, revocación de accesos	Interruptor de apagado del agente, revocación de sus credenciales, conservación de registros para el análisis
Datos o modelo envenenados	Recuperar	Copias de seguridad, puntos de restauración, gestión de cambios	Versiones de datasets, índices y modelos para volver a un estado confiable conocido

Fíjate en la última columna: casi ninguna fila exige una herramienta nueva. Exige extender el alcance de procesos que ya existen. El inventario de activos tiene que incluir modelos y fuentes de datos; la gestión de terceros tiene que preguntar qué hace el proveedor con las instrucciones y los documentos que recibe; el registro de eventos tiene que capturar lo que entra y lo que sale del modelo. En entidades financieras sujetas a DORA, los proveedores de modelos como servicio forman parte además del registro de proveedores TIC; lo detallamos en DORA y proveedores de TI.

Lo que sí hay que construir

Tres piezas no existen en la mayoría de los programas de seguridad y conviene construirlas a propósito.

Modelado de amenazas específico

Las metodologías de modelado de amenazas siguen sirviendo, pero el catálogo de técnicas de ataque es distinto. MITRE ATLAS organiza tácticas y técnicas contra sistemas de IA con una estructura similar a la de ATT&CK, y es un buen punto de partida para que el equipo de seguridad y el de ciencia de datos hablen el mismo idioma. Cada aplicación de IA con acceso a datos sensibles o a herramientas debería pasar por este ejercicio antes de llegar a producción.

Pruebas adversarias

Las pruebas de penetración tradicionales no cubren la inyección de instrucciones ni la fuga por las salidas. Hace falta un conjunto de pruebas adversarias (red teaming de IA) que se ejecute antes de cada cambio relevante de modelo, de instrucciones o de fuentes de datos. NIST AI 600-1 incluye las pruebas previas al despliegue entre sus consideraciones principales.

Registro con criterio de privacidad

Para detectar y responder hay que registrar instrucciones, contexto recuperado, respuestas y llamadas a herramientas. Esos registros contienen, por definición, datos sensibles. Su retención, su acceso y su enmascaramiento deben definirse con el área de protección de datos antes de activar el registro, no después del primer incidente.

Un plan de arranque para el CISO

Si la organización ya tiene un programa alineado con el CSF, estos pasos permiten incorporar la IA sin crear una estructura paralela:

1. Inventariar. Listar los servicios de IA en uso (aprobados o no), las aplicaciones internas con modelos y los agentes con acceso a sistemas. Las fuentes habituales son el proxy de navegación, el catálogo de aplicaciones SaaS y los equipos de desarrollo.
2. Fijar la política. Publicar qué servicios están aprobados, para qué tipos de datos y cuál es el canal para pedir uno nuevo. Una prohibición sin alternativa empuja el uso fuera de la vista.
3. Clasificar por exposición. Separar los usos que solo generan texto para una persona de los que consultan datos sensibles o ejecutan acciones. Los segundos pasan por modelado de amenazas y pruebas adversarias.
4. Extender los controles existentes. Añadir modelos y datasets al inventario de activos, los proveedores de IA a la gestión de terceros y los escenarios de IA a los playbooks de incidentes.
5. Medir y reportar. Incorporar al tablero de riesgo indicadores simples: usos inventariados, porcentaje con evaluación de riesgo e incidentes relacionados con IA.

Si la organización busca además un sistema de gestión certificable para la IA, ISO/IEC 42001 encaja con este enfoque; lo explicamos en ISO/IEC 42001 en la práctica. Y si el siguiente paso son agentes que actúan sobre la infraestructura, el contexto está en agentes de IA en la operación de TI.

Antes de fijar la política de uso y los criterios de clasificación, conviene validarlos con Cumplimiento, Legal y el área de protección de datos, porque tocan obligaciones regulatorias y laborales.