IA generativa de texto vs RGPD (II) Es el ¿Qué? no el ¿Cómo?

 

Hoy hablaremos específicamente de la IA generativa de texto en el contexto del RGPD.

Los problemas son interminables en la confluencia entre la Inteligencia Artificial generativa y la protección de datos personales porque la primera no es una sola cosa sino muchas y la segunda es transversal y se aplica en cada caso –en cada contexto- de manera distinta.

Por eso, vamos a dedicar una serie de posts a la protección de datos aplicada a la IA generativa.

Es decir, a alguno(s) tipo(s) de IA(s) generativa(s). Que no pocos hay.

 

Post publicados de esta serie:

1.- IA generativa vs RGPD (I): protegiendo la gallina de los huevos de oro

2.- IA Generativa de texto vs RGPD (II) Es el ¿qué? no el ¿cómo?

3.- IA generativa de imágenes vs RGPD (III): Mitos y preguntas frecuentes

4.- Inteligencia artificial vs RGPD (IV): Casos prácticos

 

 

Formación sobre RGPD aplicada a IA, Machine learning y decisiones automatizadas del 22…

Te recuerdo que ofrecemos una formación en doble formato: (i) RGPD puro aplicado a casos prácticos y reales de IA con El Chachi, y (ii) presentación y desmenuzamiento del horroroso Reglamento de Inteligencia Artificial con Sara Domingo de Trillateral Research. Esto empieza el 9 de octubre: toda la info aquí. Inscripciones en formacion@jorgegarciaherrero.com.

 

LLMs o Large Language Models

En un modelo de IA generativa de texto de los gordos (“Large Language Models” o “LLM” para los amigos) los tokens son las unidades mínimas de representación de texto (no coinciden necesariamente con palabras, ni siquiera con sílabas).

Los tokens permiten descomponer (al entrenarse el modelo o al entender tu prompt) y recomponer palabras y frases en modelos de lenguaje.

 

¿Cómo demonios “aprende”, “organiza” y/o ”estructura” la información un LLM?

Dos cosillas:

Una: no he elegido esos verbos entre comillas al azar. Verán, verán.

Dos: no se sientan culpables si el resto del apartado se les hace bola y saltan al siguiente, a «no hay tratamiento de datos«: a la calificación jurídica de la movida. Suelto todo este rollo aquí principalmente para rentabilizar –so to speak- de alguna manera el tiempo que me ha costado metérmelo en la cabeza.

Veamos:

Los LLMs procesan el texto en múltiples pasos que incluyen (i) la tokenización –la conversión del texto en números que representan a las palabras-, el (ii) cálculo de embeddings –o la transformación de esos números en vectores multidimensionales – y (iii) el uso de vectores para analizar el significado del texto, comprenderlo y generar respuestas contextuales.

Tokenización .- Implica descomponer el texto en «tokens«. Los tokens no suelen representar palabras enteras, sino partes: sílabas o combinaciones de varias sílabas, partes de palabras, signos de puntuación, y a veces sí, incluso palabras completas.

A cada token se le asigna un número único. El ejemplo que se suele utilizar para ilustrarlo es el de un texto que se pega en una hoja de cálculo, donde cada palabra ocupa su propia columna. La cantidad de tokens que un modelo puede procesar a la vez se conoce como «contexto». GPT-3 podía manejar hasta 2,048 tokens, y GPT-4 más de 128,000 tokens. El tamaño del contexto es muy importante, ya que define cuánta información puede «tener en cuenta» el modelo al momento de analizar el texto.

Embeddings.- Una vez que el texto ha sido tokenizado, el siguiente paso es calcular el «embedding» o representación vectorial de cada token.

Los embeddings se almacenan en un espacio de múltiples dimensiones; por ejemplo, GPT-3 utiliza un espacio con aproximadamente 12,000 dimensiones. Cada token recibe un vector (por entendernos, una flechita con una dirección y longitud determinada) que representa su significado promedio basado en el conjunto de entrenamiento del modelo.

Tokens con significados similares tendrán vectores cercanos entre sí en este espacio, y las relaciones entre tokens se reflejan en la dirección de sus vectores. Por ejemplo, la relación entre «hombre» y «mujer» podría reflejarse en una dirección similar a la relación entre «tío» y «tía». Esto permite que el modelo generalice patrones y relaciones semánticas que ha aprendido durante su entrenamiento.

Pero se pone peor.

Ajuste de Vectores y Atención.- A medida que el modelo analiza el texto, ajusta continuamente los vectores de cada token para reflejar mejor su significado en el contexto específico de cada input. Este ajuste se realiza a través de múltiples capas, donde las posiciones de los vectores en el espacio multidimensional se modifican mediante operaciones matemáticas.

El proceso de «atención» es uno de los mecanismos clave de los modelos basados en “transformers” como la popular serie GPT: en cada capa, el modelo asigna diferentes niveles de importancia (o atención) a cada token en relación con el resto de tokens del contexto.

Para cada token, el modelo «pregunta» a los demás tokens qué relevancia tienen, y los demás tokens «responden». Cuando detecta que la relación entre dos tokens es intensa, el modelo ajusta sus vectores, refinando su significado en ese contexto específico. Por ejemplo, en la frase «él tiene un coche rojo y eléctrico», el modelo reconocerá que «rojo» y «eléctrico» son descriptores relevantes para «coche» y ajustará los vectores de «coche» en esa dirección.

Este proceso se repite decenas de veces para cada palabra del input.

 

«No hay almacenamiento de datos»

Es cierto que los LLMs no almacenan el significado de las palabras en texto. Almacenan esos vectores, patrones matemáticos complejos que reflejan el promedio de los significados aprendidos durante el entrenamiento. Estos patrones no son estáticos, se ajustan en tiempo real para cada prompt del usuario.

Esta tecnología es lo que les permite precisamente “responder” a preguntas que «no se han estudiado», y sobre todo hacerlo sin buscar la respuesta “almacenada” en su memoria. Por eso se dice que las respuestas son probabilísticas, no deterministas, y por eso un porcentaje de ellas son equivocadas.

 

 

 

Pero… ¿Nos estamos haciendo la pregunta correcta? ¿Es más importante el “cómo” o el “qué”?

El cómo es apasionante. Y es bueno, útil, aprender o entender lo mejor posible el “cómo”. Pero jurídicamente es aconsejable no perder de vista el “qué”.

Porque el «qué» a nivel general dialoga con los principios generales de la normativa. Y los principios cambian poco.

En resumen, alguien podría pensar que estamos dando demasiada importancia al “cómo”, olvidándonos del “qué”. De hecho, las dos preguntas son importantes, pero lo riguroso sería hacerlas en otro orden.

En este:

Primero: ¿Qué demonios hace este LLM para contestarme cuando mi pregunta se responde con datos personales?

Y ya luego… ¿Cómo encajo esta -complicada- mierda en el RGPD?

 

Si un LLM contesta a mi pregunta con datos personales… ¿Capasao?

Recordemos que Microsoft y la Autoridad de Hamburgo sostienen que en el caso de los sistemas de IA generativa de lenguaje, el tratamiento de datos personales se inicia con (i) la prompt del usuario cuyo objeto o intención requiere una respuesta que haga referencia a “datos personales” (uséase, información relacionada con un individuo identificado o identificable)

(ii) la prompt es filtrada por los scripts de moderación antes y después de la generación del output, y

(iii) termina al despachar el output así generado y filtrado, al usuario.

Por centrarnos en el supuesto más evidente (e innegable), el input iniciará un tratamiento de datos, cuando implique un output o respuesta que contenga datos personales.

 

¿Y qué hace falta para que el output pueda ser considerado tratamiento de datos personales?

La respuesta más sencilla es… que revele datos personales (información sobre un interesado) que no estuvieran ya presentes en la prompt.

Centrándonos en los primeros principios, “¿qué preguntas?» y «¿qué contesta el modelo?” las cosas se ven mucho más claras.

Se ve mejor con un ejemplo: pidamos a ChatGPT 4o información sobre una persona identificada, excluyendo expresamente que se conecte a internet para contestar.

Si esa persona es mínimamente conocida por la razón que sea, lo normal es que te conteste suministrando datos personales, en parte correctos y en parte incorrectos.

Veamos:

 

 

La respuesta evidentemente incluye datos personales de Jordi Hurtado. Datos que no estaban en la pregunta.

Ergo estaban en el modelo.

I rest my case, your Honour.

 

 

El RGPD regula tratamientos de datos con independencia de la tecnología concreta utilizada. 

Y por eso, su art 4.2 es omnicomprensivo en su definición: “any operation … performed on personal data … such as collection… organisation… structuring… retrieval… consultation… disclosure… or otherwise making available…”

El “caso Hurtado” hace evidente que los datos personales de la respuesta salen del modelo.

Resulta secundario el formato o la tecnología con la que se haya recogido, estructurado o recuperado para generar la respuesta.

El modelo habrá procesado tokens, vectores, letras o gallifantes: da igual.

Lo relevante es que se han tratado datos personales del interesado al menos en dos momentos: en (i) el entrenamiento del modelo y en (ii) la generación de la respuesta.

 

IA generativa de texto vs RGPD: Tres conclusiones

1.- Parece indiscutible que existe tratamiento de datos.

2- Otra cosa muy distinta es que esos tratamientos (el entrenamiento y el procesamiento posterior por parte del LLM) puedan o no articularse debidamente dentro del RGPD.

Y se pueden articular, claro que sí. El tratamiento de datos de «personas conocidas» «sin su consentimiento», tiene un sólido track record.  Pero repito: por favor, ahorrémonos atajos y trucos de trilero.

3.- En el caso de los LLMs, y hablando en abstracto, lo que entra y lo que sale es lo mismo: datos personales.

Las palabras (output), son indistinguibles de las palabras utilizadas en el input, las incluidas en el training dataset, y en general de las palabras utilizadas por todos nosotros.

Esencialmente esto es lo que ha hecho tan populares y útiles a estos modelos generativos de lenguaje.

Esto todo esto no es necesariamente así en los modelos de IA generativa de imágenes.

 

Pero eso lo dejamos para la próxima semana, porque este post ya va largo.

 

Jorge García Herrero

Abogado y Delegado de Protección de Datos