Marcos de seguridad de IA en 2026: ¿Cuáles se aplican y dónde termina cada uno?

En 2026, los equipos de seguridad empresarial tienen más marcos de seguridad de IA para elegir que nunca. NIST, OWASP, MITRE ATLAS, Google SAIF, ISO 42001 y CSA MAESTRO abordan diferentes aspectos del problema general de seguridad de la IA, y ninguno de ellos es completo por sí solo.

Una vez que las organizaciones determinan qué marcos adoptar, deben comprender qué problema se diseñó para resolver cada marco de seguridad de IA y, lo que es más importante, dónde se detiene cada uno.

Esta guía compara los principales marcos de seguridad de IA según su alcance, público objetivo y cobertura práctica, y muestra cuánto queda sin abordar una vez completado el trabajo del marco.

¿Qué intentan resolver los marcos de seguridad de IA?

Los marcos de ciberseguridad tradicionales se desarrollaron específicamente para aplicaciones deterministas. Los sistemas de IA operan de forma conductual y probabilística, aprenden de los datos de entrenamiento, utilizan el procesamiento del lenguaje natural para ejecutar instrucciones y son cada vez más capaces de operar de forma independiente. Estas características conductuales presentan riesgos únicos que ningún marco de ciberseguridad anterior fue diseñado para abordar.

Los marcos de seguridad de IA intentan cerrar esta brecha ofreciendo directrices estructuradas para identificar el riesgo de la IA, gobernar los sistemas de IA a lo largo de su ciclo de vida y construir defensas fiables contra las formas en que la IA falla o es explotada.

Los equipos de seguridad empresarial se enfrentan a un verdadero desafío porque los diversos marcos cubren diferentes aspectos del mismo problema en capas. La dependencia singular de cualquier marco de seguridad de IA dado sin considerar su conjunto completo de lagunas creará debilidades identificables en la postura general de seguridad empresarial.

Los principales marcos de seguridad de IA

Veamos los marcos clave de seguridad de IA:

Marco de Gestión de Riesgos de IA del NIST 

El NIST AI RMF, publicado por el Instituto Nacional de Estándares y Tecnología, tiene cuatro componentes principales: Gobernar, Mapear, Medir y Gestionar. "Gobernar" implica establecer políticas y definir roles y responsabilidades. "Mapear" implica identificar dónde se está utilizando la IA y el riesgo de IA asociado a su implementación. "Medir" define criterios para evaluar esos riesgos. "Gestionar" establece un plan para implementar estrategias de mitigación de riesgos una vez que se han identificado los riesgos evaluados.

Con respecto a las industrias reguladas, el Marco de Gestión de Riesgos de IA del NIST es el ancla de gobernanza predeterminada. Está directamente mapeado a los niveles de riesgo definidos en la Ley de IA de la UE, y las industrias reguladas, incluidos los servicios financieros, la atención médica y la infraestructura crítica, hacen referencia explícita al NIST AI RMF en sus directrices de gobernanza de IA.

La limitación: El NIST AI RMF proporciona estructuras de gobernanza, no controles técnicos. Define qué estructuras de rendición de cuentas deben existir y qué categorías de riesgo de IA deben monitorearse, pero no proporciona orientación sobre cómo prevenir un ataque de inyección de prompt durante la ejecución. El AI RMF no aborda cómo asegurar que los agentes solo puedan invocar herramientas a las que sus usuarios están autorizados a acceder. Presupone que una entidad posterior se encargará de la aplicación. Los equipos que consideren que el cumplimiento del NIST AI RMF es exhaustivo tendrán políticas detalladas pero ninguna aplicación real durante las operaciones en vivo.

OWASP LLM Top 10 y Agentic Top 10

El LLM Top 10, producido por OWASP, describe los riesgos de seguridad de más alto nivel para las aplicaciones de modelos de lenguaje grandes, incluyendo inyección de prompt, manejo de salida inseguro, envenenamiento de datos, ataques de denegación de servicio al modelo y compromiso de la cadena de suministro. El Agentic Top 10 amplía estos riesgos al identificar riesgos únicos planteados por agentes autónomos, incluyendo uso inseguro de herramientas, privilegios excesivos, violación de los límites de confianza entre agentes y consumo incontrolado de recursos.

Ambos documentos ayudan a convertir la investigación de ataques en controles de ingeniería sobre los que los equipos de desarrollo pueden actuar directamente. Esto es particularmente valioso para los equipos que desarrollan aplicaciones LLM, ya que OWASP proporciona el mejor punto de partida para comprender qué superficie de ataque introduce su desarrollo de IA.

La limitación: OWASP sirve como un documento de concienciación sobre amenazas, identificando qué abordar en lugar de prescribir un enfoque programático para la aplicación continua. Aunque la inyección de prompts es claramente el mayor riesgo de seguridad de la IA, identificarla en un documento no la intercepta en producción. Si nada en la pila operativa puede bloquear la inyección de prompts en tiempo de ejecución, la concienciación sobre OWASP por sí sola no proporciona medidas de seguridad contra ella.

MITRE ATLAS

MITRE ATLAS es un catálogo de tácticas y técnicas adversarias reales empleadas contra soluciones basadas en IA. Estructurado como una matriz similar a MITRE ATT&CK, se mapea directamente a los equipos SOC que ya utilizan herramientas de seguridad basadas en ATT&CK. Las técnicas incluyen evasión de modelos, envenenamiento de datos, ataques de puerta trasera y extracción de modelos, todo basado en investigación publicada y datos confirmados de respuesta a incidentes, en lugar de en modelos de amenazas estimados.

Para los equipos rojos, ATLAS proporciona una forma estructurada de probar comportamientos adversarios realistas de los sistemas de IA. Para los equipos azules, ATLAS proporciona el vocabulario necesario para escribir reglas de detección para patrones de ataque específicos de IA y para mapear el riesgo de IA en los flujos de trabajo SIEM existentes.

La limitación: ATLAS describe cómo ocurren los ataques y permite su prueba, lo cual es realmente valioso. Sin embargo, MITRE ATLAS no proporciona controles en tiempo de ejecución para cargas de trabajo de IA en producción. Un equipo de seguridad puede derivar un modelo de amenazas completo basado en ATLAS, realizar un ejercicio de equipo rojo contra cada técnica de ATLAS y aun así no encontrar defensas en tiempo de ejecución que protejan esas vías de ataque en producción. ATLAS proporciona visibilidad sobre las brechas, pero requiere herramientas separadas para cubrirlas.

Google SAIF

El Marco de IA Segura desarrollado por Google ha identificado seis grandes áreas de enfoque: 

1) Construir bases de seguridad sólidas en todo el ecosistema de IA; 

2) Ampliar las capacidades de detección y respuesta al pipeline de IA; 

3) Automatizar las medidas defensivas para adelantarse a los riesgos mejorados por la IA;

4) Estandarizar los controles a nivel de plataforma para que estén regidos por una política general;

5) Ajustar los controles según sea necesario según el contexto del sistema de IA; 

6) Evaluar el riesgo de la IA en relación con los modelos de amenazas existentes. 

SAIF proporciona a las organizaciones que desarrollan aplicaciones de IA en Google Cloud o que utilizan los estándares de ingeniería de Google una excelente comprensión de los enfoques efectivos de seguridad de la IA desde las primeras fases del desarrollo del modelo hasta el desarrollo y la implementación de la IA.

La limitación: SAIF es útil como conjunto de mejores prácticas de alto nivel, pero no prescribe controles específicos ni cómo aplicarlos una vez que una aplicación de IA está en producción. SAIF proporciona una guía sustancial sobre la integridad de los datos, la seguridad del modelo y la seguridad de la cadena de suministro durante la fase de entrenamiento del modelo, pero ofrece solo un punto de partida para aplicar controles en los agentes de producción después de la implementación.

ISO 42001 

ISO 42001 es un estándar internacional de sistema de gestión para IA. Describe cómo establecer, implementar, mantener y mejorar un sistema de gestión de IA, utilizando la misma estructura de alto nivel que ISO 27001 (seguridad de la información) e ISO 9001 (gestión de calidad). Las organizaciones que ya utilizan marcos de gobernanza ISO pueden extender su programa existente a la IA utilizando ISO 42001 como lenguaje común.

La razón principal por la que las organizaciones adoptan ISO 42001 es que proporciona una vía de certificación para cumplir con los requisitos de certificación de gobernanza de IA cada vez más impuestos por los procesos de adquisición empresariales. ISO 42001 es el marco más creíble disponible para este propósito.

La limitación: ISO 42001 se centra en la certificación del sistema de gestión, no en los controles técnicos ni en las medidas de seguridad operativas. Proporciona pruebas de que una organización ha desarrollado su política de gobernanza de IA, ha establecido la rendición de cuentas y ha implementado procesos de revisión. 

Sin embargo, la ISO 42001 no aborda el comportamiento de IA agéntica, la inyección de prompts o la aplicación en tiempo de ejecución a nivel de infraestructura. Tener un sistema de gestión certificado ISO 42001 no significa que los sistemas de la organización filtren o registren las solicitudes individuales que fluyen a través de ellos. La certificación da fe del sistema de gestión de gobernanza, no de la seguridad de los datos o la aplicación del tráfico en vivo.

¿Cómo usar múltiples marcos juntos?

Estos marcos de seguridad de IA fueron creados con diferentes propósitos, y usarlos juntos compensa las debilidades de cada uno.

El NIST AI RMF proporciona el modelo de gobernanza. El OWASP LLM Top 10 y el Agentic Top 10 sirven como base para desarrolladores e ingenieros para evaluar vulnerabilidades de seguridad. MITRE ATLAS apoya el modelado de amenazas y el red teaming contra técnicas de ataque específicas de IA. ISO 42001 gestiona la verificación externa y el cumplimiento normativo. Google SAIF proporciona orientación sobre cómo integrar la seguridad en el desarrollo y entrenamiento de modelos.

La combinación de estos marcos de seguridad de IA proporciona una garantía adicional de que se consideran todas las capas del sistema de IA. El NIST AI RMF proporciona orientación sobre qué gobernar. OWASP proporciona orientación sobre qué monitorear. ATLAS proporciona orientación sobre cómo se ejecutan los ataques. ISO 42001 proporciona prueba del cumplimiento de los requisitos normativos. SAIF proporciona orientación sobre cómo desarrollar modelos de IA seguros.

Sin embargo, persiste una brecha crítica. Ninguno de estos marcos de seguridad de IA aborda el plano de control a través del cual cada solicitud de IA, acción del agente e invocación de herramientas requiere la aplicación de políticas antes de que se ejecute.

¿Qué dejan sin abordar los marcos de seguridad de IA?

Todos los marcos de seguridad de IA revisados aquí aplican acciones en uno de tres niveles: política, documentación o modelado de amenazas. Ninguno de ellos aplica directamente controles sobre el tráfico de inferencia en vivo.

El uso del NIST AI RMF no impide que un agente con privilegios excesivos ejecute una acción a través de una herramienta restringida; depende de algo posterior para manejar la aplicación correctamente.

OWASP identifica la inyección de prompts como la vulnerabilidad de seguridad de IA número uno, pero reconocerla en un documento no impide que las instrucciones inyectadas lleguen a un modelo de IA en producción.

MITRE ATLAS proporciona un modelo de cómo un atacante explota las capacidades de un agente, pero no evita esa explotación en una implementación en vivo. El equipo rojo identifica la vulnerabilidad. Una capa técnica separada debe abordar la brecha.

La certificación ISO 42001 indica que existe un sistema de gestión, pero no garantiza que todas las solicitudes procesadas por ese sistema se registren o filtren en tiempo real.

Esta brecha es estructural. Los marcos de seguridad de IA fueron diseñados para entornos de planificación, documentación y pruebas. Cerrar la brecha requiere un plano de control que opere en la capa de infraestructura, donde los sistemas de IA se ejecutan en tiempo real y donde la política se aplica antes de que las solicitudes lleguen a los modelos y herramientas.

¿Cómo TrueFoundry operacionaliza los marcos de seguridad de IA en la capa de infraestructura?

TrueFoundry opera bajo una premisa importante. La capa de infraestructura debe aplicar los marcos de control descritos anteriormente, y no dejar su aplicación a los equipos de desarrollo individuales ni documentarlos en los artefactos de gobernanza. 

La plataforma TrueFoundry se implementa en la cuenta de AWS / GCP / Azure del cliente y aplica la política en la capa de la pasarela antes de que un modelo/herramienta reciba cualquier solicitud.

• Abordando el uso inseguro de herramientas de OWASP: La inyección de identidad de OAuth 2.0 vincula cada acción del agente al alcance de los permisos del usuario autenticado. Un agente no puede invocar una herramienta a menos que el usuario solicitante esté autorizado para acceder a ella, implementando directamente el principio de mínimo privilegio que los marcos de seguridad de IA describen pero no pueden aplicar por sí mismos.
• Alineación con los estándares de gobernanza del Marco de Gestión de Riesgos de IA del NIST: El mecanismo de controles de acceso por modelo y por herramienta establece la rendición de cuentas en la gestión de riesgos de IA a nivel de sistema, en lugar de dejarlo en manos de documentos de políticas que los equipos de desarrollo pueden implementar o no de forma consistente.
• Abordando la inyección de prompts OWASP LLM01: El filtrado de inyección de prompts se aplica a nivel de infraestructura antes de que las instrucciones lleguen al contexto del modelo de IA. La anonimización de PII aborda la divulgación de información sensible OWASP LLM06 interceptando datos personales y datos sensibles antes de que entren en el modelo, satisfaciendo los requisitos de protección de datos que especifican los marcos de seguridad de IA.
• Generando registros auditables: Los registros de auditoría inmutables satisfacen los requisitos indicados en el NIST AI RMF, ISO 42001 y la Ley de IA de la UE sin requerir una infraestructura de registro separada para cada equipo o aplicación.
• Abordando los requisitos de privacidad y residencia de datos: La implementación nativa de VPC cumple con los requisitos de soberanía y residencia que todos los marcos de seguridad de IA indican, pero ninguno de ellos impone por sí solo.
• Cerrando la brecha entre la guía del marco y la realidad organizacional: A nivel de infraestructura, cada política se aplica a cada solicitud de ejecución, en lugar de documentarse en una carpeta de gobernanza y aplicarse de forma inconsistente entre los equipos.