Repaso Ejecutivo: Riesgos, Impacto, SoA y Anexos A/B

Por qué estos cuatro elementos concentran la auditoría

Si la cláusula 6 es el corazón de ISO/IEC 42001, entonces la gestión de riesgos, la evaluación de impacto, la Declaración de Aplicabilidad (SoA) y los controles de los Anexos son las cavidades por donde circula la sangre del SGIA. Un auditor líder dedica a estos cuatro elementos una parte desproporcionada de su tiempo en sitio, porque es donde la conformidad “de papel” y la conformidad “real” más se separan. Este capítulo los repasa de forma ejecutiva, con foco en la trazabilidad que el auditor debe poder reconstruir.

flowchart LR
    R[Gestión de<br/>riesgos de IA] --> I[Evaluación de<br/>impacto]
    I --> T[Tratamiento<br/>del riesgo]
    T --> S[Declaración de<br/>Aplicabilidad SoA]
    S --> A[Anexo A:<br/>controles]
    A --> B[Anexo B:<br/>guía de implementación]

    style S fill:#1e3a5f,color:#fff
    style A fill:#1e3a5f,color:#fff

Gestión de riesgos de IA

La gestión de riesgos de IA permite identificar, analizar, evaluar y priorizar los riesgos de los sistemas de IA dentro del alcance. En IA, los riesgos surgen de fuentes muy específicas: datos insuficientes o no representativos, sesgo, falta de supervisión humana, errores en las salidas, uso indebido previsible, dependencia de proveedores, baja transparencia, fallas de seguridad, incumplimiento regulatorio o impactos adversos sobre individuos y grupos.

Un principio que el auditor debe exigir es la especificidad. No basta con registrar expresiones genéricas como “riesgo de IA” o “riesgo tecnológico”. Un riesgo bien formulado deja claro qué podría ocurrir, bajo qué condiciones, qué consecuencia generaría y qué parte del SGIA o del sistema de IA está involucrada. Compara estas dos formulaciones:

Formulación deficiente	Formulación auditable
”Riesgo de sesgo en el modelo."	"El modelo de scoring crediticio, entrenado con datos históricos de 2015-2020, puede rechazar solicitudes de mujeres jóvenes a una tasa desproporcionada por subrepresentación en los datos, generando discriminación indirecta y riesgo regulatorio.”

Para que la evaluación sea consistente, deben existir criterios de riesgo de IA que permitan distinguir lo aceptable de lo inaceptable, comparar niveles y decidir tratamientos. Estos criterios consideran probabilidad, consecuencia, severidad, criticidad del proceso, afectación a personas, obligaciones legales, capacidad de detección, nivel de supervisión humana y tolerancia al riesgo. Tras aplicar controles puede quedar un riesgo residual, que debe evaluarse contra los criterios: si es aceptable, requiere aprobación formal según las responsabilidades definidas; si no, exige acciones adicionales. Y como los datos, el uso previsto, el contexto, los proveedores y la regulación cambian, la evaluación de riesgos es un proceso que se actualiza, no un ejercicio único.

Qué verifica el auditor líder: que existan criterios de riesgo documentados y aplicados de forma consistente, que los riesgos estén formulados con especificidad, que el riesgo residual cuente con aprobación de quien tiene la autoridad, y que exista evidencia de seguimiento y actualización.

Evaluación de impacto del sistema de IA

Aquí conviene una distinción que el auditor debe tener siempre presente: la evaluación de riesgos se enfoca en la incertidumbre y sus efectos sobre los objetivos de la organización; la evaluación de impacto se orienta a comprender cómo el sistema de IA afecta a individuos, grupos, organizaciones y a la sociedad. Son complementarias, no intercambiables.

La evaluación de impacto debe considerar el uso previsto (el propósito, contexto y condiciones para los que el sistema se diseña) y, de forma crítica, el uso indebido previsible (un uso no previsto pero razonablemente anticipable). Este último punto es donde más fallan las organizaciones: evalúan cómo debería usarse el sistema, pero no cómo podría usarse mal —fuera de contexto, con datos inadecuados, con autonomía no prevista o para fines distintos—.

Las dimensiones que normalmente se analizan son sesgo, equidad, transparencia, privacidad, seguridad, supervisión humana y rendición de cuentas, siempre según el contexto del sistema y las partes afectadas. La supervisión humana merece atención especial: la organización debe demostrar que existen personas con capacidad real de monitorear, revisar, intervenir o escalar cuando el sistema pueda generar consecuencias relevantes, y esa supervisión debe ser proporcional al riesgo, al impacto y al nivel de autonomía.

flowchart TD
    S[Sistema de IA] --> UP[Uso previsto]
    S --> UI[Uso indebido previsible]
    UP --> IND[Impacto en individuos:<br/>privacidad, trato justo, autonomía]
    UP --> GRP[Impacto en grupos:<br/>sesgo, discriminación]
    UI --> ORG[Impacto organizacional:<br/>cumplimiento, reputación]
    UI --> SOC[Impacto social:<br/>derechos, confianza pública]
    IND --> RA[Se integra en la<br/>evaluación de riesgos]
    GRP --> RA
    ORG --> RA
    SOC --> RA

    style UI fill:#5f1e1e,color:#fff
    style RA fill:#1e3a5f,color:#fff

Qué verifica el auditor líder: que la evaluación cubra explícitamente el uso indebido previsible, que las dimensiones analizadas correspondan al contexto real del sistema, que la supervisión humana sea efectiva y no nominal, y que los resultados del impacto se integren en la evaluación de riesgos (los controles asociados están en el grupo A.5 del Anexo A).

Tratamiento del riesgo de IA

El tratamiento consiste en seleccionar e implementar opciones para llevar el riesgo a un nivel aceptable. Las opciones son las clásicas de la gestión de riesgos: reducir mediante controles, evitar la actividad, modificar el uso del sistema, transferir parte del riesgo mediante acuerdos con terceros, o aceptar el riesgo residual cuando esté justificado y aprobado.

El punto que el auditor debe fijar es que un control no se selecciona porque aparezca en una lista, sino porque contribuye a tratar un riesgo, cumplir un requisito o fortalecer la eficacia del SGIA. Cada decisión debe estar justificada: por qué se incluye un control, por qué se excluye otro, qué riesgo trata y cómo se verificará su implementación o eficacia. Esta justificación es la que mantiene la trazabilidad entre riesgo, tratamiento, control y evidencia.

El tratamiento tampoco termina en la selección. Los controles deben implementarse en procesos reales, tener responsables y conservar evidencia de ejecución. Y hay que distinguir siempre implementación de eficacia: un control puede estar implementado y aun así no producir el efecto esperado sobre el riesgo, en cuyo caso debe revisarse, ajustarse o reemplazarse.

Declaración de Aplicabilidad (SoA)

La SoA es probablemente el documento más importante para la auditoría del SGIA, porque conecta en un solo lugar la evaluación de riesgos, el tratamiento seleccionado y los controles aplicables. Documenta cuatro cosas por cada control: si es necesario, la justificación de su inclusión, su estado de implementación y —para los controles del Anexo A que no se aplican— la justificación de la exclusión.

La SoA no es una lista automática. Su valor está en demostrar que la organización revisó los controles de referencia y tomó decisiones justificadas según su contexto. Para que sea útil debe reflejar el estado real: si un control figura como implementado, debe existir evidencia que lo respalde. Y de nuevo, implementación no es eficacia: un control marcado como implementado no demuestra por sí solo que funcione; la eficacia se evalúa con evidencia, resultados, seguimiento, métricas, auditorías o registros operativos.

Qué verifica el auditor líder: la coherencia entre la evaluación de riesgos, el tratamiento, los controles, la operación y la evidencia disponible. La SoA es su mapa de ruta: le indica qué controles debería encontrar operando y le permite detectar rápidamente inconsistencias (controles “implementados” sin evidencia, o exclusiones mal justificadas).

Anexo A — Controles de referencia

El Anexo A funciona de manera análoga al Anexo A de ISO/IEC 27001: no reemplaza la evaluación de riesgos ni la SoA, sino que ofrece una base de controles que la organización compara contra los que ya determinó, para verificar que no omitió ninguno necesario. La secuencia correcta es: primero la organización determina sus controles según riesgos, impactos, contexto y requisitos; luego los contrasta con el Anexo A; y documenta el resultado en la SoA. El Anexo A no es una lista de controles obligatorios para todos, ni es exhaustivo: la organización puede necesitar controles adicionales propios.

El Anexo A se organiza en grupos temáticos que cubren los aspectos clave de la gestión de IA:

Grupo	Tema principal	Enfoque
A.2	Políticas relacionadas con IA	Orientación y mantenimiento de las políticas de IA.
A.3	Organización interna	Roles, responsabilidades, rendición de cuentas y reporte de inquietudes.
A.4	Recursos para sistemas de IA	Recursos, datos, herramientas, infraestructura y competencias necesarias.
A.5	Evaluación de impactos de sistemas de IA	Identificación y documentación de impactos de los sistemas de IA.
A.6	Ciclo de vida del sistema de IA	Objetivos, requisitos, diseño, desarrollo, verificación, validación, despliegue y documentación técnica.
A.7	Datos para sistemas de IA	Gestión, calidad, procedencia, preparación y uso adecuado de los datos.
A.8	Información para partes interesadas	Comunicación de información relevante sobre los sistemas de IA.
A.9	Uso de sistemas de IA	Uso responsable, procesos operativos y supervisión humana.
A.10	Relaciones con terceros y clientes	Responsabilidades, proveedores, clientes y relaciones externas.

Nota: el material de referencia numera los grupos de A.2 a A.10 (nueve grupos temáticos de control). El auditor debe conocer esta estructura de memoria, porque la SoA se organiza siguiéndola y le sirve de índice al recorrer los controles en sitio.

Anexo B — Guía de implementación

El Anexo B acompaña al Anexo A: mientras el A presenta qué controles existen, el B orienta cómo implementarlos, adaptándolos al contexto, riesgos y sistemas de IA de cada organización. Es importante que el auditor no lo trate como una lista adicional de requisitos: es guía, y la organización puede adaptarla, ampliarla o usar otros enfoques si resultan más adecuados. Sus secciones (B.1 a B.10) siguen la misma numeración temática del Anexo A, ofreciendo orientación para políticas, organización interna, recursos, evaluación de impactos, ciclo de vida, datos, información a partes interesadas, uso de IA y relaciones con terceros.

Anexos C y D — Apoyo complementario

Para completar el panorama, conviene recordar dos anexos informativos. El Anexo C ofrece una lista no exhaustiva de objetivos organizacionales relacionados con IA (uso responsable, cumplimiento, transparencia, supervisión humana, equidad, entre otros) y de fuentes de riesgo (datos, diseño, uso indebido previsible, falta de supervisión, dependencia de proveedores, sesgo, vulnerabilidades de seguridad). Sirve para ampliar la mirada más allá del desempeño técnico al evaluar contexto, riesgos e impactos. El Anexo D explica que el SGIA se aplica de forma distinta según el dominio (salud, finanzas, transporte, empleo, energía, defensa) y que puede integrarse con otros sistemas de gestión como ISO/IEC 27001 (seguridad de la información), ISO/IEC 27701 (privacidad) e ISO 9001 (calidad), aprovechando estructuras existentes y evitando duplicidades.

Cierre del repaso

Con los capítulos 2 y 3 hemos refrescado, en clave de auditoría, todo lo que se audita en un SGIA: las cláusulas de requisitos y los mecanismos de riesgo, impacto, tratamiento, SoA y controles. A partir de aquí el curso cambia de eje. Dejamos de hablar de qué se audita para concentrarnos en cómo se audita: los principios que rigen la profesión, la gestión del programa de auditoría y el liderazgo del ciclo completo. Todo ello según la norma de referencia de la auditoría de sistemas de gestión, ISO 19011.

---

Capítulo 3 de la serie ISO/IEC 42001 Lead Auditor — Continúa en el Capítulo 4: Principios de la Auditoría según ISO 19011 (Cláusula 4)