ISO/IEC 42001:2023 establece requisitos para crear, mantener y mejorar un sistema de gestión de inteligencia artificial. Sirve tanto a organizaciones que desarrollan IA como a las que la proporcionan o utilizan. Una pyme no necesita reproducir la burocracia de una multinacional: necesita un alcance claro, inventario fiable, decisiones basadas en riesgo, responsables y evidencias proporcionales.
Qué es un sistema de gestión de IA
Un AIMS —Artificial Intelligence Management System— conecta política, objetivos, procesos, personas, datos, tecnología, proveedores, evaluación y mejora dentro de un sistema de gestión de IA conforme a ISO/IEC 42001. No certifica que cada salida sea correcta ni sustituye la ley: demuestra que la organización gobierna la IA mediante un sistema auditable.
ISO/IEC 42001 sigue la estructura de otras normas de gestión, lo que facilita integrarla con ISO 9001, ISO/IEC 27001 o ISO 14001.
Para quién tiene sentido
Puede aportar valor cuando la pyme:
- desarrolla productos o componentes de IA;
- integra modelos de terceros en servicios;
- utiliza IA en procesos relevantes;
- responde a requisitos de clientes o licitaciones;
- necesita coordinar AI Act, RGPD, seguridad y calidad;
- quiere una certificación independiente.
No conviene buscar certificación solo por marketing. Primero debe existir un caso de negocio y capacidad de mantener el sistema.
Paso 1. Definir alcance
El alcance identifica entidades, ubicaciones, productos, procesos y roles. «Toda la IA de la empresa» puede ser inmanejable; «desarrollo y operación del asistente documental para clientes en España» es verificable.
Debe evitarse excluir dependencias críticas: datos, plataforma, proveedores, seguridad o soporte. Las interfaces con áreas fuera del alcance se documentan.
Preguntas clave para acotar el alcance:
- ¿Desarrollamos, proporcionamos o usamos IA?
- ¿Qué sistemas generan mayor impacto?
- ¿Qué clientes y personas están afectados?
- ¿Qué obligaciones contractuales y legales existen?
- ¿Qué equipo puede sostener el sistema?
Paso 2. Contexto y partes interesadas
Se analizan cuestiones internas y externas: estrategia, regulación, madurez, dependencia de proveedores, competencias, disponibilidad de datos, ciberseguridad y expectativas sociales.
Las partes interesadas pueden incluir clientes, usuarios, personal, personas afectadas, reguladores, proveedores, accionistas y sociedad. Se registran requisitos relevantes y cómo se revisan.
No toda expectativa se convierte en obligación, pero debe justificarse la selección.
Paso 3. Inventario de sistemas de IA
El inventario es la columna vertebral. Cada ficha contiene:
- nombre, propietario y versión;
- finalidad y decisiones;
- rol de la organización;
- usuarios y personas afectadas;
- modelos, datos y herramientas;
- proveedor y subproveedores;
- entorno y ubicaciones;
- autonomía y supervisión;
- clasificación jurídica y de riesgo;
- métricas, incidentes y estado.
También se registra IA «en sombra»: cuentas personales, funciones embebidas y automatizaciones no aprobadas.
Paso 4. Política y gobierno
La política debe ser específica: principios, usos prohibidos, criterios de aprobación, responsabilidades y compromiso de mejora. No basta declarar «IA ética».
Una estructura RACI orientativa:
| Decisión | Aprueba | Ejecuta | Asesora |
|---|---|---|---|
| Incorporar sistema | Dirección/comité | Propietario | Legal, seguridad y privacidad |
| Aceptar riesgo | Nivel definido | Propietario | AIMS |
| Cambiar modelo | Propietario autorizado | Equipo técnico | Riesgo y seguridad |
| Gestionar incidente | Responsable designado | Operación | DPO/legal/comunicación |
| Retirar sistema | Dirección/propietario | Operación | Partes afectadas |
La pyme puede usar un comité pequeño, pero debe evitar decisiones sin dueño.
Paso 5. Riesgos y oportunidades
El método cubre daños y oportunidades para organización, personas y sociedad. Debe contemplar:
- resultados incorrectos;
- discriminación y accesibilidad;
- falta de transparencia;
- privacidad y propiedad intelectual;
- seguridad y uso malicioso;
- dependencia y continuidad;
- impacto laboral y humano;
- costes y consumo de recursos;
- beneficio esperado y no realizado.
Cada riesgo tiene causa, evento, impacto, probabilidad, control, responsable y riesgo residual. Los umbrales de aceptación se aprueban antes de evaluar.
Paso 6. Evaluación de impacto
La evaluación de impacto analiza efectos del sistema y usos previsibles sobre individuos, grupos y sociedad. Se coordina con EIPD, FRIA, seguridad o sostenibilidad para no duplicar.
Debe incluir personas indirectamente afectadas, usos no previstos razonablemente previsibles, fallos, beneficios, distribución de impactos y canales de reclamación.
ISO/IEC 42005 aporta guía específica y puede integrarse en el AIMS.
Paso 7. Ciclo de vida
El sistema debe controlar:
- concepción y requisitos;
- adquisición o diseño;
- datos y desarrollo;
- validación;
- despliegue;
- monitorización;
- cambios;
- retirada.
Cada puerta tiene criterios. Por ejemplo, no pasar a producción sin pruebas, propietario, documentación, supervisión, incidentes y rollback.
Datos y calidad
El gobierno de datos cubre procedencia, licitud, calidad, representatividad, etiquetado, acceso, conservación y limitaciones. Para RAG incluye documentos e índices; para modelos de terceros, entradas, salidas y telemetría.
La pyme debe documentar qué no conoce. La ausencia de información del proveedor es un riesgo que puede exigir restricciones.
Proveedores
La diligencia debida revisa:
- documentación y finalidad prevista;
- seguridad, privacidad y ubicaciones;
- uso de datos para entrenamiento;
- subproveedores;
- métricas y limitaciones;
- cambios de versión;
- incidentes;
- exportación y salida.
El contrato debe asignar responsabilidades y notificación. No se puede externalizar la rendición de cuentas.
Objetivos y métricas
Los objetivos deben medir resultados, no solo actividades. Ejemplos:
- 100 % de sistemas inventariados y con propietario;
- cero acciones críticas sin autorización;
- reducción de respuestas sin fuente;
- tiempo máximo de retirada de credenciales;
- porcentaje de cambios con regresión;
- cierre de incidentes dentro de SLA.
Cada métrica necesita definición, fuente, frecuencia, umbral y acción.
Competencia y alfabetización
La formación varía por rol. Dirección necesita riesgo y responsabilidad; desarrollo, evaluación y seguridad; usuarios, límites y verificación; compras, diligencia; DPO y legal, impacto y derechos.
La evidencia debe demostrar competencia, no asistencia: ejercicios, pruebas, observación o revisión de decisiones.
Documentación mínima viable
Una pyme puede mantener:
- alcance y contexto;
- política y objetivos;
- inventario;
- metodología de riesgo e impacto;
- procedimientos de aprobación, cambio e incidente;
- evaluación de proveedores;
- métricas y registros;
- auditoría interna;
- revisión por dirección;
- acciones correctivas.
No se crean documentos duplicados si ya existen controles en ISO 9001 o 27001; se referencian e integran.
Auditoría interna
La auditoría debe comprobar evidencia real:
- ¿Hay sistemas fuera del inventario?
- ¿La clasificación coincide con el uso?
- ¿Los controles reducen el riesgo?
- ¿Los cambios se prueban?
- ¿La supervisión puede detener?
- ¿Los incidentes generan aprendizaje?
- ¿Dirección toma decisiones con resultados?
La persona auditora debe ser objetiva y no auditar su propio trabajo.
Revisión por dirección
Dirección revisa contexto, objetivos, auditorías, incidentes, desempeño, cambios, recursos y oportunidades. La salida debe contener decisiones: prioridades, aceptación de riesgo, recursos y cambios.
Certificación
La certificación normalmente incluye etapa 1 —preparación documental y alcance— y etapa 2 —implantación y eficacia—, seguida de vigilancia. El organismo debe ser competente y operar bajo el esquema aplicable.
No se anuncia certificación antes de obtenerla ni se extiende a productos fuera del alcance.
Plan de 120 días
Días 1–30
Alcance, contexto e inventario. Política, roles y metodología. Brecha frente a requisitos.
Días 31–60
Riesgos e impactos prioritarios. Proveedores y ciclo de vida. Controles y métricas.
Días 61–90
Implantación, formación y registros. Pruebas e incidentes. Seguimiento de objetivos.
Días 91–120
Auditoría interna. Acciones correctivas. Revisión por dirección. Preparación de certificación.
El plazo depende de alcance y madurez; no es una garantía.
Errores frecuentes
- Certificar un alcance que no representa el negocio.
- Inventariar solo modelos propios.
- Copiar una política genérica.
- Separar compliance y equipo técnico.
- Medir actividades en vez de resultados.
- No controlar cambios del proveedor.
- Duplicar ISO 27001 y 9001.
- Hacer impacto al final.
- Auditar sin evidencia suficiente.
- Tratar el certificado como final del proceso.
Checklist
- Alcance verificable.
- Inventario completo con propietarios.
- Política, roles y escalado.
- Riesgo e impacto por sistema.
- Ciclo de vida y puertas de control.
- Datos y proveedores gobernados.
- Métricas con umbrales.
- Competencia por rol.
- Incidentes, cambios y retirada probados.
- Auditoría y revisión por dirección.
Preguntas frecuentes
¿ISO 42001 es obligatoria?
Es una norma voluntaria, salvo exigencia contractual o sectorial. No sustituye obligaciones legales.
¿Sirve solo a desarrolladores?
No. La norma indica que aplica a organizaciones que desarrollan, proporcionan o utilizan IA.
¿Certifica un producto?
Certifica el sistema de gestión dentro de un alcance, no que todas las salidas del producto sean correctas.
¿Puede integrarse con ISO 27001?
Sí. Comparten estructura y controles de gobierno, riesgo, auditoría y mejora, aunque sus objetos son distintos.
Summum Calidad puede acompañar el alcance, la implantación, la auditoría interna y la preparación para la certificación de ISO/IEC 42001, coordinada cuando sea necesario con la evaluación de impacto de IA (ISO/IEC 42005), sin sustituir en ningún caso al organismo certificador.