Los defectos de un sistema de gestión de IA se pueden anticipar leyendo lo que pide la norma y sabiendo cómo trabaja una organización que ya tiene ISO 9001 o ISO/IEC 27001: las exigencias nuevas se resuelven con los procedimientos que ya existen, y ahí se abren las grietas. Este artículo recorre diez de ellas, dice con qué cláusula de ISO/IEC 42001 o con qué bloque del anexo A choca cada una, cómo se ve desde fuera y qué la cierra de verdad. Una aclaración sobre el título: «típicas» significa aquí reconocibles y previsibles, no medidas. No existe estadística pública de auditorías de sistemas de gestión de IA y no vamos a inventarla: aquí no hay porcentajes ni orden de frecuencia, hay razones por las que cada defecto es esperable y la evidencia que lo delata.
El orden va del alcance a lo que se decide con el sistema ya en marcha, y el décimo explica a los otros nueve. El recorrido completo de la norma está en la guía completa de ISO 42001.
Un alcance escrito para que quepa todo, que es como no escribirlo
Un alcance que dice «los sistemas de inteligencia artificial utilizados por la organización» no delimita nada, y lo que no delimita no se puede auditar: no permite decidir si algo concreto está dentro ni, por tanto, si falta una evaluación de impacto.
Choca con la cláusula 4, contexto de la organización, donde se determina el alcance, y arrastra al bloque A.9, uso de los sistemas de IA: un alcance ambiguo no dice si el sistema de gestión cubre las herramientas que la plantilla utiliza o solo los desarrollos propios. Es previsible cuando se escribe antes de tener inventario, ancho para no cerrarse puertas, o cuando se copia del de ISO 9001. Desde fuera se ve en un minuto: el auditor señala una herramienta, pregunta si está dentro y dos personas contestan distinto.
La corrección: nombrar los sistemas o remitir al inventario por versión, decir qué procesos y centros quedan dentro y si cubre desarrollo, integración o uso, y motivar las exclusiones. Y una regla: cuando entra un sistema nuevo, alguien decide por escrito si el alcance cambia. Ese texto acaba impreso en el certificado.
El inventario de sistemas de IA que se olvida de la IA que se compró
El caso más incómodo: la IA que llega dentro del CRM que puntúa oportunidades, del programa de selección que ordena candidaturas o del asistente de atención al cliente. Nadie compró IA: se renovó una suscripción, o llegó una funcionalidad nueva en una actualización.
Choca con A.4, recursos para los sistemas de IA; con A.9, uso; y con A.10, terceros y clientes. Lo grave está más abajo: con el inventario incompleto, el análisis de riesgos de la cláusula 6 y las evaluaciones de impacto de A.5 quedan incompletos de raíz. El defecto aparece cuando el inventario se levanta preguntando por «proyectos de IA», porque la IA embebida no fue un proyecto. Desde fuera, el auditor no se cree el inventario: lo coteja contra listas que no se escribieron para él —proveedores, licencias, gasto— o pregunta al responsable de personas cómo se ordenan las candidaturas.
La corrección es construirlo al revés: barrer esas listas y preguntar a cada responsable de proceso por función, no por tecnología: si algo puntúa, ordena, clasifica, recomienda o redacta sin que lo haga una persona. Y meter esa pregunta en el alta y la renovación de proveedores, para que se mantenga solo. Cada entrada, con propietario con nombre y apellidos, decisión de negocio afectada, proveedor, versión y fecha de revisión. Qué documento vale como prueba está en las evidencias que pide el auditor de ISO 42001.
La evaluación de riesgos que se disfraza de evaluación de impacto
Son dos ejercicios con dos preguntas. El riesgo mira hacia dentro: qué puede pasarle a la organización. El impacto mira hacia fuera: qué efectos tiene el sistema sobre personas, grupos y sociedad, que pueden no ser clientes ni empleados. Hacer uno y llamarlo los dos es un hallazgo.
Choca con la cláusula 6, planificación, y con el bloque A.5, evaluación de impactos; que la norma los separe ya dice que no esperaba un documento único. Es previsible en las organizaciones más maduras: tienen una metodología de riesgos con años de rodaje y la reutilizan. Pero una matriz que mide confidencialidad, integridad y disponibilidad sobre activos no tiene casilla para anotar que un modelo deja fuera a un colectivo. Desde fuera: la evaluación de impacto es la matriz de riesgos con una columna renombrada, y no tiene disparador ni fecha.
La corrección son dos documentos, con dos disparadores y dos responsables. El de riesgos alimenta el plan de tratamiento y la declaración de aplicabilidad. El de impacto responde a quién puede salir perjudicado, cómo y por dónde reclama, y acaba en una decisión, incluso la de no cambiar nada. Los disparadores se escriben: sistema nuevo, cambio de finalidad, colectivo nuevo, cambio de modelo o de proveedor. ISO/IEC 42005 ordena ese trabajo: el procedimiento está en la evaluación de impacto con ISO 42005, punto de encaje además con la evaluación en derechos fundamentales del AI Act, materia legal de Summum Consultoría.
La declaración de aplicabilidad con los 38 controles marcados como aplicables
Marcar todo como aplicable parece prudente y es lo contrario. Cada «aplica» es una promesa de evidencia, y el auditor no lee la columna del sí: toma una muestra, elige controles y pide el registro.
Choca con el anexo A y con la cláusula 8, operación, donde debería estar funcionando lo que la declaración afirma: no es un cuestionario de intenciones, es el índice de la carpeta. El defecto aparece cuando se rellena contra el catálogo en vez de contra el inventario: excluir obliga a justificar en una reunión, y marcar «aplica» cierra la conversación ese día para reabrirla en la auditoría. Se reconoce por dos patrones: la evidencia remite a un procedimiento general que no menciona la IA, o el documento citado tiene fecha anterior a la existencia del sistema.
La corrección son dos pasadas separadas. En la primera se decide la aplicabilidad contra el inventario y contra los resultados de riesgo e impacto. En la segunda se escribe, control a control, el documento exacto, su versión y quién lo custodia; donde no hay nada, queda como hueco abierto con responsable y fecha. Un hueco declarado se discute; una evidencia fantasma se levanta como hallazgo. Cómo se sostiene una exclusión está en el anexo A de ISO 42001 y su declaración de aplicabilidad.
Formación genérica en IA donde la norma pide competencia por rol
Un curso de dos horas para toda la plantilla, con la misma diapositiva para quien atiende el teléfono y para quien decide que un modelo pase a producción. Como sensibilización está bien; como evidencia de competencia no llega. Choca con la cláusula 7, apoyo, que pide determinar la competencia necesaria para los roles que intervienen y conservar evidencia de que la tienen, y roza A.3 y A.4.
El Ómnibus digital sobre IA ha reescrito el artículo 4 del AI Act y le ha añadido esta frase: «Esta obligación no exige que los proveedores o los responsables del despliegue garanticen un nivel específico de alfabetización en materia de IA de ninguna persona en particular.» De ahí se deduce que la obligación legal es de medios: adoptar medidas atendiendo al punto de partida de cada persona y al contexto de uso. De ahí no se deduce que la competencia deje de acreditarse donde la norma la pide: la cláusula 7 sigue en su sitio y en este punto es más exigente que el Reglamento. El artículo 4 se aplica desde el 2 de febrero de 2025; el cambio completo está en el Ómnibus de IA y el sistema de gestión.
Desde fuera: una única hoja de firmas y ningún registro propio de quien valida las salidas del modelo. La corrección es un itinerario por rol con evidencia proporcional a la decisión de ese rol. Para quien usa una herramienta con supervisión basta un registro de formación con fecha y asistencia. Para quien autoriza el paso a producción, lo que demuestra competencia es su participación documentada en decisiones técnicas: los criterios que fijó antes de las pruebas. Y una regla para las rotaciones: cuando la persona cambia, la competencia del rol se vuelve a establecer.
Proveedores de IA que nadie ha evaluado, porque el modelo es de otro
El modelo lo entrenó un tercero, lo actualiza un tercero y lo explica un tercero. La responsabilidad de lo que sale en pantalla delante de una persona es de quien puso el sistema ahí.
Choca con A.10, terceros y clientes; con A.7, datos, cuando el entrenamiento es ajeno; y con la cláusula 8, que pide controlar lo que se hace fuera. Es previsible en cualquier organización con una evaluación de proveedores heredada de ISO 9001: puntúa plazo, precio e incidencias, y ninguna columna pregunta qué versión del modelo está en producción ni qué pasa si cambia. Y hay una dificultad real: a varios de estos proveedores no se les negocia el contrato. Desde fuera: nadie sabe qué versión está en producción ni cuándo cambió.
La corrección tiene tres piezas que se consiguen sin poder de negociación. Archivar la documentación que el proveedor publica —condiciones, fichas del modelo, subencargados, cambios— con la fecha en que la archivaste, porque cambia sin avisar. Poner controles propios donde el contrato no llega: revisión humana antes de actuar sobre la salida, muestreo, umbrales a partir de los cuales no se usa. Y dejar un registro de riesgo asumido con firma y fecha, porque es una decisión de dirección. La reevaluación se dispara por cambio de versión, no por calendario.
Un sistema en producción sin un solo registro de su operación
Sin control de cambios, sin pruebas documentadas y sin seguimiento del modelo hay dos cosas: un sistema funcionando y un manual que describe cómo debería funcionar. El auditor las compara.
Choca con la cláusula 8, operación, con la 9, evaluación del desempeño, y con A.6, ciclo de vida, que cubre desde la verificación previa hasta la retirada. Aparece con claridad cuando el sistema es una suscripción, porque se actualiza solo: hay procedimiento de control de cambios, pero escrito para desarrollo propio, y no existe la categoría «cambio en un sistema que no construimos nosotros». Desde fuera: a la pregunta de cuándo cambió el modelo por última vez, silencio; y la prueba de las pruebas es una captura de pantalla sin fecha, sin criterio previo y sin nombre.
La corrección es un mínimo operable por sistema. Un histórico de cambios alimentado por dos fuentes, los tuyos y el del proveedor, revisado con una periodicidad fijada. Criterios de prueba escritos antes de ejecutarlas, con apto o no apto y firma de quien decide. Y una revisión del comportamiento con un indicador definido, un umbral que obligue a actuar y alguien con nombre que lo lee y deja constancia. Cómo se implementa técnicamente el registro de eventos es otra capa y la lleva Summum IA; la auditoría de gestión mira que exista y que las desviaciones acaben en algún sitio.
La revisión por la dirección que podría ser la de ISO 9001 sin cambiar una coma
Un acta con los mismos apartados del año anterior, la IA nombrada una vez en otros asuntos y ninguna decisión detrás. Es un hallazgo doble: falla la cláusula 9, revisión por la dirección, y falla la cláusula 5, liderazgo, porque sin revisar el sistema de gestión de IA no hay evidencia de implicación de la dirección. Es previsible porque la integración se hace por el camino corto: añadir la palabra IA al orden del día que ya existe. Funciona para el acta, no para la evidencia.
La corrección es una lista de entradas propias, cada una con su epígrafe en el acta:
- Inventario: sistemas que entraron y que se retiraron.
- Evaluaciones de impacto y decisiones que salieron de ellas.
- Incidentes y reclamaciones de personas afectadas, con lo que se hizo.
- Cambios de proveedor y de versión de modelo en producción.
- Cambios legales: el Ómnibus digital sobre IA, en vigor desde el 27 de julio de 2026; la aplicación general del AI Act, el 2 de agosto de 2026.
- Acciones correctivas abiertas, una por una con su fecha.
- Suficiencia de recursos: personas, competencia y presupuesto.
Y una salida: si de la revisión no sale ninguna decisión con responsable y fecha, no ha habido revisión. Cómo se monta un acta que sirva para las tres normas está en integrar ISO 42001 con ISO 9001 y 27001. Y un detalle de un minuto: la referencia vigente es UNE-EN ISO/IEC 42001:2026, desde el 8 de abril de 2026; un acta que siga citando la referencia anulada delata que nadie ha mirado el sistema.
Acciones correctivas que arreglan el documento y no la causa
El plazo para cerrar hallazgos es corto y la corrección más barata es tocar el documento que el auditor señaló. Cierra el papel, deja el mecanismo intacto y garantiza que el defecto vuelva, a veces colgado de otro control. Choca con la cláusula 10, mejora, que pide analizar la causa y no solo corregir el efecto.
Desde fuera se lee en dos campos del formulario. En el de causa: «error humano» o «falta de formación». En el de acción: «se ha actualizado el procedimiento». Y una tercera señal: que el registro de no conformidades solo contenga hallazgos de auditoría. Si no entran las incidencias de operación, las reclamaciones y los fallos de proveedor, la cláusula 10 solo vive la semana de la visita.
La corrección empieza por dónde termina el análisis: la causa tiene que aterrizar en algo que la organización controla, una regla que no existe, un paso que falta, un rol sin propietario. «Error humano» no es una causa, es el sitio donde se notó. Después, los dos pasos que el cierre rápido se salta: extender la corrección a los casos iguales —si a un sistema le faltó el disparador de evaluación de impacto, el defecto es del procedimiento y hay que revisar los demás— y verificar la eficacia sobre un caso nuevo. Releer el documento corregido no verifica nada.
Documentar el sistema y no operarlo, que es el defecto del que salen los demás
Un manual impecable encima de una organización que no ha cambiado nada no vale. La auditoría está diseñada para encontrar eso, y lo encuentra por el rastro, no por el contenido: documentos aprobados todos el mismo día, todos en versión 01, y un comité que se ha reunido una vez.
Choca con la cláusula 5, liderazgo, con la 8, operación, y con la 9. Y arrastra: los nueve defectos anteriores son síntomas de este, lo que pasa cuando el sistema se escribe para aprobar una auditoría en lugar de para gobernar algo.
La corrección no es documentar más. Es elegir el conjunto más pequeño de cosas que van a pasar de todas formas y hacer que dejen rastro solas. Compras no cierra una suscripción nueva sin responder si lleva IA dentro, y esa respuesta crea la entrada del inventario. La autorización de paso a producción no se da de palabra. Una queja sobre una decisión automatizada entra por el circuito de reclamaciones. Un registro que no se apoya en un flujo que ya ocurre será ficción el mes siguiente. El orden para montarlo está en el cronograma de implantación, y donde estos defectos aparecen con margen para arreglarlos es la auditoría interna.
Los diez defectos, su cláusula y su corrección
Guion de autodiagnóstico: donde reconozcas el defecto, lee la corrección. La columna del medio es la que citará el auditor.
| Defecto | Cláusula o bloque | Corrección |
|---|---|---|
| Alcance que no delimita | Cláusula 4; arrastra A.9 | Nombrar sistemas y centros, motivar exclusiones y revisarlo al entrar uno nuevo |
| Inventario sin la IA comprada | A.4, A.9 y A.10; deja sin base la cláusula 6 y A.5 | Levantarlo desde licencias, proveedores y gasto; casilla fija en compras |
| Riesgo e impacto en un solo documento | Cláusula 6 y A.5 | Dos documentos, dos disparadores, dos responsables |
| Todo aplicable, sin evidencia de la mitad | Anexo A y cláusula 8 | Documento, versión y custodio por control; huecos con responsable y fecha |
| Formación genérica, no competencia por rol | Cláusula 7; roza A.3 y A.4 | Itinerario por rol y evidencia proporcional a la decisión |
| Proveedor del modelo sin evaluar | A.10 y A.7; cláusula 8 | Su documentación archivada con fecha, controles propios y riesgo asumido firmado |
| Producción sin cambios, pruebas ni seguimiento | Cláusulas 8 y 9; A.6 | Histórico de dos fuentes, criterios previos e indicador con umbral |
| Revisión por la dirección sin entradas de IA | Cláusulas 9 y 5 | Entradas propias con su epígrafe y salidas con responsable y fecha |
| Correctiva sin análisis de causa | Cláusula 10 | Causa controlable, extensión a los casos iguales y eficacia sobre un caso nuevo |
| Sistema documentado y no operado | Cláusulas 5, 8 y 9 | Registros colgados de flujos que ya ocurren: compras, producción, quejas |
Ninguno de estos diez se cierra la semana antes de la auditoría, y ninguno depende de comprar nada. Si reconoces tres o más, el trabajo no está en los documentos: está en enganchar el sistema a lo que la organización hace de verdad. La secuencia de requisitos contra la que cotejarlo está en las cláusulas 4 a 10.
Preguntas frecuentes
¿Cuáles son las no conformidades más habituales en una auditoría de ISO 42001?
No existe estadística pública de auditorías de sistemas de gestión de IA, así que nadie puede dar un orden de frecuencia con respaldo. Lo que sí se puede anticipar son los defectos previsibles a partir de lo que exige la norma: alcance sin delimitar, inventario que no recoge la IA comprada dentro de otras herramientas, riesgo e impacto confundidos, declaración de aplicabilidad sin evidencia detrás, formación genérica en lugar de competencia por rol, proveedores sin evaluar, operación sin registros, revisión por la dirección sin entradas de IA y acciones correctivas sin análisis de causa.
¿Hay que incluir en el inventario de IA las herramientas que ya tengo compradas?
Sí. Si el CRM puntúa oportunidades, el programa de selección ordena candidaturas o el asistente de atención al cliente redacta respuestas, son sistemas de IA en uso aunque no se compraran como tales. El anexo A de ISO/IEC 42001 los toca por tres sitios: recursos (A.4), uso (A.9) y relaciones con terceros (A.10). Si no están en el inventario, el análisis de riesgos y las evaluaciones de impacto quedan incompletos de raíz.
¿La evaluación de riesgos y la evaluación de impacto de ISO 42001 son lo mismo?
No. La evaluación de riesgos mira los efectos sobre los objetivos de la organización y alimenta el plan de tratamiento y la declaración de aplicabilidad. La evaluación de impacto mira los efectos del sistema sobre personas, grupos y sociedad, que pueden no ser clientes ni empleados. Son dos documentos con disparadores distintos, y la guía que ordena el segundo es ISO/IEC 42005.
¿Vale un curso general de IA para toda la plantilla como evidencia de competencia?
Como acción de sensibilización sirve; como evidencia de competencia por rol, no. El artículo 4 del AI Act, en la redacción del Ómnibus digital sobre IA, aclara que la obligación de alfabetización no exige garantizar un nivel específico de ninguna persona en particular, pero eso no toca la cláusula 7 de ISO/IEC 42001, que pide determinar la competencia necesaria para cada rol y conservar evidencia de que se tiene. Dos horas para toda la plantilla no demuestran la competencia de quien autoriza que un modelo pase a producción.
¿Se puede marcar todo el anexo A como aplicable y así no justificar exclusiones?
Se puede, y sale caro. Cada control marcado como aplicable es una promesa de evidencia, y el auditor toma una muestra y pide el registro. Es más defendible excluir un control con un motivo que remita al alcance o a un resultado del análisis de riesgos, o declarar un hueco abierto con responsable y fecha, que declarar aplicable algo que no puedes probar.