Derecho y NBIC: ANALIZAR EL ESTADO DE UN MODELO DE IA RESPECTO AL RGPD

Por: Carlos A. FERREYROS SOTO

Doctor en Derecho

Universidad de Montpellier I Francia.

RESUMEN

La CNIL publicó el 22 de julio de 2025 una ficha práctica destinada al análisis de sí un modelo de IA, entrenado sobre datos personales; se encuentra sujeto al Reglamento de Protección de Datos Personales, RGPD o considerado como anónimo.

El objetivo es de ayudar a los proveedores a determinar si su modelo es anónimo o está sujeto al RGPD, en caso de introducción de datos personales.

Los criterios de aplicabilidad de un modelo se rigen por el RGPD si es probable que se re identifique a las personas por medios razonables, como se indica en la Opinión del 28/2024 del SEPD (extracción y regurgitación de datos) Supervisor Europeo de Protección de Datos, SEPD.

La apariencia de identificación debe ser insignificante para calibrar el modelo como anónimo; de lo contrario, se aplican las normas de legalidad, derechos de las personas, información y seguridad de los datos.

Los sistemas de encapsulamiento de un modelo también presentan sus propios problemas, debido a la obligación de documentación para garantizar su conformidad. Los Modelos de IA entrenados con datos personales son relevantes para el RGPD si la extracción o regurgitación de estos datos es posible a través de medios razonablemente accesibles, y según la opinión del SEPD.

El análisis se extiende a los sistemas integrados en un modelo no anónimo, con documentación obligatoria para demostrar su cumplimiento.

La metodología del análisis comporta tres etapas:

Etapa 1: Evaluar los índices de memorización (datos raros/atípicos, tamaño del modelo, IA generativa, etc.).

Etapa 2: Efectuar Pruebas de ataque por dificultad creciente (regurgitación, inferencia de pertenencia, ex filtración, inversión/reconstrucción del modelo), considerando medios razonables (costo, acceso, estado del arte).

Etapa 3: Gobernanza de documentos que incluyen información (Análisis de Impacto de la Protección de Datos, Delegado de Protección de Datos), técnicas de medidas (anonimización, confidencialidad diferencial), resultados de datos y datos residuales.

El presente documento ha sdo traducido por el suscrito con la ayuda del aplicativo Google Translator. El enlace al documento oiginal es: https://www.cnil.fr/fr/ia-analyser-le-statut-dun-modele-dia-au-regard-du-rgpd

A fin de acceder a normas similares y estándares europeos, las empresas, organizaciones públicas y privadas interesadas en asesorías, consultorías, capacitaciones, estudios, evaluaciones, auditorías sobre el tema, sírvanse comunicar al correo electrónico:cferreyros@ferreyros-ferreyros.com

________________________________________________________

IA: Analizar el estado de un modelo de IA con respecto al RGPD

22 de julio de 2025

Los modelos de IA pueden estar sujetos al RGPD si almacenan datos personales de su entrenamiento. La CNIL (Comisión Nacional de Informática y Libertades) ofrece un método para que los proveedores evalúen si sus modelos están sujetos al RGPD.

Los modelos de IA pueden ser anónimos: en ese caso, el RGPD no se aplica a ellos.

En algunos casos, los modelos de IA almacenan algunos de los datos utilizados para su entrenamiento, lo que permite extraer datos personales si estaban presentes en el conjunto de datos de entrenamiento. Cuando esta extracción se realiza mediante métodos razonablemente viables, estos modelos entran en el ámbito de aplicación del RGPD. La CNIL (Comisión Nacional de Informática y Libertades) ayuda a los proveedores de modelos a determinar si esto aplica.

¿De qué estamos hablando?

Propósito de la ficha

Este documento, destinado a los proveedores, detalla la metodología para evaluar y documentar la probabilidad de volver a identificar personas físicas a partir de un modelo de IA entrenado con datos personales o un Sistema de IA basado en un modelo que no puede considerarse anónimo.

Tras este análisis, salvo que la probabilidad sea insignificante, el RGPD se aplicará a las actividades de tratamiento relacionadas con el modelo o sistema. En este documento, la conclusión del análisis sobre la aplicabilidad del RGPD se denominará «estado de un modelo o uso de un sistema».

Este análisis nos permitirá, cuando corresponda, extraer conclusiones sobre la aplicación del RGPD, en particular mediante una evaluación precisa de la probabilidad de re identificación asociada a cada tipo de datos personales en el conjunto de datos de entrenamiento. Una futura guía práctica aclarará las consecuencias de la aplicación del RGPD al tratamiento de datos que involucra un modelo de IA.

Las dos figuras siguientes resumen la realización del análisis en las dos situaciones siguientes:

· Figura 1: Realización del análisis como proveedor o agente del estado de un modelo de IA.

· Figura 2: Realización de análisis como implementador del estado de un sistema de IA basado en un modelo no anónimo.

Figura 1 - Análisis de estado de un modelo de IA.

Figura 2 - Análisis del estado de un sistema de IA basado en un modelo no anónimo.

Modelos y sistemas de IA relevantes

Un modelo de IA es una representación estadística de las características del conjunto de datos utilizado para entrenarlo. Numerosos estudios académicos han demostrado que, en algunos casos, esta representación es lo suficientemente detallada como para dar lugar a la divulgación de los datos de entrenamiento. Esta divulgación puede manifestarse como regurgitación de datos durante el uso, como en el caso de los sistemas de IA generativos, o como resultado de un ataque como los descritos en el artículo de LINC « Una breve taxonomía de ataques a sistemas de IA ». Como se aclara en el dictamen del Comité Europeo de Protección de Datos (CEPD) (véase el recuadro) , cuando sea posible, intencionadamente o no, que un modelo o sistema de IA regurgite o se extraigan datos personales utilizando medios razonablemente previsibles, el RGPD se aplica al tratamiento de datos relativos al modelo o sistema de IA.

Por lo tanto, el análisis de estado se refiere a cualquier modelo de IA entrenado con datos personales o a cualquier sistema de IA que incorpore un modelo de IA no anónimo. Si el análisis de estado de un modelo de IA concluye que está excluido del ámbito de aplicación del RGPD, también queda excluido cualquier sistema de IA que se base exclusivamente en dicho modelo.

Enfoque en el Dictamen 28/2024 del CEPD sobre determinados aspectos de la protección de datos relacionados con el tratamiento de datos personales en el contexto de los modelos de IA

El Comité Europeo de Protección de Datos Personales, CEPD ha emitido un dictamen sobre el uso de datos personales para el desarrollo e implementación de modelos de IA. Este dictamen examina 1) cuándo y cómo los modelos de IA pueden considerarse anónimos, 2) si el interés legítimo puede utilizarse como base jurídica y, de ser así, cómo, y 3) las consecuencias, según el RGPD, del desarrollo de un modelo de IA con datos personales que han sido tratados ilícitamente.

En cuanto a la situación de los modelos de IA, el dictamen reitera que las autoridades de protección de datos deben evaluar caso por caso si un modelo es anónimo. Especifica, en particular:

· Sí un modelo diseñado específicamente para producir o inferir información sobre las personas físicas presentes en su conjunto de entrenamiento contiene datos personales. Está sujeto al RGPD.

· Para que un modelo entrenado en particular con datos personales, pero que no está diseñado específicamente para producir o inferir información sobre esas personas, sea anónimo, debe ser muy improbable (1) que alguien identifique directa o indirectamente a las personas cuyos datos se usaron para crear el modelo a partir de los parámetros del modelo ("ataques de caja blanca"), y (2) que extraiga esos datos personales del modelo a través de consultas.

El aviso proporciona una lista no prescriptiva y no exhaustiva de métodos para demostrar el anonimato, en la que se basa esta hoja de métodos.

Necesidad de analizar el estado del modelo o sistema de IA

Todo responsable del tratamiento de datos debe documentar adecuadamente la conformidad de su tratamiento de datos personales (de acuerdo con el principio de rendición de cuentas), por ejemplo en una evaluación de impacto de la protección de datos.

Así, cuando el entrenamiento de un modelo de IA se realiza utilizando una base de datos que contiene datos personales, se debe realizar un análisis de forma sistemática para determinar si el RGPD se aplica al modelo de IA para poder extraer las conclusiones adecuadas en caso necesario.

El proveedor del modelo (a quien va dirigido este documento) será generalmente responsable de este proceso de desarrollo, ya que determina la finalidad y las características del modelo (su uso previsto, funcionalidades, contexto de implementación, etc.), así como los datos personales de entrenamiento. Cuando el proveedor concluya que el modelo de IA no está sujeto al RGPD, deberá disponer de la documentación del análisis del estado del modelo para su presentación a las autoridades de protección de datos, como la CNIL. Esta documentación debe demostrar que la probabilidad de re identificar a las personas cuyos datos contenga la base de datos de entrenamiento del modelo o sistema es mínima.

Por tanto, la documentación debe detallar las medidas adoptadas durante el entrenamiento del modelo para limitar la probabilidad de reidentificación a partir de un acceso al mismo y, en la mayoría de los casos, incluir los resultados de la realización de pruebas de ataque de reidentificación.

Cuando un modelo de IA no pueda considerarse anónimo, es posible mitigar la probabilidad de reidentificación de personas integrándolo en un sistema de IA que implemente medidas robustas para evitar la extracción de datos. En algunos casos, estas medidas pueden permitir que el uso del sistema quede fuera del ámbito de aplicación del RGPD. Por lo tanto, el proveedor de dicho sistema debe realizar y documentar su análisis, que debe incluir, en todos los casos, los resultados de las pruebas de ataques de reidentificación realizadas al sistema.

Cuando un proveedor de sistemas de IA que incorpora un modelo de IA no anónimo declara que su uso ya no está sujeto al RGPD, la CNIL recomienda compartir o publicar documentación suficiente para que los usuarios puedan verificar esta condición y demostrar así que no están tratando datos personales contenidos en el modelo. Para los proveedores de modelos de IA analizados como anónimos, compartir este análisis es una buena práctica.

Para la distribución de un modelo de IA no anónimo por parte de su proveedor, las obligaciones aplicables (incluida la documentación) se detallarán en un documento posterior. Estas obligaciones también se aplicarán cuando el modelo en cuestión se comparta con un tercero que pretenda integrarlo en un sistema para excluirlo del ámbito de aplicación del RGPD.

Consecuencias cuando los modelos o sistemas de IA no se consideran anónimos

El proveedor de un modelo o sistema de IA sujeto al RGPD debe cumplir con sus obligaciones en virtud del RGPD y, en Francia, de la Ley de Protección de Datos.

Lo mismo se aplicará a cualquier actor de la cadena (otro proveedor de sistemas de IA, distribuidor, implementador, etc.) que tendrá que cumplir con las obligaciones del RGPD para poder manejarlos o utilizarlos.

Esto implicará garantizar la licitud del tratamiento, informar a las personas, posibilitar el ejercicio de derechos, garantizar la seguridad del modelo, etc.

En la práctica, la conformidad del modelo con el RGPD depende en gran medida del proveedor; una futura guía práctica ayudará a las partes interesadas a determinar sus obligaciones. La aplicación de estos requisitos, así como el nivel de las garantías asociadas, dependerá de la naturaleza de los datos personales contenidos en el modelo y de los que puedan extraerse de él.

Nota importante: El RGPD puede aplicarse al uso de un modelo o sistema de IA incluso si su proveedor lo considera anónimo. Esta situación se analiza con más detalle al final de este documento.

Implementación del análisis

Documentar la realización del análisis de estado de un modelo de IA o un sistema basado en un modelo no anónimo

Esta sección tiene como objetivo orientar a los responsables del tratamiento de datos. En la documentación del análisis de estado de un modelo de IA o del uso de un sistema basado en un modelo no anónimo. La siguiente tabla proporciona una lista no exhaustiva de información que debe incluirse en la documentación de un modelo o sistema.

Tipo de información	Documento	Condición para incluir la información en la documentación de análisis de estado
Tipo de información	Documento	Caso de un modelo de IA entrenado con datos personales	Caso de utilización de un Sistema de IA basado en un modelo de IA no anónimo
Gobernanza general	Cualquier información relativa a una evaluación de impacto sobre la protección de datos (EIPD), incluida cualquier evaluación o decisión que haya concluido que no era necesaria	Tan pronto como exista la información	Tan pronto como exista la información
	Cualquier consejo u opinión expresada por el Delegado de Protección de Datos (DPD)(cuando se haya designado o se deba haber designado un DPO)	Tan pronto como exista la información	Tan pronto como exista la información
	Documentación sobre riesgos residuales	Incluir, en su caso, la documentación que se prevé transmitir al responsable del tratamiento que implemente el sistema y/o a los interesados, en particular, la documentación relativa a las medidas adoptadas para reducir la probabilidad de reidentificación y relativa a los posibles riesgos residuales.	Incluir, en su caso, la documentación que se prevé transmitir al responsable del tratamiento que implanta el sistema por parte de su proveedor.
Gobernanza técnica	Cualquier información sobre las medidas técnicas y organizativas adoptadas durante la fase de diseño para reducir la probabilidad de reidentificación, incluidos escenarios de una amplia gama de atacantes (desde el más débil al más fuerte) y la evaluación de riesgos en la que se basan estas medidas.	Incluya las medidas específicas adoptadas para cada fuente o tipo de fuente de datos de entrenamiento, incluyendo, cuando sea pertinente, las URL de las fuentes en las que el responsable del tratamiento de datos ha adoptado dichas medidas (o ya las ha adoptado el distribuidor en el caso de datos puestos a disposición por un tercero).	Incluya las medidas específicas adoptadas para cada fuente o tipo de fuente de datos almacenada por el modelo, incluyendo, cuando sea pertinente, las URL de las fuentes en las que el responsable del tratamiento de datos ha adoptado dichas medidas (o ya las ha adoptado el distribuidor en el caso de un modelo puesto a disposición por un tercero).
Gobernanza técnica	Medidas técnicas y operativas adoptadas en cualquier etapa del ciclo de vida que hayan: (i) contribuido a o; (ii) verificado la ausencia de datos personales en el modelo o mediante el uso del sistema.	Tan pronto como exista la información	Tan pronto como exista la información
Resistencia a los ataques	Documentación ex ante que demuestra la resistencia teórica a las técnicas de reidentificación	Tan pronto como exista la información. Esto puede incluir, en particular, un análisis teórico basado en el estado del arte (por ejemplo, considerando la relación entre la cantidad de datos de entrenamiento y el tamaño del modelo, o que tenga como objetivo estudiar la capacidad intrínseca de un modelo para memorizar datos).	Tan pronto como exista la información. Esto puede incluir, en particular, un análisis teórico a la luz del estado de la técnica (por ejemplo, considerando la existencia de técnicas que permitan eludir medidas como los filtros de salida).
Resistencia a los ataques	Los resultados de las pruebas de ataque de reidentificación ex post : · Métricas sobre la probabilidad de reidentificación con respecto al estado actual de la técnica; · Informes sobre cómo se probó el modelo (quién, cuándo, cómo y en qué medida); · Los resultados de las pruebas de reidentificación realizadas por una amplia gama de atacantes (desde el más débil al más fuerte).	En la mayoría de los casos, se determina mediante un conjunto de indicadores. Véase más abajo.	En todos los casos.

Caracterizar la necesidad de realizar pruebas de ataques de reidentificación en un modelo de IA

Un conjunto de indicadores ayuda a determinar si es necesaria una prueba de ataque de reidentificación para evaluar el estado del modelo. Es responsabilidad del responsable del tratamiento evaluar el riesgo revelado por uno o más de estos indicadores. En ocasiones, un solo indicador basta para demostrar que el riesgo de memorizaciónes alto, pero en otros casos, este mismo índice puede tener menor peso. En tales casos, deben examinarse otros criterios. Esta lista de índices es indicativa y puede evolucionar según el estado del arte, así como la comprensión científica del fenómeno de la memorización en los modelos.

La verificación de la ausencia de estos indicadores no proporciona certeza sobre la ausencia de memorización y nunca permite excluir la necesidad de un ensayo de ataque de reidentificación: constituyen indicios que llevan a considerar que se debe realizar un análisis más profundo.

Por ejemplo, en el caso de la IA generativa, la regurgitación La memorización de ciertos datos de entrenamiento, no necesariamente personales, puede demostrarse en ocasiones mediante pruebas rápidas (como consultas específicas). Esta prueba permite concluir positivamente sobre la memorización, pero no la descarta si no se recuperan datos. Esto también aplica a los criterios que se enumeran a continuación: cuando un indicador no se cumple, no permite considerar individualmente la probabilidad de reidentificación suficientemente baja, y también deben tenerse en cuenta los demás indicadores.

Evidencia de la presencia de datos personales en el modelo

Índices relacionados con el conjunto de datos de entrenamiento

El carácter identificativo y preciso de los datos del conjunto de entrenamiento, como la presencia de nombres, apellidos, fotografías faciales, extractos de voz, direcciones o fechas exactas de nacimiento.

Para mitigar este índice: considere eliminar información de identificación o, cuando sea posible, utilizar técnicas de generalización, agregación, perturbación aleatoria o seudonimización de datos.

La heterogeneidad de los datos, o la presencia de datos raros o atípicos, correspondientes a individuos únicos o cuyas características estadísticas son minoritarias en el conjunto de datos de entrenamiento, puede provocar un sobreajuste. Esto aumenta la probabilidad de sobreajuste del modelo al desviarse de la distribución estadística teórica de los datos de entrenamiento. Como resultado, el proceso de entrenamiento del modelo tenderá a priorizar su memorización.

Para mitigar este índice: realice un análisis estadístico preliminar del conjunto de datos de entrenamiento para identificar y luego eliminar datos raros o atípicos, o realice agregaciones para suavizar la distribución estadística de los datos de entrenamiento.

La duplicación de datos de entrenamiento, es decir, la presencia de repeticiones exactas o aproximadas en ellos, suele ser un factor que provoca sobreajuste y la memorización de estos datos. Dado que se representan varias veces en la distribución estadística teórica de los datos de entrenamiento, los datos personales duplicados tenderán a memorizarse primero.

Para mitigar este índice: filtre el conjunto de datos de entrenamiento para eliminar duplicados exactos y aproximados mediante de duplicación.

Pistas relativas a la arquitectura del modelo y su entrenamiento

El gran número de parámetros del modelo en relación con el volumen de datos de entrenamiento. Un mayor número de parámetros tenderá a permitir un modelado más refinado de los datos de entrenamiento, lo que facilita el aprendizaje de las características de los datos y no solo de su distribución estadística. Cabe destacar que el umbral para el número de parámetros que indica un alto riesgo de memorización debe determinarse en función del contexto, en particular de la funcionalidad del modelo y el volumen de datos de entrenamiento.

Para mitigar este índice: utilizar, especialmente basándose en el estado del arte, modelos que utilicen menos parámetros.

Un sobreajuste potencial, por parte de una métrica relevante, significa que un modelo ha aprendido una distribución estadística demasiado cercana a los datos de entrenamiento.

Para mitigar este índice :

· Implementar medidas para limitar el sobreajuste, como la regularización explícita de la función de costos, o medidas implícitas como el abandono ;

· Evalúe el nivel de sobreajuste del modelo durante las etapas de entrenamiento y detenga el entrenamiento antes de que aparezca este fenómeno.

La falta de garantías de confidencialidad en el algoritmo aprendizaje, como la confidencialidad diferencial (privacidad diferencial).

Para mitigar este índice: Implementar medidas para limitar el impacto de los datos en el aprendizaje, tales como: algoritmos que garanticen niveles satisfactorios de confidencialidad diferencial (por ejemplo, añadiendo ruido a los datos).gradiente en la optimización de la función de costo del modelo).

El uso de datos personales durante el ajuste o perfeccionamiento del modelo y el aprendizaje por transferencia, o aprendizaje por transferencia. Esta fase, al igual que el entrenamiento de un modelo ab initio, puede llevar a la memorización de los datos de entrenamiento.

Para mitigar este índice: considere anonimizar los datos de ajuste o utilizar algoritmos que proporcionen garantías formales de confidencialidad para el ajuste (por ejemplo, expresadas en términos de confidencialidad diferencial).

Pistas relativas a las funcionalidades y usos del modelo

Funciones destinadas a reproducir datos similares a los datos de entrenamiento, como la generación de contenido o la síntesis de datos de texto.

En el caso específico de la IA generativa, la generación mediante consultas (prompts) de datos no necesariamente personales contenidos en el conjunto de entrenamiento (texto, imagen, audio, vídeo), presumiblemente relacionados con los datos de entrenamiento.

La consecución de ataques exitosos al tipo de modelo desarrollado en un contexto comparable, tal y como documentan publicaciones científicas o artículos de prensa.

Los ejemplos que figuran a continuación pretenden ilustrar la aplicación práctica de este conjunto de indicadores:

· Un gran modelo de lenguaje es entrenado por una organización con conjuntos de datos de texto masivos disponibles gratuitamente en internet. La organización reutilizó estos conjuntos de datos tal cual, sin modificar su contenido. La presencia de datos personales en los conjuntos de datos puede sospecharse dada la amplia variedad de fuentes de las que provienen, la falta de medidas de anonimización y la funcionalidad del modelo. Este conjunto de evidencias lleva a la conclusión de que es necesario realizar pruebas de ataques de reidentificación.

· Un modelo utilizado en el campo de la salud ambiental para predecir el riesgo de desarrollar cáncer de pulmón en una población expuesta a ciertos contaminantes atmosféricos se entrena con los datos geográficos, el historial médico y los hábitos de vida de los pacientes. Dado que algunas áreas de la región de estudio están sub representadas en la base de datos, los datos de algunos pacientes constituyen valores atípicos en la distribución geográfica de toda la cohorte. Dado el riesgo de que un atacante pueda utilizar las puntuaciones de predicción obtenidas al realizar inferencias en el modelo entrenado con los datos de estos individuos para determinar si padecen cáncer de pulmón, el criterio de valores atípicos se considera suficiente para considerar la realización de pruebas de ataque de reidentificación, según sea necesario.

· Se utiliza una base de datos de consumo energético recopilada de varios hogares para entrenar una red neuronal que reconozca electrodomésticos. Si un electrodoméstico se encuentra solo en un pequeño número de estos hogares (se trata de un punto de datos poco común), la red neuronal entrenada podría tener una mayor fiabilidad en sus predicciones al utilizar datos de los hogares del conjunto de entrenamiento que poseen dicho electrodoméstico. Esta diferencia puede utilizarse para determinar en qué hogares se realizó la recopilación de datos (ataque de inferencia de pertenencia). Se cumplen dos criterios: la presencia de datos dispersos y el uso de un modelo con un gran número de parámetros. Se considera necesario realizar pruebas contra ataques de reidentificación.

Realizar pruebas de ataque de reidentificación en un modelo de IA

En la mayoría de los casos, especialmente con base en la evidencia anterior, será necesario someter un modelo de IA entrenado con datos personales a ataques de reidentificación, lo que puede constituir un medio razonablemente probable para re identificar a individuos. Estas pruebas de ataque buscan estimar la probabilidad de re identificar a personas físicas a partir del modelo. Para concluir que el modelo es anónimo, esta probabilidad de extracción por medios razonables debe ser insignificante.

· Determinar los medios que pueden implementarse razonablemente para extraer datos de un modelo de IA

Caracterizar los medios que el responsable del tratamiento de datos o cualquier otra persona podría razonablemente esperar implementar es un paso esencial para realizar el análisis del estado del modelo. Esta caracterización debe basarse en criterios objetivos, que pueden incluir:

· información adicional que permita la reidentificación y que sea accesible a la persona;

· el coste y el tiempo que necesita dicha persona para obtener esta información adicional;

· el estado del arte en la tecnología disponible y en desarrollo, particularmente en lo que respecta a las técnicas para extraer datos de modelos de IA.

La evaluación de las medidas razonablemente viables debe considerar la posibilidad de acceso al modelo no solo por parte del responsable del tratamiento, sino también por parte de terceros que no deberían haber tenido acceso. Si bien las medidas para reducir la probabilidad de extracción de datos personales pueden implementarse durante las fases de desarrollo e implementación de un modelo de IA, la evaluación del anonimato del modelo también debe considerar la posibilidad de acceso directo al mismo.

Restringir el acceso a los datos (o al modelo) no garantiza sistemáticamente el anonimato. Sin embargo, un acceso limitado puede reducir la probabilidad de reidentificación (sin que esta sea automáticamente insignificante). De hecho, los medios que razonablemente se puedan utilizar para extraer datos personales pueden depender del contexto en el que se desarrolla e implementa un modelo. Por lo tanto, los niveles requeridos de pruebas y resistencia a ataques pueden variar en función de este contexto. Por lo tanto, la conclusión del análisis puede diferir entre un modelo accesible públicamente a un número ilimitado de usuarios y un modelo interno de una empresa con acceso limitado a un número reducido de empleados, como se detalla más adelante en este documento sobre el análisis de sistemas de IA basados en modelos no anónimos.

Los criterios descritos anteriormente tienen en cuenta las especificidades técnicas de los modelos de IA y su diseño. Por consiguiente, no pueden aplicarse automáticamente al análisis de la anonimización en otros campos. Además, las garantías legales y contractuales destinadas a limitar el acceso o el uso de un modelo no sustituyen las técnicas de anonimización que podrían implementarse en el conjunto de datos de entrenamiento o durante la fase de aprendizaje, sino que las complementan.

· Probando el modelo de IA y su resistencia a los ataques

La siguiente lista proporciona criterios que pueden utilizarse para evaluar la probabilidad de extracción de datos personales mediante técnicas de ataque por parte de un modelo de IA entrenado con dichos datos.

La pertinencia del alcance, la frecuencia, la cantidad y la calidad de las pruebas de extracción de datos que el responsable del tratamiento ha realizado en el modelo debe evaluarse a la luz del estado de la técnica, así como de los recursos razonablemente disponibles en relación con el modelo. Estas pruebas pueden incluir, en particular:

· Pruebas de regurgitación de datos de entrenamiento, en el caso de modelos de IA generativos;

· Ataques basados en la inferencia de membresía;

· Ataques de ex filtración;

· Ataques de inversión de modelos;

· Ataques por reconstrucción;

· Una medida de la memorabilidad intrínseca de la arquitectura del modelo.

Cabe señalar que no se puede suponer que la resistencia a una técnica que implementa uno de estos tipos de ataque garantice la resistencia a otra técnica.

· Recomendaciones sobre la realización de pruebas y ataques

Algunos de los tipos de ataque descritos anteriormente requieren conocimientos técnicos y recursos exigentes para su implementación. Por lo tanto, se recomienda ejecutar los ataques al modelo de IA en orden creciente de dificultad de implementación. Cuando un ataque permite la extracción de datos personales del modelo de IA, es necesario determinar qué tipo de datos personales están involucrados en dicha extracción. El responsable del tratamiento de datos puede entonces optar por:

· Detenga el análisis en esta etapa , considerando que todos los tipos de datos presentes en el conjunto de entrenamiento se pueden extraer con la probabilidad dada por el ataque más fácil que tuvo éxito en un tipo particular;

· Continúe el análisis realizando todas las pruebas y ataques que sea razonablemente probable implementar, para determinar la probabilidad de extracción asociada a cada tipo de datos de entrenamiento. Realizar pruebas adicionales de reidentificación puede, por ejemplo, ayudar a separar la probabilidad de extracción de los datos de pre entrenamiento y ajuste, que pueden presentar diferentes riesgos para las personas involucradas.

Ejemplo: La oficina de datos de un hospital desea desarrollar un modelo lingüístico extenso para facilitar la redacción de informes de consultas médicas. Para ello, pre entrena dicho modelo con datos públicos (para dotarlo de ciertas habilidades textuales) y, a continuación, realiza una fase de ajuste con un conjunto de datos de informes médicos previamente seudonimizados (para especializarlo en este tipo de texto). Tras la fase de ajuste con datos personales sensibles, el conjunto de pruebas concluye que son necesarias pruebas de ataque de reidentificación. Durante la fase de prueba y ataque, el responsable del tratamiento de datos comienza realizando consultas sencillas en el modelo para intentar extraer los datos de entrenamiento. Resulta que las consultas sencillas permiten extraer los datos personales presentes en el conjunto de datos de pre entrenamiento. En esta etapa, el responsable del tratamiento de datos puede:

· Dejar de realizar el análisis, considerando en las consecuencias de la aplicación del RGPD que todo tipo de datos de entrenamiento, incluidos los datos sensibles de la fase de ajuste pero que no han sido extraídos en esta etapa del análisis, pueden ser extraídos del modelo con ataques simples, y por tanto, hay una alta probabilidad;

· El análisis continuará utilizando ataques más complejos para evaluar con precisión la probabilidad de extracción de datos sensibles y refinar el análisis de las consecuencias de la aplicación del RGPD. Las medidas de seguridad que se implementarán variarán en función de si los datos personales contenidos en el modelo son de acceso público o si se trata de datos confidenciales y sensibles de la fase de ajuste.

Tras este análisis, el responsable del tratamiento de datos puede determinar si el RGPD se aplica a su modelo. De ser así, pueden surgir diversas consecuencias. Una futura guía práctica detallará las consecuencias de aplicar el RGPD al tratamiento relacionado con un modelo de IA.

Reducir la probabilidad de reidentificación de un sistema de IA basado en un modelo no anónimo

Cuando un sistema de IA se basa en un modelo de IA que entra en el ámbito de aplicación del RGPD, es posible implementar medidas que, si son suficientemente eficaces y robustas, podrían reducir la probabilidad de reidentificación de personas a un nivel mínimo. El uso de dicho sistema podría quedar entonces fuera del ámbito de aplicación del RGPD, en función de los resultados del análisis requerido. Para ello, el proveedor del sistema de IA que se pretende anonimizar debe evaluar la probabilidad de reidentificación, en particular mediante pruebas de ataque al sistema. Esta sección pretende guiar este análisis.

Nota importante: Los siguientes desarrollos no son aplicables a otras formas de análisis de anonimización.

La siguiente lista detalla medidas que pueden reducir la probabilidad de reidentificación por parte de un sistema de IA que incorpore un modelo cuya probabilidad no sea despreciable. Esta lista es indicativa y no excluye la existencia de otras medidas suficientemente robustas para mitigar esta probabilidad.

Medidas para reducir la probabilidad de reidentificación a nivel del sistema

El modelo debe ser inaccesible o irrecuperable mediante interacciones con el sistema. Debe ser imposible para cualquier usuario del sistema, incluso si es malintencionado, acceder directamente al modelo o recuperarlo por cualquier medio razonablemente viable.

Restricciones de acceso al sistema , como:

· Acceso sujeto a autenticación y restringido únicamente a personal autorizado.

· asegurarse de que el usuario del sistema sea un humano, por ejemplo mediante el uso de CAPTCHA (prueba de Turing pública completamente automatizada para diferenciar computadoras de humanos); las restricciones de uso impuestas (por ejemplo en el número de inferencias por usuario –que no es suficiente por sí solo, por ejemplo en caso de colusión entre atacantes – o la posibilidad de modificar los parámetros del algoritmo de generación, como la temperatura);

· o cualquier otra medida que limite suficientemente la superficie de ataque del sistema.

Las modificaciones a los resultados del modelo ayudan a limitar el riesgo de reidentificación de personas mediante el acceso de usuarios al sistema. Por ejemplo, es posible:

· Limitar la precisión de los resultados del modelo a través del sistema, por ejemplo, redondeando, truncando o añadiendo ruido al vector de salida, requiere una implementación cuidadosa de estas medidas, que deben basarse en investigaciones fiables y adherirse a las mejores prácticas actuales. De hecho, algunas han demostrado ser ineficaces en la práctica (como limitar el resultado de un sistema de clasificación a un solo valor en lugar del vector completo: aunque parezca contradictorio, este filtro no ayuda a prevenir un ataque).

· Filtrar las salidas del modelo, por ejemplo, en el caso de la IA generativa, para detectar datos personales y evitar su exposición a los usuarios del sistema. Se debe tener mucho cuidado al implementar estas medidas; deben basarse en investigaciones fiables y adherirse a las mejores prácticas actuales. De hecho, algunas de ellas (como la ofuscación de la generación de nombres basada en una lista negra) han demostrado ser ineficaces en la práctica.

Medidas de seguridad destinadas a prevenir o detectar intentos de ataques, como el cifrado de modelos, el registro de acceso a los modelos, modificaciones y usos o el uso de métodos de autenticación fuertes.

Realizar pruebas de ataques de reidentificación en un sistema de IA basado en un modelo no anónimo

Estas pruebas tienen como objetivo estimar la probabilidad de extracción de datos personales a partir del uso del sistema y cualquier medio razonablemente previsible, incluidos los métodos de ataque con resultados probabilísticos. Para que el uso del sistema de IA se considere exento del RGPD, esta probabilidad de extracción debe ser insignificante.

· Determinar los medios que pueden implementarse razonablemente para extraer datos de un sistema de IA

Al igual que en el análisis del estado del modelo, caracterizar los medios que pueden implementarse razonablemente es un paso esencial para realizar el análisis del estado de uso del sistema. Esta caracterización debe basarse en criterios objetivos, que pueden incluir:

· el contexto en el que se implementa el sistema de IA, que puede incluir limitaciones de acceso y protecciones legales;

· el grado de acceso al funcionamiento interno del modelo mediante el uso del sistema;

· información adicional que permita la reidentificación y que sea accesible a la persona, incluso más allá de las fuentes de acceso público;

· el coste y el tiempo que necesita dicha persona para obtener esta información adicional;

· el estado del arte en la tecnología disponible y en desarrollo, particularmente en lo referente a las técnicas de extracción de datos de los sistemas de IA.

La evaluación de medidas razonablemente viables debe considerar la posibilidad de acceso al sistema por parte de cualquier persona, incluidas aquellas que no deberían haber tenido acceso. Cabe destacar que la simple restricción del acceso al modelo o al sistema no garantiza sistemáticamente el anonimato. Un acceso limitado puede reducir la probabilidad de reidentificación (aunque no la hace automáticamente insignificante).

Además, las salvaguardias legales y contractuales destinadas a limitar el acceso o el uso de un modelo no sustituyen las técnicas de anonimización, sino que pueden complementarlas. Por lo tanto, los niveles requeridos de pruebas y resistencia a los ataques pueden variar según el contexto. Por lo tanto, la conclusión del análisis puede diferir entre un sistema de IA de acceso público a un número ilimitado de usuarios y un sistema interno de la empresa con acceso limitado a un número reducido de empleados, aunque esta medida no puede sustituir minimización de la probabilidad de extraer datos personales del modelo.

· Probando el sistema de IA y su resistencia a los ataques

Esta sección tiene como objetivo orientar la evaluación de la probabilidad de reidentificación a través de ataques, mediante el uso del sistema por cualquier persona.

La idoneidad del alcance, la frecuencia, la cantidad y la calidad de las pruebas de extracción de datos que el responsable del tratamiento ha realizado en el sistema debe evaluarse a la luz del estado de la técnica, así como de los medios que razonablemente se puedan implementar para re identificar a las personas que utilicen el sistema, incluso en un futuro próximo. Estas pruebas pueden incluir, en particular:

· Pruebas destinadas a obtener acceso parcial o directo al modelo de IA mediante el uso del sistema;

· Pruebas de regurgitación de datos de entrenamiento, en el caso de modelos de IA generativos;

· Ataques basados en la inferencia de membresía;

· Ataques de ex filtración;

· Ataques de inversión de modelos;

· Ataques por reconstrucción.

Cabe señalar que no se puede suponer que la resistencia a una técnica que implementa uno de estos tipos de ataque garantice la resistencia a otra técnica.

· Recomendaciones sobre la realización de pruebas y ataques

Algunos de los tipos de ataques descritos anteriormente requieren conocimientos técnicos y recursos exigentes para su implementación. Por lo tanto, se recomienda lanzar ataques contra el sistema de IA en orden creciente de dificultad de implementación. Cuando un ataque permite la extracción de datos personales del sistema de IA, es necesario determinar qué tipo de datos personales están involucrados en dicha extracción. El responsable del tratamiento de datos puede entonces optar por:

· Detenga el análisis en esta etapa , considerando que todos los tipos de datos presentes en el modelo se pueden extraer con la probabilidad dada por el ataque más fácil que tuvo éxito en un tipo particular;

Casos en los que los modelos de IA o los sistemas que los incorporan quedan excluidos erróneamente del ámbito de aplicación del RGPD

La reidentificación de personas físicas a partir de un modelo puede materializarse incluso si su proveedor había considerado que su probabilidad era insignificante, por ejemplo, si el proveedor desconocía una vulnerabilidad o debido a la evolución de las técnicas de extracción de datos.

Por este motivo, en el marco de sus obligaciones de seguridad, la CNIL recomienda a los proveedores que comprueben periódicamente la validez de sus análisis (teniendo en cuenta la evolución del estado de la técnica) y anticipen posibles violaciones de datos que puedan producirse.

Una buena práctica consiste en proporcionar mecanismos para que los usuarios reporten incidentes (por ejemplo, mediante una función dentro de la interfaz del sistema, un formulario de contacto o la gestión de versiones del modelo). Esta práctica complementa las obligaciones del Reglamento Europeo de IA (RIA), que exige la supervisión posterior a la comercialización de los proveedores de sistemas de IA de alto riesgo (artículo 72 del RIA) y la notificación de estos riesgos por parte de los implementadores de dichos sistemas (artículo 26 del RIA).

Cuando se extraen datos personales, debe evitarse cualquier explotación de la vulnerabilidad y, siempre que sea posible, debe investigarse si la vulnerabilidad de reidentificación ha sido explotada y por quién. El proveedor también debe considerar si se trata de una violación de datos (en el sentido del artículo 33 del RGPD) y extraer las consecuencias, en particular documentar esta violación de datos (incluida la naturaleza de los datos, el método de difusión y las consecuencias resultantes), notificar a la CNIL en un plazo de 72 horas si esta violación puede entrañar riesgos para las personas, o incluso informar a las personas si los riesgos en cuestión son elevados (artículo 34 del RGPD), mediante documentación.

Nota importante: El hecho de que la extracción de datos personales se clasifique como una violación de datos no implica necesariamente una falta del proveedor. Por ejemplo, el proveedor podría no ser considerado responsable si ha concluido que su modelo está anonimizado mediante un análisis suficiente y debidamente documentado, si la extracción es posible posteriormente debido a una evolución impredecible del estado de la técnica, pero si el proveedor responde adecuadamente a esta violación de datos cumpliendo correctamente con sus obligaciones en este ámbito.

En función de la gravedad del incidente y de las posibles infracciones del RGPD resultantes, la CNIL podría exigir la reentrenamiento o la eliminación del modelo en cuestión.

< Página anterior: Garantizar la seguridad del desarrollo de sistemas de IA

Resumen

Derecho y NBIC

jueves, 12 de marzo de 2026

ANALIZAR EL ESTADO DE UN MODELO DE IA RESPECTO AL RGPD - FICHA CNIL.

No hay comentarios:

Publicar un comentario