Anexo A: Controles de Referencia y Anexo B: Guía de Implementación
Dos anexos que trabajan juntos
En los capítulos anteriores vimos que el tratamiento del riesgo se apoya en controles y que la Declaración de Aplicabilidad documenta cuáles se aplican. Ahora toca conocer el catálogo del que salen esos controles —el Anexo A— y la guía que explica cómo ponerlos en marcha —el Anexo B—.
Es fundamental entender la relación entre ambos desde el principio:
flowchart LR
A[Anexo A<br/>Controles de referencia] -.QUÉ.-> C[Control seleccionado]
B[Anexo B<br/>Guía de implementación] -.CÓMO.-> C
C --> D[(SoA)]El Anexo A responde al qué (qué controles existen como referencia) y el Anexo B responde al cómo (cómo implementarlos en la práctica). Uno es el catálogo; el otro es el manual de instrucciones.
El Anexo A: controles de referencia
El Anexo A de ISO/IEC 42001 presenta un conjunto de controles de referencia para apoyar el tratamiento de riesgos de IA dentro del SGIA. Su función es análoga a la del Anexo A de ISO/IEC 27001: no reemplaza la evaluación de riesgos ni la Declaración de Aplicabilidad, sino que proporciona una base de controles que la organización debe revisar al definir su tratamiento de riesgos.
Quien venga del mundo de la seguridad de la información reconocerá el patrón de inmediato. La lógica es la misma: los riesgos determinan los controles, y el Anexo A sirve de red de seguridad para no olvidar ninguno.
El flujo correcto de uso
La norma es explícita en el orden en que debe usarse el Anexo A, y equivocarse en este orden es un error conceptual grave:
flowchart TD
A[1. Determinar controles<br/>necesarios según riesgos,<br/>impactos, contexto,<br/>sistemas y requisitos] --> B[2. Comparar con<br/>el Anexo A]
B --> C{3. ¿Se omitió algún<br/>control necesario?}
C -->|Sí| D[Incorporar el control]
C -->|No| E[4. Documentar el<br/>resultado en la SoA]
D --> EEn ISO/IEC 42001, la organización primero determina los controles necesarios según sus riesgos, impactos, contexto, sistemas de IA y requisitos aplicables. Después compara esos controles con el Anexo A para verificar que no se haya omitido nada relevante. El resultado de esa revisión se documenta en la Declaración de Aplicabilidad.
El Anexo A no es una lista automática de controles obligatorios para todas las organizaciones. Su aplicación depende del alcance del SGIA, de los sistemas de IA incluidos, de los riesgos evaluados y de la justificación de aplicabilidad. Aplicar los controles a ciegas, sin conectarlos con riesgos reales, contradice el espíritu de la norma.
Estructura del Anexo A: nueve grupos de controles
El Anexo A está organizado en grupos de controles que cubren los aspectos clave de la gestión de IA. Estos grupos apoyan la implementación del SGIA y permiten tratar riesgos relacionados con gobierno, recursos, ciclo de vida, datos, comunicación, uso de IA y relaciones con terceros.
La numeración empieza en A.2 (la sección A.1 corresponde a las generalidades del anexo) y llega hasta A.10:
| Grupo | Tema principal | Enfoque |
|---|---|---|
| A.2 | Políticas relacionadas con IA | Define controles asociados con la orientación y el mantenimiento de las políticas de IA. |
| A.3 | Organización interna | Aborda roles, responsabilidades, rendición de cuentas y el reporte de inquietudes. |
| A.4 | Recursos para sistemas de IA | Considera recursos, datos, herramientas, infraestructura y competencias necesarias. |
| A.5 | Evaluación de impactos de sistemas de IA | Apoya la identificación y documentación de impactos relacionados con sistemas de IA. |
| A.6 | Ciclo de vida del sistema de IA | Cubre objetivos, requisitos, diseño, desarrollo, verificación, validación, despliegue y documentación técnica. |
| A.7 | Datos para sistemas de IA | Trata la gestión de datos: calidad, procedencia, preparación y uso adecuado de los datos. |
| A.8 | Información para partes interesadas | Aborda la comunicación de información relevante sobre los sistemas de IA. |
| A.9 | Uso de sistemas de IA | Considera el uso responsable, los procesos operativos y la supervisión humana. |
| A.10 | Relaciones con terceros y clientes | Trata responsabilidades, proveedores, clientes y relaciones externas vinculadas con los sistemas de IA. |
Cómo leer estos grupos: una visión de conjunto
Vistos en su conjunto, los nueve grupos no son una lista arbitraria: reproducen el ciclo de vida completo de un sistema de IA responsable, desde el gobierno hasta la relación con el exterior.
mindmap
root((Anexo A<br/>9 grupos))
Gobierno
A.2 Políticas
A.3 Organización interna
Recursos y evaluación
A.4 Recursos
A.5 Impactos
Construcción
A.6 Ciclo de vida
A.7 Datos
Uso y comunicación
A.8 Información a partes interesadas
A.9 Uso responsable
Exterior
A.10 Terceros y clientesAnalicemos cada grupo con la mirada de un auditor interno: qué busca cada uno y qué evidencia esperaría encontrar.
A.2 — Políticas relacionadas con IA
Este grupo es el punto de partida del gobierno. Sin una política de IA aprobada, comunicada y mantenida, el resto del sistema carece de dirección. La política traduce los valores y el propósito de la organización en principios operativos sobre cómo se desarrolla, provee o usa la IA. Un auditor buscará que la política exista formalmente, esté aprobada por la dirección, se haya comunicado y se revise periódicamente.
A.3 — Organización interna
De poco sirve una política si nadie es responsable de aplicarla. Este grupo aborda la asignación de roles, responsabilidades, rendición de cuentas y los mecanismos internos para reportar inquietudes. Un vacío de responsabilidad —“todos y nadie son responsables del modelo”— es una de las debilidades más comunes. También cubre la existencia de canales para que las personas planteen preocupaciones sobre el uso de IA sin temor a represalias.
A.4 — Recursos para sistemas de IA
La IA responsable requiere recursos, y no solo económicos. Este grupo considera los recursos humanos (personas con competencias adecuadas), los datos, las herramientas, la infraestructura, los recursos computacionales y las capacidades especializadas. Un sistema de IA gestionado sin las competencias necesarias es un riesgo latente: nadie entiende del todo lo que se está operando.
A.5 — Evaluación de impactos de sistemas de IA
Este grupo conecta directamente con la evaluación de impacto que estudiamos en el capítulo 11. Los controles apoyan la identificación, documentación y análisis de los impactos que un sistema de IA puede tener sobre individuos, grupos o la sociedad. Es un grupo distintivo de ISO/IEC 42001, que no encuentra equivalente directo en normas anteriores.
A.6 — Ciclo de vida del sistema de IA
Aquí reside gran parte del contenido técnico del anexo. Cubre todo el recorrido del sistema: objetivos, requisitos, diseño, desarrollo, verificación, validación, despliegue y documentación técnica. El principio de fondo es el desarrollo responsable: la responsabilidad no se añade al final, sino que se integra en cada fase. Un auditor buscará evidencia de verificación y validación antes del despliegue, y de documentación técnica que permita entender y mantener el sistema.
A.7 — Datos para sistemas de IA
Los datos son el combustible de la IA, y también una de sus mayores fuentes de riesgo. Este grupo trata la adquisición, calidad, procedencia, preparación y uso adecuado de los datos. La calidad y la gestión de los datos afectan directamente al desempeño, al sesgo, a la fiabilidad y a los riesgos del sistema. La trazabilidad de los datos —saber de dónde vienen y cómo se prepararon— es evidencia crítica.
A.8 — Información para partes interesadas
La transparencia se materializa aquí. Este grupo aborda qué información debe ponerse a disposición de las partes interesadas: documentación para usuarios, condiciones de uso, limitaciones del sistema, reportes externos y comunicación de incidentes. Un sistema opaco, del que los usuarios no reciben ninguna explicación, incumple el espíritu de este grupo.
A.9 — Uso de sistemas de IA
Este grupo se enfoca en el uso responsable durante la operación: que el sistema se utilice conforme a su uso previsto, dentro de sus límites y con los mecanismos de supervisión humana adecuados. Conecta con los conceptos de uso previsto y uso indebido previsible que vimos en la gestión de riesgos.
A.10 — Relaciones con terceros y clientes
Casi ningún sistema de IA se construye y opera en solitario. Este grupo trata las responsabilidades, requisitos e información compartida cuando proveedores, terceros o clientes participan en el ciclo de vida o en el uso del sistema. La dependencia de un proveedor de modelos, por ejemplo, introduce riesgos que este grupo ayuda a gobernar mediante acuerdos y expectativas claras.
El Anexo B: guía de implementación
Conocer los controles no basta; hay que saber implementarlos. Para eso existe el Anexo B, que proporciona orientación sobre cómo aplicar los controles del Anexo A, adaptándolos al contexto, los riesgos, los objetivos y los sistemas de IA de cada organización.
La distinción es esencial y conviene repetirla:
| Anexo A | Anexo B | |
|---|---|---|
| Naturaleza | Controles de referencia | Guía de implementación |
| Responde a | El qué | El cómo |
| Cómo tratarlo | Base a revisar frente a los riesgos | Apoyo, no lista adicional de requisitos |
El error a evitar es tratar el Anexo B como si fuera una lista adicional de requisitos que hay que cumplir. No lo es. Es una guía, un apoyo para aplicar los controles de manera adecuada. La organización puede seguirla, adaptarla, ampliarla o incluso usar otros enfoques si resultan más apropiados para tratar sus riesgos.
La correspondencia B ↔ A
El Anexo B sigue la misma estructura numérica que el Anexo A, de modo que cada sección de guía se corresponde con su grupo de controles:
flowchart LR
subgraph AnexoA["Anexo A · QUÉ"]
A2[A.2 Políticas]
A3[A.3 Organización]
A4[A.4 Recursos]
A5[A.5 Impactos]
A6[A.6 Ciclo de vida]
A7[A.7 Datos]
end
subgraph AnexoB["Anexo B · CÓMO"]
B2[B.2 Políticas]
B3[B.3 Organización]
B4[B.4 Recursos]
B5[B.5 Impactos]
B6[B.6 Ciclo de vida]
B7[B.7 Datos]
end
A2 --- B2
A3 --- B3
A4 --- B4
A5 --- B5
A6 --- B6
A7 --- B7Recorramos las secciones del Anexo B para ver qué orientación aporta cada una.
B.1 — Generalidades
La sección B.1 explica el propósito del Anexo B. La organización puede usar esta guía para implementar los controles del Anexo A, pero también puede adaptarla, ampliarla o utilizar otros enfoques si resultan más adecuados para tratar sus riesgos de IA. El Anexo B no encierra a la organización en una única forma de implementar controles: reconoce que cada contexto es distinto.
B.2 — Políticas relacionadas con IA
Orienta la implementación de los controles asociados con la política de IA. Ayuda a definir cómo documentar, comunicar, revisar y alinear la política con el propósito, el contexto, los riesgos, los valores y los requisitos aplicables de la organización. Responde, en la práctica, a preguntas como: ¿cada cuánto se revisa la política?, ¿cómo se asegura que todos la conocen?
B.3 — Organización interna
Guía la asignación de roles, responsabilidades y mecanismos internos de reporte relacionados con IA. Su propósito es fortalecer la gobernanza del SGIA y evitar vacíos de responsabilidad. Orienta sobre cómo estructurar quién decide, quién ejecuta y quién rinde cuentas.
B.4 — Recursos para sistemas de IA
Orienta la identificación y gestión de los recursos necesarios: recursos humanos, datos, herramientas, infraestructura, recursos computacionales y capacidades especializadas. Ayuda a que la organización planifique los recursos de forma deliberada, y no reactiva.
B.5 — Evaluación de impactos de sistemas de IA
Proporciona guía para implementar los controles relacionados con la evaluación de impacto del sistema de IA. Apoya la identificación, documentación y análisis de impactos sobre individuos, grupos o la sociedad. Es la contraparte práctica de la teoría de evaluación de impacto vista en el capítulo 11.
B.6 — Ciclo de vida del sistema de IA
Orienta los controles asociados con el ciclo de vida, desde el diseño y desarrollo hasta el despliegue, operación, monitoreo, mantenimiento o retiro. Incluye aspectos como objetivos de desarrollo responsable, verificación, validación, documentación técnica, registros y criterios de operación. Es una de las secciones más densas, por la amplitud del ciclo que cubre.
B.7 — Datos para sistemas de IA
Se enfoca en la gestión de datos: adquisición, calidad, procedencia, preparación, uso y trazabilidad. Es una sección especialmente relevante porque la calidad y la gestión de los datos pueden afectar el desempeño, el sesgo, la fiabilidad y los riesgos del sistema. Buena parte de los problemas de un modelo se rastrean, al final, hasta sus datos.
B.8 — Información para partes interesadas de sistemas de IA
Guía qué información debe ponerse a disposición de las partes interesadas pertinentes: información para usuarios, documentación del sistema, condiciones de uso, limitaciones, reportes externos y comunicación de incidentes. Ayuda a materializar la transparencia de forma concreta.
B.9 — Uso de sistemas de IA
Orienta los controles para el uso responsable. Ayuda a asegurar que el sistema se utilice conforme a su uso previsto, sus objetivos, sus límites, sus instrucciones y sus mecanismos de supervisión. Conecta el diseño con la operación real del día a día.
B.10 — Relaciones con terceros y clientes
Guía la gestión de relaciones con proveedores, terceros y clientes. Su propósito es definir responsabilidades, requisitos, información compartida, controles y expectativas cuando otras partes participan en el ciclo de vida o en el uso del sistema. Orienta cómo trasladar las exigencias del SGIA a los acuerdos con terceros.
Cómo usar ambos anexos en la práctica
Para cerrar, unamos las piezas en una secuencia práctica que un auditor esperaría ver funcionando:
flowchart TD
R[Riesgos e impactos<br/>identificados] --> N[Determinar controles<br/>necesarios]
N --> RA[Revisar frente<br/>al Anexo A]
RA --> S[Registrar decisiones<br/>en la SoA]
S --> IB[Implementar usando<br/>la guía del Anexo B]
IB --> AD[Adaptar la guía<br/>al contexto propio]
AD --> E[Conservar evidencia<br/>de implementación]
E --> EF[Evaluar eficacia]La secuencia deja clara la división de tareas: el Anexo A garantiza que no se olvide ningún control relevante, la SoA documenta y justifica las decisiones, y el Anexo B guía la implementación —siempre adaptada al contexto— hasta llegar a la evidencia y a la evaluación de eficacia.
Para el auditor interno, dominar esta relación es indispensable. Muchos hallazgos nacen precisamente de la confusión entre estos elementos: organizaciones que copian el Anexo A completo como si fuera obligatorio, que tratan el Anexo B como una lista de requisitos, o que implementan controles sin conectarlos con ningún riesgo. Comprender que el riesgo manda, el Anexo A recuerda, la SoA justifica y el Anexo B guía es la clave para auditar esta parte de la norma con criterio.
Capítulo 13 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 14: Evaluación del Desempeño, Mejora y Preparación para el Examen I42001IA