I.- OBJETO
Supongamos que el cliente es titular de una aplicación que ofrece a sus usuarios un chatbot. El chatbot funciona sobre un modelo de lenguaje de código abierto desarrollado y publicado por un tercero, que el cliente no ha entrenado. Partimos de que el cliente se limita a integrar el modelo en su sistema (interfaz, instrucciones de sistema, conexión con sus propias fuentes, etc.) y de que no lo ha reentrenado ni ajustado con datos propios. Si hubiera ajuste fino, el análisis cambia en los términos que se indican en el apartado 6.
La presente nota tiene un objeto acotado. Se trata de explicar qué obligaciones tiene el cliente respecto de los datos personales que el modelo base haya podido absorber durante su entrenamiento por el tercero, y qué medidas le permiten utilizarlo de forma lícita. Quedan fuera los tratamientos ordinarios de los datos que los usuarios introducen en el chat, salvo en lo que afecte directamente a esta cuestión.
Como referencia práctica hemos tomado el estudio de caso que la autoridad de protección de datos de Hamburgo (HmbBfDI) publicó el 5 de noviembre de 2026 sobre el chatbot LLMoin. En él la autoridad explica cómo aplicó el Dictamen 28/2024 del Comité Europeo de Protección de Datos (CEPD), de 17 de diciembre de 2024, a un sistema que utiliza un modelo de un tercero, y por qué concluyó que su uso era conforme al RGPD.
II.- ANÁLISIS JURÍDICO
1. El modelo base puede contener datos personales
El punto de partida del CEPD es que un modelo entrenado con datos personales no es anónimo por el mero hecho de no almacenar los datos como una base de datos convencional. Esos datos pueden quedar “absorbidos” en los parámetros y reaparecer en las respuestas, ya sea de forma espontánea o mediante consultas dirigidas a extraerlos (párrafo 31 del dictamen, según la cita del HmbBfDI). Para que el modelo se considere anónimo, la probabilidad de extraer datos de las personas cuyos datos se usaron en el entrenamiento, o de obtenerlos a través de consultas, tiene que ser insignificante, y eso debe demostrarse caso por caso. No basta con que el desarrollador lo afirme.
En la práctica, quien integra un modelo ajeno, rara vez puede verificar cómo se entrenó. Por eso el HmbBfDI propone un enfoque pragmático que consiste en presumir que el modelo, con toda probabilidad, no es anónimo y diseñar el sistema en consecuencia. Es la hipótesis de trabajo que recomendamos al cliente mientras el desarrollador no aporte una evaluación de anonimización sólida y documentada. El propio dictamen respalda este enfoque, por defecto, las autoridades deben considerar que es probable que un modelo de IA requiera una evaluación exhaustiva del riesgo de identificación y una mera afirmación de anonimato no es suficiente. Aunque el modelo llegara a ser anónimo, el RGPD seguiría aplicándose a los datos personales que el cliente trate en la fase de despliegue, como los que los usuarios introducen en el chat (párrafo 135).
2. El rol de responsable del tratamiento
El dictamen contempla tres escenarios, todos ellos partiendo de que se trataron datos personales de forma ilícita durante el desarrollo del modelo:
(i) los datos se conservan en el modelo y es el mismo responsable quien los trata después, en la fase de despliegue,
(ii) los datos se conservan en el modelo y los trata otro responsable al desplegarlo, y
(iii) el responsable se asegura de que el modelo es anónimo antes de que se produzca cualquier tratamiento posterior.
El que corresponde al cliente es el segundo, en el que un responsable distinto del desarrollador utiliza un modelo que puede haberse entrenado de forma ilícita. En ese caso, el CEPD entiende que el responsable que despliega el modelo tiene una obligación propia de comprobar, de manera adecuada a su posición, que el modelo no se desarrolló mediante un tratamiento de datos ilícito, y de impedir que el sistema devuelva datos tratados ilícitamente en el entrenamiento. La ilicitud del entrenamiento no impide por sí sola el uso posterior, pero sí puede pesar en la ponderación del interés legítimo del artículo 6.1.f) RGPD si los datos acaban saliendo en las respuestas.
El dictamen precisa que cada responsable debe garantizar la licitud del tratamiento que realiza y poder demostrarlo, y que la autoridad tendrá en cuenta si el responsable que despliega el modelo hizo una evaluación adecuada, valorando, entre otros criterios no exhaustivos, el origen de los datos y si el modelo es resultado de una infracción del RGPD declarada por una autoridad o un tribunal. El grado de detalle esperado varía según los riesgos que el tratamiento plantee para los interesados cuyos datos se usaron en el desarrollo. En la ponderación del interés legítimo cuentan también los filtros o limitaciones de acceso incorporados en el desarrollo del modelo que el cliente no puede eludir ni modificar, y la naturaleza y gravedad de la ilicitud inicial. La declaración UE de conformidad que el Reglamento de IA exige a los sistemas de alto riesgo no acredita por sí sola el cumplimiento del RGPD, aunque la autoridad puede tenerla en cuenta. Si se aprecia una infracción, las autoridades pueden adoptar medidas correctivas, desde la multa o la limitación temporal del tratamiento hasta, en último término, la supresión del conjunto de datos o del propio modelo, atendiendo a la proporcionalidad, con la consiguiente repercusión en el tratamiento posterior.
Todo ello se enmarca en el principio de responsabilidad proactiva. El artículo 5.2 del Reglamento (UE) 2016/679 (RGPD) dispone que:
“El responsable del tratamiento será responsable del cumplimiento de lo dispuesto en el apartado 1 y capaz de demostrarlo (“responsabilidad proactiva”)”.
Esa comprobación no exige al cliente auditar el entrenamiento, algo que normalmente no está a su alcance, pero sí recabar y conservar la información disponible. Entre otras cosas, conviene revisar la ficha técnica del modelo y su licencia, el origen declarado de los datos de entrenamiento, si existe, las medidas que el desarrollador dice haber aplicado para reducir la memorización de datos personales y si existe alguna resolución de una autoridad o de un tribunal que haya declarado ilícito ese entrenamiento. Debe verificarse también si los datos proceden de una violación de seguridad de los datos personales.
A estos efectos resulta útil el Reglamento (UE) 2024/1689 (Reglamento de IA). Su artículo 53.2 exime a los proveedores de modelos de uso general publicados con licencia libre y de código abierto de algunas obligaciones de documentación, pero no de la de publicar un resumen suficientemente detallado del contenido usado para el entrenamiento (artículo 53.1.d), salvo que el modelo presente riesgo sistémico, en cuyo caso no hay exención alguna.
Hay un matiz propio de los modelos de código abierto. Si el cliente descarga los pesos y aloja el modelo en su infraestructura, tiene acceso directo a los parámetros, cosa que no ocurre cuando se consume un modelo cerrado a través de una API. El dictamen del CEPD indica que la evaluación del carácter anónimo del modelo debe tener en cuenta también el acceso directo al modelo, así como el riesgo de identificación por terceros no previstos que accedan a él. Nuestra recomendación es asumir que el riesgo de extracción es mayor cuando terceros pueden acceder al modelo por vías distintas de la interfaz del chatbot, y limitar ese acceso al mínimo. Si, por el contrario, el modelo se ejecuta en un proveedor de nube, ese proveedor actuará normalmente como encargado del tratamiento y será necesario el contrato del artículo 28 RGPD, además de revisar las transferencias internacionales que puedan producirse.
3. Las medidas que el CEPD considera pertinentes se sitúan en el sistema, no en el modelo
En el caso LLMoin, el cumplimiento se juega en el sistema de IA, es decir, en la capa que el cliente construye alrededor del modelo y que controla las entradas y las salidas. Modificar el modelo para hacerlo anónimo no es técnicamente viable para quien lo integra, de modo que el riesgo de extracción ha de reducirse con un conjunto de medidas técnicas y organizativas que, valoradas en su conjunto y teniendo en cuenta su coste, ofrezcan una protección suficiente. No hay una lista cerrada: el dictamen califica sus ejemplos de medidas como no exhaustivos ni prescriptivos y los somete a valoración caso por caso. Para la fase de despliegue cita, entre otros, los filtros de salida que impidan el almacenamiento, la regurgitación o la generación de datos personales y la marca de agua digital de los contenidos generados. Las que el HmbBfDIconsideró suficientes en su caso, y que trasladamos ahora, son las siguientes:
▪ Filtros de salida: Analizan la respuesta antes de que llegue al usuario y la bloquean o modifican cuando contiene datos personales que el usuario no ha aportado o información sobre una persona que se sabe falsa o tratada ilícitamente. Sirven también para atender oposiciones del artículo 21 RGPD respecto de personas concretas. Con un modelo de código abierto este punto es especialmente relevante, porque el cliente no cuenta con los filtros que los proveedores de modelos cerrados suelen aplicar en su API y tendrá que implantarlos él mismo.
▪ Filtros de contenido: Clasifican las respuestas por categorías de riesgo (odio, contenido sexual, violencia, autolesiones, suplantación, desinformación, fraude) y suprimen las que corresponda. El dictamen del CEPD no menciona expresamente estos filtros de contenido, que proceden del caso LLMoin, pero encajan en la protección de datos desde el diseño (artículo 25.1 RGPD), que el dictamen califica de salvaguardia esencial.
▪ Instrucción de sistema: Debe indicar al modelo que no facilite datos personales que no figuren en la consulta del usuario o en las fuentes que el propio sistema le proporciona, que no adopte decisiones y que advierta cuando una afirmación no esté contrastada. No sustituye a las medidas técnicas, pero las complementa.
▪ Anclaje de las respuestas en fuentes controladas: Cuando el chatbot responde a partir de documentos aportados por el usuario o de una base de conocimiento propia del cliente (técnica conocida como RAG), depende menos de lo que el modelo recuerda de su entrenamiento. Además, los datos de esa base sí pueden suprimirse, rectificarse y someterse a permisos, lo que no ocurre con los parámetros del modelo base.
▪ Limitación de funciones: Cuanto más acotado esté el uso del chatbot a la finalidad de la aplicación (atención al cliente, ayuda sobre el producto, resumen de textos aportados), menor será el riesgo. Un chat de uso libre es un escenario en que el resto de las medidas pueden verse afectadas.
▪ Condiciones de uso: Deben prohibir de forma expresa que se utilice el chatbot para obtener información sobre personas físicas identificadas o identificables a partir del conocimiento del modelo, para generar ultrafalsificaciones o para tomar decisiones con efectos sobre terceros. En LLMoin la prohibición admitía una excepción para datos que el propio interesado hubiera hecho públicos, y el HmbBfDI señaló que hubiera sido preferible una prohibición total. Recomendamos seguir este segundo criterio.
▪ Pruebas de intrusión dirigidas (red teaming) y revisión periódica. Antes del lanzamiento y después de cada cambio de modelo o de versión, conviene someter el sistema a pruebas que intenten extraer datos de entrenamiento, eludir los filtros o la instrucción de sistema e inyectar instrucciones maliciosas. El dictamen cita como pruebas estructuradas de referencia los ataques de inferencia de atributos y de pertenencia, la exfiltración, la regurgitación de datos de entrenamiento, la inversión del modelo y los ataques de reconstrucción, y advierte de que superar ataques conocidos solo acredita resistencia frente a ellos. Los resultados deben servir para ajustar las medidas anteriores, en línea con el artículo 32.1.d) RGPD, que exige verificar y evaluar con regularidad la eficacia de las medidas de seguridad. Dichas pruebas, evidentemente, deben ser debidamente documentadas.
4. Derechos de los interesados
Si el modelo contiene datos personales, los derechos del RGPD se proyectan en principio también sobre él. Sin embargo, borrar datos concretos de los parámetros (lo que se denomina “desaprendizaje automático”) no es hoy una técnica madura y con resultados eficientes, y el CEPD se limita a pedir a los proveedores que evalúen de forma continuada su viabilidad, sin fijar una obligación de supresión exigible sobre el propio modelo. Las autoridades alemanas entienden que bloquear una respuesta con un filtro no equivale a suprimir el dato en sentido del artículo 17 RGPD, aunque sí protege al interesado frente a la salida concreta.
Para el cliente esto se traduce en contar con un procedimiento interno que permita, ante una solicitud de supresión, rectificación u oposición referida a lo que el chatbot dice de una persona, incorporar esa persona o esa información a los filtros de salida, documentar la actuación y explicar al interesado, con transparencia, qué se ha hecho y cuáles son los límites técnicos. Si la información procede del entrenamiento, conviene además informar al interesado de que puede dirigirse al desarrollador del modelo. Como garantía adicional a lo exigido por la ley, el dictamen menciona habilitar un cauce para que los interesados comuniquen casos de regurgitación o memorización de sus datos, y facilitar el ejercicio de la supresión respecto de las salidas del modelo, por lo que conviene que el procedimiento interno lo contemple.
5. Otras obligaciones relacionadas
Por tratarse de una tecnología “emergente” con posible tratamiento de datos a gran escala, entendemos que el cliente debería realizar una evaluación de impacto relativa a la protección de datos conforme al artículo 35 RGPD o, al menos, documentar de forma motivada por qué no la considera necesaria. En esa evaluación debe encontrar acomodo la comprobación del modelo descrita en el apartado 2 y las medidas del apartado 3. Esa evaluación debe abordar también la base jurídica del propio tratamiento del cliente. El dictamen reconoce que el interés legítimo puede serlo (por ejemplo, para un agente conversacional que asista a los usuarios), pero no como base por defecto, y exige superar y documentar el test de tres pasos (interés legítimo, necesidad y ponderación), teniendo en cuenta las expectativas razonables de los interesados. El tratamiento debe figurar también en el registro de actividades. Como orientación, el dictamen espera encontrar documentada, entre otros elementos, la información sobre la evaluación de impacto o la decisión motivada de no realizarla, y el asesoramiento del delegado de protección de datos, si lo hay o debería haberlo.
En materia de transparencia, la política de privacidad de la aplicación debería explicar que el chatbot funciona con un modelo de un tercero, que sus respuestas pueden ser inexactas, qué medidas se aplican para evitar que revele datos de personas y cómo ejercer los derechos. El dictamen valora, además, como refuerzo de la transparencia, publicar la ponderación del interés legítimo realizada y facilitar información adicional, por ejemplo, mediante fichas del modelo (párrafos 103 y 108). Por su parte, el artículo 50.1 del Reglamento de IA obliga a informar a los usuarios de que están interactuando con un sistema de IA, salvo que resulte evidente. Esta obligación es aplicable desde el 2 de agosto de 2026.
6. Si el cliente ajusta o reentrena el modelo (fine tuning)
Si el cliente realiza un ajuste fino del modelo con datos propios que incluyan datos personales (conversaciones de usuarios, por ejemplo), pasa a ser responsable de ese tratamiento de re-entrenamiento. Necesitará una base jurídica propia, que en la práctica será bien el consentimiento bien el interés legítimo con la correspondiente ponderación documentada, informar de ello a los usuarios y respetar su derecho de oposición. Según la entidad de la modificación, podría además llegar a ser considerado proveedor del modelo modificado a efectos del Reglamento de IA. Ambas cuestiones requerirían un análisis específico que no abordamos en esta nota.
III.- CONCLUSIÓN
El cliente debe partir de que el modelo de código abierto que integra no es anónimo y puede contener datos personales absorbidos durante su entrenamiento, salvo que el desarrollador acredite lo contrario de forma sólida.
Como responsable del tratamiento que despliega un modelo ajeno, el cliente tiene la obligación propia de valorar, en la medida de sus posibilidades, la licitud del desarrollo del modelo. Debe recabar y conservar la documentación pública del desarrollador, en particular el resumen del contenido de entrenamiento exigido por el Reglamento de IA.
El uso del modelo es lícito si el sistema que lo rodea reduce de forma suficiente el riesgo de que devuelva datos personales del entrenamiento. Recomendamos, como mínimo, filtros de salida y de contenido, una instrucción de sistema restrictiva, el anclaje de las respuestas en fuentes controladas, condiciones de uso que prohíban consultar información sobre personas y pruebas periódicas de extracción.
Los derechos de supresión, rectificación y oposición respecto de las salidas del chatbot sobre una persona, deben atenderse mediante filtros de salida y un procedimiento documentado, explicando al interesado los límites técnicos existentes.
Todo lo anterior debe quedar reflejado en una evaluación de impacto, en el registro de actividades y en la información que se facilita a los usuarios, a la que se suma el aviso de interacción con un sistema de IA del artículo 50 del Reglamento de IA.
Revisado por Gerard Espuga Torné, abogado experto en protección de datos y derecho digital.
