Evaluación de impacto de un sistema de IA: cómo se hace

Una evaluación de impacto de un sistema de IA documenta a quién puede afectar el sistema, qué daños plausibles puede causar, cómo se mitigan y en qué condiciones se detiene. No es un análisis de riesgo técnico: mira hacia fuera, hacia las personas afectadas por las salidas del sistema.

La distinción importa porque casi todas las evaluaciones que revisamos están escritas desde dentro. Enumeran riesgos para la organización —caída del servicio, fuga de credenciales, coste de la API— y no mencionan a nadie que no cobre de la organización. Una evaluación así no protege a nadie ni resiste una pregunta incómoda.

¿Qué es exactamente una evaluación de impacto de un sistema de IA?

Es el documento que responde, para un sistema concreto y una finalidad concreta, a seis preguntas: a quién puede afectar, cómo puede salir mal, con qué gravedad, qué se ha hecho para evitarlo, qué riesgo queda y cuándo se apaga.

La norma ISO/IEC 42005:2025 es la referencia dedicada a este proceso: describe cómo identificar y documentar los efectos previsibles de un sistema de IA sobre individuos, grupos y sociedad a lo largo de todo su ciclo de vida. Es una norma de proceso, no certificable por sí misma, y encaja dentro del sistema de gestión que define ISO/IEC 42001:2023, donde la evaluación de impacto es un requisito operativo, no un anexo opcional.

Conviene separarla de dos documentos con los que se confunde:

Documento	Protege a	Pregunta central
Evaluación de riesgos de seguridad	La organización y sus activos	¿Qué puede romper, filtrar o parar el sistema?
Evaluación de impacto de protección de datos	La persona cuyos datos se tratan	¿Es lícito, necesario y proporcionado tratar estos datos?
Evaluación de impacto de IA	Cualquier persona afectada por las salidas	¿A quién puede perjudicar lo que este sistema produce?

Los tres se solapan y se referencian, pero no se sustituyen. Cuando hay datos personales de por medio, la evaluación de protección de datos exigida por el Reglamento (UE) 2016/679 y la evaluación de impacto de IA se redactan en el mismo ejercicio y se enlazan; hacerlas por separado duplica el trabajo y produce contradicciones.

¿Cuándo hay que hacerla?

Con criterio, no con reflejo. Hacerla para los cincuenta sistemas del inventario garantiza que ninguna se hará bien. La regla que aplicamos:

• Siempre, si el sistema influye en decisiones sobre personas: contratación, acceso a un servicio, precio, priorización de casos, evaluación de riesgo individual.
• Siempre, si sus salidas llegan a terceros sin revisión humana.
• Siempre, si trata datos sensibles, datos de menores o información sujeta a secreto profesional.
• Al cambiar la finalidad, aunque el sistema sea el mismo. Una desviación de uso es un sistema nuevo a estos efectos.
• Al cambiar el proveedor o la versión del modelo, cuando el cambio pueda alterar el comportamiento.

Ese filtro sale directamente del inventario de sistemas de IA: si el inventario está bien clasificado, la lista de sistemas que requieren evaluación es automática. Si no existe inventario, la evaluación se hará sobre el sistema que alguien recordó mencionar, que rara vez es el más delicado.

¿Cuál es el guion completo de la evaluación?

Siete bloques. En este orden, porque cada uno alimenta al siguiente.

1. Sistema, finalidad y alcance

Descripción en lenguaje de negocio, no de arquitectura. Qué hace, sobre qué datos, quién lo usa, con qué frecuencia y qué se decide con su salida. Incluye explícitamente lo que el sistema no debe hacer: los usos excluidos son la referencia contra la que después se detecta la desviación.

Añade el papel de la organización. Si desarrollas el sistema, tus obligaciones no son las mismas que si solo lo despliegas; el Reglamento (UE) 2024/1689 separa esos dos papeles y les asigna deberes distintos, y esa clasificación condiciona todo lo que viene después.

2. Partes afectadas

La lista se hace por rondas, porque la primera siempre es corta.

1. Destinatarios directos: quienes reciben la salida.
2. Sujetos de la decisión: aquellos sobre quienes se decide algo, aunque nunca interactúen con el sistema.
3. Terceros indirectos: quien depende del sujeto de la decisión, competidores, comunidad afectada.
4. Personal propio: quien queda obligado a revisar salidas a un ritmo que hace imposible revisarlas de verdad.

El grupo 2 es el que suele faltar y el que concentra el daño real. El grupo 4 es el que hace inservibles las mitigaciones sobre el papel.

3. Daños plausibles

Plausible significa: describible como una secuencia concreta de hechos, no como categoría abstracta. "Sesgo" no es un daño; "el sistema prioriza sistemáticamente las solicitudes de un perfil y los del perfil contrario esperan el doble" sí lo es.

Categorías útiles para no dejarse ninguna:

• Error material: la salida es sencillamente falsa y alguien actúa sobre ella.
• Trato desigual: el sistema rinde peor para un grupo identificable.
• Pérdida de recurso: la persona afectada no puede saber por qué se decidió así ni impugnarlo.
• Exposición de información: entra en el sistema algo que no debía salir de la organización.
• Dependencia excesiva: el revisor humano deja de revisar porque el sistema acierta casi siempre.
• Daño reputacional a terceros: la salida atribuye a alguien algo que no hizo.

Cada daño se valora con dos ejes —gravedad para el afectado y probabilidad— y con un tercero que se olvida siempre: reversibilidad. Un error reversible en un minuto y uno que llega a un tribunal no son el mismo riesgo aunque compartan probabilidad.

4. Sesgo y equidad

Tres preguntas concretas, respondidas con datos o declaradas como no respondibles:

• ¿Sobre qué población se validó el sistema y en qué se parece a la población real de uso?
• ¿Se ha medido el rendimiento por subgrupos relevantes, o solo el rendimiento agregado?
• Si el proveedor no publica esa medición, ¿qué prueba propia se ha hecho antes de producción?

"El proveedor dice que es imparcial" no es una respuesta. Que no puedas medirlo tampoco descalifica el sistema: obliga a declararlo como limitación conocida y a compensarlo con supervisión.

5. Dependencia del proveedor

Es el bloque que más veces falta y el que más caro sale.

Pregunta	Por qué importa
¿Puede el proveedor cambiar el modelo sin avisar?	Un cambio silencioso invalida tu validación previa
¿Hay compromiso contractual sobre el tratamiento de tus datos?	Sin él, no puedes responder a un cliente qué pasa con su información
¿Se usan tus entradas para entrenar?	Determina si puedes usar el sistema con datos confidenciales
¿Qué registros conserva el proveedor y por cuánto tiempo?	Condiciona tu capacidad de reconstruir un incidente
¿Cuál es el plan si el servicio desaparece o sube de precio?	La ausencia de plan es una decisión, solo que no tomada por ti
¿En qué jurisdicción se procesa?	Cambia el régimen aplicable y las obligaciones de transferencia

6. Mitigaciones

Una mitigación válida cumple tres condiciones: es concreta, tiene responsable con nombre y es verificable por alguien de fuera. Si no se puede comprobar que está activa, no es una mitigación: es una intención.

Las que funcionan casi siempre:

• Aprobación humana previa en el punto donde la salida produce efectos irreversibles.
• Restricción de entrada: qué categorías de datos no pueden introducirse, con control técnico y no solo con instrucción.
• Registro completo de entradas, salidas y decisión humana asociada, con retención definida.
• Canal de impugnación para quien se vea afectado, con plazo de respuesta.
• Umbral de confianza por debajo del cual el sistema no responde y deriva a persona.

El diseño concreto de esos puntos de control está desarrollado en nuestro artículo sobre agentes de IA con supervisión humana.

7. Criterio de parada

La sección más corta y la única que se agradece de verdad cuando llega el mal día. Debe contener condiciones medibles, quién puede activarlas y qué pasa mientras el sistema está parado. Ejemplos de criterios reales: superar una tasa de corrección humana definida durante dos semanas seguidas; un incidente de exposición de datos de cliente; un cambio de versión del modelo no anunciado; una reclamación fundada de trato desigual.

Escribirlo antes de arrancar es lo que permite apagar sin negociar.

Un ejemplo de mitigación implementada y verificable

En nuestra plataforma de certificación probatoria, los agentes de IA pueden preparar un depósito: recopilar el material, calcular la huella y dejar el borrador listo. Ninguno puede sellar. El sellado —el acto que produce el certificado con valor probatorio y ancla la huella en una cadena pública— exige aprobación humana explícita.

Esa mitigación cumple las tres condiciones del apartado anterior. Es concreta: el permiso de sellado no existe en el rol del agente. Tiene responsable: la persona que aprueba queda registrada junto al acto. Y es verificable desde fuera: cualquiera puede comprobar de forma independiente la huella y el sello temporal de un certificado sin cuenta y sin darnos datos.

Lo relevante para una evaluación de impacto no es que exista la mitigación, sino que un tercero pueda comprobar que existe. Ese es el listón. El estado de cada marco que aplicamos, con su etiqueta honesta, está publicado en nuestro centro de confianza.

¿Quién firma y qué evidencia queda?

La firma la pone el propietario de negocio del sistema, porque es quien acepta el riesgo residual. Cumplimiento y el responsable técnico contribuyen y firman como tales.

La evidencia mínima que debe quedar archivada: versión del documento y fecha, versión del sistema evaluado, lista de participantes, decisiones tomadas con su justificación, riesgos aceptados de forma expresa y fecha de la próxima revisión. Una evaluación sin fecha de caducidad es una foto de un sistema que ya cambió.

Errores frecuentes

• Evaluar la tecnología en vez del uso. El mismo modelo con dos finalidades tiene dos impactos distintos.
• Confundir mitigación con advertencia. Un aviso en la interfaz no mitiga nada por sí solo.
• Poner "revisión humana" sin medir la carga. Si el revisor tiene diez segundos por caso, no hay revisión.
• Copiar la evaluación de otro sistema. Se nota, y el auditor lo detecta en la primera pregunta sobre partes afectadas.
• Dejar el criterio de parada para más adelante. Más adelante es durante el incidente.

Qué hacer ahora

1. Saca del inventario los sistemas de riesgo alto. Empieza por uno solo, el que más decisiones sobre personas toque.
2. Recorre los siete bloques en orden y no saltes el de partes afectadas: hazlo por rondas.
3. Convierte cada daño en una secuencia concreta de hechos, con gravedad, probabilidad y reversibilidad.
4. Elimina toda mitigación que no sea verificable por un tercero y sustitúyela por una que sí lo sea.
5. Escribe el criterio de parada antes de la puesta en producción, con umbrales numéricos y responsable.
6. Programa la revisión y engánchala al cambio de versión del proveedor.

Si te ayuda ver una evaluación completa antes de escribir la tuya, la trabajamos dentro del pilar de compliance y sobre los flujos reales de automatización supervisada que tengas en producción. También conviene revisar cómo encaja con tus obligaciones de privacidad en Europa y EE. UU.. Escríbenos en contacto con el sistema que más te preocupa y empezamos por ese.