ISO 42005: evaluación de impacto de IA

Qué aporta ISO/IEC 42005

La norma guía la planificación, ejecución, documentación y revisión de evaluaciones de impacto de sistemas de IA. Ayuda a identificar beneficios y daños, personas afectadas, usos previstos y previsibles, fallos, medidas y riesgo residual.

Su valor está en crear un lenguaje común entre negocio, ingeniería, privacidad, seguridad, legal y partes interesadas. La evaluación no debe convertirse en un informe que se archiva: debe influir en el diseño, el despliegue, los límites de uso y, si procede, la retirada del sistema.

Diferencias con otras evaluaciones

Pueden compartir inventario, personas, escenarios y medidas, pero cada una mantiene requisitos propios. Una matriz de correspondencia entre evaluaciones evita duplicar trabajo y, al mismo tiempo, dejar huecos sin cubrir.

Cuándo activar la evaluación

La organización debe definir disparadores que obliguen a iniciar una evaluación de impacto:

• nuevo sistema o caso de uso;
• decisión sobre personas;
• población vulnerable;
• gran escala o categorías sensibles;
• aumento de autonomía;
• nueva fuente de datos;
• cambio de modelo o proveedor;
• expansión a otro país o sector;
• incidente o reclamaciones;
• evidencia de resultados desiguales.

También se documenta cuándo no se realiza la evaluación y con qué fundamento.

Paso 1. Gobierno y alcance

Antes de analizar impactos se define:

• sistema, versión y propietario;
• organización y rol;
• finalidad y decisión;
• ciclo de vida cubierto;
• ubicaciones y población;
• equipo evaluador;
• personas que aprueban;
• fuentes y nivel de incertidumbre;
• calendario y revisión.

El alcance no es «el modelo». Incluye datos, interfaz, herramientas, personas, procedimiento y acciones posteriores.

Paso 2. Describir el sistema

La descripción debe permitir entender:

• función y capacidades;
• entradas y salidas;
• modelos y algoritmos;
• datos de entrenamiento, prueba y operación;
• dependencias y proveedores;
• entorno de despliegue;
• supervisión y autonomía;
• métricas y límites;
• interacción con otros sistemas.

Se registran las versiones. Una evaluación de un modelo anterior no cubre automáticamente una nueva integración.

Paso 3. Propósito, usos y límites

Conviene distinguir:

• uso previsto;
• uso no previsto pero razonablemente previsible;
• uso indebido;
• uso restringido por política;
• uso prohibido por ley o riesgo.

Ejemplo: un asistente de RR. HH. previsto para responder a políticas internas podría utilizarse para inferir el rendimiento de una persona. Aunque no sea la finalidad prevista, si el uso es previsible debe evaluarse y, en su caso, bloquearse.

Paso 4. Partes afectadas

No solo los usuarios directos. La evaluación puede afectar a:

• personas objeto de la decisión;
• personas cuyos datos entrenan el sistema;
• familiares o terceros;
• grupos con menor representación;
• personal que supervisa;
• clientes y proveedores;
• comunidades y sociedad.

Se analiza el impacto diferencial. Un promedio puede ocultar un daño concentrado en un grupo concreto.

Cuando sea apropiado, se consulta a las personas afectadas o a sus representantes. Si no se consulta, se documenta por qué y cómo se incorporó su perspectiva por otras vías.

Paso 5. Beneficios y daños

La evaluación debe contemplar ambos lados. Beneficios posibles:

• acceso a servicios;
• reducción de tiempo;
• consistencia;
• detección de errores;
• apoyo a la accesibilidad;
• mejor asignación de recursos.

Daños posibles:

• exclusión o discriminación;
• pérdida de autonomía;
• vigilancia;
• error y dificultad de corrección;
• privacidad y seguridad;
• manipulación;
• impacto laboral;
• daño económico o reputacional;
• impacto ambiental;
• dependencia tecnológica.

No se compensan automáticamente los daños a un grupo con beneficios agregados. Deben evaluarse la distribución y la gravedad de cada impacto por separado.

Paso 6. Escenarios de impacto

Un escenario claro contiene una estructura sencilla:

Debido a causa, el sistema puede evento, afectando a personas, y provocar consecuencia.

Ejemplo: por datos históricos incompletos, un sistema puede puntuar peor a candidaturas de una región concreta, reduciendo su acceso al empleo sin explicación ni revisión efectiva.

Para cada escenario se registra:

• fase del ciclo;
• causa y evidencia;
• personas afectadas;
• probabilidad;
• gravedad y reversibilidad;
• controles existentes;
• incertidumbre;
• riesgo inicial.

Paso 7. Métodos y evidencia

La evidencia puede incluir:

• pruebas cuantitativas;
• evaluación por grupos;
• ejercicios de red teaming;
• entrevistas y talleres;
• literatura e incidentes previos;
• auditorías de datos;
• pruebas de usabilidad;
• análisis jurídico;
• documentación del proveedor.

Se distingue el dato observado del supuesto. Si el proveedor no aporta información suficiente, la incertidumbre aumenta y puede justificar límites adicionales al uso del sistema.

Paso 8. Medidas

Las medidas siguen una jerarquía de actuación:

1. evitar el uso o la función;
2. reducir el alcance o la autonomía;
3. cambiar los datos, el modelo o el proceso;
4. añadir controles técnicos;
5. introducir supervisión y reparación;
6. informar y monitorizar.

Una advertencia no compensa un diseño intrínsecamente dañino.

Cada medida tiene propietario, plazo, evidencia, indicador y eficacia esperada. El riesgo residual se reevalúa después de aplicarla.

Supervisión humana y reparación

La intervención humana debe contar con información, competencia, tiempo y autoridad suficientes. Se define qué decisiones requieren revisión previa, muestreo o doble aprobación.

Las personas afectadas necesitan canales para:

• obtener información;
• corregir datos;
• aportar contexto;
• impugnar la decisión;
• recibir revisión humana;
• obtener reparación cuando proceda.

Se mide si el canal funciona en la práctica, no solo si existe sobre el papel.

Decisión y aceptación

La salida de la evaluación puede ser:

• aprobar;
• aprobar con condiciones;
• limitar la población o la función;
• pilotar en modo sombra;
• solicitar más evidencia;
• rediseñar;
• no desplegar.

La aceptación de un impacto alto debe corresponder al nivel de autoridad definido. No se delega tácitamente al equipo técnico.

Monitorización y revisión

Indicadores de seguimiento:

• errores por grupo;
• anulaciones humanas;
• reclamaciones;
• decisiones sin explicación;
• accesos indebidos;
• cambios de distribución;
• incidentes;
• beneficio realmente obtenido.

Disparadores de revisión: cambio de sistema, de población, de datos, de proveedor, de ley, de contexto o de riesgo. La evaluación se versiona como cualquier otro documento vivo.

Integración con ISO 42001

ISO/IEC 42001 establece el sistema de gestión; ISO/IEC 42005 profundiza en la evaluación de un sistema concreto. El inventario del sistema de gestión de IA (AIMS) puede activar y almacenar las evaluaciones 42005. Sus resultados alimentan riesgos, objetivos, controles, auditoría y revisión por dirección.

No se crea un proceso paralelo si ya existe gestión de producto. La evaluación se incorpora como puerta de diseño y de cambio dentro del sistema existente.

Plantilla mínima

Los anexos de la norma ofrecen ejemplos de plantillas; debe utilizarse siempre la edición adquirida.

Plan de 30 días

Semana 1

Alcance, descripción del sistema, equipo evaluador y partes afectadas.

Semana 2

Usos, beneficios, daños y escenarios.

Semana 3

Pruebas, consulta, valoración y medidas.

Semana 4

Riesgo residual, decisión, publicación interna y monitorización.

El plazo varía según la complejidad del sistema y la evidencia disponible.

Errores frecuentes

1. Evaluar solo el modelo.
2. Incluir solo a los usuarios directos.
3. Enumerar riesgos sin construir escenarios.
4. Ignorar los beneficios y su distribución.
5. Tratar la incertidumbre como ausencia de riesgo.
6. Añadir avisos en lugar de rediseñar.
7. Consultar cuando todo está ya decidido.
8. No vincular las medidas a los impactos.
9. No definir un mecanismo de reparación.
10. No revisar la evaluación tras un cambio.

Checklist

• Alcance y versión definidos.
• Finalidad, usos previsibles y prohibidos.
• Personas directas e indirectas identificadas.
• Beneficios y daños distribuidos.
• Escenarios con evidencia.
• Probabilidad, gravedad e incertidumbre.
• Medidas con propietario y prueba.
• Supervisión y reparación efectivas.
• Decisión formal y condiciones.
• Monitorización y revisión.
• Coordinación con la EIPD y la FRIA.

Preguntas frecuentes

¿ISO 42005 es certificable?

Es una norma de orientación para realizar evaluaciones. No debe presentarse como una certificación independiente de un sistema.

¿Sustituye la EIPD?

No. Puede aportar estructura y evidencia, pero la EIPD tiene requisitos jurídicos propios que debe cumplir de forma independiente.

¿Debe publicarse el informe?

Depende de la obligación aplicable, la política interna y el riesgo. Como mínimo debe existir transparencia adecuada y documentación para la rendición de cuentas.

¿Se evalúan también los beneficios?

Sí, junto con los daños y su distribución. Un beneficio agregado no borra un daño grave sufrido por un grupo concreto.

Summum Calidad puede integrar la evaluación de impacto de IA en un sistema de gestión de IA (AIMS) conforme a ISO/IEC 42001 y coordinarla con privacidad, seguridad y AI Act.