¿Qué es la gestión de riesgos de la IA?
La gestión de riesgos de la IA es el proceso estructurado y repetible que una organización utiliza para identificar, evaluar, tratar y supervisar los riesgos derivados del desarrollo, la provisión o el uso de sistemas de IA. Abarca todo el ciclo de vida de un sistema de IA, desde la definición del problema y la obtención de datos hasta el diseño, la validación, la implementación y, finalmente, la retirada del modelo.
A diferencia del riesgo de seguridad de la información tradicional, que se centra principalmente en la confidencialidad, la integridad y la disponibilidad de la información, la gestión de riesgos de la IA debe tener en cuenta un conjunto más amplio de preocupaciones. El sesgo del modelo, la falta de explicabilidad, la deriva de datos, el mal uso de los resultados, el impacto social y el comportamiento de los modelos de base de terceros entran de lleno en el ámbito de aplicación. Por eso, ISO 42001, Requiere un proceso específico de evaluación de riesgos de IA en lugar de integrar el riesgo de IA en un registro de seguridad de la información ya existente.
En la práctica, la gestión de riesgos de la IA responde a cuatro preguntas para cada caso de uso de la IA en la empresa:
- ¿Qué podría fallar en este sistema de IA, para quién y con qué gravedad?
- ¿Qué probabilidad hay de que se produzca cada uno de esos resultados, teniendo en cuenta los controles que ya tenemos?
- ¿Qué vamos a hacer ante los riesgos que superan nuestra tolerancia?
- ¿Cómo sabremos, después de la implementación, si nuestra evaluación sigue siendo válida?
Bien hecho, le da al tablero, el Comité de gobernanza de la IAy que los equipos de ingeniería compartan una visión común sobre qué iniciativas de IA pueden llevarse a cabo de forma segura, cuáles necesitan controles adicionales y cuáles deberían pausarse o redefinirse.
¿Cómo aborda la norma ISO 42001 el riesgo de la IA (Cláusula 6.1.2 frente a la Cláusula 6.1.4)?
La norma ISO 42001 separa la gestión de riesgos de la IA en dos actividades relacionadas pero distintas, y confundirlas es uno de los errores de implementación más comunes.
Cláusula 6.1.2 — Evaluación de riesgos de la IA. Este es el enfoque tradicional de gestión de riesgos, centrado en la propia organización. Se identifican los riesgos relacionados con la IA, se analiza su probabilidad y consecuencias en función de los criterios de riesgo de la organización y se decide cómo abordarlos. Este proceso es el que alimenta el registro de riesgos de la IA.
Cláusula 6.1.4 — Evaluación del impacto del sistema de IA. Esta es la perspectiva externa. Evalúa el impacto potencial de un sistema de IA en individuos, grupos de individuos y la sociedad, abarcando la equidad, la seguridad, la supervisión humana y los derechos fundamentales. El Anexo A.5 proporciona el conjunto de controles que lo operacionalizan. Encontrará orientación detallada en nuestra guía especializada. Evaluaciones del impacto de la IA .
Ambos son normativos. Ambos deben estar documentados. Ambos alimentan su Declaración de aplicabilidad y su política de IAPero responden a preguntas diferentes, tienen aportaciones distintas y, por lo general, involucran a diferentes partes interesadas. Realizarlas como un único ejercicio combinado tiende a dejar de lado la perspectiva del impacto social, que es precisamente lo que buscan los auditores y reguladores.
La guía normativa para ambas actividades se encuentra en Guía del Anexo BEl Anexo C proporciona orientación informativa sobre las fuentes de riesgo relacionadas con la IA, lo que constituye una taxonomía inicial útil al momento de completar su registro.
¿Cómo se relaciona con el riesgo de seguridad de la información (ISO 27005)?
La gestión de riesgos de la IA no sustituye a la gestión de riesgos de seguridad de la información. Muchos sistemas de IA almacenan, procesan o transmiten datos personales y se alojan en la misma infraestructura que otras cargas de trabajo reguladas. La norma ISO 27005 sigue siendo la referencia adecuada para el proceso de gestión de riesgos de seguridad de la información. El modelo práctico es:
- Los riesgos de seguridad de la información relacionados con el sistema de IA (confidencialidad, integridad, disponibilidad de datos de entrenamiento, artefactos del modelo, API) se encuentran en el registro de riesgos ISO 27001.
- Los riesgos específicos de la IA (sesgo, explicabilidad, desviación, uso no previsto, daño social) se encuentran en el registro de riesgos de la IA bajo la Cláusula 6.1.2.
- Las referencias cruzadas vinculan ambos sistemas, de modo que un único evento de riesgo puede ser rastreado a través de ambos enfoques sin duplicación.
El brecha en la gobernanza de la IA La cláusula 6.1.2 de la norma ISO 42001 precisamente pretende cerrar la brecha entre la seguridad de la información y la gobernanza de la IA.
¿Dónde encaja el Marco de Gestión de Riesgos de IA del NIST?
El Marco de Gestión de Riesgos de IA del NIST es un marco voluntario estadounidense organizado en torno a cuatro funciones: Gobernar, Mapear, Medir y Gestionar. Complementa la norma ISO 42001, en lugar de competir con ella. Las organizaciones que ya utilizan el Marco de Gestión de Riesgos de IA del NIST pueden integrar sus funciones directamente en las cláusulas de la ISO 42001 (Gobernar se alinea con las cláusulas 4 y 5, Mapear con la cláusula 6.1, Medir con la cláusula 9 y Gestionar con las cláusulas 8 y 10). Si su objetivo es un público internacional, la ISO 42001 le proporciona el sistema de gestión certificable. El Marco de Gestión de Riesgos de IA del NIST le ofrece un vocabulario ampliamente reconocido y guías prácticas para las actividades subyacentes.
Todo lo que necesitas para ISO 42001
Contenido estructurado, riesgos mapeados y flujos de trabajo integrados para ayudarlo a gobernar la IA de manera responsable y con confianza.
¿Cuáles son las principales categorías de riesgo de la IA?
Una buena taxonomía de riesgos de IA evita que se pasen por alto categorías enteras de riesgo. El Anexo C de la norma ISO 42001 proporciona una lista informativa de fuentes de riesgo relacionadas con la IA que la mayoría de las organizaciones adaptan a su propio contexto. En la práctica, ocho categorías abarcan la gran mayoría de los riesgos de la IA, y la mayoría de las entradas en su registro se corresponderán con una o más de ellas.
| Categoría | Ejemplo | Control(es) ISO 42001 | Tratamiento típico |
|---|---|---|---|
| Sesgo y equidad | El modelo de calificación crediticia subestima sistemáticamente a un grupo protegido. | A.6.2.2, A.6.2.4, A.7.4 | Mitigar mediante datos de entrenamiento equilibrados, pruebas de equidad y revisión humana. |
| Explicabilidad y transparencia | El modelo de triaje médico no puede justificar sus recomendaciones a los médicos. | A.6.2.4, A.8.2, A.8.3 | Mitigar mediante modelos interpretables, documentación y tarjetas de modelos. |
| Seguridad | Un ataque de inyección rápida extrae datos confidenciales de un LLM | A.6.2.3, A.7.3, A.8.4 | Mitigar mediante validación de datos de entrada, medidas de seguridad y modelado de amenazas. |
| Política de privacidad | Los datos de entrenamiento contienen datos personales utilizados sin una base legal. | A.7.2, A.7.4, A.8.2 | Mitigar mediante la minimización de datos, la anonimización y la alineación con la DPIA. |
| Seguridad | El sistema autónomo causa daños físicos mediante un comportamiento inesperado. | A.6.2.4, A.9.3, A.9.4 | Mitigar mediante validación, implementación gradual, interruptores de seguridad y supervisión humana. |
| Societal | El modelo de moderación de contenido amplifica la desinformación o suprime el discurso legítimo. | A.5.2, A.5.3, A.5.4 | Mitigar mediante la evaluación de impacto, la participación de las partes interesadas y la revisión continua. |
| Operacional | La deriva del modelo provoca que la precisión de las previsiones se degrade después de seis meses de producción. | A.6.2.6, A.6.2.7, A.6.2.8 | Mitigar mediante monitoreo, activadores de reentrenamiento y umbrales de rendimiento. |
| Cadena de suministro | El proveedor del modelo base cambia su comportamiento sin previo aviso, lo que provoca la interrupción de un caso de uso posterior. | A.10.2, A.10.3, A.10.4 | Mitigar mediante la debida diligencia de los proveedores, los contratos y los proveedores alternativos. |
La mayoría de las organizaciones adoptan esta taxonomía como base de su registro de riesgos de IA, y luego añaden categorías específicas del sector (por ejemplo, el sector de servicios financieros añade la gestión de riesgos de modelos según la norma SR 11-7, y el sector sanitario añade la seguridad clínica). Lo fundamental es que cada caso de uso de IA se evalúe según todas las categorías, aunque sea brevemente, para evitar que se pasen por alto riesgos por casualidad.
¿Cómo se realiza una evaluación de riesgos de la IA?
El proceso de evaluación, según la cláusula 6.1.2, sigue el ritmo habitual de Planificar-Hacer-Verificar-Actuar de los sistemas de gestión ISO, pero con aportaciones específicas de IA en cada etapa. Un método práctico y reproducible consta de seis pasos.
Paso 1: Definir el alcance y los criterios de riesgo.
Antes de evaluar nada, defina qué se considera un sistema de IA en su organización (esto ya debería estar en su Sistema de gestión de inteligencia artificial (AIMS) declaración de alcance) y qué criterios de riesgo utilizará. Los criterios de riesgo incluyen sus escalas de probabilidad y consecuencias, su umbral de aceptación de riesgos y las categorías de consecuencias que le importan (financieras, operativas, regulatorias, reputacionales, de seguridad, sociales).
Paso 2: Identificar casos de uso y recursos de IA
Inventarie todos los sistemas de IA incluidos en el alcance del proyecto. Para cada uno, registre el uso previsto, los datos de entrada, el tipo de modelo (propietario, optimizado, modelo base de terceros), los usuarios, las partes afectadas, el entorno de implementación y su criticidad. Este inventario constituye la base del resto del proceso.
Paso 3: Identificar los riesgos utilizando la taxonomía.
Analice cada sistema de IA a través de las ocho categorías de riesgo mencionadas anteriormente. Utilice las fuentes de riesgo del Anexo C, técnicas de modelado de amenazas y sesiones de lluvia de ideas estructuradas con un grupo multidisciplinario (ciencia de datos, ingeniería, seguridad, legal, producto y, cuando corresponda, la unidad de negocio que utilizará el resultado). Registre cada riesgo como un evento específico con una causa y una consecuencia, no como una etiqueta genérica.
Paso 4: Analizar la probabilidad y las consecuencias
Califique cada riesgo según sus criterios. La probabilidad debe considerar el entorno de control actual, no el estado sin control. La consecuencia debe considerar a todas las partes afectadas, no solo a la organización; aquí es donde entra en juego la evaluación de impacto de la Cláusula 6.1.4. Documente su razonamiento; un auditor le preguntará cómo llegó a una puntuación alta o baja.
Paso 5: Evaluar según los criterios de riesgo
Represente cada riesgo en su matriz y compárelo con su umbral de aceptación de riesgos. Cualquier riesgo que supere el umbral requiere una decisión de tratamiento. Cualquier riesgo igual o inferior al umbral puede aceptarse con una justificación explícita registrada.
Paso 6: Documentar y revisar
El registro de riesgos de IA es información documentada según la Cláusula 7.5. Necesita propietarios, ciclos de revisión, historial de versiones y aprobación. Se alimenta directamente al Declaración de aplicabilidad — Los controles del Anexo A se seleccionan y justifican en función de los riesgos que figuran en este registro.
¿Cómo se gestionan los riesgos de la IA?
Para cada riesgo que supere su umbral de aceptación, la cláusula 6.1.3 exige una decisión de tratamiento. Se aplican las cuatro opciones clásicas, con matices específicos de la IA:
- Evitar No construya, implemente ni utilice el sistema de IA. Es apropiado cuando el riesgo residual es inaceptable incluso con controles estrictos (por ejemplo, un caso de uso que automatiza una decisión con un impacto legal significativo en las personas sin intervención humana).
- Mitigar. Aplicar controles para reducir la probabilidad, la consecuencia o ambas. Este es el tratamiento más común. Los controles se extraen de Controles del anexo A, complementado con medidas específicas para cada sector o caso de uso. Las medidas de mitigación típicas incluyen datos de capacitación equilibrados, pruebas de imparcialidad, límites de entrada y salida, supervisión humana, implementación gradual y monitoreo continuo.
- Transferencia Transferencia de riesgos mediante contratos, seguros o responsabilidad del proveedor. Útil para riesgos en la cadena de suministro (por ejemplo, acuerdos de nivel de servicio contractuales con un proveedor de modelos básicos), pero tenga cuidado: puede transferir la responsabilidad financiera, pero rara vez la rendición de cuentas, especialmente ante los reguladores.
- Aceptar Mantenga el riesgo con una justificación explícita y documentada, y con un responsable. Solo es apropiado para riesgos iguales o inferiores al umbral de aceptación, o cuando el tratamiento no sea demostrablemente rentable y las consecuencias sean limitadas.
Cada decisión de tratamiento requiere un responsable designado, una fecha límite y evidencia de finalización vinculada al registro. Un plan de tratamiento sin evidencia de ejecución es una de las no conformidades más comunes en las auditorías de certificación ISO 42001.
Comience fácilmente con una demostración personal del producto
Uno de nuestros especialistas en incorporación lo guiará a través de nuestra plataforma para ayudarlo a comenzar con confianza.
¿Cómo se supervisan los riesgos de la IA después de su implementación?
El riesgo de la IA no es estático. Un modelo que era seguro en su lanzamiento puede volverse inseguro seis meses después debido a la variación de los datos, los cambios en el comportamiento de los usuarios, las modificaciones en el marco regulatorio o la actualización de un modelo base. La evaluación del rendimiento según la cláusula 9 y los controles de monitoreo operativo de los anexos A.6.2.6 a A.6.2.8 exigen una vigilancia constante.
Un programa de monitoreo pragmático tiene cinco señales:
- Rendimiento del modelo. Se realiza un seguimiento de las métricas de exactitud, precisión, exhaustividad, calibración y equidad en función de los umbrales establecidos durante la implementación. Las infracciones activan el reentrenamiento o la reversión.
- Desviación de datos. Comparación estadística de las distribuciones de los insumos de producción con las distribuciones de entrenamiento. Una desviación significativa desencadena una evaluación para determinar si el modelo sigue siendo adecuado para su propósito.
- Incidentes y situaciones de riesgo. Un canal formal para que los usuarios, las partes afectadas y el personal interno informen sobre inquietudes relacionadas con la IA, con clasificación, análisis de la causa raíz y registro de acciones correctivas bajo la Cláusula 10.
- eficacia del control. Verificaciones periódicas para comprobar que las medidas de mitigación del plan de tratamiento funcionan correctamente. El Anexo A.6.2.6 exige explícitamente la verificación de los controles operativos.
- Contexto externo. Nuevas regulaciones, nuevos patrones de amenazas, cambios en los modelos de terceros y nuevas mejores prácticas. Todo esto se incorpora a la evaluación de riesgos en cada revisión programada.
Los resultados se incorporan a la revisión de la dirección (Cláusula 9.3) y dan lugar a las actualizaciones del registro de riesgos, la Declaración de Aplicabilidad y la política de IA. El ciclo es continuo, no anual.
¿Cómo estructura ISMS.online la gestión de riesgos de la IA?
SGSI.online Proporciona una plataforma diseñada específicamente para el proceso completo de gestión de riesgos de IA, alineada con la cláusula 6.1.2 y la guía normativa del Anexo B. Obtendrá un registro de riesgos de IA integrado con el resto de su AIMS, en lugar de estar en una hoja de cálculo aparte.
La plataforma te ofrece:
- Un registro de riesgos de IA específico distinto de su registro de riesgos de seguridad de la información, con campos para atributos específicos de IA (caso de uso, fuentes de datos, tipo de modelo, partes afectadas, categoría de riesgo) junto con los campos estándar de probabilidad, consecuencia, tratamiento y propietario.
- Una taxonomía de riesgos de IA precargada Cubre las ocho categorías anteriores más las fuentes de riesgo del Anexo C, para que los equipos comiencen con una lista completa en lugar de una página en blanco.
- Evaluaciones de impacto de sistemas de IA vinculados para la cláusula 6.1.4, de modo que la perspectiva del impacto externo permanezca conectada a la perspectiva del riesgo organizacional sin duplicación.
- Enlace de control directo desde cada riesgo hasta los controles pertinentes del Anexo A, hasta la evidencia que demuestra el tratamiento, y hasta la Declaración de Aplicabilidad.
- Revisar los flujos de trabajo y los recordatorios automatizados. de modo que los riesgos se revisan en su ciclo definido, no cuando alguien se acuerda.
- Referencia cruzada con los riesgos de la norma ISO 27001 donde un evento tiene dimensiones tanto de seguridad de la información como de IA, evitando la doble contabilización y los planes de tratamiento contradictorios.
- Opiniones sobre informes para la junta, el comité de gobernanza de IA y los auditores de certificación, producidos a partir de los mismos datos subyacentes.
El resultado es un proceso de riesgo basado en IA que un auditor puede completar de principio a fin en menos de diez minutos, y que la organización puede seguir utilizando entre auditorías.
¿Por qué elegir ISMS.online para la gestión de riesgos de IA?
La mayoría de las herramientas GRC tratan el riesgo de la IA como un añadido posterior a un modelo de seguridad de la información. SGSI.online Fue diseñado con la gobernanza de la IA como una capacidad de primera clase. Esto es lo que significa en la práctica:
- Registros separados pero conectados. El riesgo de la IA (Cláusula 6.1.2), la evaluación del impacto del sistema de IA (Cláusula 6.1.4) y el riesgo de seguridad de la información (ISO 27005) se encuentran en registros distintos pero interrelacionados, de modo que cada perspectiva se mantiene precisa mientras los datos se comparten donde corresponde.
- Taxonomía de riesgos de IA predefinida. Las fuentes de riesgo del Anexo C y el modelo de ocho categorías vienen precargados, de modo que su equipo identifica los riesgos en función de un marco estructurado en lugar de tener que inventarlo.
- Mapeo en vivo a Controles del anexo A. Cada riesgo está directamente vinculado a los controles que lo tratan, a la evidencia que demuestra que el tratamiento funciona y a la entrada de la Declaración de Aplicabilidad que lo justifica.
- Elaborado conforme a las directrices del Anexo B. El flujo de trabajo sigue las directrices de implementación normativas del Anexo B, por lo que su proceso se ajusta a los estándares de forma predeterminada, en lugar de requerir una configuración personalizada.
- Integrado con el sistema AIMS completo. Los riesgos se conectan con su política de IA, sus evaluaciones de impacto, su programa de auditoría (Cláusula 9.2) y sus acciones correctivas (Cláusula 10), para que nada quede sin revisar.
- Método de resultados garantizados. Un método de implementación probado y soporte humano que ha ayudado a cientos de organizaciones a obtener la certificación a la primera, con la gestión de riesgos de IA integrada desde el principio en lugar de añadida posteriormente.
Ya sea que esté creando su primer registro de riesgos de IA o perfeccionando uno existente, SGSI.online Le brinda la estructura y las herramientas para operar la Cláusula 6.1.2 como un proceso vivo. Para un contexto más amplio, consulte nuestra Guía de implementación.
¿Listo para ver la plataforma en acción? Agendar demo .
Preguntas Frecuentes
¿Cuál es la diferencia entre la evaluación de riesgos de la IA (Cláusula 6.1.2) y la evaluación del impacto del sistema de IA (Cláusula 6.1.4)?
La cláusula 6.1.2 se refiere a la perspectiva interna del riesgo organizacional: qué podría salir mal para la organización, sus objetivos y sus operaciones, y cómo lo abordaremos. La cláusula 6.1.4 se refiere a la perspectiva externa: qué podría hacer el sistema de IA a las personas, los grupos y la sociedad, abarcando la equidad, la seguridad y los derechos fundamentales. Ambas son normativas, deben documentarse y se retroalimentan. Si se gestionan como una sola actividad combinada, generalmente se pierde la perspectiva del impacto social, lo cual es un hallazgo común en las auditorías.
¿Puedo reutilizar mi registro de riesgos ISO 27001 para la gestión de riesgos de IA?
No, no como un único registro combinado. El riesgo de seguridad de la información (ISO 27005) y el riesgo de IA (ISO 42001, cláusula 6.1.2) tienen alcances superpuestos pero distintos. La seguridad de la información abarca la confidencialidad, la integridad y la disponibilidad de la información. El riesgo de IA, además, abarca el sesgo, la explicabilidad, la deriva, la seguridad y el impacto social, aspectos que no se ajustan fácilmente a un modelo CIA. El patrón adecuado consiste en dos registros conectados con referencias cruzadas, donde un único evento abarca ambas dimensiones. SGSI.online Apoya precisamente este arreglo.
¿Es el Marco de Gestión de Riesgos (RMF) de IA del NIST una alternativa a la norma ISO 42001 para la gestión de riesgos?
Son complementarios, no alternativos. El Marco de Gestión de Riesgos para la IA del NIST es un marco voluntario estadounidense organizado en torno a las funciones de Gobernar, Mapear, Medir y Gestionar, con una excelente guía práctica. La norma ISO 42001 es un estándar de sistema de gestión certificable internacionalmente. Las organizaciones suelen utilizar el vocabulario y los manuales del Marco de Gestión de Riesgos para la IA del NIST para llevar a cabo las actividades que exige la ISO 42001. Ambos se complementan perfectamente y muchas organizaciones los implementan en paralelo.
¿Qué categorías de riesgo de IA debo incluir en mi registro?
Como mínimo: sesgo y equidad, explicabilidad y transparencia, seguridad, privacidad, protección, impacto social, aspectos operativos (desviación, rendimiento, disponibilidad) y cadena de suministro (modelos de terceros, proveedores de datos). El Anexo C de la norma ISO 42001 proporciona una lista informativa de fuentes de riesgo relacionadas con la IA que se ajusta a esta taxonomía. Se deben añadir categorías específicas del sector, como la gestión del riesgo de modelos para los servicios financieros o la seguridad clínica para la atención sanitaria, cuando corresponda.
¿Con qué frecuencia debo revisar el registro de riesgos de la IA?
Al menos anualmente, se realizará una revisión completa que se integrará en la revisión de gestión según la Cláusula 9.3. Los riesgos individuales deberán tener sus propios ciclos de revisión según su criticidad: generalmente trimestral para riesgos altos y semestral para riesgos medios. Cualquier cambio significativo deberá dar lugar a una revisión ad hoc: un nuevo caso de uso de IA, una actualización importante del modelo, una nueva normativa, un incidente notificado o un cambio en un proveedor externo clave. El registro es un documento dinámico, no un documento de cumplimiento anual.
¿La norma ISO 42001 exige la monitorización automatizada de los riesgos de la IA?
La norma no prescribe la automatización, pero sí exige la monitorización continua del rendimiento y la eficacia de los controles del sistema de IA (Cláusula 9.1 y Anexo A.6.2.6 a A.6.2.8). Para sistemas de IA de bajo riesgo, la monitorización automatizada del rendimiento del modelo, la deriva de datos y la eficacia de los controles es la única forma de cumplir con este requisito en la práctica. La monitorización manual a gran escala suele generar datos obsoletos e incidentes no detectados, que se manifiestan como no conformidades en las auditorías de vigilancia.
¿Quién debería ser responsable de la gestión de riesgos de la IA en la organización?
La responsabilidad recae en un ejecutivo designado, generalmente el CISO, el Director de Riesgos o un responsable de gobernanza de IA, según el tamaño de la organización y el nivel de madurez de la IA. La gestión diaria corresponde a un comité de gobernanza de IA o un grupo multifuncional equivalente integrado por profesionales de ciencia de datos, ingeniería, seguridad, asesoría legal, privacidad y las unidades de negocio que utilizan IA. Cada riesgo individual tiene un responsable designado para su tratamiento y seguimiento. La cláusula 5.3 exige que estas funciones, responsabilidades y atribuciones se asignen y comuniquen formalmente.
