Hay un patrón que se desarrolla dentro de casi todas las organizaciones de ingeniería en este momento. Un desarrollador instala GitHub Copilot para enviar código más rápido. Un analista de datos comienza a consultar una nueva herramienta LLM para generar informes. Un equipo de producto incorpora silenciosamente un modelo de terceros en una rama de funciones. Cuando el equipo de seguridad se entera de algo de esto, la IA ya está funcionando en producción: procesa datos reales, toca sistemas reales y toma decisiones reales.
Esa brecha entre la rapidez con la que la IA ingresa a una organización y la lentitud con la que la gobernanza se pone al día es exactamente donde reside el riesgo. Según una nueva guía marco práctica ‘Gobernanza de seguridad de la IA: un marco práctico para equipos de seguridad y desarrollo’ de Mend, la mayoría de las organizaciones aún no están preparadas para cerrarla. No supone que ya tenga un programa de seguridad maduro desarrollado en torno a la IA. Se supone que usted es un líder de AppSec, un gerente de ingeniería o un científico de datos que intenta descubrir por dónde empezar, y construye el manual a partir de ahí.
El problema del inventario
El marco comienza con la premisa crítica de que la gobernanza es imposible sin visibilidad (“no se puede gobernar lo que no se puede ver”). Para garantizar esta visibilidad, define ampliamente los “activos de IA” para incluir todo, desde herramientas de desarrollo de IA (como Copilot y Codeium) y API de terceros (como OpenAI y Google Gemini), hasta modelos de código abierto, funciones de IA en herramientas SaaS (como Notion AI), modelos internos y agentes de IA autónomos. Para resolver el problema de la ‘IA en la sombra’ (herramientas en uso que la seguridad no ha aprobado ni catalogado), el marco enfatiza que encontrar estas herramientas debe ser un proceso no punitivo, garantizando que los desarrolladores se sientan seguros al revelarlas.
Un sistema de niveles de riesgo que realmente escala
El marco utiliza un sistema de niveles de riesgo para categorizar las implementaciones de IA en lugar de tratarlas a todas como igualmente peligrosas. Cada activo de IA recibe una puntuación de 1 a 3 en cinco dimensiones: sensibilidad de los datos, autoridad de decisión, acceso al sistema, exposición externa y origen de la cadena de suministro. La puntuación total determina la gobernanza requerida:
Nivel 1 (bajo riesgo): puntuaciones de 5 a 7 y solo requiere una revisión de seguridad estándar y una supervisión ligera. Nivel 2 (Riesgo medio): puntuaciones de 8 a 11, lo que desencadena una revisión mejorada, controles de acceso y auditorías de comportamiento trimestrales. Nivel 3 (alto riesgo): puntuaciones de 12 a 15, lo que exige una evaluación de seguridad completa, revisión del diseño, monitoreo continuo y un manual de respuesta a incidentes listo para implementar.
Es esencial tener en cuenta que el nivel de riesgo de un modelo puede cambiar drásticamente (por ejemplo, del Nivel 1 al Nivel 3) sin cambiar su código subyacente, en función de cambios de integración como agregar acceso de escritura a una base de datos de producción o exponerla a usuarios externos.
El menor privilegio no se limita a IAM
El marco enfatiza que la mayoría de las fallas de seguridad de la IA se deben a un control de acceso deficiente, no a fallas en los modelos en sí. Para contrarrestar esto, exige la aplicación del principio de privilegio mínimo a los sistemas de IA, tal como se aplicaría a los usuarios humanos. Esto significa que las claves API deben tener un alcance limitado a recursos específicos, se deben evitar las credenciales compartidas entre la IA y los usuarios humanos, y el acceso de solo lectura debe ser el predeterminado cuando el acceso de escritura no es necesario.
Los controles de salida son igualmente críticos, ya que el contenido generado por IA puede convertirse inadvertidamente en una fuga de datos al reconstruir o inferir información confidencial. El marco requiere filtrado de salida para patrones de datos regulados (como SSN, números de tarjetas de crédito y claves API) e insiste en que el código generado por IA se trate como entrada no confiable, sujeto a los mismos análisis de seguridad (SAST, SCA y escaneo de secretos) que el código escrito por humanos.
Su modelo es una cadena de suministro
Cuando implementas un modelo de terceros, heredas la postura de seguridad de quien lo entrenó, el conjunto de datos del que aprendió y las dependencias que lo acompañan. El marco presenta la Lista de Materiales de IA (AI-BOM), una extensión del concepto SBOM tradicional para modelar artefactos, conjuntos de datos, ajustar entradas e infraestructura de inferencia. Un AI-BOM completo documenta el nombre del modelo, la versión y la fuente; referencias de datos de entrenamiento; ajustar conjuntos de datos; todas las dependencias de software necesarias para ejecutar el modelo; componentes de infraestructura de inferencia; y vulnerabilidades conocidas con su estado de reparación. Varias regulaciones emergentes, incluida la Ley de IA de la UE y el NIST AI RMF, hacen referencia explícita a los requisitos de transparencia de la cadena de suministro, lo que hace que una AI-BOM sea útil para el cumplimiento, independientemente del marco con el que se alinee su organización.
Monitoreo de amenazas que el SIEM tradicional no puede detectar
Las reglas SIEM tradicionales, la detección de anomalías basada en la red y el monitoreo de terminales no detectan los modos de falla específicos de los sistemas de IA: inyección rápida, deriva del modelo, manipulación del comportamiento o intentos de jailbreak a escala. El marco define tres capas de monitoreo distintas que requieren las cargas de trabajo de IA.
En la capa del modelo, los equipos deben estar atentos a los indicadores de inyección rápida en las entradas proporcionadas por el usuario, los intentos de extraer indicaciones del sistema o la configuración del modelo y cambios significativos en los patrones de salida o puntuaciones de confianza. En la capa de integración de aplicaciones, las señales clave son las salidas de IA que se pasan a receptores sensibles (escrituras de bases de datos, llamadas API externas, ejecución de comandos) y llamadas API de gran volumen que se desvían del uso básico. En la capa de infraestructura, el monitoreo debe cubrir el acceso no autorizado a los artefactos del modelo o al almacenamiento de datos de entrenamiento, y la salida inesperada a API de IA externas que no están en el inventario aprobado.
Los equipos de creación de políticas realmente seguirán
La sección de políticas del marco define seis componentes principales:
Aprobación de herramientas: mantenga una lista de herramientas de IA preaprobadas que los equipos pueden adoptar sin revisión adicional. Revisión por niveles: utilice un proceso de aprobación por niveles que siga siendo liviano para casos de bajo riesgo (Nivel 1) y al mismo tiempo reserve un escrutinio más profundo para los activos de Nivel 2 y 3. Manejo de datos: establezca reglas explícitas que distingan entre IA interna y externa (API de terceros o modelos alojados). Seguridad del código: Exija que el código generado por IA se someta a la misma revisión de seguridad que el código escrito por humanos. Divulgación: exigir que las integraciones de IA se declaren durante las revisiones de arquitectura y el modelado de amenazas. Usos prohibidos: describa explícitamente los usos que están prohibidos, como modelos de capacitación sobre datos regulados de clientes sin aprobación.
Gobernanza y aplicación de la ley
Una política eficaz requiere una apropiación clara. El marco asigna responsabilidad a cuatro roles:
Propietario de seguridad de IA: responsable de mantener el inventario de IA aprobado y escalar los casos de alto riesgo. Equipos de desarrollo: responsables de declarar el uso de herramientas de IA y enviar el código generado por IA para una revisión de seguridad. Adquisiciones y Legal: Enfocado en revisar los contratos de proveedores para determinar los términos adecuados de protección de datos. Visibilidad ejecutiva: necesaria para aprobar la aceptación de riesgos para implementaciones de alto riesgo (Nivel 3).
La aplicación más duradera se logra mediante herramientas. Esto incluye el uso de escaneo SAST y SCA en canalizaciones de CI/CD, la implementación de controles de red que bloquean la salida a puntos finales de IA no aprobados y la aplicación de políticas de IAM que restringen las cuentas de servicios de IA a los permisos mínimos necesarios.
Cuatro etapas de madurez, un diagnóstico honesto
El marco se cierra con un modelo de madurez de la seguridad de la IA organizado en cuatro etapas: Emergente (Ad Hoc/Concienciación), Desarrollo (Definido/Reactivo), Control (Gestionado/Proactivo) y Liderazgo (Optimizado/Adaptable), que se relaciona directamente con NIST AI RMF, OWASP AIMA, ISO/IEC 42001 y la Ley de IA de la UE. Hoy en día, la mayoría de las organizaciones se encuentran en la Etapa 1 o 2, que el marco enmarca no como un fracaso sino como un reflejo preciso de la rapidez con la que la adopción de la IA ha superado la gobernanza.
Cada etapa de transición viene con una prioridad y un resultado comercial claros. Pasar de una empresa emergente a una en desarrollo es un ejercicio que prioriza la visibilidad: implementar una AI-BOM, asignar propiedad y ejecutar un modelo de amenaza inicial. Pasar del desarrollo al control significa automatizar las barreras de seguridad (refuerzo de avisos del sistema, comprobaciones de IA de CI/CD, aplicación de políticas) para ofrecer una protección consistente sin ralentizar el desarrollo. Alcanzar la etapa de Liderazgo requiere una validación continua a través de equipos rojos automatizados, puntuación AIWE (Enumeración de debilidades de IA) y monitoreo del tiempo de ejecución. En ese momento, la seguridad deja de ser un cuello de botella y comienza a acelerar la adopción de la IA.
La guía completa, que incluye una autoevaluación que califica la madurez de la IA de su organización frente a los controles NIST, OWASP, ISO y la Ley de IA de la UE en menos de cinco minutos, está disponible para descargar.