Si opera o desarrolla sistemas de IA, utilice la ISO/IEC 27090 como capa de amenazas y controles específica para la IA dentro de su programa ISO/IEC 27001 o ISO/IEC 42001 existente, y no como un proyecto de cumplimiento independiente.
Resumen
La ISO/IEC 27090:2026 es una guía publicada sobre las amenazas de seguridad específicas de los sistemas de IA. No es certificable. Utilícela para ampliar su proceso de gestión de riesgos ISO/IEC 27001 y su sistema de gestión de IA ISO/IEC 42001. Empiece por un inventario de sistemas de IA, modelos de amenazas para los sistemas de mayor impacto, registros de procedencia, permisos de los agentes y evidencias de prueba. Respalda, pero por sí sola no demuestra, la conformidad con el artículo 15 del AI Act en materia de ciberseguridad.
La ISO/IEC 27090:2026 ya es una norma internacional publicada. La ISO la registra como publicada, con fecha de publicación el 14 de octubre de 2026. La ha elaborado el comité ISO/IEC JTC 1/SC 27, responsable de la seguridad de la información. Este artículo explica qué cubre la norma, qué no hace y cómo encaja con las normas ISO/IEC 27001 e ISO/IEC 42001.
Sobre el autor
Escrito por Alexis Hirschhorn, formador de Abilene Academy. Lead Implementer certificado en ISO/IEC 42001, Certified Artificial Intelligence Professional, CISSP, CISM, CISA, auditor principal ISO/IEC 27001 y formador certificado PECB. Unos 25 años de experiencia práctica en seguridad de la información, seguridad en la nube y gobernanza de la IA, asesorando a multinacionales, organismos públicos y organizaciones internacionales. Perfil: https://www.abileneacademy.ch/es/about/team/alexis-hirschhorn
Las citas de profesionales de este artículo reflejan la experiencia formativa de Abilene Academy y no son posiciones de la ISO. La ISO/IEC 27090 es una norma publicada, y el catálogo de la ISO es la referencia para su estado y su contenido.
Estado
ISO/IEC 27090:2026, edición 1, publicada en octubre de 2026. 56 páginas. Directrices sobre amenazas y compromisos de seguridad de los sistemas de IA. Comité: ISO/IEC JTC 1/SC 27.
No certificable
No puede certificarse según la ISO/IEC 27090. Puede usarla dentro de un sistema de gestión de seguridad de la información ISO/IEC 27001 o de un sistema de gestión de IA ISO/IEC 42001 certificado, y demostrar a auditores y clientes cómo ha gestionado las amenazas de IA.
Por qué necesitamos una norma de seguridad para la IA ahora
La mayoría de los sistemas de IA de las empresas no los ha diseñado el equipo de seguridad. Llegan como una función de un producto SaaS, como un modelo detrás de una API, como un agente conectado a una herramienta de tickets o como un asistente de código en el equipo de ingeniería. Cada uno añade rutas de ataque que un escaneo de vulnerabilidades clásico no ve: datos de entrenamiento envenenados, prompts que introducen instrucciones ocultas y salidas del modelo que provocan una acción aguas abajo.
La 27090 ofrece a los equipos de seguridad un vocabulario común y una lista de amenazas para estas rutas. No le obliga a comprar ninguna herramienta. Indica qué compromisos considerar, cómo se manifiesta cada uno, cómo detectarlo y cómo reducirlo.
La IA no autorizada hace urgente el inventario. En una encuesta de WatchGuard realizada en abril de 2026, el 64 % de los empleados declaró usar herramientas de IA no autorizadas para su trabajo. La muestra incluía a 684 empleados de organizaciones pequeñas y medianas, y las respuestas son autodeclaradas. Fuente: WatchGuard, 2026 Cybersecurity Hygiene Report.
Qué es la ISO/IEC 27090 y qué no es
La norma tiene un marco normativo breve, un cuerpo principal de directrices y tres anexos informativos. La cláusula 5 explica cómo aplicar la seguridad de la información a la IA, incluidos la gobernanza, los principios de confianza cero, las prácticas de ingeniería de software, la gestión de la cadena de suministro, el modelado de amenazas y el red teaming. La cláusula 6 describe los tipos de compromiso, desde el envenenamiento de datos hasta la inyección de prompt. La cláusula 7 cubre las medidas de mitigación, incluido cómo pueden entrar en conflicto y perder eficacia con el tiempo.
“Trate cada artefacto de modelo, cada conjunto de datos, cada plantilla de prompt y cada permiso de herramienta como una superficie de ataque. Si un elemento puede cambiar el comportamiento del modelo o llegar a un sistema aguas abajo, debe figurar en el modelo de amenazas.”
Alexis Hirschhorn, formador de Abilene Academy
Cómo encaja la ISO/IEC 27090 con las normas que ya utiliza
Norma: ISO/IEC 27001:2022 (requisitos del sistema de gestión)
Norma: ISO/IEC 27002:2022 (directrices de controles)
Norma: ISO/IEC 42001:2023 (requisitos del sistema de gestión de IA)
Norma: ISO/IEC 23894:2023 (directrices de gestión de riesgos de IA)
Norma: ISO/IEC 27090:2026 (directrices de seguridad para la IA)
Norma: ETSI EN 304 223 (base europea de requisitos de ciberseguridad para la IA)
Dos límites importan. En primer lugar, la 27090 trata de proteger los sistemas de IA, no de usar la IA para defender redes. En segundo lugar, no garantiza que un sistema sea inmune a los ataques. Sus controles reducen el riesgo, y el riesgo residual debe seguir siendo asumido y aceptado por alguien.
Las amenazas de IA que debe entender primero
La cláusula 6 describe para cada compromiso su naturaleza, los fallos que provoca, cómo detectarlo y cómo mitigarlo. La tabla usa un lenguaje sencillo. Las referencias a cláusulas proceden de la norma; las correspondencias con otros marcos son nuestra interpretación y deben verificarse con las versiones vigentes.
Amenazas de la ISO/IEC 27090 con un ejemplo
Amenaza: Envenenamiento de datos
Amenaza: Evasión
Amenaza: Inferencia de pertenencia
Amenaza: Exfiltración de modelo
Amenaza: Inversión de modelo
Amenaza: Envenenamiento directo del modelo
Amenaza: Salida sensible del modelo
Amenaza: Inyección de prompt
Amenaza: Salida con inyección
Hay dos lagunas que conviene conocer. El índice no tiene un apartado propio sobre jailbreaks, y los riesgos de los agentes y del abuso de herramientas se tratan de forma más breve que en catálogos especializados. Para ello, utilice el OWASP Top 10 para aplicaciones LLM y la base de conocimiento MITRE ATLAS junto con la 27090.
Por qué importa ahora: el calendario regulatorio
Una norma solo es útil cuando alguien pide las pruebas. Hoy hay cuatro marcos que lo hacen.
AI Act, artículo 15
Los sistemas de IA de alto riesgo deben resistir los intentos de explotar el envenenamiento de datos, el envenenamiento de modelos, los ejemplos adversarios y los ataques contra la confidencialidad. La cláusula 6 de la 27090 cubre cada una de estas categorías por su nombre. Fuente: Reglamento (UE) 2024/1689, artículo 15, y servicio de asistencia de la Comisión Europea sobre el AI Act.
El Ómnibus digital sobre IA, Reglamento (UE) 2026/1744, aplazó las obligaciones autónomas de alto riesgo del anexo III al 2 de diciembre de 2027 y las del anexo I al 2 de agosto de 2028. El calendario completo está en la guía del AI Act para sistemas de alto riesgo. El aplazamiento cambia el momento en que un regulador puede actuar; no reduce el riesgo que asumen sus sistemas.
La Directiva NIS2 exige a las entidades esenciales e importantes gestionar la seguridad de la cadena de suministro y del desarrollo, y los servicios de IA entran en esas medidas cuando forman parte del servicio. Desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades explotadas activamente en virtud del Cyber Resilience Act: un fallo de inyección de prompt en un producto que se explota en la práctica puede ser notificable. Consulte las obligaciones de notificación del CRA para conocer los plazos.
En Suiza, el PFPDT ha indicado que la LPD revisada se aplica directamente al tratamiento de datos personales asistido por IA. La inferencia de pertenencia, la inversión de modelos y las salidas sensibles son, por tanto, fallos de confidencialidad en virtud del deber de seguridad de los datos, y deben figurar en la evaluación de impacto relativa a la protección de datos.
“En Suiza, una función de IA que trata datos personales es una actividad de tratamiento como cualquier otra. La innovación no elimina la obligación de documentar la finalidad, los flujos de datos, los riesgos de seguridad, la conservación y el responsable designado.”
De la lista de amenazas a los controles con evidencias
Una prueba útil es si un control deja evidencias que un auditor puede muestrear. La tabla muestra dónde entra cada amenaza en el ciclo de vida y qué control de la 27090 se aplica.
Dónde entran las amenazas de IA en el ciclo de vida y qué control de la 27090 se aplica
Etapa: 1. Datos
Etapa: 2. Entrenamiento
Etapa: 3. Evaluación
Etapa: 4. Despliegue
Etapa: 5. Monitorización
Etapa: 6. Retirada
Un modelo de madurez para los controles de seguridad de la IA
No intente implantar todo el catálogo de una vez. Avance en tres etapas y trate cada una como un conjunto de evidencias que pueda mostrar.
Etapas de madurez para los controles de la ISO/IEC 27090
Etapa: Mínimo
Etapa: Consolidado
Etapa: Avanzado
Por qué el inventario va primero
La IA no autorizada es habitual en las dos encuestas que revisamos. Un inventario de IA debe incluir las funciones de IA integradas, las extensiones del navegador, los asistentes de código y las herramientas elegidas por los empleados, no solo los modelos que la organización ha desplegado de forma deliberada.
Exposición de datos
En una encuesta de PagerDuty realizada a 1.250 profesionales de oficina de organizaciones con una facturación de al menos 500 millones de dólares estadounidenses, el 43 % declaró haber introducido correos electrónicos u otra correspondencia en herramientas de IA públicas, el 34 % datos de clientes y el 31 % información financiera o documentos confidenciales. Es posible que los empleados ya estén introduciendo datos de clientes y documentos confidenciales en herramientas fuera de su entorno gestionado.
Fuentes de las cifras anteriores: WatchGuard, 2026 Cybersecurity Hygiene Report (encuesta de abril de 2026, respuestas autodeclaradas); PagerDuty Shadow AI Survey (junio de 2026).
Caso práctico: un agente de IA de soporte con acceso al CRM
Es un ejemplo compuesto, no un caso de cliente. Imagine un asistente de IA que responde a los tickets de clientes y puede crear notas en el CRM. Es una configuración habitual, y muestra la mayoría de las amenazas de la 27090 en un solo sistema.
Inventario. El sistema se registra con su responsable (el responsable de operaciones de clientes), su modelo y proveedor, sus fuentes de datos (texto de los tickets, registros del CRM), sus herramientas (crear nota, actualizar estado) y sus aprobaciones humanas. También se incluyen las funciones de IA integradas en la plataforma de tickets.
Modelo de amenazas. Cuatro amenazas son las más importantes: inyección de prompt indirecta a través de los correos de los clientes (6.9), permisos excesivos del agente en el CRM (5.3, 6.11.3), una salida sensible que expone el expediente de otro cliente (6.8) y llamadas a herramientas que nadie registra (7.5).
Controles. El agente tiene su propia credencial, con el alcance mínimo en el CRM. Cualquier cambio en un expediente de cliente requiere aprobación humana. La salida se sanea antes de llegar a la interfaz del CRM (6.10). Las llamadas a herramientas se registran con el usuario, la entrada y el resultado. Se aplican límites de tasa al punto de acceso (7.8). Las pruebas de red team se hacen cada trimestre, con correos que contienen inyecciones.
Evidencias que un auditor muestrearía. El alcance de la credencial del agente en el registro de accesos. Tres registros de llamadas a herramientas muestreados, con una aprobación y una acción rechazada. El último informe de red team, con sus casos de prueba de inyección y los tickets de corrección. El registro de cambios que indica cuándo se revisaron por última vez los permisos del agente.
Decisión sobre el riesgo residual. Una inyección todavía puede hacer que el agente redacte una nota incorrecta, pero no puede modificar un expediente de cliente sin aprobación ni leer los expedientes de otros clientes. El responsable acepta el riesgo residual de una redacción incorrecta, registra esa decisión y fija una fecha de revisión vinculada al siguiente cambio de modelo o de permisos.
Agentes y herramientas: dónde importa el radio de impacto
La IA agéntica es donde la norma es más escueta. La 27090 aplica confianza cero a las operaciones de los agentes y recomienda el mínimo privilegio para el modelo. Es una base sólida, pero no ofrece una lista completa de escenarios de abuso de herramientas. Las preguntas prácticas son concretas: qué herramientas puede llamar el agente, con qué credenciales, qué acciones requieren aprobación humana y qué ocurre cuando una instrucción llega dentro de un contenido recuperado. El OWASP Top 10 para aplicaciones LLM (edición 2025) incluye la capacidad excesiva de actuación (excessive agency) entre los riesgos principales: una salida del modelo que puede activar herramientas, escribir datos o enviar mensajes necesita permisos tan limitados como cualquier cuenta de servicio.
“Un filtro de inyección de prompt es un control útil, pero no es un modelo de autorización. Diseñe el agente para el día en que el modelo sea engañado: limite sus credenciales, separe sus permisos de los del usuario, exija aprobación para las acciones irreversibles y haga observable cada llamada a una herramienta.”
Alexis Hirschhorn, formador de Abilene Academy
Gobernanza de agentes
En el estudio AI Agents at Work 2026 de Okta, el 92 % de los directivos afirmó que los agentes de IA autónomos ya se utilizaban de forma generalizada (58 %) o moderada (35 %) en su organización. El 58 % de los directivos declaró haber sufrido un incidente de seguridad relacionado con la IA o un casi incidente en los últimos doce meses. Los agentes no deberían heredar por defecto los amplios privilegios del usuario. Defina la identidad del agente, las herramientas permitidas, el alcance de los datos, los umbrales de aprobación, el registro y una forma de detenerlo antes del despliegue. Son cifras de encuesta a directivos, no recuentos auditados de incidentes.
Nuestro curso Lead AI Risk Manager trabaja estos temas: identificación de riesgos de IA, decisiones trazables y mitigaciones defendibles a lo largo del ciclo de vida del sistema.
Qué nos enseñan los incidentes reales
Cuatro casos públicos muestran cómo se materializan las amenazas de la 27090. Cada uno se resume a partir de la investigación o del informe del proveedor original, con su fuente enlazada.
Inyección de prompt sin clic en un asistente empresarial. Investigadores de Aim Labs describieron un correo electrónico manipulado que llevó a un asistente de tipo Microsoft 365 Copilot a filtrar datos de su contexto sin que el usuario hiciera nada, documentado con la referencia CVE-2025-32711 y analizado en arXiv 2509.10540. El ataque encadenaba varios bypasses: la evasión de un clasificador, la superación del enmascaramiento de enlaces y una petición de imagen a un dominio permitido. Microsoft lo corrigió en el servidor. Lección: la renderización de una salida que dispara peticiones de red es una vía de fuga de datos.
Modelos maliciosos en un repositorio público. En una entrada de blog de JFrog del 27 de febrero de 2024, la empresa informó de unos cien modelos maliciosos en Hugging Face. Uno usaba la serialización pickle de Python para abrir una conexión a una dirección remota al cargarse. Lección: un archivo de modelo es código. Trátelo como un binario de terceros y prefiera formatos seguros como safetensors.
Campaña de intrusión orquestada con IA. En su informe de noviembre de 2025, Anthropic describió a un actor que atribuye con alta confianza a un grupo vinculado a un Estado, que usó una herramienta de programación agéntica para ejecutar tareas de reconocimiento e intrusión contra varias organizaciones, con intervención humana solo en unos pocos puntos de decisión. El actor presentó el trabajo como una prueba legítima para eludir las salvaguardas. Lección: la resistencia al jailbreak puede fallar, por eso importan la detección y la capacidad de cortar el acceso.
Robo de parte de un modelo en producción. En arXiv 2403.06634 (ICML 2024), Carlini et al. recuperaron la matriz de proyección de modelos de lenguaje en producción a través de su API pública. Lección: el diseño de una API es una decisión de seguridad. Los logprobs y el logit bias amplían lo que un atacante puede aprender.
La divulgación de vulnerabilidades es desigual. Un estudio sobre las políticas de divulgación de 264 proveedores de IA (arXiv 2509.06136) constató que el 36 % no ofrecía ningún canal de divulgación de vulnerabilidades y que solo el 18 % mencionaba explícitamente los riesgos de la IA. El acceso a datos, la autorización y la extracción de modelos fueron los tipos de vulnerabilidad declarados con más frecuencia dentro del alcance, mientras que el jailbreak y las alucinaciones solían quedar fuera. Los equipos de compras deberían hacer una pregunta concreta: ¿cuál es su política de divulgación de vulnerabilidades de IA, y están incluidas en ella la inyección de prompt, la extracción de modelos y el envenenamiento de datos? El estudio mide las políticas publicadas, no el comportamiento real de los proveedores.
Cómo usar la 27090 dentro de la ISO/IEC 27001 y la ISO/IEC 42001
Si gestiona un sistema de gestión de seguridad de la información 27001, añada las amenazas de IA a su registro de riesgos y a las justificaciones de su declaración de aplicabilidad. Si gestiona o planifica un sistema de gestión de IA 42001, vincule la evaluación de impacto de IA y el proceso de riesgos con el catálogo de amenazas. La norma remite a la 42001 para el sistema de gestión y a la 27002 para las directrices de controles, así que las tres funcionan como un conjunto.
Los auditores de un sistema 42001 buscan trazabilidad: desde una versión del modelo, pasando por su evaluación de impacto, sus decisiones sobre datos, sus resultados de prueba y su aprobación, hasta su monitorización. La guía Auditoría ISO 42001: qué evidencia exige detalla el expediente de evidencias.
“La preparación no es un estado que se alcanza. Es una propiedad de sus registros. Si sus evidencias solo existen porque alguien las reunió para la auditoría, nunca estuvo listo: estaba preparado, y son cosas distintas.”
Alexis Hirschhorn, formador de Abilene Academy
En los sistemas de IA, esto significa que el inventario, el modelo de amenazas, la procedencia de los datos, los resultados de las pruebas y los registros de monitorización deben mantenerse como parte del funcionamiento normal, y no reconstruirse antes de una auditoría. Use este principio como prueba para la lista de verificación de evidencias que sigue.
- Inventario de sistemas de IA con responsables, finalidades, fuentes de datos y proveedores
- Modelo de amenazas para cada sistema de IA incluido en el alcance, basado en la cláusula 6
- Registros de procedencia y linaje de los datos de entrenamiento y de ajuste fino
- Huellas o firmas de los artefactos del modelo, y serialización segura antes de cargarlos
- Reglas de tratamiento de entradas y salidas para cada función de IA que llegue a un usuario o a una herramienta
- Informe de pruebas de red team o adversarias con el estado de las correcciones
- Registro y límites de tasa en los puntos de inferencia, con monitorización de patrones de consulta
- Registro de decisiones de compromiso, por ejemplo privacidad frente a precisión, o registro frente a minimización de datos
Los equipos que quieren reunir en un solo lugar el inventario de IA, los modelos de amenazas y el rastro de evidencias suelen usar una plataforma GRC nativa de IA, como Acuna GRC, que mantiene esos registros vinculados a los controles que respaldan.
Cinco preguntas antes del despliegue
Hágase estas preguntas antes de poner en servicio cualquier sistema de IA. Cada respuesta debe estar respaldada por las evidencias de la columna de la derecha.
Cinco preguntas antes del despliegue
Pregunta: ¿Qué sistemas de IA y funciones de IA integradas existen?
Pregunta: ¿A qué datos puede acceder o qué datos puede generar el sistema?
Pregunta: ¿Qué puede hacer el modelo que provoque que otro sistema actúe?
Pregunta: ¿Cómo detectaría un uso indebido o un compromiso?
Pregunta: ¿Qué evidencia demuestra que el control funciona?
Quién debe actuar y de qué es responsable cada uno
Quién debe actuar primero y qué evidencias es responsable de mantener cada rol
Rol: CISO / responsable de seguridad
Rol: Producto e ingeniería
Rol: Responsable de gobernanza de IA
Rol: Compras
Rol: Auditor / cumplimiento
Lo que la 27090 no resuelve
Sobrestimar la norma es el error más frecuente. Conviene ser claros con sus límites. No certifica a una organización. No crea una presunción de conformidad con el AI Act: la presunción del artículo 40 depende de normas armonizadas citadas en el Diario Oficial. No sustituye a la ISO/IEC 27001, a la 27002 ni a la 42001. No proporciona un catálogo completo de controles para agentes y abuso de herramientas. No elimina la necesidad de una evaluación de riesgos específica de cada sistema y de una decisión documentada de aceptación del riesgo residual.
Preguntas frecuentes
¿Está publicada la ISO/IEC 27090?
Sí. La ISO la registra como publicada, en su edición 1, con fecha de publicación el 14 de octubre de 2026. Los borradores describen un texto que ha cambiado después, así que verifique la versión publicada antes de citarla.
¿Puede certificarse una organización según la ISO/IEC 27090?
No. Es una norma de orientación y no existe un esquema de certificación para ella. Certifíquese según la ISO/IEC 27001 o la ISO/IEC 42001 y use la 27090 como referencia para gestionar las amenazas de IA dentro de ese alcance.
¿Sustituye la ISO/IEC 27090 a los controles de la ISO/IEC 27002 para los sistemas de IA?
No. La norma recuerda que los controles clásicos de seguridad de la información siguen aplicándose según el riesgo. La 27090 añade por encima las amenazas específicas de la IA y los controles que las tratan.
¿Cubre la ISO/IEC 27090 la inyección de prompt?
Sí. La cláusula 6.9 cubre la inyección de prompt, y su definición incluye el contenido incorporado a una instrucción, lo que abarca la inyección indirecta a través de documentos, correos electrónicos y páginas web. La cláusula 6.10 cubre las salidas que llevan una carga de inyección.
¿Ayuda la ISO/IEC 27090 a cumplir el AI Act?
Es una guía pertinente para las expectativas de ciberseguridad del artículo 15 aplicables a los sistemas de alto riesgo. No es una norma armonizada, así que usarla no crea por sí sola una presunción de conformidad con el AI Act.
¿Cuándo se aplican ahora las obligaciones del AI Act para sistemas de alto riesgo?
En virtud del Reglamento (UE) 2026/1744, las obligaciones para los sistemas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027, y las del anexo I desde el 2 de agosto de 2028. Las obligaciones de transparencia del artículo 50 se aplican desde el 2 de agosto de 2026.
¿Es relevante la ISO/IEC 27090 en Suiza?
Sí. El PFPDT indica que la LPD revisada se aplica directamente al tratamiento asistido por IA. Las orientaciones de la norma sobre ataques a la privacidad respaldan las obligaciones de seguridad de los datos y de evaluación de impacto de la LPD. Las empresas suizas que atienden a clientes europeos también están sujetas al AI Act y al CRA.
¿En qué se diferencia la ISO/IEC 27090 de la ISO/IEC 42001?
La ISO/IEC 42001 establece requisitos para gestionar la IA de forma responsable en toda la organización, y es certificable. La ISO/IEC 27090 profundiza en las amenazas de seguridad de los sistemas de IA y en cómo detectarlas y reducirlas. La mayoría de las organizaciones usarán ambas.
¿Aborda la norma la IA agéntica?
En parte. Aplica confianza cero a las operaciones de los agentes y recomienda el mínimo privilegio para el modelo. Para el abuso de herramientas y la confianza entre agentes, añada el OWASP Top 10 para LLM y el catálogo de técnicas de MITRE ATLAS.
Cómo usamos esta norma en la formación
En nuestras sesiones de seguridad de la IA y de ISO/IEC 42001 pedimos a los equipos que traigan una función de IA real. Cartografiamos sus fuentes de datos, el modelo o proveedor, las herramientas, las aprobaciones humanas, los registros y los escenarios de fallo. La carencia más habitual no es un control técnico ausente. Es una función de IA sin propietario, integrada en un sistema de negocio existente.
Dónde formarse después
Equipos de seguridad y SOC. El curso Lead AI Risk Manager cubre la identificación y el tratamiento de los riesgos de IA, con el enfoque de riesgo que exige la 27090. Alexis Hirschhorn es uno de sus formadores; puede consultar su perfil de formador.
Responsables de sistemas de gestión. El curso ISO/IEC 42001 Lead Implementer cubre el sistema de gestión de IA, y el curso ISO/IEC 27001 Lead Implementer cubre el sistema de gestión de seguridad de la información en el que encajan las amenazas de IA.
Nuestra área de gobernanza de la IA reúne el itinerario formativo completo: consulte el centro de gobernanza de IA de Abilene Academy.
Fuentes y verificación
Estado, estructura y alcance de la norma: catálogo de la ISO sobre la ISO/IEC 27090:2026 y la explicación publicada por la ISO. Estructura de cláusulas y definiciones: vista previa pública de la norma, cuando esté permitido. Artículo 15 del AI Act: Reglamento (UE) 2024/1689 y servicio de asistencia de la Comisión Europea sobre el AI Act. Calendario del AI Act: Reglamento (UE) 2026/1744 publicado en el Diario Oficial. Incidentes: las fuentes citadas arriba, con sus fechas de publicación. Las correspondencias con marcos (NIST AI 100-2e2025, OWASP Top 10 para LLM 2025, MITRE ATLAS) son nuestra interpretación y deben verificarse con las versiones vigentes.
Este artículo es un resumen para planificación. El texto completo de la norma es de pago. Compruebe los requisitos concretos de cada cláusula frente a la versión publicada antes de confiar en ellos.
