Marcos de gestión de riesgos de la IA: una visión general

La IA forma parte del trabajo diario, pero sus riesgos no siempre encajan en las listas de tareas de seguridad habituales. Los marcos de gestión de riesgos de la IA aportan estructura y control.

Contenido

1. Categorías de riesgo de la IA
2. Ley de IA de la UE
3. Marco de gestión de riesgos de la IA del NIST (AI RMF 1.0)
4. ISO/IEC 23894:2023 e ISO/IEC 42001
5. Componentes clave de la gestión de riesgos de la IA
6. ¿Qué marco es el más adecuado?
7. Implementación del marco

Puntos clave: marcos de gestión de riesgos de la IA

• Riesgos específicos de la IA no cubiertos totalmente por los enfoques tradicionales de seguridad informática
• Marcos voluntarios de gestión de riesgos de la IA como el NIST AI RMF y la norma ISO/IEC 42001, junto con normativas vinculantes como la Ley de IA de la UE
• Categorías de riesgo de la Ley de IA de la UE con diferentes obligaciones en función del nivel de riesgo
• La ISO/IEC 42001 como norma certificable para los sistemas de gestión de la IA con vínculos con la norma ISO 27001
• Gestión eficaz de los riesgos de la IA mediante la supervisión continua, una gobernanza clara y una formación en concienciación estructurada

Categorías de riesgo de la IA: a lo que ya se enfrentan las empresas hoy en día

Muchas empresas ya utilizan la IA en el trabajo diario, a menudo antes de que existan normas claras. Un equipo prueba una nueva herramienta. Un resultado suena plausible y se incorpora a una decisión.

Los riesgos de la IA no solo surgen en sistemas de IA complejos. También surgen en los flujos de trabajo rutinarios. La gestión de riesgos de la IA ayuda a las organizaciones a identificar estas situaciones, evaluarlas y decidir dónde se necesitan controles.

Riesgos técnicos: cuando los resultados erróneos suenan correctos

Un equipo de ventas utiliza la IA para evaluar una lista de cuentas antes de una reunión sobre el pipeline. La herramienta destaca varias cuentas como posibles compradoras, sugiere un buen momento para ponerse en contacto con ellas y ofrece al equipo un orden de prioridades claro. Al principio, eso parece más útil que arriesgado.

El problema aparece cuando el equipo compara la clasificación con los datos de ventas actuales. Ciertos sectores siguen apareciendo en los primeros puestos, aunque las últimas cifras del pipeline no justifican esa preferencia. Los ejemplos de entrenamiento anticuados parecen haber dado demasiado peso a esos sectores. El resultado no falla estrepitosamente. Simplemente parece lo suficientemente razonable como para utilizarlo, mientras que otras oportunidades mejores descienden en la lista.

La IA generativa lleva el mismo riesgo al trabajo diario. Un material de baja calidad puede sonar bien. Una fuente puede parecer creíble a primera vista y, aun así, no llevar a ninguna parte. Un número puede superar una comprobación rápida y luego resultar inexacto. Una afirmación puede leerse como si hubiera sido cuidadosamente sopesada, aunque falten las pruebas.

La deriva del modelo crea un problema más silencioso. Puede que el modelo funcionara bien en el momento del lanzamiento, pero el contexto que lo rodea cambia: productos, datos, mercados, comportamiento de los clientes. Desde un punto de vista técnico, puede que nada parezca raro. Pero las respuestas pueden volverse menos útiles con el tiempo, y su calidad puede disminuir.

La gestión de riesgos de la IA necesita comprobaciones operativas para esto:

• Resultados seleccionados para su revisión
• Errores y patrones recurrentes
• Desencadenantes claros para reevaluar un modelo

Riesgos de seguridad de la IA: cuando una entrada se convierte en un ataque

Los riesgos de seguridad de la IA suelen aparecer en las interfaces. Un chatbot responde a las preguntas de los clientes y utiliza bases de conocimiento internas para hacerlo. Un atacante formula una petición de forma que el bot sobrepase sus instrucciones normales.

El chatbot está diseñado para responder a la pregunta de un cliente. En cambio, la formulación lo dirige hacia directrices internas, notas de soporte técnico o contenido de la base de conocimientos que los clientes no deberían ver.

La inyección de instrucciones no se limita a la ventana de chat. También puede estar oculta en el material que se le pide al sistema de IA que lea. Un empleado puede utilizar una herramienta de IA para resumir una página web externa. La página parece normal, pero una sección está escrita para el modelo en lugar de para el lector. El resumen puede entonces seguir ese texto oculto para saltarse las protecciones o incluir información que no corresponde a la respuesta.

Con el envenenamiento de datos, el riesgo comienza incluso antes de que se utilice el modelo. Los comentarios de los clientes, los tickets de soporte técnico o las reseñas de productos pueden ayudar a mejorar un modelo, pero aun así necesitan una revisión antes de convertirse en datos de entrenamiento. Las entradas manipuladas pueden afectar más adelante a cómo clasifica el modelo los casos, qué patrones favorece o qué excepciones pasa por alto.

Los ataques antagónicos toman otra ruta. Son especialmente relevantes para los sistemas que reconocen imágenes, voz o patrones, por ejemplo, en el control de calidad. Un proveedor podría alterar una imagen de una pieza defectuosa lo suficiente como para que el modelo pase por alto el defecto. Una persona que revise la imagen podría no ver casi ninguna diferencia.

La gestión de riesgos de la IA debe incluir estas rutas de ataque, especialmente cuando la IA está conectada a datos de clientes, sistemas internos o procesos críticos para el negocio.

Riesgos de privacidad de la IA: cuando la velocidad tiene prioridad sobre la protección de datos

Los riesgos de privacidad de la IA suelen surgir sin intención maliciosa. Tomemos como ejemplo los RR. HH. Un empleado quiere comparar solicitudes de empleo rápidamente y sube currículos completos a una herramienta pública de IA en cuestión de segundos.

El departamento de adquisiciones puede enfrentarse a la misma presión. Un contrato necesita un resumen rápido, el plazo se acerca y el borrador completo acaba en una herramienta de IA no aprobada. Ese borrador puede contener precios, condiciones de entrega, márgenes de negociación y otros detalles que no deberían salir de la empresa sin una revisión.

En marketing, el riesgo puede ser más difícil de detectar. Los segmentos de clientes, los datos de campañas y los análisis internos pueden subirse porque el modelo de IA devuelve sugerencias útiles casi de inmediato. El equipo obtiene una respuesta más rápida, pero pierde de vista la ruta de los datos. ¿Dónde se procesa la información? ¿Se almacena? ¿Quién podría tener acceso a ella?

La IA en la sombra lleva esto un paso más allá. El departamento informático de la empresa no puede ver todas las herramientas. El departamento jurídico no conoce todos los casos de uso. La dirección a menudo se entera con retraso de qué herramientas de IA ya están utilizando los empleados.

La gestión de riesgos de la IA debe empezar aquí por el comportamiento. Los empleados necesitan una orientación clara sobre:

• Herramientas de IA aprobadas para el trabajo
• Datos permitidos en las herramientas de IA
• Punto de contacto para casos poco claros

Riesgos operativos: cuando la IA se convierte silenciosamente en la opción por defecto

Los riesgos operativos tienden a crecer gradualmente: un equipo de control utiliza primero la IA para acortar informes. Luego, la herramienta empieza a redactar comentarios. Al cabo de un tiempo, partes de esos comentarios aparecen en documentos de gestión tras solo una rápida revisión.

El proceso parece eficiente, así que el equipo sigue utilizándolo. Las suposiciones del informe reciben menos atención. La vía manual sigue estando disponible, pero se utiliza mucho menos. El equipo tiene menos práctica a la hora de detectar una lógica débil, la falta de contexto o conclusiones que no encajan del todo. Si la IA establece una conexión equivocada, el error puede pasar por varias capas antes de que alguien lo detecte.

El mismo patrón puede aparecer en el departamento informático. La IA clasifica los tickets, primero para ahorrar tiempo y luego como la forma normal de trabajar. Como la clasificación está siempre disponible, empieza a parecer fiable. Si se cuelan errores, los incidentes críticos pueden ser redirigidos con demasiada lentitud o gestionados con la prioridad equivocada.

Una gestión estructurada de los riesgos de la IA debería definir:

• Puntos de revisión para los resultados generados por la IA
• Decisiones que recaen en una persona
• Métricas de calidad para las respuestas de la IA
• Autoridad para detener resultados raros de la IA

Riesgos de cumplimiento de las normativas de la IA y riesgos legales de la IA: cuando un texto generado por IA puede tener implicaciones legales

“Integración perfecta”. “Máxima resiliencia”. “Listo para usar en minutos”. La IA puede redactar afirmaciones como estas rápidamente. Antes de su publicación, alguien todavía debe comprobar si la redacción es precisa y si está respaldada por pruebas y aprobada para su uso.

Esa revisión debe realizarse antes de que la afirmación aparezca en una página web, en una presentación de ventas o en material de producto. ¿Quién la aprobó? ¿Qué pruebas la respaldan? ¿Quién es el responsable de la redacción si se cuestiona más tarde?

La gestión de riesgos de la IA debe hacer que esta revisión sea rastreable, incluso en lo que respecta al cumplimiento de la NIS2:

• Herramientas de IA utilizadas para la redacción o revisión
• Usuarios autorizados
• Pasos de aprobación antes de la publicación
• Pruebas para las afirmaciones sobre productos y seguridad

Ese registro ayuda a los departamentos jurídico y de auditoría o a los reguladores a entender qué se comprobó y quién lo hizo.

Marcos de gestión de riesgos de la IA

El software tradicional sigue un código definido. Los sistemas de IA trabajan con patrones aprendidos de los datos. Esa diferencia es importante en la práctica. Un error de software a menudo puede rastrearse hasta una línea de código, una configuración o una dependencia. Un error de la IA puede provenir de los datos de entrenamiento, el comportamiento del modelo, las instrucciones, el contexto del usuario o cambios en el entorno.

Un marco de gestión de riesgos de la IA ofrece a los equipos de riesgos, seguridad, asuntos jurídicos y de negocio una forma compartida de tomar decisiones sobre esos sistemas. Ayuda a definir qué se debe documentar, qué controles son necesarios, quién aprueba y cuándo un caso de uso necesita otra revisión. Aquí es donde la gobernanza de la IA se convierte en parte de las operaciones diarias.

El NIST AI RMF y la norma ISO/IEC 42001 son marcos voluntarios. La Ley de IA de la UE tiene un papel diferente: establece requisitos legales vinculantes en la UE para ciertos sistemas y casos de uso de la IA. Muchas organizaciones necesitan ambas perspectivas. La normativa marca el límite legal; los marcos ayudan a los equipos a gestionar los riesgos de la IA en la práctica.

Ley de IA de la UE

La Ley de IA de la UE clasifica los sistemas de IA según el riesgo que puedan suponer para los derechos fundamentales, la seguridad y los valores sociales. Esta clasificación determina qué obligaciones se aplican. Por lo tanto, la gestión de riesgos de la Ley de IA de la UE no comienza con el nombre de una herramienta, sino con su caso de uso específico.

Marco de gestión de riesgos de la IA del NIST (AI RMF 1.0)

El Marco de gestión de riesgos de la IA del NIST fue publicado en 2023 por el Instituto Nacional de Normas y Tecnología de EE. UU. Es voluntario y se utiliza a menudo como referencia práctica porque es tecnológicamente neutro y puede aplicarse a organizaciones de diferentes tamaños.

Un breve resumen del Marco de gestión de riesgos de la IA del NIST comienza con el núcleo del AI RMF. Se basa en cuatro funciones: gobernar, mapear, medir y gestionar.

Gobernar

Gobernar define cómo se asigna la responsabilidad de los riesgos de la IA dentro de la organización. Esto incluye las aprobaciones, las políticas y las expectativas para los empleados. También incluye una pregunta práctica: ¿las personas están preparadas para el uso diario de la IA? La formación y la formación en concienciación estructurada pertenecen a esta capa porque los empleados influyen en qué datos entran en los sistemas de IA, cómo se utilizan los resultados y cuándo se escalan las preocupaciones.

Mapear

Mapear crea visibilidad sobre cómo se utiliza la IA en toda la organización. Describe el proceso de registrar los sistemas de IA, comprender su contexto de uso e identificar a las partes interesadas afectadas. En esta fase, muchas organizaciones descubren que ya se está utilizando más IA de la que se conocía internamente.

Medir

Medir evalúa la probabilidad de un riesgo y la gravedad de sus consecuencias. Esta evaluación no debe realizarse una sola vez. Los sistemas de IA cambian, y también su entorno. La gestión de riesgos de la IA debe reflejar esta realidad.

Gestionar

Gestionar convierte las evaluaciones en acciones: reducir, aceptar, transferir o seguir supervisando los riesgos. Las responsabilidades y los controles deben estar claramente definidos. El panel de métricas de gestión del riesgo humano de SoSafe lo facilita al hacer que el factor de riesgo humano en este proceso sea continuamente visible.

Para los equipos familiarizados con el Marco de Ciberseguridad del NIST, la lógica del AI RMF puede resultar relativamente conocida.

ISO/IEC 23894:2023 e ISO/IEC 42001

Las organizaciones que ya trabajan con la norma ISO 27001 tienen una base útil para la seguridad de la información. La IA añade cuestiones que la norma ISO 27001 por sí sola no responde completamente: cómo se comporta un modelo, qué datos le dieron forma, cómo se revisan las decisiones y cuánta transparencia se necesita. Dos normas ISO pueden ayudar a ampliar las estructuras existentes a la IA.

ISO/IEC 23894:2023

La norma ISO/IEC 23894 es una guía para la gestión de riesgos de la IA. Describe cómo pueden las organizaciones identificar, registrar y gestionar los riesgos relacionados con la IA de forma estructurada. La guía se basa en las ideas de la norma ISO 31000. No es certificable, pero ofrece a los equipos un método más claro para abordar los riesgos de la IA.

ISO/IEC 42001

La norma ISO/IEC 42001 define los requisitos para un sistema de gestión de la IA y es certificable. Su estructura sigue la lógica habitual de los sistemas de gestión ISO, lo que puede facilitar la integración para las organizaciones que ya trabajan con normas ISO. Para los equipos de ISO 27001, la superposición es práctica: gestión de riesgos, documentación, auditorías internas y controles relacionados.

Desde la perspectiva de un director de ciberseguridad

En la práctica, no se trata de una decisión de elegir entre la ISO/IEC 42001 y la ISO 27001. Los sistemas de IA a menudo procesan datos sensibles, se conectan a sistemas internos e influyen en las decisiones. La norma ISO 27001 ya cubre parte de ese territorio. La capa específica de la IA añade cuestiones sobre el comportamiento del modelo, los datos del entrenamiento, la transparencia y la supervisión humana. La norma ISO/IEC 42001 proporciona la estructura del sistema de gestión para ello, mientras que la norma ISO/IEC 23894 se ocupa del método de gestión de riesgos.

Componentes clave de la gestión de riesgos de la IA

Un marco proporciona estructura. Lo que importa en las operaciones diarias son los procesos que hay detrás. Independientemente del marco que elija una organización, varios componentes aparecen en todo enfoque eficaz de la gestión de riesgos de la IA.

Supervisión continua

La deriva del modelo rara vez aparece de repente. Los datos cambian, el comportamiento de los usuarios varía y los mercados se mueven. Por lo tanto, un modelo puede empezar a producir resultados de peor calidad aunque siga funcionando sin errores técnicos. La supervisión automatizada con umbrales definidos y rutas claras de notificación de progreso pertenece al modelo operativo, no solo al plan del proyecto.

Documentación y trazabilidad

Una herramienta de IA puede entrar rápidamente en un proceso: una cuenta de prueba, un primer caso de uso, resultados iniciales. Meses después, el departamento de auditoría puede preguntar quién aprobó la herramienta, qué datos se utilizaron y si se revisó el resultado.

Si no hay respuestas claras, esto puede crear un riesgo de cumplimiento de las normativas de la IA. Las pruebas son importantes, especialmente en el contexto de la Ley de IA de la UE. Una buena documentación comienza con el primer caso de uso, no justo antes de una auditoría.

Gobernanza para sistemas autónomos

Los sistemas de IA autónomos pueden hacer algo más que dar respuestas. Algunos pueden mover tickets, redactar emails, iniciar tareas o recuperar datos de otros sistemas. Una decisión débil puede convertirse rápidamente en una cadena de procesos.

Estos sistemas necesitan mecanismos de protección prácticos. ¿Qué puede hacer el agente por su cuenta? ¿Cuándo necesita aprobación? ¿Quién puede ver lo que está sucediendo? ¿Y quién puede intervenir antes de que un error se convierta en varios?

El factor humano

La tecnología y los procesos por sí solos no son suficientes. Los empleados deciden qué herramientas de IA utilizan, qué datos introducen y si cuestionan los resultados. El panel de métricas de gestión del riesgo humano de SoSafe ayuda a las organizaciones a desarrollar un firewall humano y a hacer visible el factor de riesgo humano en la gestión de riesgos de la IA.

¿Qué marco de gestión de riesgos de la IA es el más adecuado?

El marco adecuado depende del contexto. El entorno normativo, la madurez del uso de la IA y las estructuras existentes desempeñan un papel importante. La siguiente tabla es un punto de partida para el debate, no un sustituto de una evaluación individual.

Estos enfoques no son mutuamente excluyentes. Muchas organizaciones utilizan el NIST AI RMF para estructurar los riesgos y la norma ISO/IEC 42001 para crear un sistema de gestión de la IA. La Ley de IA de la UE proporciona el marco legal con el que ambos enfoques pueden alinearse.

La combinación adecuada depende de la organización:

• Madurez de los procesos de gestión de riesgos existentes
• Sistemas de IA actualmente en uso
• Obligaciones normativas pertinentes
• Tiempo, presupuesto y experiencia disponibles para la implementación

Implementación del marco

Las empresas deben empezar la implementación donde ya existan estructuras: gestión de riesgos, seguridad de la información, protección de datos y aprobaciones internas. A partir de ahí, la gestión de riesgos de la IA puede convertirse en parte de los procesos existentes en lugar de un proyecto complementario.

1. Inventario

Comienza con una pregunta sencilla: ¿qué sistemas de IA se utilizan realmente? Los sistemas adquiridos oficialmente son solo una parte de la historia. Las cuentas de prueba, las herramientas basadas en navegador, los proyectos piloto y las soluciones a nivel de departamento también deben incluirse en el inventario.

Aquí es donde a menudo se hace visible la IA en la sombra. Los equipos utilizan la IA porque ahorra tiempo, no porque quieran eludir la gobernanza. Para la gestión de riesgos de la IA, la respuesta debe ser clara: los sistemas desconocidos no pueden evaluarse, aprobarse ni protegerse.

2. Aclarar las clases de riesgo y la normativa

Después del inventario, los sistemas deben clasificarse. ¿Un sistema está contemplado por la Ley de IA de la UE? ¿Es un sistema de alto riesgo? ¿Existen requisitos de la regulación sectorial, de la protección de datos o de las políticas internas?

Estas preguntas determinan cuánta revisión, documentación y control pueden ser necesarios.

3. Seleccionar y adaptar el marco

Ningún marco se adaptará perfectamente desde el principio. El NIST AI RMF ayuda a los equipos a estructurar los riesgos de la IA. La norma ISO/IEC 42001 describe un sistema de gestión de la IA. Las organizaciones que trabajan con la norma ISO 27001 a menudo pueden basarse en roles, procesos y controles que ya existen.

4. Integrar la gobernanza

Un marco de gestión de riesgos de la IA necesita responsabilidades designadas, no solo una responsabilidad general. La aprobación no puede recaer en “la empresa” en abstracto. La revisión de los resultados también necesita un responsable claro. Lo mismo se aplica a la detención de un caso de uso cuando el panorama de riesgos cambia.

Los empleados también necesitan normas y formación que reflejen situaciones laborales reales.

5. Supervisión y mejora continua

El uso de la IA cambia después de la puesta en marcha. Los equipos encuentran atajos, los proveedores lanzan actualizaciones y los datos ya no son exactamente los mismos que durante las pruebas.

Por lo tanto, las revisiones operativas periódicas forman parte de la gestión de riesgos de la IA. En función de lo que muestren, el siguiente paso puede ser un proceso de aprobación más estricto, una comprobación técnica, una orientación más clara o formación adicional.