ISO/IEC 23894 explicado: cómo gestionar riesgos específicos de IA
Una organización puede tener un proceso de gestión de riesgos sólido y, aun así, pasar por alto riesgos importantes de inteligencia artificial. El problema no suele ser que la organización haya olvidado conceptos como probabilidad, impacto o tratamiento. El problema es que la IA cambia qué debe observarse, quién puede verse afectado y con qué frecuencia debe revisarse el riesgo.
Un modelo puede degradarse sin que cambie el proceso de negocio. Un proveedor puede modificar un servicio sin que la organización controle el cambio. Un sistema puede cumplir su objetivo técnico y, al mismo tiempo, producir efectos no deseados sobre clientes, empleados u otros grupos. Y una aplicación inicialmente de bajo impacto puede volverse material cuando aumenta su escala o cambia su propósito.
ISO/IEC 23894:2023 existe para cerrar esa brecha. No sustituye la gestión de riesgos empresarial ni crea un universo separado para la IA. Su función es ayudar a las organizaciones a integrar consideraciones específicas de IA en sus actividades y procesos de gestión de riesgos.
ISO/IEC 23894 no es un sistema de gestión ni una certificación
La primera distinción importante es de propósito.
ISO/IEC 23894 es una norma de orientación sobre gestión de riesgos de IA. ISO la dirige a organizaciones que desarrollan, producen, despliegan o utilizan productos, sistemas y servicios que emplean inteligencia artificial. La guía puede adaptarse al contexto de cada organización y está concebida para utilizarse junto con ISO 31000:2018, el marco general de gestión de riesgos.
Esto cambia la forma en que un auditor debe utilizarla. ISO/IEC 23894 no debería convertirse automáticamente en una lista de requisitos de conformidad. Su valor está en enriquecer el método de riesgo: ampliar las fuentes consideradas, mejorar el análisis de consecuencias, conectar el riesgo con el ciclo de vida de la IA y reforzar el monitoreo.
La relación con ISO/IEC 42001:2023 también es complementaria. ISO/IEC 42001 establece requisitos para un sistema de gestión de IA y exige procesos de evaluación y tratamiento del riesgo. La propia norma remite a ISO/IEC 23894 como orientación para implementar la gestión de riesgos de IA. En términos prácticos:
| Marco | Pregunta principal |
|---|---|
| ISO 31000 | ¿Cómo debe integrarse y operar la gestión de riesgos en una organización? |
| ISO/IEC 23894 | ¿Qué cambia cuando el objeto del riesgo incluye sistemas y actividades de IA? |
| ISO/IEC 42001 | ¿Qué requisitos debe cumplir un sistema de gestión para gobernar la IA de forma sistemática? |
La diferencia importa porque una organización puede utilizar ISO/IEC 23894 sin implantar un sistema certificable bajo ISO/IEC 42001. Y un auditor puede utilizarla como referencia profesional sin presentar cada orientación como obligación.
La IA amplía el objeto de la evaluación de riesgos
Una evaluación de riesgos tradicional puede comenzar con el proceso: ¿qué puede impedir que compras, crédito, recursos humanos o atención al cliente alcancen sus objetivos?
Con IA, esa pregunta sigue siendo válida, pero ya no es suficiente.
El análisis debe considerar cómo el sistema aprende o genera resultados, de qué datos depende, quién lo proporciona, cómo se utiliza, qué decisiones influye, qué personas pueden verse afectadas y cómo cambia con el tiempo. La unidad de análisis deja de ser únicamente el proceso y pasa a incluir un sistema sociotécnico: tecnología, personas, datos, proveedores, decisiones y contexto organizacional.
Esto permite identificar fuentes de riesgo que una taxonomía genérica de “riesgo tecnológico” puede ocultar. Entre ellas pueden aparecer:
- datos incompletos, no representativos o inadecuados para el propósito;
- resultados incorrectos, inconsistentes o difíciles de explicar;
- automatización excesiva o supervisión humana ineficaz;
- dependencia de proveedores, modelos o infraestructura externos;
- cambios en el contexto de uso que vuelven inválidas las premisas iniciales;
- efectos adversos sobre individuos, grupos o la sociedad;
- vulnerabilidades de seguridad, privacidad o manipulación;
- expectativas de desempeño que no corresponden con las capacidades reales del sistema.
El objetivo no es crear una lista infinita de “riesgos de IA”. Es mejorar la relación entre objetivo, contexto, fuente de riesgo y consecuencia.
Un registro de riesgos de IA es débil cuando solo añade nuevas etiquetas. Es útil cuando cambia las decisiones sobre diseño, uso, supervisión y tratamiento.
Identificar el riesgo exige mirar más allá del modelo
Uno de los errores más comunes es concentrar la evaluación en el algoritmo. Para muchas organizaciones, los riesgos más relevantes no nacen del modelo aislado, sino de la forma en que se incorpora a una decisión empresarial.
Pensemos en una herramienta generativa utilizada para preparar respuestas a clientes. El riesgo no se limita a que el modelo produzca una respuesta incorrecta. También importa si el usuario puede detectar el error, si existen fuentes autorizadas, si se registra qué versión o proveedor generó la salida, si hay datos sensibles en el prompt, si el cliente puede recurrir una decisión y si los incidentes generan aprendizaje.
Por ello, una identificación de riesgos madura debería conectar al menos cinco perspectivas:
- Objetivo y uso previsto. Qué pretende lograr el sistema y qué decisiones soporta.
- Datos y tecnología. De qué información, modelos, infraestructura y configuraciones depende.
- Personas y partes interesadas. Quién lo opera, quién confía en sus resultados y quién puede sufrir consecuencias.
- Entorno y terceros. Qué proveedores, obligaciones, jurisdicciones o dependencias externas condicionan el riesgo.
- Ciclo de vida y cambio. Qué puede variar desde diseño y adquisición hasta despliegue, operación, modificación y retiro.
Para auditoría interna, esta estructura es particularmente útil porque convierte una discusión abstracta sobre “IA responsable” en preguntas de evidencia: ¿está documentado el uso previsto?, ¿se entienden las dependencias?, ¿existen criterios de aceptación?, ¿se revisan los riesgos después de cambios significativos?
El tratamiento debe responder al riesgo, no a una lista estándar de controles
Una vez evaluado el riesgo, el siguiente reto es evitar el tratamiento mecánico.
Dos aplicaciones del mismo modelo pueden necesitar controles diferentes. Un asistente que resume documentos públicos y un sistema que recomienda decisiones de crédito pueden compartir tecnología, pero tienen consecuencias, partes interesadas y tolerancias de riesgo muy distintas.
ISO/IEC 42001 refuerza esta lógica al exigir que la organización determine los controles necesarios a partir de los resultados de su evaluación de riesgos y verifique que no haya omitido controles necesarios al compararlos con sus controles de referencia. La secuencia correcta es, por tanto:
riesgo → decisión de tratamiento → control → responsable → evidencia → riesgo residual
No al revés.
Los tratamientos pueden incluir evitar un uso, cambiar el diseño, limitar el alcance, introducir supervisión humana, mejorar datos, añadir validaciones, modificar un contrato, restringir accesos, establecer mecanismos de reclamación, aumentar el monitoreo o aceptar conscientemente un riesgo residual.
Para el auditor, una prueba potente consiste en seleccionar riesgos materiales y recorrer esa cadena en ambos sentidos. Si un control existe, debería poder explicarse qué riesgo trata. Si un riesgo fue aceptado, debería existir autoridad, criterio y evidencia para esa aceptación.
El monitoreo es donde la gestión de riesgos de IA deja de ser una fotografía
El mayor aporte práctico de un enfoque específico para IA es reconocer que la evaluación inicial pierde valor rápidamente si el sistema o su contexto cambian.
ISO/IEC 42001 exige repetir las evaluaciones de riesgo en intervalos planificados o cuando se propongan o produzcan cambios significativos, además de verificar la eficacia del tratamiento. Esa exigencia operacionaliza una idea central de ISO/IEC 23894: gestionar el riesgo de IA requiere un proceso continuo de monitoreo, revisión, registro y comunicación.
¿Qué debería activar una reevaluación? Entre otros factores:
- un nuevo propósito o grupo de usuarios;
- cambios relevantes en datos, modelo, proveedor o configuración;
- deterioro del desempeño;
- incidentes, reclamaciones o resultados inesperados;
- cambios regulatorios o contractuales;
- expansión del sistema a nuevas geografías o procesos;
- aparición de nuevas vulnerabilidades o técnicas de ataque;
- evidencia de que el tratamiento actual no funciona.
Esto transforma el registro de riesgos en un mecanismo de gobierno. El punto no es actualizar una puntuación cada trimestre, sino detectar cuándo las premisas que sustentaban una decisión ya no son válidas.
Qué debería revisar auditoría interna
Para un trabajo de auditoría, ISO/IEC 23894 es más útil como lente de profundidad que como checklist. Cinco preguntas suelen revelar la madurez del proceso:
- ¿El método de riesgo está integrado en la gestión empresarial o funciona como un ejercicio paralelo de IA?
- ¿La identificación considera sistema, datos, personas, terceros, uso previsto y ciclo de vida, además de riesgos tecnológicos tradicionales?
- ¿Las consecuencias se analizan para la organización y también para las partes interesadas relevantes?
- ¿Existe trazabilidad desde los riesgos priorizados hasta tratamientos, controles, responsables y riesgo residual?
- ¿Los cambios, incidentes y métricas pueden activar una reevaluación real?
La evidencia puede incluir criterios de riesgo, registros de riesgos, evaluaciones, decisiones de aprobación, planes de tratamiento, resultados de pruebas, métricas, registros de incidentes, actas de comités, cambios de proveedores y evidencia de aceptación del riesgo residual.
El auditor no necesita convertirse en científico de datos para revisar la arquitectura de este proceso. Sí necesita reconocer cuándo una conclusión depende de afirmaciones técnicas —por ejemplo, robustez estadística, sesgo de un modelo o seguridad adversarial— que requieren especialistas.
El valor de ISO/IEC 23894 está en hacer visible lo que un marco genérico puede omitir
La gestión de riesgos de IA no necesita abandonar los principios conocidos. Necesita aplicarlos con un objeto de riesgo más complejo y dinámico.
ISO 31000 aporta la arquitectura general. ISO/IEC 23894 profundiza en las particularidades de la IA. ISO/IEC 42001 convierte parte de esa lógica en requisitos de un sistema de gestión. Juntos ofrecen una secuencia coherente: entender el contexto, identificar mejor el riesgo, tratarlo de forma proporcional y volver a evaluarlo cuando la realidad cambie.
Para auditoría interna, esa es la consecuencia más importante. La pregunta no es si la organización tiene un “registro de riesgos de IA”. La pregunta es si su proceso detecta las características que hacen diferente a la IA y si esas características realmente cambian las decisiones de gobierno, control y monitoreo.