ISO 42001, NIST AI RMF y el Reglamento de IA: conecte sus funciones

La gobernanza de la IA puede combinar un sistema de gestión, un marco de riesgos y obligaciones jurídicas. El reto de ingeniería consiste en conectarlos sin fingir que son intercambiables. Una política, un informe de evaluación y una decisión de clasificación jurídica pueden respaldar el mismo servicio de IA, pero cada uno responde a una pregunta distinta.

ISO/IEC 42001 establece cómo gestiona una organización la IA. El AI Risk Management Framework del NIST ayuda a los equipos a investigar y gestionar los riesgos en su contexto. El Reglamento de IA de la UE establece obligaciones jurídicas en función del sistema, de su finalidad prevista y del rol de la organización como operador.

Para un CTO, el resultado útil es una única cadena de gobernanza revisable: un caso de uso definido, responsables que rinden cuentas, salvaguardas implantadas, evidencias de pruebas, decisiones de puesta en producción y monitorización. Las correspondencias entre marcos deben apuntar a esa cadena y, al mismo tiempo, conservar los requisitos que todavía exigen trabajo técnico, jurídico o relacionado con la conformidad.

Entienda qué establece cada instrumento

ISO 42001: haga repetible la gobernanza

ISO/IEC 42001 especifica los requisitos para establecer, implementar, mantener y mejorar continuamente un SGIA. Sus requisitos de sistema de gestión abarcan el contexto de la organización, el liderazgo, la planificación, el apoyo, la operación, la evaluación del desempeño y la mejora.

Esta estructura importa cuando varios equipos desarrollan o compran IA. Proporciona una base para decidir quién autoriza el despliegue, cómo se realizan las evaluaciones de impacto y de riesgos, cómo se gestionan las dependencias de proveedores y cómo los fallos dan lugar a acciones correctivas.

La norma incluye también controles de referencia en el anexo A y orientaciones de implementación. La selección de controles se basa en el riesgo y requiere una justificación documentada; copiar el anexo en una lista de comprobación no demuestra que el sistema de gestión funcione.

Un organismo de certificación independiente puede evaluar el SGIA dentro de su alcance. ISO no certifica organizaciones. La certificación proporciona aseguramiento sobre ese sistema de gestión dentro de los límites declarados, no una afirmación ilimitada de que cada modelo o cada resultado sea seguro.

NIST AI RMF: investigue el riesgo real

El NIST AI RMF organiza el trabajo sobre riesgos en torno a Govern, Map, Measure y Manage (gobernar, mapear, medir y gestionar). Govern es transversal; las funciones no son simplemente cuatro fases secuenciales de un proyecto.

Sus características de fiabilidad incluyen la validez y la fiabilidad, la seguridad física, la seguridad y la resiliencia, la rendición de cuentas y la transparencia, la explicabilidad y la interpretabilidad, la mejora de la privacidad y la equidad con gestión de los sesgos perjudiciales. Estas características pueden implicar compensaciones. Por ejemplo, unas explicaciones más detalladas pueden revelar información que requiere protección de la privacidad.

La guía del NIST ayuda a los equipos a convertir objetivos amplios en preguntas y evaluaciones específicas de cada caso de uso. También aborda la rendición de cuentas; la gobernanza no es exclusiva de ISO 42001. No existe un esquema de certificación del NIST AI RMF comparable a la certificación de sistemas de gestión ISO. Una evaluación externa puede contribuir al aseguramiento, pero deben indicarse su alcance y su metodología.

El Reglamento de IA: determine obligaciones, no solo riesgos

El Reglamento de IA de la UE regula determinadas prácticas, sistemas de IA y modelos de IA de uso general mediante disposiciones diferentes. La aplicabilidad jurídica no se determina únicamente con una puntuación técnica de riesgo. Importan la finalidad prevista, el ámbito territorial, el rol del operador y las normas de clasificación específicas.

Las obligaciones de un proveedor difieren de las de un responsable del despliegue. Un modelo no es lo mismo que la aplicación que lo incorpora, y llamar «agente» a un software no resuelve su rol ni su clasificación jurídica.

Empiece por el alcance y la aplicabilidad jurídica

Mantenga un inventario de IA al nivel de los casos de uso operativos, no solo de los nombres de los proveedores. Un mismo modelo subyacente puede dar soporte tanto a un asistente interno de redacción como a una herramienta de selección de personal. Esos despliegues tienen personas afectadas, consecuencias, controles y posibles obligaciones diferentes.

Para cada caso de uso, registre:

• La finalidad prevista, las decisiones a las que da soporte, los usos prohibidos y los lugares de despliegue.
• El responsable del sistema, el responsable técnico, los usuarios y las personas afectadas.
• Los proveedores del modelo y de la aplicación, las condiciones de alojamiento y las dependencias.
• Las fuentes de datos, los resultados, las integraciones y las acciones permitidas.
• El rol de la organización como operador y el razonamiento que lo sustenta.
• La clasificación, las obligaciones aplicables, la fecha de revisión y las cuestiones pendientes.

Una organización establecida fuera de la UE puede quedar dentro del ámbito de aplicación del Reglamento en determinadas circunstancias. A la inversa, tener clientes en la UE no justifica atribuir todas las obligaciones posibles a todos los productos. Revise las condiciones territoriales y de rol reales.

Separe las prácticas prohibidas, los requisitos de los sistemas de alto riesgo, las obligaciones de transparencia específicas y las obligaciones de los modelos de IA de uso general. No son niveles intercambiables de una única escala de gravedad de ingeniería. Un chatbot de aparente bajo impacto puede tener obligaciones de transparencia; un caso de uso de alto impacto requiere una evaluación jurídica más detallada.

Utilice el calendario de aplicación vigente

La presentación general del Reglamento de IA de la Comisión Europea, consultada a 7 de octubre de 2026, ofrece el siguiente calendario:

Evalúe por separado las disposiciones modificadas, el régimen transitorio y el sistema concreto. No aplace obligaciones que ya son aplicables porque exista una fecha posterior para el alto riesgo. Mantenga fechada la evaluación jurídica y utilice nuestra guía de preparación para el Reglamento de IA como contexto sobre el calendario y la evaluación de roles.

Construya una única cadena de evidencias, no tres bibliotecas documentales

Una cadena de gobernanza práctica empieza por el caso de uso y termina con una decisión revisada:

Finalidad → impactos y riesgos → requisitos → salvaguardas → evaluaciones → aprobación → monitorización.

Cada eslabón necesita el detalle suficiente para que alguien ajeno al equipo de implementación pueda examinarlo. «Supervisión humana implantada» es insuficiente si el revisor no puede determinar quién puede intervenir, qué ve y si la intervención funciona.

Utilice un registro de requisitos que distinga el requisito de origen de su implementación. Un esquema mínimo útil incluye la fuente y su versión, el alcance, el texto o la referencia del requisito, la interpretación local, el responsable del control, las evidencias vinculadas, el revisor, el estado y la brecha residual.

Trate esta tabla como una ayuda para la implementación, no como un mapa de equivalencias autorizado. Las relaciones son de muchos a muchos: una evaluación puede respaldar varios requisitos, mientras que un requisito puede necesitar varios controles y registros.

Antes de reutilizar evidencias, compruebe su alcance, su fecha, la versión del sistema y la conclusión. Una prueba realizada con una configuración del modelo no puede respaldar automáticamente otra configuración. Una política corporativa demuestra que existe una norma documentada; se necesitan registros operativos para demostrar su ejecución.

Utilice las funciones del NIST para definir el trabajo de ingeniería

Las funciones del NIST ofrecen una forma útil de organizar las preguntas de implementación dentro del SGIA. Deben producir artefactos concretos, no solo campos de cuestionario completados.

Govern: establezca la autoridad de decisión

Defina quién es responsable del sistema, quién revisa de forma independiente los riesgos significativos y quién puede aprobar excepciones o detener el despliegue. Especifique los requisitos de competencia y las vías de escalado. Vincule estas responsabilidades con los procesos existentes de seguridad, privacidad, compras y gestión de incidentes.

Un entregable útil es un procedimiento de puesta en producción que identifique a los revisores y las evidencias necesarios. La aceptación del riesgo debe indicar quién toma la decisión, la justificación, las condiciones y el desencadenante de revisión, en lugar de limitarse a registrar «aceptado».

Map: describa el contexto y las consecuencias

Documente el flujo de trabajo antes de elegir las métricas. Identifique dónde influye la IA en las decisiones, quién sufre las consecuencias y qué ocurre cuando los resultados son erróneos, no están disponibles o se utilizan indebidamente.

Incluya el uso indebido previsible y los fallos de las dependencias. En el caso de un agente que puede ejecutar acciones, mapee las herramientas, las credenciales, los datos accesibles, los límites de aprobación y las vías de recuperación. En el caso de una IA de terceros, registre qué controla el proveedor y qué sigue siendo responsabilidad suya.

Measure: pruebe las afirmaciones que importan

Elija evaluaciones vinculadas a los riesgos identificados. Según el caso de uso, pueden incluir la precisión en la tarea, el rendimiento por subgrupos, la robustez, la fuga de datos personales, la inyección de prompts, las acciones no autorizadas y la comprensión por parte de los operadores.

Documente la procedencia de los conjuntos de datos, su representatividad, las condiciones de prueba, las métricas, las limitaciones y los umbrales de aceptación. Mida la aplicación completa siempre que sea posible: la recuperación de información, los prompts, los permisos, las interfaces y el flujo de trabajo humano pueden cambiar los resultados aunque el modelo subyacente no varíe.

Manage: implante el tratamiento y el seguimiento

Traduzca los hallazgos en salvaguardas, restricciones, subsanaciones o la decisión de no desplegar. Algunos ejemplos son reducir los permisos de las herramientas, exigir aprobación para las acciones con consecuencias, excluir los usos no admitidos u ofrecer una alternativa fiable sin IA.

Fije umbrales de monitorización y procedimientos de respuesta. Una métrica sin responsable ni regla de respuesta es solo telemetría. Registre qué eventos desencadenan una nueva evaluación, incluidas las actualizaciones del proveedor, los cambios en las fuentes de datos, la ampliación de los usos y los incidentes.

Haga auditable ISO 42001 mediante registros operativos

Si la certificación es un objetivo, defina los límites del SGIA antes de prepararse para una auditoría externa. El alcance puede abarcar un producto concreto, una unidad de negocio o un conjunto de actividades del ciclo de vida, pero debe describir con claridad las actividades y las interfaces incluidas. Un alcance reducido no debe presentarse como un aseguramiento de toda la organización.

Realice un análisis de brechas frente a los requisitos del sistema de gestión y los controles aplicables. Establezca la política, los objetivos, los métodos de evaluación de riesgos y de impacto, la aplicabilidad documentada de los controles, las responsabilidades y los procedimientos operativos. Después, genere evidencias de que estos procesos funcionan realmente.

Entre los registros útiles figuran las evaluaciones completadas, las revisiones de proveedores, los registros de formación, las aprobaciones de puesta en producción, las revisiones de la monitorización, las acciones correctivas, los hallazgos de la auditoría interna y las decisiones de la revisión por la dirección. La auditoría interna y la revisión por la dirección son actividades distintas: la primera evalúa la conformidad y la eficacia; la segunda apoya la evaluación y la orientación del sistema de gestión por parte de la dirección.

Un proceso de certificación independiente suele incluir fases de evaluación de la preparación y de la implementación. Acuerde el alcance y las condiciones de auditoría con el organismo de certificación en lugar de tratar la certificación como la presentación de un expediente. Mantenga la monitorización, la revisión interna y la mejora después de la certificación.

Ni un certificado ni una evaluación conforme al RMF sustituyen a una evaluación de la conformidad aplicable con arreglo al Reglamento de IA. La vía de conformidad depende del sistema y de las disposiciones pertinentes; no todos los sistemas de alto riesgo requieren la misma vía con intervención de terceros. Del mismo modo, los requisitos de declaración, registro, marcado y notificación deben comprobarse para el rol y el sistema pertinentes.

Ejemplo práctico: un despliegue de IA relacionado con la contratación

Supuestos ilustrativos: un empleador de la UE compra una aplicación que clasifica a los candidatos para su revisión antes de las entrevistas. El proveedor suministra la aplicación, mientras que el empleador configura los criterios del puesto y utiliza las clasificaciones. Los reclutadores toman las decisiones finales de contratación. Supongamos que la revisión jurídica identifica un uso de alto riesgo en el ámbito del empleo según el anexo III y considera inicialmente al empleador como responsable del despliegue.

Esto no se resuelve diciendo que «una persona toma la decisión final». La clasificación puede influir sustancialmente en quién recibe consideración. La evaluación debe examinar el flujo de trabajo real, incluido si los reclutadores ignoran sistemáticamente a los candidatos situados por debajo de un umbral.

Establezca el registro específico del sistema

El responsable técnico registra los campos de entrada, la información sobre la lógica de clasificación que facilita el proveedor, la versión de la aplicación, la configuración, los usuarios y los destinos de exportación. El área de compras solicita al proveedor las instrucciones, las limitaciones, las evidencias de evaluación pertinentes, las notificaciones de cambios y el apoyo para cumplir las obligaciones de la organización.

La revisión jurídica documenta la clasificación y los supuestos de rol, incluido si una modificación o un cambio de marca futuros podrían alterar el rol. La revisión de privacidad evalúa por separado el tratamiento de los datos de los candidatos. La gobernanza de la IA no sustituye al análisis de protección de datos.

Pruebe e implante las salvaguardas

Con las funciones Map y Measure del NIST, el equipo evalúa escenarios de selección representativos, el comportamiento ante datos ausentes y las diferencias de rendimiento entre los grupos pertinentes, cuando sea lícito y viable. Documenta la incertidumbre y las limitaciones de la muestra en lugar de presentar una métrica de equidad como prueba de que han desaparecido todos los sesgos perjudiciales.

La supervisión humana incluye la formación de los reclutadores, la visibilidad de las limitaciones, una vía para revisar las candidaturas excluidas y la posibilidad de suspender la clasificación. El equipo comprueba si los revisores entienden los resultados y pueden anularlos sin obstáculos operativos.

Los controles de seguridad restringen el acceso a los registros de los candidatos e impiden exportaciones no aprobadas. El control de cambios exige una nueva evaluación cuando cambian los criterios de clasificación, los modelos o las condiciones de tratamiento del proveedor.

Mantenga separadas las tres conclusiones

El registro del SGIA demuestra cómo funcionaron las evaluaciones, las responsabilidades, la revisión de proveedores y los procesos de aprobación. El registro del RMF explica los riesgos contextuales, las pruebas, el tratamiento y la incertidumbre residual. El registro jurídico identifica las obligaciones aplicables al responsable del despliegue, los plazos y el trabajo pendiente.

Supongamos que el proveedor no ha facilitado instrucciones suficientes para una supervisión fiable. El registro de puesta en producción debe mostrar esa carencia, su responsable y la decisión de retrasar o restringir el despliegue, no un estado verde heredado del certificado ISO del empleador.

Fije prioridades y mantenga las evidencias después de la puesta en producción

Priorice primero las obligaciones jurídicas aplicables y los riesgos operativos inaceptables. La certificación ISO puede avanzar en paralelo a la subsanación, pero un objetivo de auditoría no debe desplazar a los controles urgentes.

Si los equipos carecen de responsabilidades y procesos de revisión coherentes, construya la base del SGIA. Si la gobernanza existe pero las evaluaciones de los sistemas son débiles, utilice el RMF para mejorar el análisis contextual y las pruebas. Si un cliente exige una certificación, confirme el alcance esperado antes de presupuestar.

Evite suposiciones universales sobre costes o plazos. El esfuerzo depende del número de sistemas, de la gobernanza existente, de las necesidades de evaluación, de la visibilidad sobre los proveedores y de la subsanación. El RMF es de libre acceso, pero su implementación sigue consumiendo tiempo del personal; la certificación ISO añade consideraciones sobre el acceso a la norma y la evaluación externa.

Después de la puesta en producción, asigne desencadenantes de revisión a los artefactos. Una actualización del modelo del proveedor puede invalidar los resultados de la evaluación; un nuevo permiso de acción puede cambiar el modelo de amenazas; un nuevo mercado puede requerir una nueva evaluación jurídica. Conserve las versiones y decisiones anteriores para que los revisores puedan reconstruir qué se aprobó en cada momento.

Entre los errores habituales figuran tratar las correspondencias como cumplimiento, reunir políticas sin evidencias operativas, aceptar las afirmaciones de los proveedores sin un análisis específico del despliegue y registrar el riesgo residual sin un responsable de la decisión. Otro es medir la calidad del modelo ignorando los permisos de la aplicación y el comportamiento humano.

Secani puede dar soporte al flujo de evidencias vinculando requisitos, controles, material de origen, responsables, tareas y decisiones revisadas. Empiece con un alcance definido, adjunte las evidencias a aquello que respaldan y convierta el material ausente u obsoleto en trabajo asignado. Trate las sugerencias asistidas por IA como borradores: una persona debe revisar las correspondencias y las conclusiones, y deben conservarse las fuentes y el razonamiento de la aprobación. Así, la base de la gobernanza sigue siendo examinable sin sustituir el criterio técnico ni jurídico.

Preguntas que afectan a la implementación

¿Se pueden reutilizar los controles de seguridad existentes?

Sí, cuando su implementación y sus evidencias cubren el despliegue de IA. El control de acceso, la respuesta a incidentes y la gestión de proveedores suelen contribuir. Por sí solos, no responden a las preguntas sobre los sesgos perjudiciales, la finalidad prevista o la eficacia de la supervisión humana.

¿Y si un proveedor no revela el funcionamiento interno del modelo?

Registre la limitación de visibilidad. Busque evidencias proporcionadas al caso de uso, evalúe la aplicación desplegada y determine si son necesarias garantías contractuales, restricciones o proveedores alternativos. La falta de visibilidad no es automáticamente aceptable porque el servicio esté disponible comercialmente.

¿Qué debe hacer primero el equipo?

Elija un caso de uso con consecuencias relevantes y reúna su responsable, su finalidad, la evaluación del rol, el registro de riesgos, las salvaguardas, las pruebas y la aprobación. Revise las brechas en los tres instrumentos. Ese ejercicio acotado revela si la organización necesita una mejor gobernanza, mejores evidencias técnicas o resolver trabajo jurídico pendiente antes de ampliar el alcance.