El catálogo de controles de IA
Los 66 controles en cuatro bloques, las normas que los anclan y lo que se dejó fuera a propósito.
De 22 a 66
El bloque nació con 22 controles derivados del NIST AI RMF 1.0, todos de gobernanza: política, roles, inventario, cumplimiento. Auditado contra la CSA AICM y la ISO/IEC 42001, aparecieron dos lagunas de naturalezas distintas.
Faltaba superficie técnica. No había ningún control sobre separación entre instrucción y dato, guardrails, aislamiento de ejecución de herramienta, frontera de agente, integridad de artefacto de modelo o envenenamiento de datos — que es donde vive el riesgo explotable al evaluar a un proveedor de IA.
Y faltaba el sistema de gestión. Las cláusulas 4 a 10 de la ISO 42001 exigen un sistema de gestión de IA — contexto, liderazgo, objetivos, auditoría interna, revisión por la dirección. El catálogo tenía los controles de riesgo y no tenía el sistema que los sostiene.
Bloque | Controles | Ancla |
|---|---|---|
ARC01–22 | 22 | NIST AI RMF 1.0 |
ARC23–38 | 16 | CSA AICM — superficie técnica |
ARC39–47 | 9 | ISO/IEC 42001 Anexo A |
ARC48–66 | 19 | ISO/IEC 42001 cláusulas 4–10 |
La cobertura final de la ISO 42001 es de 23 de 23 cláusulas y 36 de los 38 controles del Anexo A.
Dos exclusiones deliberadas
Dos controles del Anexo A quedan fuera cuando la dirección es evaluar a un proveedor: especificación de requisitos del sistema de IA y preparación de datos. Son internos al proveedor y producen evidencia débil cuando se piden desde fuera.
Están registrados como laguna con justificación explícita, no como agujero silencioso. Y vuelven cuando la dirección es autoevaluación — una Declaración de Aplicabilidad tiene que abordar los 38.
Por qué ninguna norma sola bastaría
Cuatro controles tienen ancla en el AI RMF y ninguna en la ISO 42001: cumplimiento regulatorio de IA, escenario adversarial, explicabilidad y desactivación rápida de modelo. En la dirección opuesta, el AI RMF 1.0 no tiene subcategoría para amenaza adversarial — fue la AICM la que llenó esa laguna.
Es el argumento concreto contra adoptar un solo framework: elegir un framework es elegir qué parte del riesgo no ver.
Una limitación conocida
Con 66 controles el bloque dejó de ser homogéneo: 19 son de sistema de gestión, 16 de superficie técnica y el resto se reparte entre transparencia, datos de entrenamiento y cadena. Preguntar los 66 a cualquier proveedor no es viable, y los 19 de sistema de gestión solo tienen sentido para quien se propone tener un programa formal de IA — no para un SaaS que consume una API de terceros.
Falta un eje de alcance por papel en la cadena de IA — consumidor de API, operador de modelo, proveedor de modelo — ortogonal al perfil de criticidad. Está registrado como pendiente de metodología.