Gestión de riesgos de IA: cómo identificar, evaluar y tratar los riesgos de tus sistemas

Un riesgo aparece cuando existe incertidumbre sobre algo que puede afectar a nuestros objetivos.

En inteligencia artificial podemos expresarlo de forma sencilla: algo puede ocurrir y provocar una consecuencia que nos importa.

Por ejemplo: un sistema recomienda candidatos para una oferta de empleo. Uno de los riesgos podría ser que determinados perfiles resulten sistemáticamente perjudicados.

El riesgo no es simplemente: “la IA tiene sesgos”. Necesitamos concretarlo mejor.

¿Qué puede ocurrir? ¿Por qué podría ocurrir? ¿A quién podría afectar? ¿Qué consecuencias tendría?

Cuando formulamos el riesgo de esta manera empezamos a poder gestionarlo.

El mismo sistema de IA puede tener riesgos muy distintos dependiendo de cómo se utilice.

Un modelo que clasifica fotografías para organizar un archivo personal no tiene las mismas consecuencias que un sistema que ayuda a decidir:

• quién obtiene un empleo
• quién recibe un crédito
• qué paciente necesita prioridad
• o quién puede acceder a un determinado servicio.

Por eso gestionar riesgos de IA no empieza por una lista genérica. Empieza por entender el sistema: qué hace, para qué se utiliza, quién puede verse afectado, qué datos utiliza, qué decisiones influye y qué ocurriría si falla.

Aquí el inventario de sistemas de IA resulta especialmente útil. También permite detectar usos que podrían requerir una clasificación como sistema de IA de alto riesgo.

En determinados sistemas de alto riesgo, el AI Act hace especialmente relevantes la gestión de riesgos, la supervisión humana y la protección de los derechos fundamentales.

Antes de calcular niveles de riesgo necesitamos saber qué estamos buscando.

Algunas categorías que pueden aparecer son:

• calidad de datos
• sesgo y discriminación
• errores en los resultados
• falta de explicabilidad
• uso indebido
• dependencia de proveedores
• seguridad
• privacidad
• supervisión humana insuficiente
• cambios en el modelo
• pérdida de trazabilidad
• impacto sobre derechos
• incumplimiento normativo.

No todos los sistemas tendrán todos estos riesgos. La identificación debe ser proporcional al contexto.

Una pregunta sencilla puede ayudar: ¿Qué tendría que ocurrir para que este sistema generase un problema real?

La ISO/IEC 23894 puede servir como referencia especializada para estructurar la gestión de riesgos asociados a sistemas de IA, sin sustituir el análisis concreto de cada organización.

Una vez identificado un riesgo podemos empezar a valorarlo. Dos criterios especialmente útiles son:

Probabilidad

¿Qué posibilidades existen de que ocurra?

Podemos utilizar una escala sencilla:

• muy baja
• baja
• media
• alta
• muy alta.

Impacto

Si ocurre, ¿qué gravedad podría tener?

De nuevo podemos utilizar una escala:

• muy bajo
• bajo
• medio
• alto
• muy alto.

Combinar ambos criterios nos permite establecer prioridades. Porque no todos los riesgos requieren la misma respuesta.

Una matriz de riesgos nos ayuda a visualizar la combinación entre probabilidad e impacto.

Por ejemplo: un riesgo con impacto alto y probabilidad alta debería recibir una atención claramente superior a otro con impacto bajo y probabilidad muy baja.

La matriz no sustituye el criterio. Lo organiza.

Su utilidad principal consiste en permitir que diferentes personas dentro de la organización hablen el mismo lenguaje cuando evalúan riesgos.

En esta evaluación de riesgos de IA conviene distinguir dos momentos. El riesgo inherente es el nivel de riesgo antes de aplicar controles. El riesgo residual es el nivel que permanece después de aplicarlos.

El objetivo no siempre es llevar el riesgo a cero, sino comprobar si ese nivel residual se encuentra dentro de los criterios de aceptación definidos por la organización.

Identificar un riesgo no sirve de mucho si después no hacemos nada con él. Aquí aparece el siguiente paso: el control.

Riesgo

¿Qué puede ocurrir?

Control

¿Qué hacemos para reducir la probabilidad o el impacto?

Evidencia

¿Cómo podemos demostrar que ese control existe y funciona?

Por ejemplo:

Riesgo identificado: el sistema puede perjudicar sistemáticamente a determinados perfiles durante la selección.

Valoración inicial: probabilidad media e impacto alto.

Nivel inicial: riesgo alto.

Tratamiento: reducir.

Controles:

• revisión periódica de resultados
• comprobación de posibles diferencias entre grupos
• supervisión humana antes de adoptar una decisión
• registro de las decisiones y excepciones.

Después de aplicar los controles, el riesgo se vuelve a evaluar.

Ejemplo de valoración residual: probabilidad baja e impacto alto.

Riesgo residual: medio.

Decisión: el responsable del riesgo puede aceptar temporalmente ese nivel residual si cumple los criterios definidos por la organización. La justificación y la fecha de revisión deben quedar documentadas.

Los controles también pueden cumplir funciones distintas:

• preventivos, cuando intentan evitar que el riesgo se materialice, como revisar los datos y criterios utilizados antes de poner el sistema en uso
• detectivos, cuando ayudan a identificar un problema, como comprobar periódicamente si existen diferencias entre grupos
• correctivos, cuando permiten responder o reducir las consecuencias, por ejemplo revisando una decisión y corrigiendo el proceso cuando se detecta una desviación.

Conservar evidencias de IA permite demostrar que el control existe y funciona.

No todos los riesgos se gestionan de la misma manera. Estas decisiones forman parte del tratamiento de riesgos. Una organización puede decidir:

Reducirlo

Aplicar controles para disminuir su probabilidad o impacto.

Evitarlo

Cambiar o eliminar la actividad que genera el riesgo.

Transferirlo o compartirlo

Por ejemplo, mediante determinadas obligaciones contractuales o mecanismos con proveedores.

Aceptarlo

Puede haber riesgos que la organización considere asumibles. Pero aceptar un riesgo no significa ignorarlo. Significa tomar una decisión consciente y documentada.

Y esa decisión debería indicar:

• quién la tomó
• sobre qué riesgo
• por qué se considera aceptable
• durante cuánto tiempo
• y cuándo debe revisarse.

Los riesgos de IA rara vez pertenecen únicamente al departamento tecnológico.

Un mismo sistema puede afectar a:

• IT
• Compliance
• Legal
• Recursos Humanos
• Seguridad
• Protección de Datos
• Compras
• Operaciones
• negocio
• dirección.

Por eso la gestión de riesgos funciona mejor cuando combina diferentes perspectivas.

La tecnología puede explicar cómo funciona el sistema. El negocio puede explicar para qué se utiliza. Legal y Compliance pueden analizar obligaciones. Y las personas responsables del proceso pueden explicar qué ocurre realmente cuando el sistema se utiliza.

Ese enfoque transversal forma parte del gobierno de IA.

Además, cada riesgo relevante debería tener un responsable o propietario claramente identificado. No tiene por qué ser el propietario técnico del sistema: es la persona o función encargada de seguir el riesgo, comprobar que se aplican los controles, revisar su evolución y elevar la decisión cuando sea necesario.

La ISO/IEC 42001 ayuda a integrar estas responsabilidades, controles, actividades de seguimiento y evidencias dentro de un sistema de gestión de IA.

Una evaluación realizada una vez no sirve para siempre.

Los sistemas cambian. Los datos cambian. Los proveedores actualizan modelos. Las personas empiezan a utilizar herramientas de formas que inicialmente no estaban previstas. Y también cambia el entorno regulatorio.

Por eso los riesgos deberían revisarse cuando:

• cambia significativamente el sistema
• cambia el uso previsto
• aparecen nuevos datos
• cambia el proveedor
• ocurre una incidencia
• aparece nueva información relevante
• o llega la fecha de revisión prevista.

Gestionar riesgos no consiste únicamente en hacer una matriz. Consiste en mantenerla viva.

La gestión de riesgos necesita dejar rastro.

No porque queramos producir documentación innecesaria. Sino porque dentro de seis meses alguien podría preguntar:

¿Por qué consideramos aceptable este riesgo? ¿Qué controles decidimos aplicar? ¿Quién tomó la decisión? ¿Cuándo debía revisarse?

Si podemos reconstruir esa historia, tenemos trazabilidad. Y la trazabilidad convierte la gestión de riesgos en un proceso de gobierno real.

Qué debería registrar una organización

Un registro de riesgos de IA debería recoger, como mínimo:

• riesgo
• causa
• consecuencia
• probabilidad
• impacto
• nivel de riesgo inicial
• tratamiento
• controles
• responsable o propietario del riesgo
• riesgo residual
• decisión de aceptación, si aplica
• fecha de revisión.

Este registro facilita la trazabilidad, el seguimiento y la rendición de cuentas sin convertir la gestión en documentación innecesaria.

Ninguna organización puede eliminar toda incertidumbre. Tampoco es ese el objetivo.

Gestionar riesgos significa poder responder con criterio a preguntas como:

¿Qué puede ocurrir? ¿Qué impacto tendría? ¿Qué probabilidad existe? ¿Qué hacemos para reducirlo? ¿Quién es responsable? ¿Y cómo sabemos que el riesgo sigue estando bajo control?

Cuando esas respuestas existen y pueden demostrarse, la gestión de riesgos deja de ser una tabla. Se convierte en una forma de tomar mejores decisiones sobre IA.

Empieza por identificar tus sistemas y entender cómo se están utilizando.

El diagnóstico de Céntrika puede ayudarte a obtener una primera visión del nivel de gobierno, riesgo y cumplimiento de IA de tu organización y detectar áreas que necesitan una revisión más profunda.

Realizar diagnóstico →

El diagnóstico ofrece una primera orientación y no sustituye una evaluación específica.