ISO/IEC 42001: el manual de operaciones del sistema de IA — cómo encaja el AIMS sobre la plataforma LLM on-premise descrita en el blog

Este post cierra una asimetría que el blog acumulaba: hemos descrito en detalle la plataforma técnica (siete capas del stack, siete fases del despliegue, cinco niveles de madurez), el pipeline operativo (seis etapas LLMOps), las piezas data (curación de corpus, versionado), las piezas eval / safety (evals, guardrails, LLM Guard) y las piezas observe (tracing OTel GenAI). Lo que no había aparecido es la capa de gobierno que un cliente regulado pide encima de todo eso. ISO/IEC 42001 es esa capa.

TL;DR

ISO/IEC 42001:2023 es la primera norma internacional certificable que define cómo se gestiona un sistema de IA. No es una norma técnica (no dice “usa este motor de inferencia” ni “este threshold de safety”): es una norma de gestión, prima de ISO 27001 e ISO 9001. Hereda de ambas la estructura Annex SL —siete cláusulas obligatorias que recorren contexto, liderazgo, planificación, soporte, operación, evaluación de desempeño y mejora— y añade un Annex A con 38 controles específicos de IA en 9 secciones: políticas, organización interna, recursos, impact assessment, ciclo de vida, datos, información a partes interesadas, uso, terceros. La tesis del post es que la arquitectura técnica descrita en este blog cubre directamente entre el 60% y el 80% de los controles A sin trabajo adicional —el pipeline LLMOps materializa A.6, el versionado y curación materializan A.7, los guardrails y evals materializan A.9, el tracing OTel materializa A.8—; el resto es disciplina de gobierno que no aparece en el código (política de IA escrita, impact assessments por sistema, registro de stakeholders, decisiones de roles entre provider/producer/customer, documentación obligatoria), y es precisamente lo que diferencia una certificación real de un cumplimiento performativo. El post mapea control a control la correspondencia, cruza con EU AI Act (siete artículos directamente alineados con 42001: 9, 10, 11, 12, 13, 14, 17), con NIS2 (asset register, incident notification, supply chain) y con ENS (RD 311/2022, categorías Básico/Medio/Alto), lista los siete documentos obligatorios mínimos que un auditor pide, presenta el caso del chatbot multi-tenant del blog como checklist 42001 vivo, y cierra con las cinco trampas habituales (confundir 42001 con cumplimiento EU AI Act, sobre-documentar sin medir, ignorar A.5 hasta el audit, asumir que 27001 cubre la parte AI, pensar que la certificación es un proyecto puntual y no un sistema vivo).

La analogía: el manual de operaciones del avión

Un avión moderno —un A350, un Boeing 787, un dron certificado para reparto urbano— no vuela porque tenga buenos motores. Vuela porque la organización que lo opera tiene un Manual de Operaciones aprobado por la autoridad aeronáutica (EASA en Europa, FAA en EEUU, AESA en España como delegada). El manual no contiene los planos del motor —eso lo certifica el fabricante—; contiene los procedimientos: quién es el comandante en cada vuelo, qué checklist se ejecuta antes de cada despegue, qué inspecciones periódicas se hacen a las 100, 500 y 2.000 horas de vuelo, qué proveedores externos están autorizados a tocar qué componentes, qué se documenta tras cada incidente, qué hacer cuando aparece una alerta nueva en el panel. La autoridad no se sienta en cada vuelo: lee el manual, audita aleatoriamente la trazabilidad de los vuelos pasados contra el manual, y si todo cuadra, mantiene la certificación.

Un sistema de IA en producción —el chatbot multi-tenant del post forense, un copiloto para abogados, un sistema de scoring crediticio— es exactamente lo mismo. Vuela porque el modelo es bueno, el pipeline LLMOps está bien montado, los guardrails atrapan los casos malos. Pero certifica porque la organización que lo opera tiene un AIMS (AI Management System) descrito en un manual auditable. ISO/IEC 42001 es ese manual: su índice obligatorio (Annex SL, siete cláusulas) y su catálogo de controles específicos de IA (Annex A, 38 controles). El auditor no se sienta junto al ingeniero MLOps: lee la política de IA, revisa los impact assessments de los últimos sistemas desplegados, comprueba que el retrain de incidentes está documentado, verifica los contratos con terceros, audita una muestra de trazas en Langfuse cruzadas con dataset_hash y prompt_id. Y si todo cuadra, certifica.

La analogía importa porque acota la pregunta correcta: 42001 no certifica el modelo ni el código. Certifica la forma de operar del sistema completo. Un equipo puede tener el mejor stack OSS del mundo y suspender la auditoría porque no tiene una política de IA escrita ni una decisión documentada sobre qué rol (provider vs producer vs customer) ocupa frente a sus clientes. Y viceversa: un equipo con un modelo modesto pero con disciplina de manual de operaciones puede certificar sin acrobacias.

ISO/IEC 42001 en 15 segundos

• Publicación: diciembre de 2023, ISO/IEC JTC 1/SC 42 (el subcomité ISO/IEC de AI).
• Estado en 2026: norma vigente, certificable por organismos acreditados (BSI, AENOR, TÜV, Bureau Veritas, A-LIGN, Schellman). Aún no reconocida formalmente como norma armonizada del EU AI Act, pero proporciona la base de gestión sobre la que apoyarse.
• Compatibilidad: comparte la estructura Annex SL con ISO 9001 (calidad), 27001 (seguridad de la información), 27701 (privacidad), 22301 (continuidad), 20000-1 (servicios IT). Las organizaciones con sistemas de gestión integrados (IMS) la añaden con un esfuerzo del 20-40% del que costaría implantarla desde cero.
• Aplicabilidad: cualquier organización que desarrolle, provea, despliegue o use sistemas de IA. No se limita a desarrolladores: una empresa que consume un LLM hospedado y lo integra en un producto propio está dentro del alcance.
• Certificación: ciclo de 3 años con auditoría inicial (Stage 1: review documental + Stage 2: auditoría in-situ) y auditorías de seguimiento anuales. Coste típico: 15.000-60.000 € la inicial según tamaño; 6.000-20.000 € por seguimiento anual.

Lo que no hace 42001:

• No dice qué modelos usar ni qué thresholds aplicar.
• No certifica el modelo individual (eso lo hacen evaluaciones específicas tipo NIST AI RMF profile o EU AI Act technical documentation).
• No sustituye al EU AI Act ni al RGPD: es complementaria. Implantarla bien facilita el cumplimiento legal pero no lo garantiza.
• No es una norma técnica de explicabilidad ni de robustez (esas son ISO/IEC 25059, 24029, 23894 y otras de la familia SC 42).

Distinción con marcos vecinos

Tres distinciones que importan operativamente y que son fuente de confusión recurrente con clientes:

1. ISO 42001 ≠ EU AI Act compliance. Tener la certificación 42001 facilita demostrar artículos 9-17 del Reglamento europeo, pero el Reglamento exige más cosas que 42001 no cubre directamente (CE marking de sistemas de alto riesgo, registro en la base de datos europea, declaración de conformidad, post-market monitoring específico). Implantar 42001 primero y luego completar los huecos del AI Act es la ruta estándar.
2. ISO 27001 no es suficiente. 27001 cubre confidencialidad, integridad y disponibilidad de la información. Falta el lado AI: sesgo, opacidad, deriva del modelo, calidad del corpus de entrenamiento, evaluación humana, impacto sobre afectados. 42001 es complemento, no sustituto. Las organizaciones con 27001 ya implantado tienen ventaja porque comparten la mitad de la documentación.
3. NIS2 ≠ AI safety. NIS2 obliga a registrar activos críticos, notificar incidentes en 24 h, gestionar la cadena de suministro digital. Los sistemas de IA pueden estar dentro del alcance NIS2 si forman parte del activo crítico (un LLM que sirve atención al cliente en una entidad financiera lo está), pero NIS2 no audita la calidad del modelo. 42001 sí.

Las siete cláusulas (Annex SL): el índice obligatorio

Las siete cláusulas de la cláusula 4 a la 10 son comunes a todas las normas de gestión modernas (Annex SL, también llamado “High Level Structure”). Esto significa que una organización con ISO 9001 o 27001 ya implantada reconoce la estructura. Las cláusulas 1-3 son introductorias (alcance, referencias normativas, términos).

Cláusula 4 — Contexto de la organización

Identificar el contexto externo (regulación aplicable, expectativas de los clientes, riesgos sociales) y el contexto interno (estrategia, cultura, capacidades). Identificar las partes interesadas y sus expectativas: clientes, reguladores, afectados, empleados, proveedores. Definir el alcance del AIMS: qué sistemas de IA están dentro y cuáles fuera.

El gap habitual: organizaciones que dicen “todos nuestros sistemas IA están en el alcance” sin haberlos enumerado. El auditor pide la lista. Sin lista, no hay alcance.

Cláusula 5 — Liderazgo

La dirección debe aprobar y publicar una política de IA (AI policy), asignar roles y responsabilidades (típicamente AI lead, AI risk owner, data officer), y demostrar compromiso con recursos, comunicación y supervisión. La política es documento auditable y debe ser proporcionada al personal y partes interesadas.

El gap habitual: política de IA genérica copiada de internet, sin medibles ni objetivos concretos. El auditor pide cómo se mide su cumplimiento. Sin métricas, la política es teatro.

Cláusula 6 — Planificación

Identificar riesgos y oportunidades del AIMS (no del modelo individual). Definir objetivos de IA medibles, con plazos y responsables. Planificar los cambios al AIMS.

El gap habitual: confundir riesgos del AIMS (¿qué pasa si no documentamos correctamente?) con riesgos del modelo (¿qué pasa si el modelo sesga?). El primero va aquí; el segundo va a A.5.

Cláusula 7 — Soporte

Recursos humanos, técnicos, financieros, infraestructura. Competencia del personal (formación documentada). Conciencia del personal sobre la política. Comunicación interna y externa. Información documentada (la columna vertebral del SI: política, procedimientos, registros, evidencias).

El gap habitual: documentación dispersa en confluence/notion/drive sin control de versiones ni aprobaciones registradas. El auditor pide el último cambio: ¿quién lo aprobó? ¿cuándo? ¿con qué justificación?

Cláusula 8 — Operación

La cláusula más operativa. Exige:

• Planificación y control operacional: cómo se gestiona el ciclo de vida del sistema de IA día a día. → Cubierto en el blog por pipeline LLMOps de seis etapas.
• Impact assessment (vinculado a A.5).
• Gestión del ciclo de vida del sistema de IA (vinculado a A.6).
• Datos para sistemas de IA (vinculado a A.7).

Es la cláusula que se materializa en los controles A.5, A.6, A.7. Por sí sola no añade requisitos nuevos: enlaza con el Annex A.

Cláusula 9 — Evaluación del desempeño

Monitoreo, medición, análisis, evaluación. Auditorías internas (planificadas, con criterios, alcance, frecuencia, registro de resultados). Revisión por la dirección (típicamente trimestral o semestral, con agenda obligatoria: inputs, evidencia, decisiones, acciones).

El gap habitual: hay tracing OTel + Langfuse + Grafana y datos de sobra, pero no hay agenda formal de revisión por la dirección con minuta documentada. El auditor pide la minuta. Sin minuta, no hay revisión.

Cláusula 10 — Mejora

No conformidad y acción correctiva: cuando algo falla, se registra, se analiza causa raíz, se acuerda corrección, se verifica eficacia. Mejora continua: el sistema evoluciona deliberadamente.

El gap habitual: tickets de Jira con post-mortems técnicos pero sin registro formal de “no conformidad ISO” que cierra con verificación de eficacia. Son dos artefactos distintos aunque puedan integrarse.

Los 38 controles del Annex A: el catálogo AI-específico

A diferencia del Annex SL (común), el Annex A es la firma AI-específica de la 42001. Los 38 controles se organizan en 9 secciones (A.2 a A.10; A.1 es la introducción) que cubren los riesgos AI-específicos: opacidad, sesgo, deriva, calidad del corpus, impacto sobre afectados, dependencia de terceros. Cada control tiene objetivo (qué se quiere conseguir) y guidance de implementación en el Annex B.

Lo que sigue es el mapeo control por sección al material que ya hemos cubierto en el blog. La intención editorial es enseñar qué huecos quedan después de tener implementada la arquitectura técnica, para que el camino a certificación no empiece desde cero.

Mapeo cruzado: 38 controles ↔ posts del blog

A.2 — Políticas de IA (2 controles): PARCIAL

• A.2.2 AI policy: la organización debe tener una política de IA documentada, aprobada por dirección, revisada periódicamente, comunicada y disponible. Cubre principios, alcance, compromisos.
• A.2.3 Alignment with other policies: la política de IA no es huérfana — se alinea con políticas existentes de seguridad, privacidad, calidad, ética.

Hueco: no es asunto del código. La política de IA es un documento que la dirección de la organización aprueba y firma. El blog enseña la postura editorial neutra y técnica (sin hype, soberanía, OSS por defecto en ENS/NIS2) pero esto no es la política IA de una organización concreta. Cada cliente debe redactarla y firmarla.

Plantilla mínima: 1-2 páginas con: principios (transparencia, supervisión humana, fairness, responsabilidad, sostenibilidad), alcance (qué sistemas), compromisos medibles (revisión anual, evaluación de impacto antes de despliegue, formación al equipo), gobierno (quién aprueba qué).

A.3 — Organización interna (3 controles): HUECO

• A.3.2 AI roles and responsibilities: roles definidos, no solapados, comunicados. Típicamente: AI lead, AI risk owner, data steward, AI ethics officer (puede ser uno solo en organizaciones pequeñas).
• A.3.3 Reporting of AI incidents/concerns: canal para que cualquier persona (interna o externa) reporte un problema con un sistema IA, con seguimiento documentado.
• A.3.4 Identification of stakeholders: lista mantenida de stakeholders (clientes, afectados, reguladores, partners) y sus expectativas.

Hueco: tampoco técnico. Decisión organizativa. La forma habitual de cubrirlo es nombrar un AI lead (puede ser el CIO, CTO o un rol nuevo dependiendo del tamaño), reusar el canal de reporting de seguridad (típicamente ya existe por 27001) extendiéndolo a IA, y mantener un registro vivo de stakeholders.

A.4 — Recursos (6 controles): CUBIERTO

• A.4.2 Documented information: documentación del AIMS.
• A.4.3 Data resources: identificación y gestión de los datos disponibles para entrenamiento, evaluación, operación.
• A.4.4 Tooling resources: herramientas de desarrollo, validación, monitoreo.
• A.4.5 System resources: hardware, infraestructura, cómputo.
• A.4.6 Human resources: personal con competencia.
• A.4.7 Financial resources: presupuesto.

Cubierto por el blog en los tres posts arquitectónicos:

• Anatomía del stack: siete capas — A.4.5 system resources, A.4.4 tooling.
• Siete fases del despliegue — A.4.5 + A.4.7 (presupuesto implícito).
• Cinco niveles de madurez — A.4.5 + A.4.6 (madurez del equipo).
• Catálogo OSS de herramientas — A.4.4 tooling.
• Data versioning con DVC y lakeFS — A.4.3 data resources.

A.5 — Impact assessment (5 controles): PARCIAL

• A.5.2 AI impact assessment process: procedimiento documentado de evaluación de impacto.
• A.5.3 Documentation of AI impact assessments: registros de las evaluaciones hechas.
• A.5.4 Alignment with AI risk treatment: las decisiones del impact assessment alimentan el tratamiento de riesgos.
• A.5.5 Impacts on individuals: dimensiones específicas sobre personas afectadas (derechos, discriminación, privacidad).
• A.5.6 Societal impacts: dimensiones sobre la sociedad (información, derechos sociales).

Parcial: el método existe en la familia ISO/IEC SC 42 — ISO/IEC 23894:2023 es la norma técnica de risk management para IA y NIST AI RMF 1.0 es el equivalente americano de uso libre. Pero la organización debe escribir su procedimiento y ejecutarlo por sistema antes del despliegue. No es código, es disciplina.

Plantilla mínima del impact assessment (3-5 páginas por sistema):

1. Descripción del sistema (qué hace, a quién sirve, modelo y stack subyacentes).
2. Stakeholders identificados.
3. Impactos potenciales (intencionados + no intencionados) en personas, grupos y sociedad.
4. Métricas de fairness y robustez aplicadas, con umbrales y resultados.
5. Mitigaciones aplicadas (guardrails, evals, supervisión humana, rate limiting).
6. Riesgos residuales aceptados, con justificación firmada.
7. Cadencia de revisión (típicamente anual o ante cambio sustancial).

A.6 — Ciclo de vida del sistema IA (4 controles): CUBIERTO

• A.6.2.2 Objectives for responsible development of AI: objetivos de desarrollo responsable definidos por sistema.
• A.6.2.3 Processes for responsible AI design and development: procedimientos de diseño y desarrollo.
• A.6.2.4 AI system requirements and specifications: especificación formal del sistema.
• A.6.2.5 Verification and validation: V&V antes y durante operación.
• A.6.2.6 Deployment: procedimientos de despliegue.
• A.6.2.7 Operation and monitoring: operación y monitoreo continuo.
• A.6.2.8 Documentation: documentación del ciclo de vida.

Cubierto por el blog:

• Pipeline LLMOps de seis etapas — el mapa maestro completo del ciclo de vida.
• Anatomía de una petición LLM — la versión forense de cómo se ejecuta en producción.
• Fine-tuning continuo en producción — la disciplina A.6.2.3 + A.6.2.5 + A.6.2.6 + A.6.2.7 en operativa real.
• Evals: la capa después del tracing — A.6.2.5 verification and validation.
• Retrain — A.6.2.7 operación + iteración continua.
• Alignment moderno: DPO, KTO, ORPO, SimPO — A.6.2.3 design responsable.
• MLOps panorama 2026 — el panorama de herramientas.

A.7 — Datos para sistemas IA (5 controles): CUBIERTO

• A.7.2 Data for development and enhancement of AI: política y procedimientos de gestión de datos para desarrollo y mejora.
• A.7.3 Acquisition of data: procedimientos de adquisición (origen, autorización, calidad).
• A.7.4 Quality of data for AI systems: criterios de calidad medibles.
• A.7.5 Data provenance: lineage del dato.
• A.7.6 Data preparation: procedimientos de preparación (chunking, anonimización, etiquetado).

Cubierto por el blog:

• RAG corpus curation: el bibliotecario activo — A.7.4 + A.7.5 + A.7.6 al detalle (cinco capas: schema, dedup, PII, anti-contaminación, lineage).
• Data versioning: DVC y lakeFS — A.7.2 + A.7.5 (los cuatro artefactos data versionados con lineage).
• Reranker y hybrid retrieval — A.7.6 preparación + filtrado.
• LLM Guard — A.7.6 anonimización en runtime con Vault.

A.8 — Información para partes interesadas (4 controles): CUBIERTO

• A.8.2 System documentation and information for users: documentación técnica disponible.
• A.8.3 External reporting: capacidad de reportar a autoridades cuando aplique.
• A.8.4 Communication of incidents to users: notificación a usuarios cuando hay incidente.
• A.8.5 Information for interested parties: información para otros stakeholders.

Cubierto por el blog:

• Tracing LLM con OpenTelemetry GenAI — A.8.2 trazabilidad por request, A.8.3 capacidad de extraer reporting forense.
• Prompt versioning con Langfuse y MLflow — A.8.2 versionado documentado.
• Guardrails y safety en LLMs — A.8.4 spans gen_ai.guardrail.* como base para notificación de incidentes.
• LLM Guard — A.8.4 incident events para retrain.

A.9 — Uso de sistemas IA (3 controles): CUBIERTO

• A.9.2 Processes for responsible use of AI: procedimientos de uso responsable.
• A.9.3 Objectives for responsible use of AI: objetivos.
• A.9.4 Intended use of AI systems: documentación del uso previsto.

Cubierto por el blog:

• Guardrails y safety en LLMs — A.9.2 + A.9.3 (las cuatro líneas de defensa).
• LLM Guard — A.9.2 detalle operativo.
• Evals: la capa después del tracing — A.9.3 medición de objetivos.
• Retrain — A.9.2 closed loop.

A.10 — Terceros y relaciones con clientes (4 controles): CUBIERTO

• A.10.2 Allocation of responsibilities: distribución de responsabilidades entre roles AI.
• A.10.3 Suppliers: procedimientos para proveedores AI.
• A.10.4 Customers: procedimientos hacia clientes.
• A.10.5 Third parties: procedimientos para terceros.

Cubierto por el blog:

• El catálogo paralelo: OSS vs hyperscalers — A.10.3 evaluación de proveedores con análisis de lock-in y soberanía contractual.
• El catálogo OSS para LLMOps — A.10.5 inventario de terceros (componentes OSS con licencias y gobierno).
• Anatomía de una petición LLM — A.10.2 + A.10.4 en el caso multi-tenant.

Los roles definidos por la norma

ISO/IEC 22989:2022 (vocabulario IA, complementaria a 42001) define seis roles. Cada organización debe decidir cuáles ocupa y documentarlo:

Una organización puede ocupar varios roles a la vez, lo cual cambia los controles aplicables. Un patrón habitual en consultoría es: producer + customer + provider hacia el cliente final. Las responsabilidades A.10 se modulan según los roles.

Ejemplo de mapeo de roles del chatbot multi-tenant del post forense:

• Fabricante del modelo base (Llama 4): AI producer del modelo base.
• Operador del stack OSS (consultora): AI producer del adapter LoRA + AI provider del chatbot a sus clientes + AI customer del modelo base de Meta.
• Cliente final (aseguradora): AI customer del chatbot + AI provider del servicio de atención al cliente.
• Asegurado: AI subject.
• AEPD + autoridad EU AI Act: relevant authority.

Cada caja del cuadro genera obligaciones distintas. La consultora, por ser producer del adapter, debe documentar A.6 (ciclo de vida) y A.7 (datos) del adapter. Por ser provider del chatbot, debe documentar A.10.4 (customers). Por ser customer del modelo base, debe documentar A.10.3 (suppliers) y validar que Meta cumple su parte.

Niveles de impacto y proporcionalidad

42001 no obliga el mismo rigor a todos los sistemas. La cláusula 6.1.2 y el control A.5 introducen el concepto de impacto como modulador. La norma no define categorías taxativas (a diferencia del EU AI Act, que sí define “prohibido / alto riesgo / riesgo limitado / mínimo”), pero recomienda usar niveles según severidad y probabilidad.

La práctica industrial 2026 alinea los niveles 42001 con las categorías del EU AI Act:

Esta proporcionalidad es clave operativa: implantar 42001 al máximo rigor para un sistema de bajo riesgo es desperdicio; relajarla en uno de alto riesgo es incumplimiento.

Los siete documentos mínimos del AIMS

Un auditor en Stage 1 (revisión documental) pide entre siete y diez documentos. Los siete imprescindibles:

1. Política de IA (cláusula 5.2 + A.2.2). 1-2 páginas. Aprobada por dirección, fechada, versionada.
2. Alcance del AIMS (cláusula 4.3). Lista de sistemas IA dentro del alcance, criterios de inclusión.
3. Registro de stakeholders (cláusula 4.2 + A.3.4). Lista mantenida con expectativas.
4. Registro de riesgos AIMS (cláusula 6.1). Riesgos del sistema de gestión, no de cada modelo.
5. Procedimiento de impact assessment (A.5.2) + registros de assessments ejecutados (A.5.3). Procedimiento + uno o varios assessments hechos.
6. Procedimiento de ciclo de vida de IA (A.6.2) — puede ser literalmente “consultar el pipeline LLMOps de seis etapas” con referencias a runbooks técnicos.
7. Procedimiento de gestión de datos (A.7.2) — incluye adquisición, calidad, provenance, preparación, anonimización.

Documentos adicionales habituales:

8. Política de uso responsable (A.9.2) con tipos de uso permitidos/no permitidos.
9. Procedimiento de gestión de terceros AI (A.10.3, A.10.5) con criterios de evaluación de proveedores AI.
10. Plan de auditorías internas + agenda de revisión por dirección (cláusulas 9.2 + 9.3).

Para una organización con stack OSS maduro, los documentos 6 y 7 son referencias a artefactos técnicos ya existentes (runbooks de pipeline, configuraciones de DVC, política de PII en LLM Guard). El esfuerzo documental real está en los documentos 1, 2, 3, 4, 5.

Caso aplicado: el chatbot multi-tenant del blog → checklist 42001

Tomamos el sistema descrito en el post forense —chatbot multi-tenant de atención al cliente para aseguradoras sobre stack OSS on-premise— y lo recorremos como auditor 42001 haría.

Cláusula 4 — Contexto. El alcance del AIMS incluye el chatbot, no incluye el sistema interno de RRHH (otra IA distinta). Stakeholders identificados: aseguradoras cliente, asegurados afectados, AEPD, autoridad EU AI Act (cuando entre en vigor 2 ago 2026), proveedor Meta (modelo base), proveedor de hardware NVIDIA. → Documentado.

Cláusula 5 — Liderazgo. Política de IA firmada por CEO, vigente. Roles asignados: AI lead (CTO), AI risk owner (CISO), data steward (Head of Data), AI ethics committee trimestral. → Documentado.

Cláusula 6 — Planificación. Registro de riesgos AIMS: documentación incompleta, churn del equipo, dependencia de proveedor único de GPU, cambio regulatorio EU AI Act. Objetivos AIMS para 2026: certificación 42001 antes Q4, cumplimiento EU AI Act high-risk antes 2 ago. → Documentado.

Cláusula 7 — Soporte. Recursos: cluster 4×H100 SXM + siete capas del stack. Competencia: 2 MLE + 2 SRE + 1 AI ethics part-time, todos con formación documentada. Comunicación: política de IA en intranet + handbook. → Documentado.

Cláusula 8 — Operación. Procedimientos operativos = pipeline LLMOps de seis etapas. Impact assessment ejecutado antes del despliegue + revisión anual + revisión ante cambio sustancial (definido: cambio de modelo base, cambio de adapter mayor, expansión a nuevo tenant). → Documentado.

Cláusula 9 — Evaluación. Monitoring: Langfuse + Tempo + VictoriaMetrics + Grafana. Métricas obligatorias en dashboard: F1 por categoría guardrail sobre tráfico real, drift estadístico, faithfulness RAG, tasa de refused. Auditoría interna trimestral con criterios escritos. Revisión por dirección semestral con minuta firmada. → Documentado.

Cláusula 10 — Mejora. Tickets de incident-driven retrain mapeados como no-conformidades cuando severity ≥ HIGH. Análisis causa raíz documentado. Eficacia verificada en el siguiente eval gate. → Documentado.

Annex A — Por sección:

• A.2 (Políticas): política de IA + política de uso responsable. → Documentado.
• A.3 (Organización): roles asignados, canal de reporting, registro de stakeholders. → Documentado.
• A.4 (Recursos): siete fases despliegue + catálogo OSS + plan de formación + presupuesto anual. → Documentado.
• A.5 (Impact): procedimiento + assessments por sistema + métricas de fairness aplicadas. → Documentado.
• A.6 (Ciclo de vida): pipeline LLMOps + fine-tuning continuo + retrain. → Documentado.
• A.7 (Datos): data versioning + RAG corpus curation + LLM Guard Vault + Presidio. → Documentado.
• A.8 (Información partes): tracing OTel + Langfuse + spans gen_ai.guardrail.* + notificación a tenants en SLA. → Documentado.
• A.9 (Uso): guardrails + evals + política de uso responsable. → Documentado.
• A.10 (Terceros): OSS vs hyperscalers con análisis de lock-in + contrato Meta para modelo base + contratos con tenants. → Documentado.

Resultado del recorrido: certificable. Los huecos típicos (A.2.2 política escrita, A.3 roles, A.5 procedimiento de impact assessment) están cubiertos como documentos formales. Las cláusulas operativas (8, 9, 10) se apoyan en la arquitectura técnica del blog. La distancia entre “tener la arquitectura” y “tener certificación” se mide en disciplina documental, no en código.

Mapeo cruzado con EU AI Act, NIS2 y ENS

EU AI Act (Reg. 2024/1689) — siete artículos directamente alineados

Las obligaciones principales para sistemas de alto riesgo entran en aplicación el 2 de agosto de 2026. Implantar 42001 ahora construye la base de gestión que ese deadline exige.

Qué falta para cumplimiento EU AI Act que no cubre 42001:

• Conformidad CE de los sistemas de alto riesgo (declaración de conformidad, marcado, registro en EU database).
• Post-market monitoring específico exigido por el Art. 72.
• Reporting de incidentes graves a autoridades en plazos legales (no sólo a usuarios).
• Obligaciones de transparencia a usuarios para sistemas de riesgo limitado (Art. 50): chatbots, deepfakes, contenido generado.
• Prohibiciones del Art. 5 (social scoring, manipulación, biometría en tiempo real con excepciones).

NIS2 (Dir. 2022/2555) — tres pilares con solapamiento

• Asset register (Art. 21.2.f): los sistemas IA en alcance NIS2 deben estar en el inventario de activos. → Solapa con A.4 + cláusula 4.3 (alcance).
• Incident notification (Art. 23): incidentes significativos se notifican en 24 h (alerta inicial) + 72 h (informe detallado). → Solapa con A.3.3 (reporting) + cláusula 10 (improvement).
• Supply chain security (Art. 21.2.d): evaluación de seguridad de la cadena de suministro digital. → Solapa con A.10.3 (suppliers).

Para entidades NIS2 esenciales que además usan sistemas IA, 42001 cubre la parte AI-específica que NIS2 exige inferencialmente pero no detalla.

ENS (RD 311/2022)

El Esquema Nacional de Seguridad español ya contempla expresamente IA en su anexo II (controles ENS). Categorías Básico/Medio/Alto se alinean con niveles de impacto 42001. Los controles ENS de trazabilidad (op.exp.8), registro de actividad (op.exp.10) y gestión de incidentes (op.exp.7) se cubren con los mismos artefactos técnicos que A.8 y A.5 de 42001. Una organización certificada en ENS Categoría Alta con sistemas IA está a un esfuerzo razonable de añadir 42001.

Las cinco trampas habituales de la certificación

Trampa 1 — Confundir 42001 con cumplimiento EU AI Act. Pasar la auditoría 42001 no implica conformidad con el Reglamento europeo. Son universos distintos con solapamiento del 60-70%. La trampa se descubre cuando el cliente pide CE marking del sistema de alto riesgo y la organización presenta sólo el certificado 42001.

Trampa 2 — Sobre-documentar. Manuales de 200 páginas con procedimientos copiados de plantillas, sin medibles ni evidencias de aplicación. El auditor pide la última ejecución del procedimiento — si no hay registros, los procedimientos son ornamento. La regla práctica: prefiere documentos cortos referenciando artefactos técnicos vivos a documentos largos auto-contenidos.

Trampa 3 — Sub-medir. Definir objetivos AIMS sin métricas operativas. “Mejorar la calidad del modelo” es objetivo nulo; “F1 por categoría guardrail ≥ 0,85 sobre tráfico real, medido semanalmente, revisado trimestralmente en management review” es objetivo auditable. El blog ha insistido en esto en cada post de evals, guardrails y retrain.

Trampa 4 — Ignorar A.5 hasta el día del audit. El impact assessment es el control más infravalorado y el primero que pide el auditor. Sin assessments por sistema ejecutados antes del despliegue, no hay forma de demostrar A.5. La trampa se descubre cuando ya no hay tiempo de hacer assessments retrospectivos creíbles.

Trampa 5 — Asumir que 27001 cubre lo AI. Las organizaciones con 27001 ya implantado a veces piensan que “tenemos la mitad hecha”. Es verdad para Annex SL (estructura) y para A.5/A.6/A.7 de 27001 (no de 42001) en lo que se refiere a infosec. Es falso para A.5 de 42001 (impact assessment), A.7 de 42001 (data quality AI-específica), A.9 (uso responsable) y A.10.4 (customers AI). Hay que añadir, no asumir.

Lo que no hemos cubierto (próximos posts)

• Plantillas concretas de los siete documentos obligatorios, con ejemplos de redacción y métricas. Material para un post tipo “Manual del AIMS en 7 documentos” con frame de referencia.
• Mapeo detallado a EU AI Act por artículo con la checklist de evidencias técnicas que se pueden derivar del stack OSS del blog. Especialmente Arts 11 (technical documentation), 14 (human oversight) y 72 (post-market monitoring).
• Caso ENS Categoría Alta + 42001 combinados: qué controles ENS se cubren con qué artefactos del AIMS, evitando duplicidades.
• Comparativa NIST AI RMF 1.0 vs 42001: muchos clientes internacionales piden ambos. Cómo se reciclan los mismos artefactos para satisfacer los dos frameworks.
• 42001 para agentes LLM y MCP: dimensiones nuevas que emergen cuando el sistema IA es agéntico (excessive agency, tool use, autonomía graduada). El post de guardrails introdujo la línea 3 (tool GR); 42001 tiene huecos abiertos en este terreno y la SC 42 trabaja en addendums.

Referencias

• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/81230.html.
• ISO/IEC 22989:2022 — Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. Define los roles AI provider/producer/customer/partner/subject.
• ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. Insumo de A.5.
• ISO/IEC 38507:2022 — Governance implications of the use of AI by organizations. Complemento de gobierno.
• ISO/IEC 5259 — Data quality for analytics and machine learning (familia). Insumo de A.7.
• EU AI Act (Regulation 2024/1689) — texto consolidado en EUR-Lex. Entrada en vigor de obligaciones de alto riesgo: 2 ago 2026.
• NIS2 (Directive 2022/2555) — texto consolidado en EUR-Lex.
• ENS — Real Decreto 311/2022 — Esquema Nacional de Seguridad, BOE-A-2022-7191.
• NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
• EUR-Lex EU AI Act consolidated text — https://eur-lex.europa.eu/eli/reg/2024/1689.
• A-LIGN / BSI / Schellman — blogs sobre experiencia de auditoría 42001 con casos reales 2024-2025.

Ver también

• El pipeline LLMOps de seis etapas — el procedimiento operativo que materializa A.6 ciclo de vida sin trabajo adicional.
• Anatomía de una petición LLM en producción — el caso forense recorrido como checklist 42001 en la sección “caso aplicado” de este post.
• Siete capas del stack de inferencia LLM on-premise y siete fases del despliegue — material directo para A.4 recursos.
• Cinco niveles de madurez de la plataforma — cómo justificar la proporcionalidad de los controles según el nivel de madurez existente.
• Data versioning con DVC y lakeFS y RAG corpus curation — A.7 datos cubierto al detalle.
• Tracing LLM con OpenTelemetry GenAI — A.8 información a partes interesadas a través de trazabilidad estandarizada.
• Guardrails y safety en LLMs y LLM Guard — A.9 uso responsable.
• Evals: la capa después del tracing y LLM-as-judge — A.6.2.5 verification and validation.
• Retrain: cerrar el bucle feedback → dataset → adapter — cláusula 10 mejora continua + bucle incident-driven que alimenta no-conformidades formales.
• El catálogo paralelo: OSS vs hyperscalers — A.10.3 evaluación de proveedores con análisis estructural de lock-in y soberanía contractual; insumo directo del registro de proveedores AI.
• El catálogo OSS para LLMOps — A.10.5 inventario de terceros OSS con licencia, gobierno y madurez documentados.
• MLOps específico para LLMs en 2026: panorama — contexto operativo en el que el AIMS opera y se audita.
• EU AI Act: el expediente técnico artículo por artículo — el post hermano sobre el Reglamento UE 2024/1689; baja del sistema de gestión a las obligaciones legales directamente aplicables, con plazos, sanciones y mapeo control-a-artículo.
• Controles técnicos: el mapeo cruzado ENS × ISO 42001 × EU AI Act — el tercer post de la trilogía de gobernanza; baja al detalle de los 25 controles técnicos comunes a los tres marcos con la tabla maestra de cumplimiento triple y el etiquetado de evidencia.
• Runbooks de incident response para LLM con Keep + Kafka — la materialización operativa de la cláusula 10 (mejora continua) y la traza WORM que A.8.2 exige: cada incidente abre no-conformidad, dispara postmortem, actualiza el runbook y queda registrado en audit.actions Kafka.