La evaluación de impacto de un sistema de IA contesta lo que la evaluación de riesgos no contesta: qué les puede pasar a las personas alcanzadas por el sistema. La guía de referencia es ISO/IEC 42005:2025, «Information technology — Artificial intelligence (AI) — AI system impact assessment», en vigor desde el 28 de mayo de 2025. Tres cosas que casi nadie cuenta bien: es una guía, no una norma de requisitos, así que no se certifica —lo certificable es ISO/IEC 42001—; no tiene versión UNE, AENOR la vende con su código internacional y se cita tal cual; y lo que deja al terminar no es un informe descriptivo, sino una decisión firmada sobre un impacto residual que alguien acepta en nombre de la organización.
Qué es ISO 42005 y para qué sirve ya lo contamos en el post sobre ISO 42005 y la evaluación de impacto de sistemas de IA. Aquí va la otra mitad: el procedimiento. Cómo se recorre una evaluación de principio a fin, quién decide en cada paso y qué documento queda en la carpeta.
Evaluación de riesgos y evaluación de impacto no son el mismo ejercicio
La distinción ordena todo lo demás, y en castellano está mal contada casi siempre porque las dos cosas se llaman «riesgo». La evaluación de riesgos del sistema de gestión mira hacia dentro: qué le pasa a la organización si el sistema falla, se desvía o se usa mal. Continuidad, coste, reputación. La evaluación de impacto mira hacia fuera: qué consecuencias tiene el sistema para las personas y los grupos afectados, incluidos los que no son clientes ni empleados y no sabrán nunca que hubo un modelo por medio.
Cambia el sujeto que sufre el daño y cambia la métrica. Un sistema que ordena candidaturas tiene, en el registro de riesgos, una fila sobre contratar mal y otra sobre el litigio posterior: las dos se miden en dinero y en tiempo. En la evaluación de impacto la fila es otra —la persona descartada sin saber por qué, el grupo al que el modelo trata peor porque los datos históricos ya lo trataban peor— y eso no cabe en las columnas de probabilidad y consecuencia.
Por eso son dos documentos. Añadir una columna «impacto en personas» al registro de riesgos parece un atajo y no sirve para ninguna de las dos cosas: se rellena con la gravedad para la empresa, el afectado no aparece y no hay decisión que firmar. Hacer un ejercicio y presentarlo como los dos es un hallazgo de auditoría, y se cierra escribiendo el documento que falta, no explicándolo en la reunión de cierre. Qué se pide de cada uno está en las evidencias que pide el auditor de ISO 42001.
Dónde encaja en el sistema de gestión: el bloque A.5
El anexo A de ISO/IEC 42001 reúne nueve objetivos de control, numerados de A.2 a A.10, con 38 controles en total. Uno de esos bloques, A.5, se llama «Evaluación de impactos de los sistemas de IA». Así que la evaluación de impacto no es un anexo opcional que se añade si sobra tiempo: es la pieza que ese bloque pide. Un sistema de gestión de IA sin evaluaciones de impacto tiene un objetivo de control entero sin sostener, y eso se ve en la declaración de aplicabilidad antes de abrir ninguna carpeta. Cómo se justifica cada bloque está en la pieza sobre el anexo A de ISO 42001 y la declaración de aplicabilidad.
ISO 42001 dice que hay que evaluar el impacto; ISO 42005 explica cómo. Y como es guía, el auditor no te audita ISO 42005: comprueba que tu evaluación hace lo que el sistema de gestión necesita. Eso da libertad de formato y quita la excusa de «lo hicimos de otra manera». Si citas la evaluación como evidencia de A.5, la referencia lleva código, versión y fecha; sin eso es un adorno que se destapa pidiendo el documento. El recorrido completo, en la guía completa de ISO 42001.
Cuándo se hace, y qué la obliga a repetirse
Se hace antes de poner el sistema en producción, y con margen suficiente para que el resultado pueda ser «no». Una evaluación que llega cuando el despliegue ya tiene fecha en el comité no es una evaluación: es una justificación. El momento natural es antes de la autorización de puesta en servicio, encadenada a ella, para que quien firma la autorización tenga el informe delante.
Y se repite cuando cambia algo que altera el impacto. Los disparadores hay que escribirlos en el procedimiento con nombre y apellidos, porque un «se revisará cuando sea necesario» no dispara nunca.
Los dos que más se escapan son el grado de autonomía y la versión del modelo. El primero llega sin proyecto: alguien decide que las salidas con puntuación alta ya no hace falta revisarlas y el sistema pasa de recomendar a decidir sin que se toque una línea de código. El segundo llega de fuera, y su disparador tiene que estar enganchado al contrato y al inventario, no a la buena voluntad.
El paso a paso: ocho movimientos, y lo que sale de cada uno
Lo que sigue es el ejercicio con nuestras palabras, no el texto de la norma, que se compra y hay que tener en la mesa. Cada paso se cierra con algo escrito. Si un paso no produce nada, no se hizo: se comentó.
1 · Delimitar qué sistema se evalúa y para qué se usa de verdad
Entra la ficha del sistema en el inventario. Se decide el objeto: un sistema y un uso, no «la IA de la empresa». Sale un apartado de alcance con el sistema, su versión, el proceso donde interviene, qué decisiones toca y qué usos quedan fuera.
Lo que casi todos se saltan es la diferencia entre para lo que se compró la herramienta y para lo que se usa. Un asistente contratado para resumir documentos acaba redactando la motivación de una denegación, y esa segunda vida no está en ninguna ficha. Los usos que aparecieron por el camino se evalúan o se prohíben, y la prohibición tiene que estar donde la lea quien usa la herramienta.
2 · Identificar a quién afecta
Entra el proceso de negocio y quién aparece en él. Se decide la lista de afectados en tres capas: quien opera el sistema, la persona sobre la que el sistema decide o influye, y quien no lo toca y aun así recibe el efecto. Sale un apartado con, por cada grupo, qué le llega y si puede enterarse de que le llegó.
La tercera capa falta siempre: el proveedor descartado por una puntuación automática, el paciente al que le cambian el orden de la lista, el vecino del expediente. Hay una comprobación de treinta segundos: si tu lista de afectados coincide con la de usuarios con licencia, no está terminada. Dentro de cada grupo se señala a quien está en peor posición para reaccionar, porque el mismo error no pesa igual según a quién le caiga.
3 · Describir cómo funciona, lo justo
Entra la documentación del proveedor o del equipo. Se decide cuánto detalle hace falta para razonar sobre el impacto. Sale media página: qué entra, qué sale, en qué formato llega la salida a quien la usa, quién la revisa y qué pasa si el sistema no está disponible.
No es la arquitectura: cómo se implementa el registro de eventos o la supervisión humana dentro del producto es el terreno de la adecuación técnica al AI Act de Summum IA. Lo que sí hace falta, y casi nunca está, es la lista de lo que no sabes: con qué datos se entrenó el modelo del proveedor, qué criterios pesan en la salida, si hubo evaluación de sesgo. Esa lista es parte del resultado, y sirve para preguntárselo al proveedor por escrito y guardar la respuesta o el silencio.
4 · Identificar los impactos posibles, negativos y positivos
Entran los tres pasos anteriores. Se decide en qué dimensiones puede tocar el sistema a las personas del paso 2. Sale un catálogo de impactos, cada uno atado a un grupo concreto y a un momento del proceso: un impacto sin grupo y sin momento no se puede valorar ni mitigar.
Las dimensiones que hay que recorrer, aunque alguna quede vacía: trato desigual entre grupos, acceso a un servicio o a una oportunidad, seguridad física, información personal, condiciones de trabajo de quien opera, margen de la persona para decidir por sí misma y su capacidad de enterarse y reclamar. Los positivos se anotan igual: si el sistema reduce un error que hoy perjudica a alguien, eso pesa en la decisión. Un informe que solo enumera daños se lee como un trámite, y un trámite se firma sin leerlo.
5 · Valorar cada impacto
Entra el catálogo. Se decide la escala, y se decide dentro del propio documento. Sale una tabla valorada donde dos personas distintas puntuarían parecido.
Los dos últimos criterios son los que más cambian el resultado: un error leve que el afectado no puede detectar y que no tiene vía de corrección pesa más que uno grave que salta al momento y se arregla el mismo día. Ahí se separa una evaluación de una lista de miedos. La escala, corta: tres o cuatro niveles definidos con un criterio, no con adjetivos. Si «alto» no está definido, cada evaluador usa el suyo y no puedes comparar dos evaluaciones del mismo sistema en años distintos.
6 · Medidas de mitigación, y quién las asume
Entra la tabla valorada. Se decide qué se hace con cada impacto que no se acepta como está. Sale cada medida con un responsable con nombre, una fecha y la forma de comprobar que está puesta.
El repertorio es corto: cambiar el diseño o los datos, meter revisión humana en un punto concreto, limitar el uso a un subconjunto de casos, informar al afectado, abrir una vía de reclamación con plazo, o no desplegar. La última es una medida, no un fracaso. Sobre la revisión humana: si quien revisa solo puede aprobar, no es una revisión; hay que escribir qué puede hacer, en qué plazo y con qué información delante. Y si la medida cae del lado del proveedor, se traduce en cláusula o en una comprobación propia, porque el impacto no se subcontrata.
7 · Impacto residual y la decisión: la firma que casi nunca está
Entran las medidas comprometidas. Se decide qué queda después de aplicarlas y si eso se acepta. Sale el apartado de impacto residual con la aceptación firmada: nombre, cargo, fecha y condiciones.
Este paso convierte el documento en algo que sirve, y es el que falta en la mayoría de las evaluaciones que nos llegan. Sin firma tienes un análisis; con firma, una decisión con dueño, que es lo que hace falta para poder revisarla después. Firma quien puede asignar recursos y parar el despliegue, no quien redactó el informe. La aceptación puede ser condicional —solo un colectivo reducido, revisión en una fecha fijada, revisión humana hasta que los indicadores digan otra cosa— y las condiciones van en el mismo apartado, no en un correo. Si nadie quiere firmar, eso también es un resultado: el sistema no sale.
8 · Seguimiento después de desplegar
Entra la decisión con sus condiciones. Se decide qué se mira, cada cuánto y quién. Sale un registro de seguimiento y, cuando toca, la reapertura de la evaluación.
Los indicadores van escritos en el informe, porque un seguimiento que se decide después de desplegar no se hace. Los que rinden: las reclamaciones y su motivo, con qué frecuencia el revisor humano corrige la salida —si nunca la corrige, la revisión es un sello—, el reparto de resultados por grupo cuando se pueda medir sin abrir otro problema, y las incidencias con su tratamiento. Ese registro prueba que A.5 está vivo, y su ausencia es una de las no conformidades típicas en auditorías de ISO 42001.
El informe que queda: secciones y lo que mira el auditor
El resultado se maqueta como un registro del sistema de gestión —código, versión, propietario, fecha de próxima revisión—, no como una presentación, y se archiva donde el auditor lo encuentre desde la declaración de aplicabilidad.
| Sección del informe | Qué contiene | Qué comprueba el auditor |
|---|---|---|
| Identificación y versión | Sistema, versión, fecha, quién redacta y quién revisa | Que la fecha es anterior a la producción y que la versión es la que cita la declaración de aplicabilidad |
| Alcance y uso real | Proceso donde interviene, decisiones que toca, usos excluidos | Que el uso descrito es el de la operación, no el del folleto del proveedor |
| Partes afectadas | Grupos, qué recibe cada uno, quién está peor situado para reaccionar | Que aparece alguien que no es cliente ni empleado. Si solo hay usuarios, falta trabajo |
| Descripción funcional y límites | Entradas, salidas, revisión humana, caída y lo que no se sabe del modelo | Que la lista de lo que no se sabe existe y se intentó cerrar con el proveedor |
| Impactos y valoración | Catálogo por grupo con gravedad, alcance, reversibilidad, detectabilidad y reacción | Que la escala está definida en el documento y aplicada igual en todas las filas |
| Medidas y responsables | Medida, dueño con nombre, fecha y comprobación | Que la medida existe fuera del informe: procedimiento, configuración o cláusula |
| Impacto residual y decisión | Qué queda tras las medidas, quién lo acepta y con qué condiciones | Nombre, cargo y fecha. Lo primero que busca y lo que más veces falta |
| Seguimiento | Indicadores, periodicidad, responsable y disparadores de reapertura | Que hay registros del seguimiento, no solo el plan |
| Encaje con otras evaluaciones | Referencias cruzadas a protección de datos y, si aplica, a derechos fundamentales | Que dos documentos del mismo sistema no se contradicen |
De los informes que se caen en auditoría, la mayoría se cae por dos sitios: la fecha es posterior al despliegue, o no hay nadie que acepte el residual. El resto puede estar impecable y da igual, porque sin esas dos cosas no hay ni prevención ni responsable.
Cómo no hacer tres veces la misma evaluación
Cuando el sistema trata datos personales y además entra en el ámbito del AI Act, sobre la mesa hay tres ejercicios con solapamiento real: la evaluación de impacto del sistema de IA con ISO/IEC 42005, la evaluación de impacto relativa a la protección de datos del artículo 35 del Reglamento (UE) 2016/679 y la evaluación de impacto relativa a los derechos fundamentales del artículo 27 del Reglamento (UE) 2024/1689. Tres documentos que describen el mismo sistema, el mismo uso y a las mismas personas, y que en muchas empresas llevan tres departamentos que no se hablan.
| Ejercicio | Qué mira | Qué lo pide | Quién lo firma |
|---|---|---|---|
| Impacto del sistema de IA (ISO/IEC 42005:2025) | Las consecuencias del sistema para las personas y los grupos afectados | El bloque A.5 del anexo A de ISO/IEC 42001. ISO 42005 aporta el método y no se certifica | Quien acepta el impacto residual y puede parar el despliegue |
| Protección de datos | El tratamiento de datos personales y su riesgo para los interesados | El artículo 35 del Reglamento (UE) 2016/679, en los términos en que lo cita el artículo 27 del AI Act | Quien responde del tratamiento. Desde calidad se cita, no se redacta |
| Derechos fundamentales | Materia legal, no de sistema de gestión: aquí no se desarrolla | El artículo 27 del Reglamento (UE) 2024/1689, con los apartados 4 y 5 modificados por el Reglamento (UE) 2026/1744 | El responsable del despliegue, en los términos del propio artículo 27 |
Y hay un dato reciente que casi nadie ha incorporado. El Reglamento (UE) 2026/1744, el Ómnibus digital sobre IA, de 8 de julio de 2026 y en vigor desde el 27 de julio de 2026, modificó los apartados 4 y 5 del artículo 27 para permitir expresamente que la evaluación en derechos fundamentales se apoye en la de protección de datos por referencias cruzadas. El apartado 4 queda así:
«4. Si ya se cumplen cualesquiera de las obligaciones establecidas en el presente artículo mediante la evaluación de impacto relativa a la protección de datos realizada en virtud del artículo 35 del Reglamento (UE) 2016/679 o del artículo 27 de la Directiva (UE) 2016/680, el responsable del despliegue podrá, al llevar a cabo la evaluación de impacto relativa a los derechos fundamentales a que se refiere el apartado 1 del presente artículo, incluir referencias cruzadas a las secciones pertinentes de dicha evaluación de impacto relativa a la protección de datos o incluir las partes pertinentes de esta en la evaluación de impacto relativa a los derechos fundamentales.»
El apartado 5 añade algo que conviene esperar antes de inventarse una plantilla propia: «5. La Oficina de IA elaborará un modelo de cuestionario, incluido mediante una herramienta automatizada, a fin de facilitar que los responsables del despliegue cumplan sus obligaciones en virtud del presente artículo de manera simplificada. […]»
A quién obliga el artículo 27 y con qué consecuencias es terreno legal, y lo trata el servicio de cumplimiento del AI Act de Summum Consultoría. Lo que toca desde calidad es el efecto documental: un sistema, un expediente. La evaluación con ISO 42005 es la base, porque describe el sistema, su uso real y a quién afecta; la de protección de datos conserva su objeto y su carpeta; y la de derechos fundamentales, cuando toque, se apoya en las secciones pertinentes en vez de reescribirlas. El resto lo hace la disciplina de identificación: la misma versión del sistema, el mismo alcance y la misma lista de afectados en los tres. Si no coinciden, la referencia cruzada deja la contradicción a la vista.
El solapamiento tiene límites. La de protección de datos no cubre impactos que no vienen del tratamiento, y la de ISO 42005 se hace igual en sistemas sin un solo dato personal, donde no hay nada que reutilizar. Cuando sí los hay, la vecina natural es ISO/IEC 27701 para la gestión de la privacidad; y lo demás que el Ómnibus mueve en el sistema de gestión está en la pieza sobre el Ómnibus de IA y el sistema de gestión.
Cuatro errores que dejan la evaluación inservible
Hacerla después de desplegar. La fecha delata, pero el problema de fondo es otro: cuando el sistema ya está en producción, ninguna medida que implique no desplegarlo está sobre la mesa. El ejercicio pierde su única salida fuerte y queda en un inventario de daños asumidos por omisión.
Hacerla sin nadie del negocio en la sala. Calidad sabe montar el documento; quien opera el proceso sabe qué decide realmente el sistema, a quién le llega la salida y qué hace la gente con ella cuando va con prisa. Sin esa persona, el apartado de uso real se rellena con la descripción del proveedor. La reunión mínima son cuatro sillas: quien opera el proceso, quien responde del sistema, quien lleva los datos personales si los hay y quien puede firmar.
No identificar al colectivo afectado real. Invalida lo que viene detrás, porque los impactos se valoran contra los grupos: si el grupo no está, su impacto no existe en el papel. Los que se caen son siempre los mismos, los que no tienen relación contractual contigo y no pueden quejarse por el canal habitual.
No dejar constancia de quién acepta el impacto residual. «Aceptado por la dirección» no es una firma, y «revisado en comité» tampoco si el acta no dice qué se aceptó. Sin nombre, cargo y fecha no hay decisión, y sin decisión el informe no se puede revisar cuando el sistema cambie: no sabes qué se dio por bueno ni con qué información.
Si lo que tienes es una evaluación de riesgos con una columna añadida, o un informe sin firmar, el arreglo no es reescribirlo entero: es recorrer los ocho pasos y ver cuáles produjeron algo. Así lo planteamos en la evaluación de impacto de sistemas de IA con ISO 42005, encadenada al bloque A.5 para que no acabe siendo un documento que solo existe en la semana de la auditoría.
Preguntas frecuentes
¿ISO 42005 se puede certificar?
No. ISO/IEC 42005:2025, en vigor desde el 28 de mayo de 2025, es una guía para evaluar el impacto de un sistema de IA, no una norma de requisitos, así que no hay certificación de ISO 42005. La norma certificable de la familia es ISO/IEC 42001, el sistema de gestión de IA, y su auditoría sí comprueba que las evaluaciones de impacto existen y funcionan.
¿Qué diferencia hay entre evaluación de riesgos y evaluación de impacto de un sistema de IA?
La evaluación de riesgos mide qué le pasa a la organización si el sistema falla o se usa mal: continuidad, coste, reputación. La evaluación de impacto mide las consecuencias para las personas y los grupos afectados por el sistema, que muchas veces no son clientes ni empleados. Son dos ejercicios con métricas distintas y dos documentos separados; presentar uno como los dos suele acabar en hallazgo de auditoría.
¿Cuándo hay que repetir la evaluación de impacto de un sistema de IA?
La primera se hace antes de poner el sistema en producción. Se repite cuando cambia algo que altera el impacto: la finalidad declarada, los datos o la población que representan, el colectivo afectado, el grado de autonomía con que se usa la salida, o la versión del modelo del proveedor. Conviene fijar además una revisión con fecha aunque no haya cambiado nada, porque el contexto de uso cambia solo.
¿Se puede reutilizar la evaluación de impacto de protección de datos para la del AI Act?
El Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, modificó los apartados 4 y 5 del artículo 27 del AI Act para permitir expresamente «incluir referencias cruzadas a las secciones pertinentes» de la evaluación de impacto relativa a la protección de datos del artículo 35 del Reglamento (UE) 2016/679, o incorporar sus partes pertinentes. El mismo artículo encarga a la Oficina de IA un modelo de cuestionario. A quién obliga cada evaluación es materia legal.
¿Quién firma la evaluación de impacto de un sistema de IA?
La redacta quien lleva el sistema de gestión junto con la gente del proceso, pero la firma que importa es la del apartado de impacto residual: quien acepta lo que queda después de las medidas. Tiene que ser alguien con capacidad de asignar recursos y de parar el despliegue, y en el documento consta con nombre, cargo, fecha y las condiciones de la aceptación.