Lo esencial
- La seguridad de la IA consiste en proteger los datos, los modelos, las canalizaciones y las interfaces de un sistema de IA a lo largo de todo su ciclo de vida. Es una disciplina distinta del uso de la IA al servicio de las operaciones de seguridad.
- Con el Reglamento europeo de IA, la seguridad de la IA ya no es opcional: el artículo 15 exige a los sistemas de alto riesgo un nivel adecuado de exactitud, solidez y ciberseguridad, incluida la resistencia a los ataques adversarios y al envenenamiento de datos.
- Las amenazas son propias del aprendizaje automático: ejemplos adversarios, envenenamiento de datos y modelos, robo de modelo, inyección de instrucciones y tratamiento inseguro de las salidas, recogidos en el OWASP Top 10 para aplicaciones LLM y en MITRE ATLAS.
- No se protege lo que no se ha inventariado: el registro de los sistemas de IA y la detección de la IA en la sombra son el primer control, no un detalle posterior.
- Las organizaciones que aciertan tratan la seguridad de la IA como un conjunto de controles gobernado, vinculado al Reglamento europeo, a la ISO/IEC 42001 y al NIST AI RMF, respaldado por pruebas que un auditor aceptará en lugar de un panel de control.
¿Qué es la seguridad de la IA?
La seguridad de la IA es la práctica de proteger un sistema de IA y todo aquello de lo que depende: los datos de entrenamiento e inferencia, el modelo en sí, las canalizaciones que lo construyen y lo sirven, y las interfaces que lo exponen a los usuarios y a otros sistemas. Abarca todo el ciclo de vida, desde la recogida de datos hasta el entrenamiento, la puesta en producción, la supervisión y la retirada.
Una distinción suele confundir las primeras conversaciones, conviene enunciarla con claridad. Usar la IA para la seguridad significa aplicar el aprendizaje automático a tareas defensivas, por ejemplo la detección de anomalías o la clasificación de alertas. La seguridad de la IA, objeto de esta guía, significa proteger el propio sistema de IA frente a ataques y fallos. La distinción importa, porque ambas requieren responsables, controles y pruebas diferentes.
¿Por qué pesa esta distinción en el cumplimiento? Porque los reguladores tratan ya la seguridad del sistema de IA como una obligación expresa. El Reglamento europeo reúne exactitud, solidez y ciberseguridad en un solo artículo para los sistemas de alto riesgo (artículo 15 del Reglamento de IA). En cuanto la seguridad pasa a ser un requisito legal y no una preferencia de ingeniería, exige gobernanza: controles definidos, responsabilidad asignada y registros que demuestren que los controles funcionan.
Por qué la seguridad de la IA es hoy un requisito de cumplimiento
Durante una década, asegurar un modelo fue una buena idea confinada a la ingeniería. Eso ha cambiado. Tres instrumentos convierten hoy la seguridad de la IA en una obligación documentada.
En primer lugar, el Reglamento europeo de IA. El artículo 15 obliga a los proveedores de sistemas de alto riesgo a diseñarlos para alcanzar un nivel adecuado de exactitud, solidez y ciberseguridad, y a mantener esas propiedades a lo largo de la vida del sistema. El texto nombra al adversario sin rodeos: los sistemas deben resistir los intentos de terceros no autorizados de alterar su uso, sus salidas o su rendimiento, incluidos los ataques adversarios y el envenenamiento de datos.
En segundo lugar, la ISO/IEC 42001. La norma de 2023 es el primer sistema de gestión de la IA certificable, y sus controles del anexo A integran la seguridad de la IA, la gobernanza de los datos y la mitigación de los ataques adversarios en un sistema que un organismo externo puede auditar (ISO/IEC 42001). La seguridad encuentra así un lugar dentro de un ciclo gobernado en lugar de en una lista de pendientes.
En tercer lugar, el marco de gestión de riesgos de IA del NIST. El NIST organiza el trabajo en cuatro funciones, Gobernar, Mapear, Medir y Gestionar, y en la función Gestionar residen los controles de seguridad (NIST AI RMF). Leído junto con la correspondencia de marcos de nuestra guía de referentes, convierte la seguridad en una rutina repetible y documentada.
La brecha entre obligación y capacidad sigue siendo amplia. En una evaluación de Microsoft sobre 28 organizaciones, 25 carecían de las herramientas adecuadas para asegurar sus sistemas de IA. Es el cumplimiento lo que cierra esa brecha, porque obliga al inventario, a la selección de controles y a la prueba, en lugar de dejar la seguridad a quien se acuerde de pedirla.
El panorama de amenazas a la IA
Proteger un sistema de IA empieza por saber contra qué se defiende uno. Los ataques a la IA no se ajustan a la seguridad de aplicaciones clásica, porque el modelo, los datos y la instrucción son todos superficies de ataque. Conviene agrupar las amenazas por objetivo. La base de conocimiento MITRE ATLAS recoge estas técnicas en una matriz inspirada en ATT&CK, y nuestra guía de MITRE ATLAS recorre la correspondencia entre técnica y control.
Ataques al modelo
Los ejemplos adversarios son entradas diseñadas para hacer que el modelo clasifique mal aunque parezcan normales al ojo humano. Los ataques por evasión los emplean en la inferencia para sortear un clasificador. La extracción de modelo, es decir, el robo de modelo, consulta un modelo en producción las veces suficientes para reconstruir una copia funcional, sustrayendo propiedad intelectual y creando un modelo en la sombra que el atacante puede sondear sin conexión.
Ataques a los datos
El envenenamiento corrompe el conjunto de entrenamiento para que el modelo aprenda lo equivocado, desde una degradación sutil de la exactitud hasta puertas traseras ocultas que se activan con una entrada elegida. Los ataques por inferencia de pertenencia hacen lo contrario: comprueban si un registro concreto estaba en los datos de entrenamiento, lo que puede exponer información personal o confidencial.
Ataques a la capa de aplicación
En los sistemas construidos sobre grandes modelos de lenguaje, la capa de aplicación es hoy el blanco más blando. El OWASP Top 10 para aplicaciones LLM encabeza la lista con la inyección de instrucciones, con la que un atacante oculta instrucciones en una consulta, un documento o la salida de una herramienta para sortear las salvaguardas del modelo, exfiltrar datos o desencadenar acciones a través de las herramientas conectadas. El tratamiento inseguro de las salidas, cuando la respuesta del modelo se propaga sin validación, convierte un defecto de lenguaje en un compromiso del sistema.
Cadena de suministro y riesgos agenticos
Modelos, conjuntos de datos y bibliotecas provienen de terceros, de modo que un modelo de pesos abiertos envenenado o una dependencia comprometida constituyen un riesgo de cadena de suministro. Los sistemas agenticos, capaces de invocar herramientas y de actuar sobre sus propias salidas, amplian el radio de impacto: una sola inyección lograda puede propagarse en acciones reales. Nuestra guía de agentes de IA autónomos trata los controles de gobernanza que estos sistemas necesitan.
No se protege lo que no se ve: inventario de IA e IA en la sombra
Cada control que sigue presupone que usted sabe qué sistemas de IA opera. La mayoría de las organizaciones no lo sabe. Los equipos adoptan copilotos, integran modelos de terceros y conectan agentes más rápido de lo que cualquier función central puede seguir, generando IA en la sombra: IA en uso que la gobernanza nunca ha visto.
La IA en la sombra es un problema de seguridad antes que de cumplimiento. Un modelo no registrado no tiene responsable, ni evaluación de amenazas, ni supervisión, ni vía de gestión de incidentes. El primer control de un programa de seguridad de la IA no es, por tanto, un cortafuegos, sino un inventario. Un registro vivo de los sistemas de IA, de sus datos, sus modelos y su nivel de riesgo es lo que hace posible cada control posterior. Nuestra guía de la IA en la sombra explica cómo el uso oculto de la IA se convierte en una laguna de gobernanza y por qué el descubrimiento es el control cero.
Vincular la seguridad de la IA a los marcos: Reglamento de IA, ISO 42001, NIST AI RMF
El movimiento que ninguna página de la competencia realiza consiste en vincular cada amenaza al control que la responde y a la cláusula que lo exige. Es esto lo que convierte la seguridad de la IA, de una lista de la compra de herramientas, en una posición de cumplimiento defendible.
| Obligación | Qué exige | Control que la satisface |
|---|---|---|
| Artículo 15 (solidez) | Resistencia a errores, fallos y manipulación adversaria | Pruebas adversarias y red teaming, pruebas fuera de distribución |
| Artículo 15 (ciberseguridad) | Resistencia a la alteración no autorizada del uso, las salidas o el rendimiento | Control de accesos, integridad del modelo y los datos, servicio seguro |
| ISO/IEC 42001 anexo A | Controles de seguridad de la IA gestionados en un sistema certificado | Conjunto de controles documentado, responsable designado, ciclo de revisión |
| NIST AI RMF (Gestionar) | Tratamiento priorizado de los riesgos de IA identificados | Registro de riesgos, correspondencia de controles, supervisión |
Construya la correspondencia una vez y cada auditoría se vuelve una consulta en lugar de una carrera. La explicación de la ISO 42001 y la guía del NIST AI RMF profundizan en cada lado, y la guía operativa del Reglamento de IA sitúa el artículo 15 entre las obligaciones más amplias de los sistemas de alto riesgo.
De las amenazas a controles auditables
Una amenaza que no se puede probar es una amenaza que no se puede defender en una auditoría. Cada clase de amenaza debería, por tanto, resolverse en un control nombrado, con un responsable y un registro.
- Ataques adversarios y por evasión: pruebas adversarias y red teaming programados, con resultados registrados y repetidos cada vez que cambia el modelo.
- Envenenamiento de datos: trazabilidad y procedencia de los datos, controles de integridad en la canalización de entrenamiento.
- Robo de modelo: limitación de frecuencia, supervisión de consultas y control de accesos en los puntos de inferencia.
- Inyección de instrucciones y salidas inseguras: validación de entradas y salidas, listas de autorización de herramientas, aislamiento entre el modelo y las acciones posteriores.
- Deriva y obsolescencia: supervisión continua del rendimiento y el comportamiento, con umbrales que generan una alerta.
El sentido de formular los controles así no es la lista, sino la prueba. Un panel muestra un estado en el instante presente; un auditor necesita un registro a lo largo del tiempo. Cada control debería producir un artefacto fechado: un informe de prueba, un registro de supervisión, una revisión de accesos. Nuestra guía de auditabilidad expone qué hace auditable a un sistema de IA y cómo demostrarlo, y la supervisión continua del cumplimiento es el modo en que esos artefactos se acumulan sin carreras manuales antes de cada revisión.
¿Quién responde de la seguridad de la IA? Funciones y gobernanza
La seguridad de la IA fracasa cuando cada cual da por hecho que se ocupa otro. La ciberseguridad clásica recae en el CISO, pero la seguridad de la IA atraviesa la ciencia de datos, el MLOps y el cumplimiento, de modo que la responsabilidad ha de ser explícita.
Un reparto viable asigna la rendición de cuentas a un responsable o a un comité de gobernanza de la IA, con el CISO a cargo de los controles de seguridad, la ciencia de datos a cargo de las pruebas del modelo y el cumplimiento a cargo de las pruebas y la correspondencia con los marcos. Una breve matriz de responsabilidades, acordada una vez, evita el fallo común de que un modelo se publique sin un responsable de su seguridad. Esta capa de gobernanza es el tema de nuestra guía del sistema operativo de la gobernanza de la IA, que muestra cómo se conectan estas funciones con el entorno de control más amplio.
Cómo poner en marcha un programa de seguridad de la IA
Traducir estas ideas en un programa en funcionamiento es una secuencia, no un proyecto con fecha de fin.
- Inventariar cada sistema de IA, incluida la IA en la sombra, y asignar a cada uno un nivel de riesgo.
- Realizar una evaluación de amenazas y riesgos por sistema, usando el OWASP LLM Top 10 y MITRE ATLAS como listas de verificación.
- Seleccionar controles a partir de su correspondencia con los marcos y asignar a cada uno un responsable.
- Probar los controles: pruebas adversarias, red teaming y validación, dimensionados al nivel de riesgo.
- Recoger las pruebas como artefactos fechados para cada control.
- Supervisar de forma continua la deriva, los abusos y las nuevas vulnerabilidades.
- Integrar la gestión de incidentes, incluida la notificación regulatoria cuando proceda. El Reglamento europeo fija obligaciones de notificación de incidentes graves, tratadas en nuestra guía de notificación conforme al artículo 73.
Ejecute la secuencia como un bucle. Cada nuevo modelo vuelve a entrar en el paso uno, y cada cambio sustancial reactiva las pruebas y la evidencia.
Preguntas frecuentes
¿Qué es la seguridad de la IA, en pocas palabras?
La seguridad de la IA es proteger un sistema de IA, sus datos, su modelo, sus canalizaciones y sus interfaces frente a ataques y fallos a lo largo de su ciclo de vida. Se distingue del uso de la IA para tareas de seguridad como la detección de amenazas. En un contexto de cumplimiento también abarca obligaciones expresas, como el requisito del artículo 15 del Reglamento europeo de que los sistemas de alto riesgo mantengan exactitud, solidez y ciberseguridad.
¿Cuál es la diferencia entre seguridad de la IA y ciberseguridad?
La ciberseguridad clásica protege redes, aplicaciones y puntos finales. La seguridad de la IA añade superficies de ataque que los controles clásicos no cubren: los datos de entrenamiento, el comportamiento aprendido del modelo y la instrucción. Un cortafuegos no detiene ni el envenenamiento de datos ni la inyección de instrucciones. La seguridad de la IA extiende, pues, la ciberseguridad con controles conscientes del modelo, como pruebas adversarias, trazabilidad de datos y validación de salidas, y los vincula a los marcos propios de la IA.
¿Cuáles son las principales amenazas a la IA?
Las clases recurrentes son los ejemplos adversarios y los ataques por evasión a los modelos, el envenenamiento de datos y modelos, el robo o la extracción de modelo, la inferencia de pertenencia, la inyección de instrucciones y el tratamiento inseguro de salidas en la capa de aplicación, y los riesgos de cadena de suministro por modelos y bibliotecas de terceros. El OWASP Top 10 para aplicaciones LLM y MITRE ATLAS son los dos catálogos de referencia que la mayoría de los equipos usa para comprobar que no falta ninguna categoría.
¿El Reglamento europeo de IA exige la seguridad de la IA?
Sí. El artículo 15 obliga a los proveedores de sistemas de alto riesgo a alcanzar y mantener un nivel adecuado de exactitud, solidez y ciberseguridad, estable durante toda la vida del sistema. Nombra expresamente la resistencia a los ataques adversarios y al envenenamiento de datos. La seguridad es, por tanto, una obligación documentada para los sistemas de alto riesgo, no una práctica de ingeniería opcional.
¿Cómo se relacionan ISO 42001 y NIST AI RMF con la seguridad de la IA?
La ISO/IEC 42001 es un sistema de gestión de la IA certificable cuyos controles del anexo A incluyen la seguridad de la IA, dándole un hogar gobernado y auditable. El NIST AI RMF organiza el trabajo en Gobernar, Mapear, Medir y Gestionar, con los tratamientos de seguridad situados en la función Gestionar. Juntos permiten vincular cada control de seguridad a una cláusula reconocida, lo que hace de la auditoría una consulta en lugar de una carrera.
¿Por dónde empezar un programa de seguridad de la IA?
Por el inventario. No se puede asegurar, probar ni atestiguar un sistema de IA que no se ha registrado, y la mayoría de las organizaciones opera IA en la sombra que la gobernanza nunca ha visto. Construya un registro vivo de los sistemas de IA con sus datos, modelos y niveles de riesgo, realice después las evaluaciones de amenazas, seleccione controles vinculados a los marcos, pruébelos y recoja evidencias fechadas. El inventario es el control cero; todo lo demás depende de él.
Conclusión
La seguridad de la IA ha pasado de refinamiento de ingeniería a obligación de cumplimiento expresa, y las páginas que se posicionan para el término no se han puesto al día: describen amenazas y venden herramientas, sin vincular la seguridad a los marcos que ahora la exigen. Las organizaciones que lo hacen bien tratan la seguridad de la IA como un conjunto de controles gobernado, vinculado al Reglamento europeo, a la ISO 42001 y al NIST AI RMF, partiendo de un inventario honesto para llegar a pruebas que un auditor aceptará. AI Sigil está construido para ejecutar exactamente ese bucle, desde el descubrimiento de la IA hasta la correspondencia de controles y las pruebas listas para auditoría. Vea cómo el sistema operativo de la gobernanza de la IA convierte la seguridad de la IA en una capacidad defendible y continua.