El anexo A de ISO/IEC 42001 es el catálogo de controles de referencia del sistema de gestión de IA: nueve objetivos de control, numerados de A.2 a A.10, con 38 controles en total. El mecanismo le va a sonar a cualquiera que haya certificado ISO/IEC 27001: se recorre el catálogo control a control, se decide qué se aplica a partir del análisis de riesgos y el resultado se firma en una declaración de aplicabilidad que el auditor usará como índice de la carpeta. Lo que cambia es el objeto: no un activo de información que está quieto, sino un sistema que se reentrena, cambia de versión sin avisar y afecta a personas que no son clientes de la empresa.
Lo que se hereda de ISO 27001 y lo que no
Se hereda el método entero. El anexo no es una lista de la compra: es una referencia contra la que se contrasta lo que la organización ya hace, y aplicar o no un control tiene que poder rastrearse hasta una evaluación previa. Se hereda la declaración de aplicabilidad como pieza documental y se hereda la mecánica de auditoría: el auditor entra por el riesgo, salta al control y pide la evidencia de que funciona. Si la cadena está rota en un punto, da igual cómo esté redactada la política.
Cambia la aritmética, y conviene decirlo porque se cuela en muchos cuadros resumen: la numeración arranca en A.2 y termina en A.10, así que son nueve bloques, no diez. Y son objetivos de control, no epígrafes temáticos: la decisión se justifica contra el objetivo. Cambia también el fondo. En seguridad de la información el riesgo se mide sobre la organización y sus activos; aquí hay un bloque entero —A.5— dedicado a los impactos sobre personas, grupos y sociedad, que pueden ser ajenos a la organización y no figurar en ningún registro de activos.
Y en IA la aplicabilidad caduca: un control excluido con razón porque el sistema no tomaba decisiones automáticas deja de estar bien excluido el día que alguien activa una funcionalidad nueva en la herramienta de siempre. Las dos mitades del sistema —este anexo y las cláusulas 4 a 10 de ISO 42001— se sostienen justo ahí. El recorrido completo está en la guía completa de ISO 42001.
Los nueve bloques: qué cubre cada uno y qué deja por escrito
Una advertencia: aquí no vas a encontrar cuántos controles tiene cada bloque. Las fuentes públicas que publican ese reparto no coinciden entre sí, el texto de la norma está tras un muro de pago y dar una cifra sin cotejarla contra el original sería inventarla. El total, 38, sí está contrastado en fuentes independientes. Tampoco transcribimos los controles uno a uno: la norma se compra, y quien la implanta necesita el documento en la mesa.
A.2 · Políticas relativas a la IA
La primera decisión es cuántas políticas hacen falta: una declaración general se queda corta en cuanto conviven el uso de herramientas de IA por parte de la plantilla y el desarrollo o la integración de sistemas propios. Deja una política aprobada con fecha, la firma de quien la aprueba y constancia de que ha llegado a quien aplica. Cuando está mal cubierto se nota: la política reproduce el índice de la norma y su fecha de aprobación es anterior al inventario de sistemas. Escrita antes de saber qué sistemas tienes, es una declaración de intenciones.
A.3 · Organización interna
Roles, responsabilidades y a quién se rinde cuentas. La decisión lleva nombres: quién responde de cada sistema, quién aprueba que pase a producción y quién puede pararlo sin pedir permiso —esta última es la que más veces falta—. Deja una matriz de responsabilidades por sistema, las actas del órgano que decide y las delegaciones escritas. Señal de bloque flojo: a «¿quién es el propietario de este sistema?» se contesta con un departamento, no con una persona, o la misma firma aparece en el diseño y en la aprobación.
A.4 · Recursos para los sistemas de IA
El bloque que más sorprende a quien viene de calidad; tiene apartado propio abajo. «Recursos» aquí no son solo las personas y los equipos: son los datos, los modelos, la capacidad de cómputo y las herramientas con las que se construye y ejecuta cada sistema. La decisión es documentar qué usa cada sistema, en qué versión y de dónde viene. Está mal cubierto cuando hay una lista de aplicaciones que no dice qué modelo tiene detrás cada una ni dónde se ejecuta el cómputo; sin esa trazabilidad no se sostiene nada de lo que declaren A.6 y A.7.
A.5 · Evaluación de impactos de los sistemas de IA
Los efectos del sistema sobre personas, grupos y sociedad, que no son los riesgos para la organización. La decisión de fondo es el disparador: cuándo hay que evaluar el impacto —sistema nuevo, cambio de finalidad, colectivo afectado nuevo, cambio de modelo— y quién revisa el resultado. Deja la evaluación fechada, con su alcance y con la decisión que salió de ella, incluida la de no hacer nada. ISO/IEC 42005 ordena ese trabajo y el procedimiento está en la evaluación de impacto con ISO 42005 paso a paso. Es además el punto de encaje con la evaluación de impacto en los derechos fundamentales del AI Act, materia legal que cubre el servicio de cumplimiento del AI Act de Summum Consultoría.
A.6 · Ciclo de vida del sistema de IA
Desde el objetivo de diseño hasta la retirada, pasando por verificación, validación, puesta en servicio, operación y cambios. La decisión es dónde se ponen las puertas: en qué momentos alguien aprueba por escrito para que el sistema avance. Deja registros de diseño, resultados de pruebas contra criterios fijados antes de hacerlas, aprobación de la puesta en servicio, historial de cambios y constancia de las bajas. El error clásico no es no tener procedimiento: es tener uno escrito para desarrollo propio cuando todo se compra o se consume como servicio.
A.7 · Datos para los sistemas de IA
Origen, calidad, preparación y trazabilidad de los datos que entran y salen. La decisión es qué conjunto de datos se acepta como bueno para qué uso, con qué criterio y quién lo dice. La evidencia útil es una ficha por conjunto: procedencia, base para usarlo, tratamiento aplicado, criterios de calidad y última revisión. La alarma salta cuando esa ficha no existe y la sustituye la confianza en que «el proveedor ya lo tiene mirado»: si el modelo es de un tercero y no puedes documentar sus datos de entrenamiento, el control no desaparece, se convierte en cláusula de contrato.
A.8 · Información para las partes interesadas
Qué se cuenta, a quién y en qué forma: lo que se entrega a quien usa el sistema, lo que se avisa a quien resulta afectado y el canal por el que cualquiera de los dos puede reclamar. Deja la información tal como se entregó —no un borrador—, el registro de a quién se comunicó y cuándo, y el histórico de consultas con su respuesta. Es el bloque que más se descuida en sistemas internos: el empleado cuyo trabajo se reorganiza según una recomendación automática es una parte interesada, y el auditor lo tratará como tal.
A.9 · Uso de los sistemas de IA
La organización como usuaria, el papel real de la mayoría de las empresas españolas: usos autorizados, usos prohibidos, condiciones para usar una salida sin revisión humana y seguimiento de que eso se cumple. Deja reglas de uso publicadas con acuse, autorizaciones registradas, evidencia de que alguien comprueba si se respetan e incidencias tratadas. Y aquí aparece el asunto que nadie quiere sacar en la reunión de apertura: las herramientas que la plantilla ya usa sin constar en ningún inventario, sobre las que unas reglas impecables no demuestran nada.
A.10 · Relaciones con terceros y clientes
Las dos direcciones de la cadena: lo que se exige a quien te suministra IA y lo que se debe a quien recibe un servicio tuyo que la lleva dentro. Deja un registro de terceros con lo que aporta cada uno, las cláusulas que lo respaldan y constancia de los cambios notificados. Tiene apartado propio al final, porque en la práctica sostiene a los demás.
La declaración de aplicabilidad: cómo se sostiene una exclusión
La declaración de aplicabilidad es la tabla que recorre los 38 controles y dice, de cada uno, si aplica, por qué y dónde está la evidencia. Su valor no está en la columna del sí o el no: está en la del porqué, y esa columna solo aguanta si el motivo remite a algo que existe fuera del documento —el alcance, un resultado del análisis de riesgos, una evaluación de impacto concreta—. Qué vale como prueba de cada control es otra conversación, resuelta en las evidencias que pide el auditor de ISO 42001.
La diferencia con una declaración de seguridad de la información es que aquí el argumento tiene fecha de caducidad. Por eso el documento necesita versión, fecha y un disparador de revisión enganchado al inventario: si cambia el inventario, se revisa la declaración. Sin ese enganche envejece sin que nadie lo note; lo nota el auditor.
| Situación real | Justificación que no aguanta | Cómo se sostiene |
|---|---|---|
| No se desarrolla IA: se compra y se usa | «No aplica: no desarrollamos IA» | Aplica con otro contenido: criterios de selección, validación antes de usar, seguimiento del proveedor |
| Los datos de entrenamiento del modelo son del proveedor | «No aplica: no son nuestros datos» | Aplica y pasa al contrato: qué declara el proveedor y qué se hace si no contesta |
| El sistema es interno y no afecta a personas | «No aplica: es de uso interno» | Aplica salvo que lo descarte la evaluación de impacto, que se cita con su fecha |
| El sistema está en piloto, sin usuarios | «Pendiente: está en pruebas» | «Pendiente» no es decisión: aplicable con plazo y responsable, o fuera del alcance |
| El control lo cubre un procedimiento de ISO 9001 o de ISO/IEC 27001 | Aplicable, y la celda de evidencia en blanco | Se cita ese procedimiento por su código y se comprueba que menciona los sistemas de IA |
Queda el error que más caro sale, y es el que parece prudente: marcar los 38 controles como aplicables para no argumentar ninguna exclusión. Cada «aplicable» es una promesa de evidencia, y treinta y ocho promesas sin cumplir generan más hallazgos que unas pocas exclusiones bien razonadas. Además desdibuja el sistema: cuando todo aplica, nada señala dónde está el riesgo. Una declaración con exclusiones justificadas demuestra que hubo análisis; una sin ninguna, que se copió el índice.
Ese criterio de proporción ya no es solo doctrina de consultoría. El Reglamento (UE) 2026/1744, el Ómnibus digital sobre IA, en vigor desde el 27 de julio de 2026, lo ha escrito en el artículo 17, apartado 2, del AI Act, sobre el sistema de gestión de la calidad de los proveedores de alto riesgo: «La aplicación de los aspectos mencionados en el apartado 1 será proporcional al tamaño de la organización del proveedor, en particular si el proveedor es una pyme […]». Es texto legal, no requisito de ISO 42001, pero fija un criterio que a un auditor le cuesta ignorar.
Un detalle documental que afecta a toda declaración firmada en España: la referencia española cambió el 8 de abril de 2026, cuando UNE-EN ISO/IEC 42001:2026 sustituyó a la UNE-ISO/IEC 42001:2025, anulada ese mismo día. El contenido es idéntico y no hay que rehacer nada, pero la declaración cita la norma por su código y toca actualizarla; lo cuenta la pieza sobre el cambio de la referencia española.
Los anexos B, C y D: informativos, y aun así los más usados
El anexo A es la referencia normativa contra la que se declara la aplicabilidad. Los otros tres son informativos, no se auditan como requisito y por eso mucha gente ni los abre. Error de cálculo: son los que resuelven las dudas del día a día. Con una cautela: el texto es de pago y no hemos podido cotejar contra el original la redacción exacta de sus títulos, así que lo que sigue es su contenido según fuentes secundarias, no una cita.
| Anexo | Qué trae | Cuándo lo abres de verdad |
|---|---|---|
| B | Orientación de implantación para los controles del anexo A | Cuando conoces el título del control y no sabes qué se espera de ti. Antes de redactar el procedimiento, no después |
| C | Repertorio de posibles objetivos y de fuentes de riesgo relacionados con la IA | Al fijar objetivos y al evaluar riesgos, para contrastar tu lista con una ajena y ver qué se te había pasado |
| D | Uso del sistema de gestión en distintos sectores y correspondencia con otras normas de sistemas de gestión | Cuando hay que defender ante dirección que esto se integra con lo ya certificado y no es un sistema aparte |
El C es el que más rendimiento da y el que menos se usa: un análisis de riesgos hecho solo con las cabezas del comité encuentra los riesgos que ya temía. El D es el argumento de la integración, desarrollado en la pieza sobre cómo integrar ISO 42001 con ISO 9001 e ISO/IEC 27001: se reutiliza la maquinaria común —contexto, competencia, auditoría interna, revisión por la dirección, no conformidades—, no los controles, que son propios de la IA.
A.4 y A.7: los dos bloques donde se va el tiempo
Aquí es donde se atasca una implantación. A.4 se atasca porque la palabra «recursos» engaña: en un sistema de calidad, el capítulo 7, Apoyo, se cierra rápido con personas, formación, infraestructura y equipos de medida. En un sistema de gestión de IA, lo que hay que poder identificar por sistema incluye cosas que ningún inventario de calidad recoge y que cambian de versión sin que nadie emita un parte.
Por eso el inventario de sistemas de IA no puede ser una tabla de tres columnas: necesita, por cada sistema, qué modelo hay detrás y en qué versión, quién lo suministra, dónde se ejecuta, qué datos consume y quién responde. Ese documento sostiene A.6, A.7 y A.10 a la vez.
A.7 se atasca por otro motivo: es donde el sistema de gestión se cruza con la ley. La gobernanza de datos es el artículo 10 del Reglamento (UE) 2024/1689, y la correspondencia control a control entre el anexo A y las obligaciones del AI Act ya está resuelta en el mapeo de controles entre ISO 42001 y el AI Act, así que no la repetimos. Sí conviene añadir una novedad del Ómnibus que cae en la carpeta de datos: el nuevo artículo 4 bis permite tratar excepcionalmente categorías especiales de datos personales cuando sea estrictamente necesario para detectar y corregir sesgos de sistemas de IA de alto riesgo, con seis condiciones acumulativas entre las que están la pseudonimización, el control documentado del acceso, la prohibición de transmitirlos a terceros y su supresión una vez corregido el sesgo. El propio artículo aclara que su apartado 2 «no crea obligación alguna de llevar a cabo dicha detección y corrección de sesgos»; pero si se hace, cada una de esas condiciones es una evidencia que alguien va a pedir.
A.10: el bloque que sostiene la cadena de suministro
En la mayoría de las empresas españolas que se plantean certificar, la IA del alcance no la ha construido nadie de la casa: es una interfaz contratada, un modelo que se ejecuta en la nube de un tercero o una funcionalidad que llegó en una actualización del programa de gestión de siempre. Con ese punto de partida A.10 deja de ser el bloque administrativo del final: la calidad de los datos, el control del ciclo de vida y la información a los afectados dependen de lo que haga un tercero y de lo que se le haya exigido por escrito.
Tres decisiones lo resumen. Qué se pide a cada proveedor y en qué documento consta, porque no basta el contrato marco firmado antes de que la IA existiera en el catálogo. Cómo se entera la organización de que el modelo ha cambiado de versión, porque va a cambiar y la validación hecha sobre la anterior deja de valer sin que nadie avise. Y qué se le cuenta al cliente propio cuando el servicio que recibe lleva IA dentro. Cuando el bloque falta, el hallazgo no es «no hay contrato»: es que la organización no puede demostrar qué versión de qué modelo está usando hoy en un proceso que afecta a personas.
Por dónde empezar si la declaración está en blanco
- Cierra el inventario de sistemas de IA antes de tocar el anexo A, con los recursos de cada uno: modelo y versión, proveedor, dónde se ejecuta, qué datos consume y quién responde. Sin alcance no hay exclusión que se pueda justificar.
- Recorre los nueve bloques contra ese inventario y anota qué procedimiento cubre cada uno y qué falta. Lo que cubran documentos de ISO 9001 o de ISO/IEC 27001 se cita por su código, no se reescribe.
- Redacta la declaración con versión, fecha, responsable y el disparador de revisión. Las exclusiones, con su motivo y la referencia que lo sostiene.
Si lo que está atascado es el punto uno, el problema todavía no es el anexo A. En Summum Calidad arrancamos por ahí en la implantación de ISO 42001: una declaración escrita sobre un inventario incompleto hay que rehacerla entera.
Preguntas frecuentes
¿Cuántos controles tiene el Anexo A de ISO 42001?
El Anexo A de ISO/IEC 42001 recoge nueve objetivos de control, numerados de A.2 a A.10, con 38 controles en total. No publicamos cuántos controles corresponden a cada bloque porque las fuentes públicas que dan ese reparto no coinciden entre sí y el texto de la norma es de pago; el total sí está contrastado en fuentes independientes que coinciden.
¿Se puede excluir un control del Anexo A de ISO 42001?
Sí. La declaración de aplicabilidad puede excluir controles siempre que el motivo remita a algo verificable fuera del propio documento: el alcance del sistema de gestión, un resultado del análisis de riesgos o una evaluación de impacto concreta. Lo que no vale es un «no aplica» sin referencia, ni marcarlo todo como aplicable para ahorrarse el argumento, porque cada control aplicable obliga a presentar evidencia.
¿El Anexo A de ISO 42001 es igual que el de ISO 27001?
El mecanismo es el mismo: un catálogo de controles de referencia, la selección a partir del análisis de riesgos y una declaración de aplicabilidad que justifica inclusiones y exclusiones. Cambian el objeto y parte del contenido: ISO 42001 dedica un bloque completo a los impactos del sistema sobre personas, grupos y sociedad, y agrupa sus controles bajo objetivos de control numerados de A.2 a A.10.
¿Para qué sirven los anexos B, C y D de ISO 42001?
Son informativos y no se auditan como requisito. Según las fuentes secundarias disponibles, porque el texto oficial es de pago, el B da orientación para implantar los controles del anexo A, el C recoge posibles objetivos y fuentes de riesgo relacionados con la IA, y el D trata el uso del sistema de gestión en distintos sectores y su correspondencia con otras normas de sistemas de gestión.
¿Hay que rehacer la declaración de aplicabilidad con la norma UNE de 2026?
No hay que rehacer el trabajo. UNE-EN ISO/IEC 42001:2026 está en vigor desde el 8 de abril de 2026 y anula a UNE-ISO/IEC 42001:2025, pero AENOR declara la equivalencia idéntica con ISO/IEC 42001:2023, así que el contenido de los controles no cambia. Lo que hay que actualizar es la referencia documental: la declaración de aplicabilidad, la política, el manual y los informes de auditoría citan la norma por su código.