ISO/IEC 42005: cómo evaluar el impacto de los sistemas de IA

Una organización puede tener un inventario de sistemas de inteligencia artificial, una política aprobada y un comité de gobernanza y, aun así, no saber con suficiente claridad quién puede resultar afectado por una aplicación concreta, de qué manera y con qué evidencia se tomó la decisión de desplegarla.

Ese vacío es precisamente el terreno de ISO/IEC 42005:2025. Publicada en mayo de 2025, la norma ofrece orientación para realizar evaluaciones de impacto de sistemas de IA sobre personas, grupos y la sociedad a lo largo del ciclo de vida. Su valor para auditoría no está en añadir otro checklist, sino en convertir preguntas dispersas sobre consecuencias humanas y sociales en un proceso trazable: definir alcance, asignar responsabilidades, analizar impactos, documentar decisiones, aprobar resultados y revisar la evaluación cuando cambie el sistema o su contexto.

La tesis práctica es sencilla: una buena evaluación de impacto es evidencia estructurada y una entrada directa para decidir qué debe auditarse con mayor profundidad.

ISO/IEC 42005 responde a una pregunta distinta del riesgo tradicional

Una evaluación de riesgos suele comenzar con la exposición de la organización: qué puede impedir sus objetivos, qué probabilidad existe y qué tratamiento conviene aplicar. Una evaluación de impacto de IA cambia el punto de observación. Pregunta también qué consecuencias puede producir el sistema para quienes lo usan, para quienes son objeto de sus decisiones y para otras partes potencialmente afectadas.

La ISO/IEC 42005:2025 se centra en esas consecuencias y en sus aplicaciones previsibles. La propia estructura de la norma cubre el desarrollo del proceso de evaluación, su alcance, responsabilidades, umbrales, ejecución, análisis, registro, aprobación, monitoreo y revisión. Después profundiza en la documentación del sistema, sus usos, datos, modelos, entorno de despliegue, partes interesadas e impactos reales o razonablemente previsibles.

Un mismo sistema puede ser aceptable operacionalmente y seguir generando impactos relevantes. Un modelo de priorización puede mejorar tiempos de respuesta y, al mismo tiempo, afectar de forma desigual a determinados grupos. Un asistente generativo puede elevar la productividad y, a la vez, introducir riesgos para la confidencialidad, la calidad de decisiones o la capacidad de impugnar una recomendación automatizada.

Por eso, impacto y riesgo no compiten. Se alimentan mutuamente.

La relación con ISO/IEC 42001: requisito frente a orientación

La distinción entre ambas normas es esencial. ISO/IEC 42001:2023 es una norma de sistemas de gestión que establece requisitos para crear, implementar, mantener y mejorar un sistema de gestión de IA. En su cláusula 6.1.4 exige que la organización defina un proceso para evaluar las consecuencias potenciales de los sistemas de IA sobre individuos, grupos y sociedades, considerando el despliegue, el uso previsto, el uso indebido previsible, el contexto técnico y social y las jurisdicciones aplicables. El resultado debe documentarse y alimentar la evaluación de riesgos.

La cláusula 8.4 añade la dimensión operativa: las evaluaciones deben realizarse en intervalos planificados o cuando se propongan cambios significativos, y sus resultados deben conservarse como información documentada.

ISO/IEC 42005 explica cómo estructurar mejor ese trabajo. Es una norma de orientación; no crea por sí sola un sistema de gestión certificable equivalente a ISO/IEC 42001. Sus anexos, incluidas las taxonomías y plantillas de ejemplo, ayudan a diseñar y documentar la evaluación, pero deben entenderse según su naturaleza informativa.

Para un auditor, la diferencia evita un error frecuente: tratar cada elemento de ISO/IEC 42005 como si fuera un requisito obligatorio de certificación. El criterio de auditoría debe dejar claro qué proviene de ISO/IEC 42001, qué proviene de obligaciones legales o internas y qué se utiliza como buena práctica de ISO/IEC 42005.

La evidencia debería contar la historia de una decisión

Una evaluación madura permite reconstruir por qué la organización consideró aceptable desarrollar, adquirir, modificar o desplegar un sistema. La evidencia útil no es un PDF aislado, sino un rastro coherente entre contexto, análisis y decisión.

Área de evidencia	Qué debería poder reconstruir el auditor	Señal de alerta
Gobierno del proceso	Responsable, alcance, versión, aprobaciones y disparadores de revisión	Evaluación sin propietario o sin aprobación
Sistema y uso	Propósito, funciones, dependencias, uso previsto, uso no previsto y entorno de despliegue	El análisis describe la tecnología pero no su uso real
Datos y modelo	Información relevante sobre datos, calidad, modelo o algoritmo y limitaciones conocidas	Conclusiones sin conexión con datos o supuestos
Partes interesadas e impactos	Personas directamente afectadas, otras partes relevantes, beneficios, daños, fallos y uso indebido previsible	Solo se analiza el impacto para la organización
Respuesta y seguimiento	Medidas adoptadas, decisiones, riesgos trasladados a gestión y condiciones para reevaluar	La evaluación termina en una lista de riesgos sin acción

El INCITS, organismo estadounidense participante en la normalización de tecnologías de información, destaca que el Anexo E de ISO/IEC 42005 incluye ejemplos de plantillas que cubren, entre otros elementos, identificadores del sistema, historial de revisiones y aprobaciones, propósito, usos previstos y no previstos, información de datos y calidad, modelo o algoritmo, entorno de despliegue, partes interesadas, beneficios, daños, fallos y posible uso indebido.

Para auditoría interna, esa documentación es evidencia de la gobernanza realizada por la organización, no evidencia automática de que las conclusiones sean correctas. El auditor todavía debe evaluar suficiencia, relevancia y confiabilidad, contrastar supuestos y comprobar que las medidas declaradas realmente existen y funcionan.

“Parte interesada” no significa solo usuario

Uno de los aportes más importantes de una evaluación de impacto es obligar a ampliar la mirada. El usuario del sistema puede no ser la persona que soporta la consecuencia.

Pensemos en una herramienta de IA utilizada por empleados para priorizar solicitudes de clientes. Los usuarios directos son los empleados, pero los clientes pueden verse afectados por la clasificación; ciertos grupos pueden sufrir efectos desproporcionados; proveedores tecnológicos pueden influir en el funcionamiento; y funciones como legal, privacidad, cumplimiento o seguridad pueden tener responsabilidades de supervisión.

ISO/IEC 42005 dedica una parte específica de la documentación a las partes interesadas relevantes y distingue entre quienes son afectados directamente y otras partes relevantes. Eso no significa que toda evaluación deba convertirse en una consulta pública ni que todos los grupos deban participar de la misma manera. Significa que la organización necesita una lógica defendible para determinar quién importa para ese sistema y qué expectativas o impactos deben considerarse.

Para el auditor, una lista de stakeholders es solo el comienzo. Las preguntas importantes son si se omitieron colectivos razonablemente previsibles, si se consideraron situaciones de vulnerabilidad, si las conclusiones reflejan el contexto real de uso y si existe un mecanismo para incorporar nueva información después del despliegue.

La evaluación de impacto debería modificar el alcance de auditoría

Aquí es donde ISO/IEC 42005 deja de ser un tema exclusivo de gobernanza de IA y se convierte en una herramienta de planificación de auditoría.

La Norma 13.2 de las Normas Globales de Auditoría Interna exige comprender la actividad bajo revisión, identificar información confiable, relevante y suficiente, considerar marcos aplicables y priorizar los riesgos que serán revisados. La Norma 13.3 exige establecer y documentar los objetivos y el alcance de cada trabajo.

Una evaluación de impacto bien construida puede enriquecer ambos pasos. Por ejemplo:

si identifica consecuencias potencialmente severas para personas, el alcance puede incluir supervisión humana, mecanismos de revisión, calidad de datos y pruebas de resultados;
si revela múltiples proveedores o dependencias, puede justificar procedimientos sobre terceros, cambios de modelo, contratos y disponibilidad de evidencia;
si el impacto depende de país, idioma o población, el alcance puede necesitar muestras o pruebas segmentadas por contexto de despliegue;
si existe uso indebido razonablemente previsible, pueden entrar en alcance controles de acceso, monitoreo, detección de abuso e incidentes;
si el sistema cambia con frecuencia, la auditoría puede concentrarse en disparadores de reevaluación, monitoreo y gestión de cambios.

La evaluación también ayuda a marcar los límites del auditor generalista. Un equipo puede revisar gobierno, responsabilidades, trazabilidad, calidad del proceso y evidencia de controles sin realizar por sí mismo validación estadística avanzada, pruebas de ciberseguridad o evaluación especializada de un modelo. Cuando el impacto indica que esas pruebas son necesarias, el hallazgo de planificación puede ser precisamente la necesidad de incorporar especialistas.

Auditar el proceso de decisión, no solo la plantilla

El riesgo de cualquier metodología es confundir completitud documental con calidad. Una evaluación de impacto puede estar perfectamente rellenada y seguir siendo débil si utiliza supuestos obsoletos, ignora partes afectadas, minimiza daños plausibles o nunca se actualiza después de cambios significativos.

Para el auditor interno, el objetivo no debería ser preguntar “¿existe una evaluación de impacto?”. Una pregunta más útil es: ¿puede la organización demostrar que identifica de forma consistente los impactos relevantes, los incorpora a sus decisiones de riesgo y control, y reabre la evaluación cuando cambia el sistema o su contexto?

Esa es la conexión más poderosa entre ISO/IEC 42005 y auditoría. La norma ayuda a convertir impactos difusos en información estructurada. Auditoría convierte esa información en prioridades de aseguramiento, preguntas de evidencia y decisiones sobre profundidad de prueba.

Cuando ambas disciplinas funcionan juntas, la evaluación de impacto deja de ser un anexo de gobernanza y se convierte en una señal temprana de dónde la organización necesita más control, más supervisión o más aseguramiento.