ISO 42001 Annex A: visión general de los controles

El Anexo A de la ISO/IEC 42001:2023 es el catálogo normativo de 38 controles de referencia en 9 dominios de control (A.2 a A.10), del que las organizaciones seleccionan, mediante la Declaración de aplicabilidad (SoA) y con un enfoque basado en riesgos, las medidas que les resultan relevantes. Los controles cubren todo el arco: desde el marco de la política de IA, pasando por roles, recursos, ciclo de vida y gobernanza de datos, hasta el uso responsable y las relaciones con terceros.

El Anexo A funciona igual que el Anexo A de la ISO/IEC 27001 en combinación con la ISO 27002: cada dominio de control tiene un objetivo («To …») y una lista de controles que, juntos, permiten alcanzarlo. La guía de implementación correspondiente está en el Anexo B, de carácter informativo.

Tres respuestas rápidas:

• ¿Cuántos? 9 dominios de control, 38 controles. Los recuentos divergentes (39, 42 controles; 10 dominios) se deben a convenciones de recuento; la cifra canónica es 9/38.
• ¿Obligatorio? No en bloque. La selección se hace con un enfoque basado en riesgos a través de la SoA. Cada control se marca como aplicable o no aplicable, en ambos casos con justificación.
• ¿Por qué importa? El Anexo A es el núcleo operativo en el que la gobernanza de la IA se concreta dentro de la cláusula 8 (Operación). En la auditoría es la base central del muestreo.

Los 9 dominios de control de un vistazo

La siguiente tabla resume todos los dominios de control del Anexo A con su objetivo y una medida de ejemplo típica.

A.2 a A.5: gobierno, organización, recursos e impacto

A.2 (Policies related to AI) abarca la propia política de IA como orientación aprobada por la dirección (A.2.2), su alineación con otras políticas (A.2.3) y su revisión periódica (A.2.4). Para un operador de agentes, la política de IA debería cubrir de forma explícita los niveles de autonomía (solo lectura / recomendar / actuar con aprobación / actuar de forma autónoma), los límites en el uso de herramientas, las reglas de escalado y de human in the loop, la diversidad de proveedores de modelos y los casos de uso prohibidos (por ejemplo, nada de asesoramiento jurídico autónomo).

A.3 (Internal organisation) regula los roles y responsabilidades de IA con segregación de funciones (A.3.2) y un canal para comunicar inquietudes (A.3.3). La ISO 42001 no prescribe un título fijo de «AI Officer»; en las pymes de la región DACH (Alemania, Austria y Suiza), el rol de responsable del AIMS se combina a menudo con el de CISO o el de delegado de protección de datos.

A.4 (Resources for AI systems) exige documentar los recursos (A.4.2), así como los recursos de datos (A.4.3), de herramientas (A.4.4), de sistema y computación (A.4.5) y humanos (A.4.6). Para los deployers de agentes, A.4.2 es el inventario de IA/agentes, con cada agente en producción, su finalidad, su responsable, sus dependencias de modelos, sus fuentes de datos y su clase de riesgo. Es el artefacto más importante para el muestreo de la auditoría.

A.5 (Assessing impacts of AI systems) define el proceso de evaluación de impacto (A.5.2), su documentación (A.5.3), así como la evaluación del impacto sobre individuos y grupos de individuos (A.5.4) y del impacto en la sociedad (A.5.5). Estos cuatro controles son el anclaje operativo de la norma complementaria ISO/IEC 42005:2025. Funcionalmente se solapan con la EIPD del art. 35 del RGPD y con la FRIA del art. 27 del Reglamento de IA de la UE, pero no las sustituyen.

A.6 a A.10: ciclo de vida, datos, información, uso y terceros

A.6 (AI system lifecycle) es el dominio más amplio: va desde los objetivos del ciclo de vida (A.6.1.2), pasando por el diseño responsable (A.6.1.3), la especificación de requisitos (A.6.2.2), la documentación del diseño (A.6.2.3), la verificación y validación (A.6.2.4), el despliegue (A.6.2.5), la operación y la monitorización (A.6.2.6) y la documentación técnica (A.6.2.7), hasta el registro de eventos (A.6.2.8). Este último establece una obligación explícita de registro que discurre funcionalmente en paralelo al art. 12 del Reglamento de IA de la UE (registro de eventos en la IA de alto riesgo). Al mismo tiempo, A.6.2.8 es el control que con más frecuencia se evidencia de forma insuficiente en los despliegues de agentes, porque normalmente solo se registran las llamadas a herramientas y no las entradas del modelo, las trazas de razonamiento ni los eventos de intervención humana.

A.7 (Data for AI systems) ancla la gobernanza de datos: datos para el desarrollo y la mejora (A.7.2), adquisición (A.7.3), calidad (A.7.4), procedencia/origen (A.7.5) y preparación (A.7.6). A.7 es el punto de anclaje de la referencia cruzada a la serie ISO/IEC 5259 y se alinea conceptualmente con el art. 10 del Reglamento de IA de la UE. Importante: aunque solo se utilicen modelos fundacionales de terceros, A.7 sigue siendo aplicable. El dominio abarca los datos de recuperación/RAG, las plantillas de prompts y los conjuntos de datos de evaluación.

A.8 (Information for interested parties) cubre la documentación del sistema y la información para usuarios, como las model cards (A.8.2), los informes externos (A.8.3), la comunicación de incidentes (A.8.4) y la información para las partes interesadas (A.8.5). A.8.2 se corresponde estrechamente con el art. 13 del Reglamento de IA de la UE (transparencia / instrucciones de uso), y A.8.4 con el art. 73 (notificación de incidentes graves) y con las obligaciones del deployer del art. 26.

A.9 (Use of AI systems) abarca los procesos para un uso responsable (A.9.2), los objetivos correspondientes (A.9.3) y el uso previsto (A.9.4). A.9.4 es crítico para los deployers: si un agente se opera fuera del uso previsto declarado por el proveedor, el deployer (en el Reglamento de IA: responsable del despliegue) puede pasar a ser considerado proveedor en virtud del art. 25, apartado 1, del Reglamento de IA, por ejemplo cuando la modificación de la finalidad prevista convierte un sistema que hasta entonces no estaba clasificado como de alto riesgo en un sistema de IA de alto riesgo (letra c). Un caso así debería desencadenar automáticamente una nueva evaluación de impacto según A.5.

A.10 (Third-party & customer relationships) regula el reparto de responsabilidades en la cadena de valor (A.10.2), los proveedores (A.10.3) y los clientes (A.10.4). Para los deployers que se apoyan en modelos fundacionales o plataformas de agentes de terceros, A.10.3 documenta el reparto contractual y operativo de funciones entre proveedor y deployer, incluida la due diligence sobre certificaciones, protección de datos y versionado de modelos.

Cómo se integra el Anexo A en la SoA

El Anexo A no se implementa en bloque, sino que se selecciona a través de la Declaración de aplicabilidad (SoA). La cláusula 6.1.3 exige la SoA, y en la auditoría ISO 42001 es el documento más revisado. Cada control aparece en la SoA con:

1. Referencia y título del control (p. ej., A.6.2.8 Registro de eventos)
2. Decisión de aplicabilidad (aplicable / no aplicable)
3. Justificación (el riesgo tratado o el motivo de exclusión)
4. Estado de implementación (planificado / en curso / implementado / supervisado)
5. Referencia a evidencias (política, procedimiento, registro, sistema)
6. Responsable

El hallazgo de no conformidad más frecuente en la práctica de auditoría de 2024–2026 son las exclusiones sin justificación basada en riesgos (un «n/a» con una frase estándar). También es típico marcar un control como aplicable sin mantener el documento en que se basa (por ejemplo, A.4.2 «applicable» sin un registro real de recursos), así como una SoA estática que no se actualiza cuando se incorporan nuevos agentes o se cambia de modelo.

Ejemplo práctico de implementación: agente de atención al cliente

Una empresa mediana que actúa como deployer (unos 800 empleados) opera un agente de atención al cliente basado en un modelo fundacional de terceros, conectado mediante RAG a la base de conocimiento interna. La lógica de la SoA para los controles críticos:

• A.4.2 aplicable: entrada en el inventario de IA/agentes con la finalidad «soporte de primer nivel», responsable: el jefe de atención al cliente, dependencia de modelos documentada, clase de riesgo «media».
• A.5.2–A.5.5 aplicables: agente de cara al cliente con efectos sobre individuos; AISIA con análisis de derechos fundamentales y de privacidad.
• A.6.2.8 aplicable: registro del prompt y de las instrucciones del sistema, ID y versión del modelo, llamadas a herramientas, consultas de recuperación e ID de documentos, salidas, eventos de intervención humana y de escalado. Conservación: por lo general, el plazo más largo entre 6 meses y el requisito sectorial, con justificación en la SoA.
• Controles de desarrollo de A.6 (p. ej., entrenamiento de modelos): excluibles en parte, ya que no hay desarrollo propio. Justificación: «La organización no desarrolla modelos de IA; todos los modelos son de terceros y están cubiertos por A.10.3.»
• Objetivo medible (cláusula 6.2): «≥ 90 % de precisión en el conjunto de evaluación gold standard, medición en ventana móvil de 30 días, informe mensual.»

Esta selección resiste una auditoría porque cada inclusión y cada exclusión lleva una justificación trazable basada en riesgos, y porque detrás de cada «applicable» hay un artefacto real.

Nota: Este artículo sirve de orientación técnica y no constituye asesoramiento jurídico. Las correspondencias con el RGPD, el Reglamento de IA de la UE y números de artículo concretos (p. ej., art. 12, 13, 25, 35, 73) deberían acordarse con tu departamento jurídico antes de cualquier implementación vinculante.

Para agencias y decisores B2B

Quien opera agentes de IA en producción no necesita una «IA certificada»: la ISO 42001 certifica el sistema de gestión (AIMS/SGIA), no el modelo concreto. El camino más rápido hacia la preparación para la auditoría pasa por tres palancas: un inventario de IA/agentes completo (A.4.2), un registro de eventos fiable para cada agente (A.6.2.8) y una SoA actualizada y justificada con criterios de riesgo. Blck Alpaca ayuda a empresas y agencias de toda Europa a implantar los controles del Anexo A de forma ágil y a prueba de auditorías, integrados con los sistemas ISO 27001/9001 existentes y alineados con las obligaciones solapadas del Reglamento de IA de la UE. Así, el catálogo de controles se convierte en un sistema de gobernanza gestionable y no en una colección de documentos.