Marco de referencia · Seguridad de los sistemas de IA
La ISO 27090 describe cómo los atacantes pueden comprometer sistemas de IA y cómo detectar y contener esos ataques. Sightadel le ayuda a evaluar estas amenazas para cada sistema de IA y a gestionar las medidas allí donde ya están sus evidencias para la ISO 27001, la ISO 42001 y el Reglamento de IA.
De qué se trata
La primera edición de la ISO 27090 se publicó en octubre de 2026. La norma trata las amenazas de seguridad que afectan específicamente a los sistemas de IA. Describe qué consecuencias puede tener un ataque a lo largo del ciclo de vida de un sistema y cómo detectar y mitigar esos ataques. Está pensada para organizaciones de todo tipo y tamaño que desarrollan o utilizan sistemas de IA.
Se trata de ataques que no existen de esta forma en el software convencional. ISO menciona como ejemplos el envenenamiento de los datos de entrenamiento y el robo de un modelo mediante consultas aparentemente inofensivas. Artículos especializados sobre la norma citan otros tipos, como entradas manipuladas que engañan a un modelo, la inyección de prompts o las inferencias sobre los datos de entrenamiento. La norma también ayuda a aclarar qué hay que proteger, desde los datos de entrenamiento hasta el modelo final.
La ISO 27090 es una guía. No contiene requisitos con los que un organismo certifique ni un sistema de gestión propio. ISO la presenta como complemento de la ISO 27001 y la ISO 27002: quien opera un SGSI incorpora las amenazas específicas de la IA a la apreciación de riesgos y elige los controles adecuados. Por ahora, la norma solo existe en inglés.
Clientes y compras preguntan cómo protege los modelos y los datos de entrenamiento frente a manipulaciones. La norma le da un lenguaje común para estas respuestas y una lista de ataques que debería haber revisado.
Aunque solo use un modelo de lenguaje a través de un proveedor, está afectado, por ejemplo cuando el texto de correos o documentos lleva al sistema a una acción equivocada. Aquí lo importante es la elección del proveedor, la configuración y la supervisión.
Si opera la ISO 27001 o la ISO 42001, no necesita un proceso nuevo. Las amenazas de la ISO 27090 se incorporan a la apreciación de riesgos existente y las medidas al plan de tratamiento existente.
Requisitos
Resumido con nuestras propias palabras. Prevalece siempre el texto original en su versión vigente.
Sabe qué sistemas de IA desarrolla o utiliza y qué partes requieren protección: datos de entrenamiento, modelos, entradas y salidas.
En SightadelRegistra los sistemas de IA y sus componentes como activos con un responsable. Un inventario de IA de la ISO 42001 se reutiliza.
Se conocen los tipos de ataque posibles para sus sistemas, por ejemplo el envenenamiento de datos o el robo de modelos, así como el daño que causaría un ataque con éxito.
En SightadelRegistra las amenazas por sistema de IA en el registro de riesgos, evaluadas y vinculadas a los activos afectados.
Los ataques se asignan a las fases en las que actúan: desarrollo, operación y actualización del modelo.
En SightadelLos puntos pendientes de cada fase se convierten en planes de acción con responsable y plazo.
Se estiman las consecuencias de un ataque, sobre todo allí donde la IA interviene en aplicaciones críticas para la seguridad o en decisiones importantes.
En SightadelLa valoración figura junto al riesgo y la justificación en el comentario. El registro de actividad muestra quién decidió qué y cuándo.
Para las amenazas relevantes se eligen controles que permiten detectar ataques o limitar su efecto.
En SightadelCada control con estado, responsable y evidencia. El mismo control puede cubrir también un requisito de la ISO 27001 o de la ISO 42001.
Los datos de entrenamiento, los modelos preentrenados y los servicios de IA de terceros se tratan como una posible vía de entrada. Sabe de dónde proceden y quién puede modificarlos.
En SightadelEvalúa a los proveedores de datos, modelos y servicios de IA en el módulo Proveedores, con cuestionario y evidencias.
Durante la operación vigila señales de ataque, como patrones de consulta inusuales. Los incidentes en sistemas de IA pasan por el proceso habitual de gestión de incidentes.
En SightadelLo aprendido de los incidentes se convierte en medidas con plazo, y el historial queda visible en el registro de actividad.
Las amenazas específicas de la IA forman parte de la apreciación de riesgos del SGSI y los controles del plan de tratamiento.
En SightadelVincula las evidencias una vez y las usa para la ISO 27001, la ISO 42001 y el Reglamento de IA.
Proceso
De dos a cuatro meses hasta el análisis de amenazas y el plan de medidas de los sistemas de IA más importantes, si ya funciona un SGSI. Implantar los controles técnicos puede llevar más tiempo.
Listar todos los sistemas de IA, también los servicios contratados. Anotar para cada sistema qué datos, modelos e interfaces le pertenecen.
Revisar con la norma qué tipos de ataque son relevantes para cada sistema y en qué fase actúan.
Estimar consecuencias y probabilidad, primero los sistemas críticos. Los resultados pasan al registro de riesgos existente.
Elegir contramedidas, nombrar responsables y respaldar la implantación con evidencias. Planificar los controles técnicos junto con desarrollo y operaciones.
Observar la operación, volver a evaluar tras cambios de modelo y cuando se conozcan nuevos tipos de ataque, y llevar los resultados a la revisión por la dirección.
Listo para empezar
Quien aclara pronto estas preguntas se ahorra semanas después. En Sightadel están creadas como primeras tareas.
Reparto del trabajo
Si un software lo rellenara todo, la norma no cumpliría su finalidad, y el auditor lo notaría. Por eso está claramente definido qué queda en sus manos.
De la práctica
De muchos años de experiencia en consultoría y certificación: estos son los puntos que más tiempo cuestan o que provocan no conformidades en la auditoría.
Cortafuegos y control de acceso no protegen frente a datos de entrenamiento envenenados o entradas manipuladas. Revise aparte los ataques dirigidos al propio modelo.
Los modelos de lenguaje en software estándar y servicios en la nube también cuentan. Precisamente ahí funcionan los ataques a través de las entradas, aunque no entrene un modelo propio.
Para la ISO 27090 no existe. Planifique la acreditación a través de la auditoría de la ISO 27001 o la ISO 42001 o de una revisión externa.
Implantarla ayuda con el art. 15 del Reglamento de IA, pero no demuestra su cumplimiento. Compruebe por separado las obligaciones legales.
Sin desarrollo ni responsables de datos, el análisis de amenazas se queda en teoría. Quien construye o opera el modelo tiene que estar en la mesa.
Los modelos, datos y tipos de ataque nuevos cambian la situación continuamente. Defina desencadenantes para nuevas valoraciones y revise con regularidad los sistemas críticos.
Una evidencia, varios frameworks
No damos a propósito un porcentaje: depende de su alcance. Donde los requisitos coinciden, una misma evidencia queda vinculada a todos.
ISO describe la ISO 27090 como complemento de la ISO 27001 y la 27002. La apreciación de riesgos, el plan de tratamiento, el proceso de incidentes y la auditoría interna del SGSI sostienen también los controles para sistemas de IA.
ISO 42001El sistema de gestión de IA exige una apreciación de riesgos para los sistemas de IA. La ISO 27090 aporta la parte sobre ataques dirigidos, y el inventario de IA sirve para ambas.
EU AI ActEl art. 15 exige solidez y ciberseguridad para los sistemas de IA de alto riesgo, también de forma expresa frente al envenenamiento de datos, la evasión del modelo y los ataques a la confidencialidad. La ISO 27090 ayuda a implantarlo, pero no es una norma armonizada.
RGPDLos ataques que permiten inferencias sobre los datos de entrenamiento pueden revelar datos personales. Para la privacidad en la IA, ISO trabaja en la norma hermana ISO 27091, que aún no se ha publicado.
Auditoría y acreditación
No es posible certificarse según la ISO 27090. La norma es una guía y no contiene requisitos auditables. Se hace visible a través de los sistemas de gestión en los que la integra: en la auditoría de la ISO 27001 o la ISO 42001 muestra cómo ha evaluado y tratado las amenazas a los sistemas de IA.
Si quiere una mirada independiente, encargue una revisión externa del análisis de amenazas y de las medidas. Sightadel no revisa. Usted elige un revisor de nuestra red de socios independiente o uno de su elección, y por las revisiones no se paga ninguna comisión, ni a nosotros ni a los socios. El revisor obtiene en Sightadel un acceso propio a respuestas, justificaciones y evidencias y no puede eliminar nada.
Ir a la red de auditores independientesLa ISO 27090 se centra en las amenazas que afectan solo o sobre todo a los sistemas de IA. Las asigna al ciclo de vida, describe sus posibles consecuencias y muestra formas de detectar y mitigar los ataques. La descripción de la norma por parte de ISO menciona expresamente el envenenamiento de los datos de entrenamiento y el robo de un modelo mediante consultas que parecen un uso normal. También destaca las consecuencias en aplicaciones críticas para la seguridad.
La norma no redefine la seguridad de la información en general. El control de acceso, el cifrado, el registro, la gestión de vulnerabilidades y la continuidad siguen siendo cosa de la ISO 27001 y la 27002. La ISO 27090 interviene donde esos controles no bastan para la IA, por ejemplo cuando un atacante cambia el comportamiento de un modelo a través de datos o entradas sin tomar el control de un servidor.
La equidad, la transparencia o el impacto en las personas afectadas tampoco son su tema. Para eso existen la ISO 42001, con apreciación de riesgos y evaluación de impacto para la IA, y el Reglamento de IA de la UE. Para la privacidad en la IA, ISO elabora la norma hermana ISO 27091. Quien implante la norma debe conocer esta delimitación para que las responsabilidades no se asignen dos veces o ninguna.
La norma en sí se compra a ISO o a un organismo nacional de normalización. No necesita un organismo de certificación, porque no hay certificado. Licencia de Sightadel para la ISO 27090: Precio bajo consulta. Si ya gestiona la ISO 27001 o la ISO 42001 en Sightadel, sigue usando el registro de riesgos, los controles y las evidencias.
La partida más grande es el tiempo de los especialistas. Un análisis de amenazas para sistemas de IA no lo puede hacer solo el equipo de seguridad de la información. Necesita personas que conozcan los modelos, los datos y las interfaces: desarrollo, responsables de datos, operaciones y, en servicios contratados, compras. Cuente con varias sesiones de trabajo por cada sistema de IA crítico.
Implantar controles técnicos puede resultar caro, por ejemplo comprobaciones adicionales de los datos de entrenamiento, límites de consultas o pruebas con entradas manipuladas a propósito. Conviene avanzar por criticidad y empezar por los sistemas en los que un ataque causaría más daño. Donde falte experiencia, puede contratar asesoramiento como paquete dentro de la aplicación.
En su art. 15, el Reglamento de IA de la UE exige que los sistemas de IA de alto riesgo alcancen un nivel adecuado de precisión, solidez y ciberseguridad durante todo su ciclo de vida. Entre los ataques citados figuran el envenenamiento de datos, el envenenamiento de modelos, las entradas manipuladas para la evasión del modelo, los ataques a la confidencialidad y los defectos del modelo. Esto coincide en gran medida con los temas de la ISO 27090.
Aun así, la norma no es una prueba de conformidad. No es una norma armonizada con referencia publicada en el Diario Oficial de la UE y, por tanto, no genera la presunción de que se cumple el art. 15. CEN-CENELEC elabora una norma europea propia sobre la ciberseguridad de los sistemas de IA en el marco del reglamento, que por ahora solo existe como proyecto. Tras el aplazamiento de 2026, las obligaciones para sistemas de alto riesgo se aplican desde diciembre de 2027 para sistemas independientes y desde agosto de 2028 para la IA en productos regulados.
Si su sistema se considera de alto riesgo y qué obligaciones se derivan de ello es algo que debe comprobar por separado, preferiblemente con su asesoría jurídica. Sightadel no ofrece asesoramiento jurídico al respecto. Para las obligaciones legales, Sightadel tiene un framework propio para el Reglamento de IA, que gestiona con las mismas evidencias.
El menor esfuerzo se consigue cuando usa la ISO 27090 como fuente de conocimiento para procesos existentes. En la apreciación de riesgos según la ISO 27001 añade para cada sistema de IA las amenazas de la norma. Los controles elegidos van al plan de tratamiento y, cuando van más allá del anexo A, a la Declaración de aplicabilidad como controles adicionales.
Si opera la ISO 42001, el inventario de IA ya le da la lista de sistemas, sus finalidades y sus responsables. La apreciación de riesgos de la IA pregunta allí por los riesgos para la organización y para las personas afectadas. La ISO 27090 ayuda a completar bien la parte sobre ataques dirigidos, en lugar de despacharla con frases generales sobre seguridad informática.
En Sightadel, las amenazas, los controles y las evidencias están vinculados al sistema de IA correspondiente. El mismo control, por ejemplo una comprobación del origen de los datos de entrenamiento, lo vincula con la ISO 27001, la ISO 42001 y el Reglamento de IA. Así lo mantiene una sola vez y ve en cada framework dónde cuenta. En la auditoría interna comprueba después si los controles para sistemas de IA funcionan como estaba previsto.
En el envenenamiento de datos, un atacante introduce datos manipulados en el entrenamiento para que el modelo reaccione después de forma errónea o a su favor. Esto importa sobre todo si entrena o reentrena modelos por su cuenta, por ejemplo con datos de internet, de clientes o de proveedores de servicios. Protegen las fuentes conocidas, las comprobaciones antes del entrenamiento y unos permisos claros sobre quién puede modificar los datos.
En el robo de modelos, un atacante lanza muchas consultas y, a partir de las respuestas, construye un modelo que se comporta de forma parecida. Afecta sobre todo a proveedores cuyo modelo es accesible a través de una interfaz. Los patrones de consulta inusuales y los límites por usuario son aquí puntos de partida evidentes. Si solo contrata IA, este ataque suele afectarle menos.
En los sistemas con modelos de lenguaje se añade la inyección de prompts: instrucciones ocultas en entradas, correos o documentos hacen que el sistema eluda reglas o revele datos. Esto afecta también a empresas que solo usan IA a través de un proveedor. Qué ataques describe la norma en detalle lo encontrará en su texto. Sightadel no contiene el texto literal.
Como no hay certificado, nadie prescribe una documentación concreta. Resultan útiles, también en auditorías de la ISO 27001 o la ISO 42001, una lista de los sistemas de IA con las partes que hay que proteger, el análisis de amenazas por sistema, los controles elegidos con su justificación y evidencias de que están implantados y son eficaces. Deje constancia de quién hizo cada valoración y cuándo.
Los sistemas de IA cambian más deprisa que muchos otros sistemas. Un modelo nuevo en el proveedor, un conjunto de datos nuevo o una interfaz nueva pueden cambiar la valoración. Defina qué cambios desencadenan un nuevo análisis y haga de la comprobación un paso fijo en las compras y la puesta en producción. Tras un incidente o cuando se conozca un ataque nuevo, revise los sistemas afectados fuera del calendario.
En Sightadel, las nuevas valoraciones, las revisiones de proveedores, la auditoría interna y la revisión por la dirección funcionan como ciclos recurrentes con fecha. En el Trust Center muestra a sus clientes cómo protege los sistemas de IA sin reunir documentos nuevos para cada solicitud.
Cuánto cuesta
Solo paga por los frameworks que realmente necesita. Las ediciones se diferencian en capacidad y tiempo de respuesta, no en el alcance técnico. Quien gestiona varios frameworks ahorra de forma permanente. Todos los precios, descuentos y una calculadora están en la página de precios.
Los honorarios del organismo de certificación o de auditoría se los factura este directamente a usted. Si lo necesita, puede contratar consultoría como paquete en la aplicación.
Material de trabajo
Encontrará listas de comprobación y plantillas para otros frameworks en Recursos.
Ayudas de trabajo, no asesoramiento jurídico.
Términos
Preguntas y respuestas
Más respuestas en las preguntas frecuentes o directamente a través de nuestro formulario de contacto.
No. La norma es una guía sin requisitos auditables. Sin embargo, en la auditoría de la ISO 27001 o la ISO 42001 puede mostrar cómo ha evaluado y tratado las amenazas a los sistemas de IA.
Sí. La primera edición se publicó en octubre de 2026, por ahora solo en inglés.
No automáticamente. En contenido, la norma encaja bien con las obligaciones de ciberseguridad de los sistemas de IA de alto riesgo, pero no es una norma armonizada. Si le afectan obligaciones y cuáles, lo comprueba por separado. Sightadel no ofrece asesoramiento jurídico al respecto.
A menudo sí, a menor escala. Los ataques a través de entradas, como la inyección de prompts, también afectan a los servicios que utiliza. El foco está entonces en la elección del proveedor, la configuración, los permisos del sistema y la supervisión.
ISO describe la ISO 27090 como complemento de la ISO 27001 y la 27002. Usted incorpora las amenazas específicas de la IA a la apreciación de riesgos de su SGSI y gestiona los controles en el mismo plan de tratamiento.
La ISO 42001 es el sistema de gestión de la IA, con inventario, apreciación de riesgos y evaluación de impacto. La ISO 27090 aporta conocimiento sobre ataques dirigidos que alimenta esa apreciación de riesgos. Solo la ISO 42001 tiene certificado.
Licencia de Sightadel: Precio bajo consulta, con todos los detalles en la página de precios. A ello se suman el ejemplar de la norma y su esfuerzo interno. No hay costes de organismo de certificación.
No. Las normas ISO están protegidas por derechos de autor. Sightadel contiene estructura, preguntas guía, plantillas y explicaciones propias, no el texto literal. Necesita un ejemplar de la norma en su organización.
Además de seguridad de la información, las personas que desarrollan u operan los modelos, los responsables de datos y, en servicios contratados, compras. Sin ellas, el análisis se queda en la superficie.
14 días, acceso completo, sin datos de pago. Todo lo que cree se conserva en el plan de pago.
