Tratamiento del Riesgo de IA y Declaración de Aplicabilidad (SoA)

Del riesgo evaluado a la acción

En el capítulo anterior aprendimos a identificar, analizar, evaluar y priorizar los riesgos de IA. Pero un riesgo evaluado que no se trata no sirve de nada. El tratamiento del riesgo de IA es el momento en que la organización pasa del diagnóstico a la acción: selecciona e implementa opciones concretas para modificar el riesgo hasta un nivel aceptable, de acuerdo con los criterios que ella misma definió.

La palabra clave es modificar. El tratamiento no siempre significa eliminar el riesgo —eso rara vez es posible—, sino llevarlo a un nivel tolerable de forma justificada y documentada.

Las cinco opciones de tratamiento

ISO/IEC 42001 no obliga a reducir todos los riesgos con controles. Ofrece un abanico de opciones, y elegir la adecuada para cada riesgo es una decisión de gobierno:

flowchart TD
    R[Riesgo de IA<br/>evaluado] --> D{Opción de<br/>tratamiento}
    D --> A[Reducir<br/>mediante controles]
    D --> B[Evitar<br/>la actividad]
    D --> C[Modificar el uso<br/>del sistema de IA]
    D --> E[Transferir<br/>a terceros]
    D --> F[Aceptar el<br/>riesgo residual]
    A --> A1[Implementar controles<br/>del Anexo A u otros]
    B --> B1[No desarrollar o<br/>retirar el sistema]
    C --> C1[Ajustar propósito,<br/>límites o autonomía]
    E --> E1[Acuerdos, contratos,<br/>seguros con terceros]
    F --> F1[Con justificación<br/>y aprobación]

Opción	Cuándo tiene sentido	Ejemplo en IA
Reducir	El riesgo es tratable con controles y la actividad aporta valor	Añadir revisión humana a las decisiones de un modelo de scoring
Evitar	El riesgo supera cualquier beneficio razonable	Descartar un caso de uso de reconocimiento facial por su impacto desproporcionado
Modificar el uso	El riesgo nace del alcance o autonomía del sistema	Limitar un modelo generativo a borradores internos, nunca a comunicaciones externas sin revisión
Transferir	Otra parte está mejor posicionada para gestionar el riesgo	Contratar a un proveedor certificado que asuma responsabilidades específicas
Aceptar	El riesgo residual es tolerable según los criterios	Aceptar un pequeño margen de falsos positivos, con aprobación formal

Modificar el uso del sistema es una opción especialmente propia de la IA: muchas veces el riesgo no está en el modelo, sino en cómo y para qué se usa.

Selección de controles: nunca “porque está en la lista”

La selección de controles debe responder a los riesgos identificados. Este es uno de los principios que más equivocaciones causa. Un control no debe seleccionarse únicamente porque aparece en el Anexo A o en un catálogo de buenas prácticas, sino porque contribuye a tratar un riesgo concreto, cumplir un requisito o fortalecer la eficacia del SGIA.

ISO/IEC 42001 utiliza el Anexo A como referencia de controles, pero la organización puede necesitar controles adicionales según su contexto, sus sistemas de IA y sus impactos. El Anexo A es un punto de partida, no un techo ni una camisa de fuerza.

El orden lógico es este:

flowchart LR
    A[Riesgos e<br/>impactos] --> B[Controles<br/>necesarios]
    B --> C[Comparar con<br/>Anexo A]
    C --> D{¿Falta algún<br/>control necesario?}
    D -->|Sí| E[Añadir control]
    D -->|No| F[Documentar en<br/>la SoA]
    E --> F

Primero se determinan los controles necesarios a partir de los riesgos; después se comparan con el Anexo A para verificar que no se olvidó ninguno; y el resultado se documenta en la Declaración de Aplicabilidad.

Toda decisión de tratamiento debe justificarse

Cada decisión de tratamiento debe estar justificada. La organización debe poder explicar, ante sí misma y ante un auditor:

• Por qué selecciona un control determinado.
• Por qué excluye otro.
• Qué riesgo busca tratar con él.
• Cómo se verificará su implementación o su eficacia.

Esta justificación es lo que mantiene la trazabilidad entre riesgo, tratamiento, control y evidencia. Sin ella, el SGIA se convierte en una colección de documentos inconexos que no resiste una auditoría seria.

El tratamiento no termina en la selección

Un error frecuente es creer que, una vez elegidos los controles, el trabajo está hecho. No es así. El tratamiento continúa:

1. Los controles deben implementarse en procesos reales, no quedarse en el papel.
2. Deben contar con responsables claramente asignados.
3. Deben conservar evidencia de ejecución.
4. La organización debe evaluar si son eficaces, es decir, si producen el efecto esperado sobre el riesgo.

Cuando el tratamiento no es eficaz, debe revisarse. Esto puede implicar modificar controles, actualizar el plan de tratamiento, reevaluar el riesgo o establecer acciones adicionales. Un control implementado que no reduce el riesgo es tan problemático como no tener control alguno.

Tratamiento y objetivos del SGIA

El tratamiento del riesgo no vive aislado: debe conectarse con los objetivos del SGIA. Si la organización definió objetivos relacionados con uso responsable de IA, reducción de impactos, fortalecimiento de controles, transparencia, supervisión humana o cumplimiento, entonces los tratamientos seleccionados deberían contribuir a esos resultados. Un tratamiento que no empuja hacia ningún objetivo declarado es una señal de que algo está desalineado.

La Declaración de Aplicabilidad (SoA)

Llegamos a uno de los documentos más importantes de todo el SGIA. La Declaración de Aplicabilidad, conocida por sus siglas en inglés SoA (Statement of Applicability), documenta las decisiones de control tomadas por la organización.

Su función es cuádruple:

1. Registrar los controles necesarios.
2. Justificar su inclusión.
3. Indicar su estado de implementación.
4. Justificar la exclusión de controles del Anexo A cuando corresponda.

La SoA no es una lista automática

El malentendido más peligroso es tratar la SoA como una lista donde se copian todos los controles del Anexo A y se marcan como “aplicables”. La SoA es una declaración estructurada que conecta tres cosas:

flowchart LR
    A[Evaluación<br/>de riesgos] --> B[Tratamiento<br/>seleccionado]
    B --> C[Controles<br/>aplicables]
    C --> D[(SoA)]
    A --> D
    B --> D
    D -.demuestra.-> E[Decisiones justificadas<br/>según el contexto]

Su valor está en demostrar que la organización revisó los controles de referencia y tomó decisiones justificadas según su contexto. Una SoA copiada de una plantilla, sin relación con los riesgos reales, es papel mojado a los ojos de un auditor.

Inclusiones y exclusiones

La revisión de la SoA debe considerar tanto las inclusiones como las exclusiones, y ambas exigen justificación:

Decisión	Qué debe justificar
Inclusión de un control	Por qué es necesario: relación con el riesgo, con un requisito aplicable, con un objetivo del SGIA o con una decisión interna de gobierno
Exclusión de un control del Anexo A	Por qué no aplica, considerando el alcance del SGIA, el contexto, los sistemas de IA incluidos y los riesgos evaluados

Excluir un control es legítimo —no todos los controles aplican a toda organización—, pero la exclusión debe estar suficientemente justificada. Una exclusión sin fundamento es una no conformidad habitual.

Estado real de implementación

Para que la SoA sea útil debe reflejar el estado real de implementación. Si un control aparece como “implementado”, debe existir evidencia que respalde esa afirmación. Una SoA que declara implementaciones que no existen no solo es inútil: es engañosa, y compromete la credibilidad de todo el sistema.

Implementación no es lo mismo que eficacia

Un matiz que el auditor interno debe tener siempre presente: implementación y eficacia son cosas distintas. Un control puede estar definido, e incluso implementado, y aun así no ser eficaz.

• Implementación: el control existe y opera.
• Eficacia: el control produce realmente el efecto esperado sobre el riesgo.

La eficacia debe evaluarse mediante evidencia, resultados, seguimiento, revisiones, métricas, auditorías o registros operativos. No se presume; se demuestra.

La SoA como columna vertebral de la auditoría

La SoA es uno de los documentos más importantes para la auditoría del SGIA porque permite verificar si existe coherencia entre la evaluación de riesgos, el tratamiento, los controles, la operación y la evidencia disponible. Es, en la práctica, el mapa que el auditor sigue para comprobar que todas las piezas del sistema encajan. Cuando una pieza no cuadra —un control declarado sin evidencia, una exclusión sin justificar, un riesgo alto sin tratamiento— la SoA es donde primero se hace visible.

---

Capítulo 12 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 13: Anexo A: Controles de Referencia y Anexo B: Guía de Implementación