La matriz de riesgos ISO 27001 frente a la IA

Su SGSI se diseñó antes que su IA

Si su organización incorporó herramientas, modelos o flujos de datos de IA después de su última evaluación de riesgos de ISO/IEC 27001, es posible que su Sistema de Gestión de Seguridad de la Información (SGSI) ya no describa cómo circula realmente la información en su negocio.

La IA cambia adónde van los datos, quién (o qué) puede acceder a ellos y qué se puede deducir a partir de ellos.

Un registro de cliente pegado en un chatbot público, un conjunto de datos de entrenamiento copiado a una nueva región de la nube o un modelo que memoriza sin que nadie lo advierta información confidencial pueden generar riesgos que su Declaración de aplicabilidad actual nunca contempló.

La buena noticia: ISO/IEC 27001:2022 ya le ofrece el marco para gestionar estos riesgos. Los controles del Anexo A en los que se apoya hoy siguen siendo aplicables.

Solo hay que interpretarlos, delimitarlos y evidenciarlos teniendo en cuenta la IA. Esta guía le muestra cómo hacerlo.

Por qué los controles tradicionales del Anexo A se quedan cortos

La mayoría de los controles del Anexo A se redactaron pensando en activos de TI convencionales: servidores, aplicaciones, bases de datos y las personas que los utilizan. Los flujos de trabajo de IA rompen varios de los supuestos en los que esos controles se apoyan de manera implícita.

• Los datos pasan a formar parte del activo. Una vez que los datos de entrenamiento moldean un modelo, el propio modelo puede conservar rastros de esos datos. Eliminar el archivo de origen no necesariamente elimina la información.
• Las entradas son instrucciones. En los sistemas de IA, las instrucciones del usuario (prompts) y el contenido recuperado pueden modificar el comportamiento del sistema, lo que difumina la frontera entre datos y código.
• El uso se extiende más rápido que la gobernanza. Los empleados pueden adoptar herramientas de IA en cuestión de minutos, a menudo al margen de las compras, de la revisión de TI o de su inventario de activos.
• Los proveedores se multiplican. Una sola función de IA puede depender de un proveedor de modelos, una plataforma de alojamiento, una base de datos vectorial y componentes de código abierto, cada uno de ellos un eslabón de su cadena de suministro de TIC.
• Los datos cruzan fronteras por defecto. Las cargas de trabajo de inferencia y entrenamiento suelen enrutarse hacia donde haya capacidad de cómputo disponible, no hacia donde sus compromisos de residencia de datos indican que deben permanecer.

Nada de esto exige abandonar su SGSI. Exige revisar su contexto (cláusula 4), su evaluación y tratamiento de riesgos (cláusula 6.1) y los controles que seleccionó en su Declaración de aplicabilidad.

Las vulnerabilidades de IA sobre las que su auditor le preguntará

IA en la sombra (shadow AI)

La IA en la sombra es el uso de herramientas, complementos o modelos de IA sin el conocimiento ni la aprobación de los equipos de TI y de seguridad.

Un empleado que pega código fuente, condiciones contractuales o datos de clientes en un chatbot no autorizado ha transferido información fuera de su entorno controlado, a menudo a un proveedor con el que no existe ningún acuerdo.

La IA en la sombra socava a la vez su inventario de activos, sus normas de uso aceptable, sus controles de proveedores y sus controles de transferencia de información. Si no figura en su inventario, no figura en su evaluación de riesgos.

Inversión de modelos

La inversión de modelos es un ataque en el que un adversario consulta un modelo entrenado y utiliza sus resultados para reconstruir información sensible de los datos de entrenamiento.

Técnicas afines, como la inferencia de pertenencia, pueden revelar si el registro de una persona concreta se utilizó para entrenar el modelo.

Esto significa que un modelo puede filtrar datos confidenciales o personales aunque la base de datos subyacente esté completamente protegida.

Sus controles de acceso, el enmascaramiento de datos y los controles de privacidad deben extenderse al modelo y a sus resultados, no solo al almacén de datos.

Correspondencia entre riesgos de IA y controles del Anexo A

El siguiente desglose relaciona los riesgos de IA más comunes con los controles del Anexo A de ISO/IEC 27001:2022 a los que afectan, y muestra cómo debe evolucionar la implementación de cada control.

Utilícelo como punto de partida para actualizar su evaluación de riesgos y su Declaración de aplicabilidad; su selección final de controles siempre debe responder a sus propias decisiones de tratamiento del riesgo.

IA en la sombra

El riesgo: Los empleados utilizan herramientas de IA no autorizadas que sacan datos de la empresa de su entorno controlado.

Controles del Anexo A:

• 9 Inventario de información y otros activos asociados
• 10 Uso aceptable
• 19 Seguridad de la información en las relaciones con proveedores
• 3 Concienciación, educación y formación

Enfoque tradicional: Inventario de hardware, software y datos aprobados

Qué debe cambiar:

• Detectar e inventariar las herramientas, complementos y API de IA en uso
• Publicar una política de uso aceptable de la IA
• Someter los servicios de IA a la revisión de proveedores
• Formar al personal sobre qué datos pueden introducirse en las herramientas de IA

Inversión de modelos e inferencia de pertenencia

El riesgo: Los atacantes consultan un modelo entrenado para reconstruir datos sensibles de entrenamiento o confirmar de quién son los registros utilizados.

Controles del Anexo A:

• 11 Enmascaramiento de datos
• 34 Privacidad y protección de la información de identificación personal (IIP)
• 3 Restricción del acceso a la información

Enfoque tradicional: Restringir el acceso a los registros almacenados

Qué debe cambiar:

• Tratar los modelos entrenados como activos que pueden contener datos sensibles
• Minimizar, desidentificar o enmascarar la IIP antes del entrenamiento
• Restringir y limitar la frecuencia de las consultas al modelo
• Comprobar si los modelos filtran datos

Fuga de datos a través de instrucciones y resultados

El riesgo: Los datos sensibles introducidos en las instrucciones, o devueltos en los resultados del modelo, llegan a personas o proveedores que no deberían verlos.

Controles del Anexo A:

• 12 Prevención de fuga de datos
• 12 Clasificación de la información
• 14 Transferencia de información

Enfoque tradicional: Supervisar el correo electrónico, las transferencias de archivos y los soportes extraíbles

Qué debe cambiar:

• Extender la prevención de fuga de datos (DLP) a las instrucciones, las cargas de archivos y las respuestas de la IA
• Definir qué niveles de clasificación pueden utilizarse con qué herramientas de IA
• Filtrar los resultados para detectar contenido sensible

Inyección de instrucciones (prompt injection)

El riesgo: Instrucciones maliciosas ocultas en las entradas del usuario o en documentos recuperados hacen que el sistema de IA ignore sus reglas, exponga datos o realice acciones no previstas.

Controles del Anexo A:

• 26 Requisitos de seguridad de las aplicaciones
• 28 Codificación segura
• 29 Pruebas de seguridad en el desarrollo y la aceptación

Enfoque tradicional: Validación de entradas en aplicaciones convencionales

Qué debe cambiar:

• Tratar todas las instrucciones y el contenido recuperado como entradas no confiables
• Limitar las acciones que pueden realizar los agentes de IA
• Incluir pruebas adversarias de instrucciones antes del lanzamiento

Envenenamiento de datos de entrenamiento

El riesgo: Datos manipulados o de baja calidad introducidos en los conjuntos de entrenamiento o de ajuste fino sesgan el comportamiento del modelo.

Controles del Anexo A:

• 25 Ciclo de vida de desarrollo seguro
• 32 Gestión de cambios
• 33 Información de prueba

Enfoque tradicional: Proteger el código fuente y los datos de prueba

Qué debe cambiar:

• Verificar el origen y la integridad de los datos de entrenamiento y de ajuste fino
• Aplicar control de versiones a los conjuntos de datos
• Exigir aprobación para los cambios en datos y modelos

Compromiso de la cadena de suministro de IA

El riesgo: Los modelos de terceros, los pesos de código abierto y las bibliotecas introducen vulnerabilidades que usted no creó y que quizá no pueda inspeccionar.

Controles del Anexo A:

• 21 Gestión de la seguridad de la información en la cadena de suministro de TIC
• 20 Abordaje de la seguridad de la información en los acuerdos con proveedores
• 8 Gestión de vulnerabilidades técnicas

Enfoque tradicional: Evaluar a los proveedores de software y aplicar parches

Qué debe cambiar:

• Evaluar a los proveedores de modelos de terceros y los modelos de código abierto
• Añadir a los contratos cláusulas específicas de IA (uso de datos, conservación, entrenamiento con sus datos)
• Hacer seguimiento de las vulnerabilidades en los marcos y bibliotecas de IA

Robo y extracción de modelos

El riesgo: Los atacantes copian un modelo propio, o lo aproximan mediante consultas repetidas, y exponen propiedad intelectual valiosa.

Controles del Anexo A:

• 2 Derechos de acceso privilegiado
• 5 Autenticación segura
• 24 Uso de criptografía

Enfoque tradicional: Proteger los sistemas y las credenciales

Qué debe cambiar:

• Proteger los pesos del modelo como activos de alto valor
• Cifrar los modelos en reposo y en tránsito
• Vigilar los volúmenes de consulta inusuales que sugieran una extracción

Uso indebido de la IA no detectado

El riesgo: Sin registro ni supervisión específicos para la IA, el uso indebido de herramientas, instrucciones o agentes de IA puede pasar inadvertido.

Controles del Anexo A:

• 15 Registro de eventos
• 16 Actividades de seguimiento
• 7 Inteligencia sobre amenazas

Enfoque tradicional: Registrar la actividad de los sistemas y de los usuarios

Qué debe cambiar:

• Registrar las instrucciones, los resultados y las acciones de los agentes de IA cuando sea lícito
• Vigilar el comportamiento anómalo de la IA
• Seguir la inteligencia sobre amenazas de IA emergentes

Tratamiento transfronterizo no controlado

El riesgo: El entrenamiento, la inferencia y el registro de la IA se ejecutan en regiones que pueden entrar en conflicto con sus obligaciones de residencia y transferencia de datos.

Controles del Anexo A:

• 23 Seguridad de la información para el uso de servicios en la nube
• 31 Requisitos legales, estatutarios, reglamentarios y contractuales
• 34 Privacidad y protección de la IIP

Enfoque tradicional: Seleccionar proveedores y regiones de la nube

Qué debe cambiar:

• Confirmar dónde se realizan el entrenamiento, la inferencia y el registro
• Alinear los flujos de datos de IA con las obligaciones de residencia y transferencia de cada jurisdicción en la que opere

Las organizaciones que necesiten gobernar la IA de forma más amplia, incluidas la equidad, la transparencia y la rendición de cuentas, pueden combinar ISO/IEC 27001 con ISO/IEC 42001, la norma internacional para los sistemas de gestión de inteligencia artificial.

Una sola correspondencia, cualquier jurisdicción

ISO/IEC 27001 es una norma internacional, y eso hace que esta correspondencia sea trasladable.

Tanto si sus cargas de trabajo de IA se ejecutan en una única región de la nube como si abarcan proveedores en Norteamérica, Europa y Asia-Pacífico, se aplican los mismos controles del Anexo A.

Esa coherencia importa a los equipos de cumplimiento internacionales. Las arquitecturas de nube transfronterizas suelen implicar datos recopilados en un país, modelos entrenados en otro e inferencia ofrecida a escala global.

Cada salto es una transferencia de información, una relación con un proveedor y, potencialmente, un nuevo conjunto de obligaciones legales.

Al anclar el riesgo de IA al Anexo A, su equipo puede:

• Aplicar un único marco de controles en todas las regiones, en lugar de mantener un enfoque distinto para cada mercado
• Incorporar los requisitos locales de privacidad y protección de datos a un único conjunto de controles auditables mediante los controles 5.31 y 5.34
• Demostrar a clientes, socios y reguladores de todo el mundo que el riesgo de IA se gestiona dentro de un sistema de gestión acreditado y reconocido internacionalmente
• Escalar la adopción de la IA a nuevos mercados sin reconstruir su programa de seguridad cada vez

Su lista de verificación para un SGSI preparado para la IA

• Actualice su contexto y sus partes interesadas (cláusulas 4.1 y 4.2) para reflejar cómo su organización desarrolla, provee o utiliza IA
• Detecte y añada herramientas, modelos, conjuntos de datos y API de IA a su inventario de activos
• Repita su evaluación de riesgos con amenazas específicas de la IA, incluidas la IA en la sombra y la inversión de modelos
• Revise su Declaración de aplicabilidad y documente cómo se aplican a la IA los controles seleccionados
• Publique una política de uso aceptable de la IA y forme a los empleados en ella
• Revise a los proveedores de IA y actualice los contratos con condiciones de uso y conservación de datos
• Mapee dónde se procesan el entrenamiento, la inferencia y los registros de IA en las distintas regiones
• Incluya los sistemas de IA en su programa de auditoría interna y en la revisión por la dirección

Certifíquese con confianza

Perry Johnson Registrars, Inc. (PJR) ofrece certificación acreditada ISO/IEC 27001 a organizaciones de todo el mundo.

Nuestros auditores comprenden cómo los entornos modernos de nube e IA afectan a su SGSI, y nuestra certificación ofrece a sus clientes una garantía independiente de que su seguridad de la información, incluido su flujo de trabajo de IA, se gestiona conforme a una norma reconocida internacionalmente.

PJR también ofrece la certificación ISO/IEC 42001 para las organizaciones que estén listas para demostrar una gobernanza responsable de la IA junto con la seguridad de la información.