← Volver al listado de tecnologías ← Índice de ISO/IEC 42001 Auditor Interno

Planificación: Riesgos, Oportunidades y Objetivos de IA (Cláusula 6)

Por: Artiko
ISO 42001SGIAauditoría internaIAgestión de riesgos

Planificación: Riesgos, Oportunidades y Objetivos de IA (Cláusula 6)

La cláusula 6 de ISO/IEC 42001 marca el momento en que la organización deja de “entender su contexto” y empieza a decidir qué va a hacer al respecto. Si las cláusulas 4 y 5 respondían a dónde estamos y quién es responsable, la cláusula 6 responde a la pregunta operativa que todo auditor interno buscará evidenciar: ¿cómo se planifica el sistema de gestión de IA para que efectivamente logre lo que promete y no genere daños?

La planificación en un SGIA no es un ejercicio documental. Es la columna vertebral que conecta el análisis del contexto con la operación diaria de los sistemas de IA. Aquí se definen los riesgos que se van a tratar, los objetivos que se van a perseguir y la forma en que los cambios se introducirán sin romper la coherencia del sistema.

Esta cláusula se organiza en tres grandes bloques:

mindmap
  root((Cláusula 6<br/>Planificación))
    6.1 Riesgos y oportunidades
      6.1.1 General
      6.1.2 Evaluación de riesgos de IA
      6.1.3 Tratamiento de riesgos de IA
      6.1.4 Evaluación de impacto
    6.2 Objetivos de IA
      Coherentes con la política
      Medibles
      Monitoreados
      Documentados
    6.3 Planificación de cambios
      Qué cambia
      Por qué
      Quién es responsable
      Cómo se verifica

6.1 Acciones para abordar riesgos y oportunidades

La subcláusula 6.1 introduce el conjunto de acciones que la organización debe planificar para abordar tanto los riesgos como las oportunidades dentro del SGIA. Es la sección más extensa y, probablemente, la más importante desde la óptica de la auditoría interna, porque establece la secuencia lógica que gobierna toda la gestión de riesgos de IA.

Esa secuencia se descompone en cuatro apartados:

ApartadoNombrePropósito
6.1.1GeneralDeterminar riesgos y oportunidades a partir del contexto
6.1.2Evaluación de riesgos de IAIdentificar, analizar, evaluar y priorizar riesgos
6.1.3Tratamiento de riesgos de IASeleccionar controles y elaborar la Declaración de Aplicabilidad
6.1.4Evaluación de impacto del sistema de IAAnalizar consecuencias sobre individuos y sociedad

La función conjunta de estos apartados es establecer un flujo de planificación en cadena: primero se determinan riesgos y oportunidades, luego se evalúan los riesgos de IA, después se definen tratamientos y controles, y finalmente se considera la evaluación de impacto del sistema de IA cuando corresponda.

flowchart LR
    A[6.1.1<br/>Determinar riesgos<br/>y oportunidades] --> B[6.1.2<br/>Evaluar<br/>riesgos de IA]
    B --> C[6.1.3<br/>Tratar riesgos<br/>y definir controles]
    C --> D[6.1.4<br/>Evaluar impacto<br/>del sistema de IA]
    D -.->|retroalimenta| B
    style A fill:#dbeafe,stroke:#2563eb
    style B fill:#dcfce7,stroke:#16a34a
    style C fill:#fef9c3,stroke:#ca8a04
    style D fill:#fce7f3,stroke:#db2777

Ese flujo circular es clave: la evaluación de impacto (6.1.4) no es un callejón sin salida, sino que retroalimenta la evaluación de riesgos. Un impacto sobre personas descubierto tarde se convierte en un riesgo que debe reevaluarse.

6.1.1 General: el punto de partida

La subcláusula 6.1.1 establece la base general para abordar riesgos y oportunidades en el SGIA. Al planificar el sistema de gestión, la organización debe partir de dos insumos que ya conoce de la cláusula 4:

  1. Las cuestiones internas y externas determinadas en 4.1 (por ejemplo, la madurez técnica del equipo, la presión regulatoria del sector o la dependencia de un proveedor de modelos fundacionales).
  2. Los requisitos de las partes interesadas determinados en 4.2 (clientes que exigen explicabilidad, reguladores que exigen trazabilidad, usuarios que exigen no discriminación).

Con esos dos insumos, la organización identifica los riesgos y oportunidades que necesitan abordarse. El propósito de esta planificación es triple:

Un elemento distintivo de ISO/IEC 42001 aparece aquí: la obligación de establecer y mantener criterios de riesgo de IA. Estos criterios son las reglas del juego que permiten diferenciar lo aceptable de lo inaceptable. Sin ellos, cualquier evaluación de riesgo posterior sería arbitraria.

Ejemplo concreto. Una fintech que usa un modelo de scoring crediticio define como criterio de riesgo de IA que “ningún grupo demográfico protegido puede tener una tasa de rechazo superior en más de 5 puntos porcentuales al grupo de referencia”. Ese criterio, cuantitativo y verificable, es lo que permitirá más adelante clasificar un sesgo detectado como riesgo no aceptable que exige tratamiento inmediato.

Los criterios de riesgo de IA sirven para cuatro actividades encadenadas: diferenciar riesgos aceptables de no aceptables, realizar las evaluaciones de riesgo, ejecutar el tratamiento y evaluar los impactos relacionados con IA.

Además, los riesgos y oportunidades deben determinarse considerando:

Finalmente, la organización debe planificar las acciones concretas para abordar esos riesgos y oportunidades, definir cómo se integrarán e implementarán en los procesos del SGIA y evaluar la eficacia de dichas acciones. Toda la información documentada sobre las acciones tomadas debe conservarse.

Ejemplos de evidencia que buscará el auditor interno:

6.1.2 Evaluación de riesgos de IA

La subcláusula 6.1.2 exige que la organización defina y aplique un proceso para evaluar los riesgos asociados a los sistemas de IA dentro del alcance del SGIA. No basta con tener criterios: hay que tener un método repetible.

Ese proceso debe permitir identificar, analizar, evaluar y priorizar los riesgos de IA de manera consistente, utilizando los criterios establecidos en 6.1.1.

flowchart TD
    I[Identificar<br/>¿Qué puede salir mal?] --> A[Analizar<br/>Probabilidad × Consecuencia]
    A --> E[Evaluar<br/>¿Supera el criterio?]
    E --> P[Priorizar<br/>¿Qué tratamos primero?]
    P --> R{¿Requiere<br/>tratamiento?}
    R -->|Sí| T[Pasa a 6.1.3]
    R -->|No| Acp[Riesgo aceptado<br/>y documentado]
    style I fill:#dbeafe,stroke:#2563eb
    style T fill:#fef9c3,stroke:#ca8a04
    style Acp fill:#dcfce7,stroke:#16a34a

La evaluación permite determinar qué riesgos requieren tratamiento y con qué prioridad. Para que sea significativa, debería considerar varios factores propios de los sistemas de IA:

Factor a considerarEjemplo en un sistema de IA
Uso previstoUn chatbot de atención médica no diseñado para diagnosticar
Contexto de aplicaciónDespliegue en un país con legislación estricta de datos
Partes interesadasPacientes, personal clínico, reguladores sanitarios
Datos utilizadosHistoriales clínicos con datos sensibles y posibles sesgos
Condiciones de operaciónAlta latencia, funcionamiento sin conexión, picos de carga
Consecuencias posiblesRecomendación errónea que retrasa una atención urgente

El resultado de la evaluación debe conservarse como información documentada, de modo que la organización pueda demostrar cómo evaluó los riesgos y cómo sustenta las decisiones posteriores de tratamiento. Esta trazabilidad es exactamente lo que un auditor interno rastreará: del riesgo registrado, al control seleccionado, a la evidencia de implementación.

Ejemplos de evidencia:

6.1.3 Tratamiento de riesgos de IA

La subcláusula 6.1.3 establece cómo tratar los riesgos ya evaluados. El tratamiento consiste en seleccionar e implementar opciones para abordar los riesgos, de acuerdo con los criterios definidos y con los resultados de la evaluación.

Un paso central es que la organización debe determinar los controles necesarios para implementar las opciones de tratamiento seleccionadas, y esos controles deben compararse con los controles de referencia del Anexo A. El objetivo de esa comparación no es “copiar” el Anexo A, sino verificar que no se haya omitido ningún control necesario.

De este proceso nace uno de los documentos más emblemáticos de la norma: la Declaración de Aplicabilidad (SoA, Statement of Applicability). La SoA documenta cuatro cosas:

  1. Los controles necesarios.
  2. La justificación de su inclusión.
  3. Su estado de implementación.
  4. La justificación de las exclusiones de controles del Anexo A.
flowchart LR
    RE[Riesgo evaluado<br/>en 6.1.2] --> OP[Seleccionar opción<br/>de tratamiento]
    OP --> CO[Determinar<br/>controles necesarios]
    CO --> AX[Comparar con<br/>Anexo A]
    AX --> SOA[Declaración de<br/>Aplicabilidad SoA]
    SOA --> PL[Plan de tratamiento<br/>de riesgos de IA]
    PL --> AP[Aprobación +<br/>aceptación de<br/>riesgos residuales]
    style SOA fill:#fef9c3,stroke:#ca8a04
    style AP fill:#dcfce7,stroke:#16a34a

Además de la SoA, la organización debe formular un plan de tratamiento de riesgos de IA y obtener la aprobación correspondiente, incluyendo la aceptación de los riesgos residuales cuando aplique. Un riesgo residual es aquel que permanece después de aplicar los controles; alguien con autoridad debe aceptarlo formalmente y por escrito.

Todo el proceso de tratamiento debe conservarse como información documentada.

La norma añade tres notas que amplían el margen de la organización:

Nota 1. Los controles pueden ser diseñados por la organización según sus necesidades o identificados a partir de otras fuentes pertinentes. La organización no está limitada únicamente a los controles del Anexo A.

Nota 2. El Anexo A proporciona una lista de controles de referencia. Su uso ayuda a verificar que no se pasen por alto controles necesarios.

Nota 3. Los controles del Anexo A no son exhaustivos. La organización podría necesitar controles adicionales según su contexto, sus sistemas de IA, sus riesgos y sus impactos.

Ejemplo concreto. Ante el riesgo de sesgo en el modelo de contratación, una empresa selecciona tres controles: (a) auditoría periódica de equidad del modelo — diseñado a medida; (b) supervisión humana obligatoria antes de descartar candidatos — inspirado en A.9; (c) documentación del conjunto de datos de entrenamiento — alineado con A.7. En su SoA justifica la inclusión de los tres y excluye un control del Anexo A relativo a IA generativa porque su sistema no genera contenido, dejando registrada esa justificación.

Ejemplos de evidencia:

6.1.4 Evaluación de impacto del sistema de IA

La subcláusula 6.1.4 introduce un concepto que distingue a ISO/IEC 42001 de otras normas de gestión: la organización debe definir un proceso para evaluar las posibles consecuencias que pueden resultar del desarrollo, provisión o uso de sistemas de IA sobre individuos, grupos de individuos y sociedades.

Mientras la evaluación de riesgos (6.1.2) mira hacia la organización y sus objetivos, la evaluación de impacto mira hacia afuera, hacia las personas afectadas. Esta doble mirada es lo que da a la norma su carácter de gestión responsable de la IA.

La evaluación de impacto debe considerar:

flowchart TD
    S[Sistema de IA] --> UP[Uso previsto]
    S --> UI[Uso indebido<br/>previsible]
    UP --> C{Consecuencias sobre...}
    UI --> C
    C --> IND[Individuos]
    C --> GRU[Grupos de individuos]
    C --> SOC[Sociedades]
    IND --> DOC[Resultado documentado]
    GRU --> DOC
    SOC --> DOC
    DOC --> RG[Se integra en la<br/>evaluación de riesgos 6.1.2]
    style C fill:#fce7f3,stroke:#db2777
    style RG fill:#dcfce7,stroke:#16a34a

El resultado de esta evaluación debe documentarse y, cuando sea apropiado, la organización puede ponerlo a disposición de las partes interesadas relevantes que haya definido. Es más: la organización debe considerar los resultados de la evaluación de impacto dentro de la evaluación de riesgos de IA. Aquí se cierra el círculo que se dibujó al inicio de 6.1. Los controles relacionados con la evaluación de impactos se encuentran en el grupo A.5 del Anexo A.

Nota. En contextos como sistemas de IA críticos para seguridad, privacidad u otros ámbitos especializados, la organización puede requerir evaluaciones de impacto específicas por disciplina —seguridad operacional, privacidad, seguridad de la información— como parte de sus actividades generales de gestión de riesgos.

Ejemplo concreto. Un sistema de reconocimiento facial para control de acceso evalúa su impacto y detecta que, aunque su uso previsto es abrir puertas a empleados, un uso indebido previsible sería rastrear los movimientos internos del personal. El impacto sobre la privacidad de grupos de individuos se documenta y se reintroduce como un nuevo riesgo en 6.1.2, obligando a añadir un control de minimización de datos que no estaba en el plan original.

Ejemplos de evidencia:

6.2 Objetivos de IA y planificación para lograrlos

La cláusula 6.2 establece que la organización debe definir objetivos de IA en las funciones y niveles pertinentes. Estos objetivos traducen la política de IA (definida en la cláusula 5) en metas concretas y verificables. Sin objetivos, la política queda como una declaración de buenas intenciones; con ellos, el SGIA se orienta hacia resultados medibles.

Los objetivos de IA deben cumplir un conjunto de características —fácilmente recordables como una lista de verificación de auditoría:

CaracterísticaQué significa
Coherentes con la política de IANo pueden contradecir los principios declarados
Medibles cuando sea viableCon indicadores cuantificables siempre que se pueda
Consideran requisitos aplicablesLegales, regulatorios y de partes interesadas
MonitoreadosSe les hace seguimiento periódico
ComunicadosLas personas pertinentes los conocen
ActualizadosSe revisan según corresponda
DocumentadosDisponibles como información documentada

Al planificar cómo lograr los objetivos, la organización debe responder cinco preguntas clásicas de la gestión:

flowchart LR
    O[Objetivo de IA] --> Q1[¿Qué se hará?]
    O --> Q2[¿Qué recursos<br/>se requieren?]
    O --> Q3[¿Quién es<br/>responsable?]
    O --> Q4[¿Cuándo se<br/>completará?]
    O --> Q5[¿Cómo se evaluarán<br/>los resultados?]
    style O fill:#dbeafe,stroke:#2563eb

Los objetivos de IA pueden relacionarse con múltiples ámbitos: gestión de riesgos, mejora de controles, uso responsable de sistemas de IA, supervisión humana, calidad de datos, transparencia, seguridad, privacidad, desempeño del SGIA o reducción de impactos no deseados.

Ejemplo concreto. Una empresa de logística fija el objetivo: “Reducir en un 30 % los falsos positivos del sistema de detección de fraude en envíos durante el próximo ciclo, manteniendo la tasa de detección por encima del 95 %.” Es coherente con su política (uso responsable y eficaz), medible (30 % y 95 %), tiene responsable (líder de datos), plazo (un ciclo) y método de evaluación (métricas del modelo revisadas mensualmente).

Nota. El Anexo C proporciona una lista no exhaustiva de objetivos organizacionales relacionados con IA y fuentes de riesgo. Los controles relacionados con la identificación de objetivos para el desarrollo y uso responsable de sistemas de IA se encuentran en A.6.1 y A.9.3, con orientación de implementación en B.6.1 y B.9.3.

Ejemplos de evidencia:

6.3 Planificación de cambios

La cláusula 6.3 cierra la planificación con un principio de disciplina: cuando la organización determine la necesidad de realizar cambios en el SGIA, estos deben llevarse a cabo de manera planificada. Un sistema de gestión de IA es un organismo vivo; los cambios improvisados son la principal fuente de degradación de la coherencia del sistema.

La planificación de cambios busca preservar la integridad del sistema cuando se modifican procesos, responsabilidades, controles, sistemas de IA, proveedores, criterios de riesgo, objetivos o información documentada.

En un SGIA, los cambios pueden originarse por múltiples causas:

flowchart TD
    subgraph Orígenes del cambio
    A[Nuevas necesidades<br/>organizacionales]
    B[Actualización de<br/>sistemas de IA]
    C[Incorporación de<br/>proveedores]
    D[Cambios regulatorios]
    E[Resultados de<br/>auditoría]
    F[No conformidades]
    G[Incidentes]
    H[Revisión por<br/>la dirección]
    I[Nuevas evaluaciones<br/>de riesgo e impacto]
    end
    A & B & C & D & E & F & G & H & I --> PLAN[Cambio planificado]
    style PLAN fill:#dcfce7,stroke:#16a34a

La planificación de cada cambio debe permitir definir:

Ejemplo concreto. Una plataforma de recomendación decide migrar de un modelo propio a un modelo fundacional de un proveedor externo. En lugar de sustituirlo de un día para otro, el cambio se planifica: se documenta la razón (mejor rendimiento), el responsable (arquitecto de IA), los recursos (presupuesto de API y revisión legal del contrato), los efectos previstos (nueva dependencia de un tercero, que se registra como riesgo) y la verificación (pruebas A/B antes del despliegue completo). Así, un cambio potencialmente disruptivo se integra sin romper el SGIA.

Ejemplos de evidencia:

Síntesis del capítulo

La cláusula 6 convierte el entendimiento del contexto en un plan accionable. El bloque 6.1 encadena la determinación de riesgos, su evaluación, su tratamiento con controles y Declaración de Aplicabilidad, y la evaluación de impacto sobre las personas —un ciclo que se retroalimenta. El bloque 6.2 traduce la política en objetivos medibles con responsables y plazos. El bloque 6.3 asegura que ningún cambio erosione la integridad del sistema.

Para el auditor interno, esta cláusula es una mina de evidencias verificables: criterios de riesgo, registros de riesgos, la SoA, los planes de tratamiento, la aceptación de riesgos residuales, los objetivos con sus indicadores y los registros de cambios. Dominar la trazabilidad entre estos artefactos es el corazón de una auditoría de conformidad sólida.

Capítulo 8 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 9: Soporte: Recursos, Competencia, Comunicación e Información Documentada (Cláusula 7)

← Volver al listado de tecnologías ← Índice de ISO/IEC 42001 Auditor Interno