Gestión de Riesgos de IA y Evaluación de Impacto en Profundidad

De la teoría del riesgo a la práctica en sistemas de IA

En los capítulos anteriores establecimos que el SGIA se construye sobre un ciclo PHVA y que la planificación (cláusula 6) exige a la organización enfrentarse a sus riesgos y oportunidades. Ahora bajamos al detalle operativo: cómo se hace realmente la gestión de riesgos de IA y por qué la norma introduce, junto a la evaluación de riesgos, un instrumento propio de este dominio: la evaluación de impacto del sistema de IA.

La gestión de riesgos de IA permite a la organización identificar, analizar, evaluar y priorizar los riesgos asociados con los sistemas de IA incluidos en el alcance del SGIA. Su propósito no es producir un documento para archivar, sino determinar qué situaciones pueden afectar los resultados previstos del sistema de gestión o generar efectos no deseados sobre personas, procesos, servicios, productos, partes interesadas u objetivos organizacionales.

La diferencia con la gestión de riesgos tradicional es sutil pero decisiva. En un sistema de información clásico, el riesgo suele medirse contra la confidencialidad, integridad y disponibilidad de los datos. En IA, el catálogo de cosas que pueden salir mal se amplía enormemente: un modelo puede funcionar técnicamente a la perfección y, aun así, discriminar a un grupo, erosionar la privacidad, tomar decisiones inexplicables o depender de un proveedor que mañana cambia sus condiciones.

De dónde surgen los riesgos de IA

Los riesgos de IA rara vez tienen una única fuente. La norma nos invita a mirar el sistema completo —datos, modelo, infraestructura, procesos y personas— y no solo el algoritmo. Las fuentes más habituales son:

Fuente de riesgo	Ejemplo concreto en un sistema real
Datos insuficientes o no representativos	Un modelo de scoring crediticio entrenado solo con clientes urbanos falla sistemáticamente con solicitantes rurales.
Sesgo	Un sistema de selección de personal penaliza currículos con nombres femeninos por aprender de decisiones históricas sesgadas.
Falta de supervisión humana	Un chatbot de soporte médico emite recomendaciones sin que nadie pueda revisarlas antes de llegar al paciente.
Errores en salidas de IA	Un modelo de detección de fraude bloquea transacciones legítimas con una tasa de falsos positivos inaceptable.
Uso indebido previsible	Una herramienta de generación de texto interno se usa para redactar comunicaciones legales sin validación.
Dependencia de proveedores	El modelo base se consume vía API de un tercero que puede modificar el modelo o retirarlo sin previo aviso.
Baja transparencia	Los usuarios afectados por una decisión automatizada no reciben ninguna explicación de por qué fueron rechazados.
Fallas de seguridad	El modelo es vulnerable a ataques de inyección de prompts que exfiltran datos sensibles.
Incumplimiento regulatorio	El sistema procesa datos biométricos sin la base legal exigida por la regulación aplicable.
Impactos adversos sobre individuos o grupos	Una herramienta de vigilancia predictiva concentra la atención policial sobre determinados barrios.

Esta tabla no es un checklist para “marcar casillas”. Es un mapa mental que ayuda al auditor a comprobar si la organización ha mirado más allá de lo técnico.

Formular bien un riesgo

Uno de los errores más frecuentes —y uno de los primeros que un auditor interno debe detectar— es la identificación genérica del riesgo. No basta con registrar expresiones vagas como “riesgo de IA” o “riesgo tecnológico”. Un riesgo así formulado no permite analizarlo, ni priorizarlo, ni tratarlo.

Un riesgo bien formulado debe permitir comprender cuatro cosas:

1. Qué podría ocurrir (el evento).
2. Bajo qué condiciones (la causa o el contexto que lo dispara).
3. Qué consecuencia podría generar (el impacto).
4. Qué parte del SGIA o del sistema de IA estaría involucrada.

Compara estas dos formulaciones del mismo problema:

• ❌ “Riesgo de sesgo en el modelo.”
• ✅ “Si el modelo de aprobación de préstamos se entrena con datos históricos que reflejan prácticas discriminatorias por género (condición), podría rechazar sistemáticamente a solicitantes mujeres solventes (evento), generando daño a personas, incumplimiento regulatorio y daño reputacional (consecuencia), afectando al control de datos A.7 y a la evaluación de impacto A.5 (parte del SGIA).”

La segunda versión es auditable: se puede rastrear hasta la evidencia, los controles y las decisiones de tratamiento.

Criterios de riesgo: la vara de medir

Para que la evaluación sea consistente y no dependa del criterio subjetivo de quien la haga ese día, la organización debe establecer criterios de riesgo de IA. Estos criterios son la vara de medir que permite diferenciar riesgos aceptables de no aceptables, comparar niveles entre sí y decidir su tratamiento.

Los criterios pueden combinar varias dimensiones:

mindmap
  root((Criterios de<br/>riesgo de IA))
    Probabilidad
      Frecuencia esperada
      Historial de incidentes
    Consecuencia
      Severidad del daño
      Alcance de la afectación
    Contexto
      Criticidad del proceso
      Obligaciones legales
    Personas
      Afectación a individuos
      Afectación a grupos
    Controlabilidad
      Capacidad de detección
      Nivel de supervisión humana
    Apetito
      Tolerancia al riesgo definida

Definir estos criterios antes de evaluar es lo que distingue a una organización madura. Si los criterios se inventan después de conocer los resultados, la evaluación pierde objetividad y el auditor tendrá razones fundadas para levantar un hallazgo.

Análisis, evaluación y priorización

Una vez identificados los riesgos con la especificidad adecuada, la organización los analiza y evalúa. Son dos pasos distintos que conviene no confundir:

flowchart LR
    A[Identificación<br/>específica] --> B[Análisis]
    B --> C[Evaluación]
    C --> D[Priorización]
    D --> E{¿Aceptable?}
    E -->|Sí| F[Aceptación con<br/>aprobación]
    E -->|No| G[Tratamiento]
    B -.comprende.-> B1[Causas<br/>Consecuencias<br/>Controles existentes<br/>Nivel de exposición]
    C -.compara con.-> C1[Criterios de<br/>riesgo definidos]

El análisis busca comprender el riesgo por dentro: sus causas, sus consecuencias, los controles que ya existen y el nivel de exposición resultante. La evaluación toma ese resultado y lo compara contra los criterios definidos para decidir si el riesgo es aceptable o si requiere tratamiento.

La priorización enfoca los recursos —siempre limitados— en los riesgos más relevantes. Aquí la norma hace una advertencia crucial para IA: la priorización no debe basarse únicamente en criterios técnicos. Un modelo puede tener un error técnico pequeño y, sin embargo, un impacto social enorme. Por eso la priorización debe considerar también:

• Privacidad de las personas afectadas.
• Seguridad y equidad.
• Transparencia hacia usuarios y reguladores.
• Continuidad operativa del negocio.
• Reputación de la organización.
• Cumplimiento normativo.
• Confianza de las partes interesadas.

El riesgo residual y su aprobación

Después de aplicar controles o acciones de tratamiento, casi siempre queda algo: el riesgo residual. Ningún control elimina el riesgo por completo, y pretender lo contrario es un signo de inmadurez.

Ese riesgo residual debe evaluarse de nuevo frente a los criterios definidos:

• Si es aceptable, debe contar con aprobación según las responsabilidades establecidas por la organización. La aceptación no puede ser silenciosa ni anónima: alguien con autoridad debe firmarla.
• Si no es aceptable, se deben definir acciones adicionales hasta reducirlo a un nivel tolerable.

Para el auditor, la pregunta clave es: ¿quién aprobó este riesgo residual y con qué autoridad? Un riesgo residual aceptado sin una aprobación trazable es una no conformidad frecuente.

El riesgo no es estático

La gestión de riesgos de IA requiere seguimiento continuo. Los riesgos cambian —a veces de un día para otro— cuando se modifican los datos, el uso previsto, el contexto de aplicación, los proveedores, los controles, la regulación o el propio desempeño del modelo. Un modelo que era seguro hace seis meses puede degradarse silenciosamente por data drift, o volverse ilegal si cambia la normativa.

Por eso la evaluación de riesgos no es una actividad única que se hace una vez y se archiva. Es un proceso vivo que se actualiza cuando corresponde: ante cada cambio relevante del sistema, del contexto o de los requisitos aplicables.

Evidencia relevante para el auditor: criterios de riesgo de IA, registro de riesgos, resultados de análisis y evaluación, priorización documentada, decisiones de tratamiento, aceptación de riesgo residual con su aprobación y registros de seguimiento.

La evaluación de impacto del sistema de IA

Aquí la norma introduce algo que la diferencia de otros sistemas de gestión. Junto a la evaluación de riesgos, ISO/IEC 42001 exige una evaluación de impacto del sistema de IA. No son lo mismo, y confundirlas es un error conceptual serio:

	Evaluación de riesgos	Evaluación de impacto
Foco	La incertidumbre y sus efectos sobre los objetivos de la organización	Cómo el sistema de IA afecta a individuos, grupos y sociedad
Perspectiva	Hacia adentro (¿qué me puede pasar?)	Hacia afuera (¿a quién puedo afectar?)
Pregunta central	¿Qué amenaza mis resultados previstos?	¿Qué consecuencias genera este sistema en el mundo?

Ambas se complementan. Un sistema puede tener bajo riesgo para la organización y, aun así, un impacto alto sobre las personas —o viceversa—. La evaluación de impacto obliga a mirar el sistema desde los ojos de quienes lo sufren, no solo de quienes lo operan.

Uso previsto y uso indebido previsible

La evaluación de impacto debe partir del uso previsto del sistema: el propósito, contexto y condiciones para las cuales se diseña, proporciona o utiliza. Cuando un sistema se usa fuera de ese propósito, aparecen impactos que nadie evaluó y controles que resultan insuficientes.

Pero la norma va más allá y exige considerar el uso indebido previsible: un uso no previsto pero razonablemente anticipable. Este punto es especialmente importante en IA, porque un sistema puede utilizarse fuera de contexto, con datos inadecuados, con niveles de autonomía no previstos o para fines distintos a los originales.

Por ejemplo, un modelo de resumen de textos diseñado para notas internas podría acabar usándose para resumir historiales clínicos —un uso indebido previsible que introduce riesgos de privacidad y exactitud que la evaluación original nunca contempló. Anticipar estos desvíos es parte de una evaluación de impacto seria.

Niveles de impacto

La evaluación debe considerar efectos en varios niveles:

flowchart TD
    S[Sistema de IA] --> I[Individuos]
    S --> G[Grupos]
    S --> O[Organización]
    S --> Soc[Sociedad]
    I --> I1[Privacidad · Acceso a servicios<br/>Trato justo · Autonomía<br/>Reputación · Calidad de atención]
    G --> G1[Sesgo · Discriminación<br/>Afectación diferenciada]
    O --> O1[Cumplimiento · Confianza<br/>Continuidad · Seguridad<br/>Responsabilidad frente a terceros]
    Soc --> Soc1[Transparencia · Inclusión<br/>Derechos · Seguridad pública<br/>Confianza en la IA]

Dimensiones a analizar

Entre las dimensiones que normalmente deben analizarse están: sesgo, equidad, transparencia, privacidad, seguridad, supervisión humana y rendición de cuentas. Estas dimensiones no son una lista fija que se aplica igual a todo; deben examinarse según el contexto del sistema y las partes interesadas afectadas. Un modelo de recomendación de contenido y un modelo de diagnóstico médico comparten dimensiones pero las ponderan de forma muy distinta.

La supervisión humana como eje del impacto

La supervisión humana merece una mención especial dentro de la evaluación de impacto. La organización debe preguntarse si existen personas con capacidad real —no solo nominal— para monitorear, revisar, intervenir o escalar situaciones cuando el sistema pueda generar consecuencias relevantes.

La clave está en la palabra “real”. Un humano que aprueba automáticamente todo lo que el modelo propone, sin tiempo ni información para revisarlo, no es supervisión: es una firma. La supervisión debe ser proporcional al riesgo, al impacto y al nivel de autonomía del sistema. Cuanto más autónomo y de mayor impacto, más robusta debe ser la capacidad humana de intervenir.

Documentar el impacto

Finalmente, la evaluación de impacto debe generar información documentada suficiente para demostrar cómo se analizaron los impactos y qué acciones se definieron. Esta información se vincula con la evaluación de riesgos de IA y con los controles seleccionados para tratar riesgos o reducir impactos adversos. La trazabilidad entre impacto, riesgo, control y evidencia es lo que un auditor buscará seguir de punta a punta.

---

Capítulo 11 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 12: Tratamiento del Riesgo de IA y Declaración de Aplicabilidad (SoA)