DPIA y evaluación de derechos fundamentales en IA: cómo decidir qué evaluación necesitas antes de usar datos sensibles

La pregunta inicial no es si hay IA, sino qué ocurre con cada persona

Un asistente que resume expedientes, un modelo que ordena solicitudes o una herramienta que estima un riesgo pueden usar técnicas similares y, sin embargo, plantear obligaciones y daños potenciales muy distintos. La evaluación debe empezar por el tratamiento y el efecto reales: qué información entra, qué resultado produce el sistema, quién lo recibe, qué acción provoca y qué consecuencias puede tener para una persona concreta.

Esta distinción importa especialmente cuando intervienen datos de salud, biométricos, laborales, financieros, de seguros, de menores o de personas en una situación de dependencia. También importa cuando el sistema infiere información que nadie entregó expresamente, como una prioridad, una propensión, una categoría de riesgo o una supuesta elegibilidad. Que una inferencia no figure en un formulario no elimina su relevancia para la protección de datos ni para los derechos fundamentales.

El objetivo de una evaluación no es declarar que un modelo es ético, seguro o conforme de forma abstracta. Es documentar si un uso delimitado es necesario y proporcionado, qué daños plausibles puede causar, qué evidencias permitirán detectar esos daños, qué controles los reducirán y qué responsable tiene capacidad real para detener el uso. Una plantilla completada por un proveedor puede aportar información técnica, pero no puede resolver por sí sola cuestiones que dependen de la finalidad, la población afectada, las reglas operativas y el marco jurídico de quien despliega el sistema.

Cuatro capas de riesgo que conviene separar

La evaluación de impacto relativa a la protección de datos, conocida habitualmente como DPIA o EIPD, se centra en los riesgos para los derechos y libertades de las personas derivados de un tratamiento de datos personales. El Reglamento General de Protección de Datos exige realizarla antes del tratamiento cuando este probablemente entrañe un alto riesgo. No es una política de privacidad ampliada: debe describir el tratamiento, valorar necesidad y proporcionalidad, analizar riesgos y establecer medidas para afrontarlos.

La evaluación de impacto en los derechos fundamentales prevista por el Reglamento de Inteligencia Artificial tiene otro punto de partida. Para determinados desplegadores de sistemas de IA de alto riesgo, debe realizarse antes del primer uso. Analiza cómo el uso previsto puede afectar a las personas o grupos afectados y se relaciona con el contexto de despliegue. Puede incluir riesgos de discriminación, acceso desigual a servicios, dignidad, protección de menores, libertad de expresión, tutela efectiva u otras garantías, además de riesgos vinculados a datos personales.

A estas capas se suman la seguridad técnica y el riesgo operativo. La primera abarca, entre otras materias, robustez, fallos, ciberseguridad, degradación de rendimiento y trazabilidad. La segunda observa cómo las personas usan el resultado: presión por cumplir objetivos, automatización excesiva, falta de tiempo para revisar, ausencia de vías de corrección o incentivos que convierten una recomendación en una decisión automática de hecho. Un expediente sólido conecta las cuatro, pero no las confunde ni presume que superar una prueba técnica elimina los riesgos jurídicos o sociales.

Árbol de decisión antes del despliegue

No hay una regla fiable que convierta cualquier uso de IA en una DPIA, ni otra que permita descartarla porque exista revisión humana. La decisión exige reunir hechos del caso y contrastarlos con el RGPD, las listas de tratamientos sujetas a DPIA publicadas por la autoridad de control competente y, cuando proceda, el Reglamento de Inteligencia Artificial.

Primero, determine si hay datos personales. Pueden estar en los datos de entrada, en los registros de uso, en los resultados o en las inferencias. Después, identifique si concurren factores que suelen elevar el riesgo: categorías especiales de datos, perfilado, evaluación sistemática, decisiones con efectos jurídicos o efectos significativamente similares, observación sistemática, gran escala, personas vulnerables, combinación de conjuntos de datos, tecnologías novedosas o una relación de poder asimétrica. Estos factores no operan como una lista mecánica; sirven para justificar una conclusión y para no pasar por alto riesgos previsibles.

A continuación, analice si el sistema y su uso previsto se encuentran dentro de una categoría de alto riesgo del Reglamento de Inteligencia Artificial. La clasificación depende del uso efectivo y de las categorías normativas pertinentes, no del nombre del producto ni de una declaración comercial. Si lo es, debe verificarse si el desplegador pertenece a los supuestos obligados a realizar una evaluación de impacto en los derechos fundamentales antes del primer uso. Cuando el flujo también procesa datos personales con probable alto riesgo, es posible que sean necesarias ambas evaluaciones.

Si, tras las medidas previstas, el tratamiento sigue entrañando un alto riesgo que el responsable no puede mitigar, el RGPD establece la consulta previa a la autoridad de control antes de iniciar el tratamiento. La conclusión no debe presentarse como un mero riesgo aceptado internamente si la norma exige esa consulta.

Qué debe contener una DPIA y por qué no equivale a un aviso de privacidad

La DPIA debe incluir una descripción sistemática de las operaciones de tratamiento y de sus fines, incluida la finalidad legítima perseguida cuando corresponda. También debe contener una evaluación de la necesidad y proporcionalidad, una valoración de los riesgos para los derechos y libertades de las personas y las medidas previstas para afrontarlos. Por tanto, no basta con enumerar categorías de datos, incorporar cláusulas genéricas de seguridad o afirmar que existe interés empresarial en automatizar.

En un flujo de IA, la descripción sistemática debería alcanzar la recogida, preparación, entrenamiento cuando exista, inferencia, validación, intervención humana, comunicación del resultado, registros y eliminación. Debe identificar tanto los datos directos como las inferencias. Por ejemplo, una puntuación de fraude, una prioridad clínica o una predicción de abandono pueden ser datos personales si se refieren a una persona identificada o identificable y se usan para evaluarla.

Una política de privacidad informa a las personas sobre un tratamiento y puede ser necesaria para cumplir deberes de transparencia. Sin embargo, no sustituye la evaluación interna previa de riesgos, necesidad, proporcionalidad y medidas. Tampoco una evaluación genérica elaborada por el proveedor sustituye el análisis del responsable, porque el proveedor normalmente no conoce con precisión la población atendida, los datos locales, los umbrales, la acción decidida por el personal ni los recursos de reclamación disponibles.

Las listas de tratamientos que requieren DPIA y las listas de excepciones pueden variar según la autoridad de control competente. Una organización que opere en varios Estados miembros debe documentar qué autoridad y qué lista ha considerado. Cuando haya duda razonable, una evaluación proporcionada y temprana puede revelar que el diseño debe cambiar antes de que el coste de revertirlo sea alto.

Evaluación de impacto en derechos fundamentales: alcance y coordinación con la DPIA

El Reglamento de Inteligencia Artificial prevé una evaluación de impacto en los derechos fundamentales para determinados desplegadores antes del primer uso de sistemas de IA de alto riesgo. El deber no se activa por cualquier software que use IA. Requiere verificar tanto que el sistema entra en las categorías de alto riesgo aplicables como que el desplegador encaja en los supuestos previstos por la norma. Entre los contextos que requieren atención especial se encuentran determinados usos por organismos públicos o entidades que prestan servicios públicos y ciertos usos de alto riesgo relacionados con ámbitos como crédito, seguros o servicios de emergencia, según la clasificación y el alcance normativo aplicable.

La evaluación debe ser contextual. Un mismo sistema puede presentar riesgos distintos si se usa para apoyar una cola de trabajo interna, para filtrar acceso a un servicio esencial o para priorizar actuaciones que afectan a una persona. Debe describir grupos que puedan verse afectados, posibles consecuencias, medidas de supervisión humana y mecanismos de información y reclamación que resulten pertinentes. También debe tener en cuenta si hay barreras prácticas para impugnar o corregir un resultado.

Cuando el sistema procesa datos personales y la DPIA es obligatoria, las dos evaluaciones deben coordinarse, no duplicarse de forma ciega. Un inventario común de datos, finalidad, participantes, versiones y controles reduce incoherencias. Aun así, debe conservarse una respuesta diferenciada para cada obligación: la DPIA ha de demostrar el análisis exigido por el RGPD, mientras que la evaluación de derechos fundamentales debe responder a los elementos del Reglamento de Inteligencia Artificial aplicables al despliegue.

El calendario de aplicación del Reglamento de Inteligencia Artificial contiene reglas transitorias y ha sido objeto de modificaciones. Antes de concluir que una obligación ya resulta exigible para un caso concreto, documente la fecha de uso previsto, la versión normativa consultada, la categoría del sistema y la disposición transitoria aplicable. Esta guía no sustituye esa comprobación jurídica específica.

Inventario mínimo y pruebas que deben acompañar al expediente

Antes de medir precisión o sesgo, construya un inventario que permita reproducir el análisis. Debe fijar la finalidad aprobada y las finalidades excluidas; la base y límites del tratamiento; los orígenes de datos; los atributos proporcionados, observados e inferidos; las personas afectadas; los destinatarios; los periodos de conservación; el proveedor; el modelo y su versión; los umbrales; y las acciones que el resultado permite o desencadena. Si una organización no puede describir estos elementos, difícilmente podrá demostrar necesidad, proporcionalidad o trazabilidad.

Las pruebas deben responder a los daños plausibles, no sólo a una métrica agregada. Si una puntuación decide el orden de atención, importan los falsos negativos que retrasan casos urgentes y los falsos positivos que desplazan injustamente otros casos. Si el rendimiento puede diferir por grupos, la evaluación debe explicar qué grupos se han analizado, por qué son relevantes, qué limitaciones tienen los datos de prueba y qué se hará si no existe evidencia suficiente. En algunos casos, recopilar atributos para medir disparidades crea a su vez riesgos de protección de datos; esto exige una justificación y salvaguardas específicas, no una omisión automática del análisis.

También deben probarse abstención y degradación. Un sistema puede ser más seguro si se abstiene cuando la información es incompleta o su confianza no supera un umbral, pero esa abstención ha de enviar el caso a una ruta humana real y dentro de plazos definidos. Simule incidentes: datos erróneos, cambios de población, caída de un proveedor, resultados incoherentes, solicitudes de acceso o rectificación, y presión operativa para omitir revisiones. Registre qué evidencia permitiría detectar el problema y quién actuaría.

Controles de rediseño, riesgo residual y autoridad para detener el sistema

La salida de una evaluación no debe reducirse a aprobar o rechazar un producto. A menudo permite rediseñar el flujo para reducir exposición y daño. Entre las opciones están minimizar variables, no usar categorías especialmente sensibles cuando no sean necesarias, separar una recomendación de la decisión final, limitar el sistema a una tarea administrativa, reducir la escala inicial, elevar el umbral de abstención, impedir determinados usos secundarios y habilitar una revisión competente antes de efectos adversos.

La revisión humana sólo es un control si tiene capacidad, información, tiempo y autoridad. Una persona que confirma cientos de puntuaciones por hora o que no conoce las limitaciones del modelo puede aportar una apariencia de control sin modificar el riesgo. Defina qué resultados requieren revisión, qué señales permiten anular la recomendación, qué formación recibe el equipo, qué plazo aplica y cómo se registra la discrepancia. Las anulaciones pueden revelar un problema de datos, de umbral o de diseño que obliga a reabrir la evaluación.

El riesgo residual debe describirse de forma concreta: qué daño sigue siendo posible, a quién puede afectar, con qué probabilidad y gravedad estimadas, qué controles quedan activos y qué incertidumbres persisten. La aceptación no puede quedar implícita. Debe asignarse a una persona o órgano con competencia para asumirla y debe coexistir con una autoridad independiente para parar o revertir el sistema cuando se active un umbral de seguridad, calidad, discriminación, incumplimiento o incidente.

Reabra la evaluación antes de cambios materiales, no después de que el daño ocurra. Son disparadores habituales el cambio de modelo, proveedor, datos, población, finalidad, umbral, integración, acción automática, volumen, normativa aplicable o evidencia de rendimiento desigual. Las revisiones periódicas ayudan, pero no reemplazan estos disparadores basados en cambios concretos.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.