La mayoría de las funcionalidades de IA tratan datos personales, a menudo sin que nadie haya decidido que deban hacerlo. Un chatbot de soporte recibe nombres, teléfonos y detalles de pedidos. Un pipeline de documentos lee facturas con los identificadores fiscales de autónomos. Un agente con acceso al CRM mete historiales de clientes en su contexto. Cada uno de esos flujos está sujeto a la normativa de protección de datos —el RGPD en la UE, las leyes nacionales en otros países— y a las obligaciones contractuales con los clientes. Esta guía traduce los requisitos legales en decisiones de ingeniería. No es asesoramiento jurídico; consulta a tu DPD o a tu abogado para tu caso concreto.

Por dónde circulan los datos personales en una aplicación LLM

Mapea los flujos antes de elegir los controles:

Flujo Ejemplo Riesgo típico
Entrada del usuario El cliente escribe su teléfono y su reclamación Se envía a un proveedor de modelos externo
Contexto recuperado (RAG) Notas del CRM, tickets, contratos en el prompt Compartir de más entre usuarios; datos innecesarios en los prompts
Resultados de herramientas El agente obtiene un pedido con dirección y datos de pago Datos en el contexto, en los logs y en las trazas
Salida del modelo Un resumen que contiene datos personales Se muestra al usuario equivocado; se guarda indefinidamente
Logs y trazas Prompts completos en herramientas de observabilidad Retención larga, acceso amplio
Memoria "Recuerda" datos de un usuario entre sesiones Difícil de localizar y borrar
Datos de fine-tuning Conversaciones pasadas usadas para entrenar Memorización, imposibilidad de borrar

Cada fila es una actividad de tratamiento que necesita una finalidad, una base jurídica y salvaguardas.

Los principios del RGPD, traducidos a ingeniería

Los principios básicos del RGPD (artículo 5) se traducen directamente en decisiones de diseño:

  • Limitación de la finalidad: usa los datos enviados al asistente para responder, no en silencio para entrenar o para marketing.
  • Minimización de datos: envía al modelo solo lo que necesita. Un bot de soporte rara vez necesita la ficha completa del cliente; pásale el pedido relevante, no el perfil con fecha de nacimiento y dirección completa.
  • Exactitud: no dejes que la salida del modelo sobrescriba los datos maestros sin verificación.
  • Limitación del plazo de conservación: define la retención de conversaciones, prompts en logs, embeddings y memoria.
  • Integridad y confidencialidad: cifrado, control de acceso, protección frente al prompt injection y la exfiltración de datos; consulta seguridad de agentes de IA.
  • Responsabilidad proactiva: documenta lo que haces: registro de actividades de tratamiento, evaluaciones de impacto cuando se requieran, evaluación de proveedores.

El artículo 25 —protección de datos desde el diseño y por defecto— es en esencia una instrucción para tomar estas decisiones en la arquitectura, no en un documento de políticas.

Elegir y configurar los proveedores de modelos

Cuando envías datos a un proveedor por API, normalmente es tu encargado del tratamiento y necesitas un contrato de encargo (DPA). Comprueba por escrito:

  1. Entrenamiento con tus datos. Las ofertas business y de API de los grandes proveedores, en general, no entrenan con los datos de los clientes por defecto; las aplicaciones de consumo pueden hacerlo. Asegúrate de estar en el nivel de producto adecuado.
  2. Retención. ¿Cuánto tiempo se guardan los prompts y las salidas, para vigilar abusos o por otros motivos? Muchos proveedores ofrecen retención cero o reducida a los clientes que cumplen los requisitos.
  3. Ubicación y transferencias. ¿Dónde se tratan los datos? Para transferencias fuera del EEE, apóyate en una decisión de adecuación (como el Marco de Privacidad de Datos UE-EE. UU. para empresas certificadas) o en cláusulas contractuales tipo, y documenta una evaluación de la transferencia. Varios proveedores ofrecen residencia de datos en la UE o tratamiento regional a través de las grandes plataformas de nube.
  4. Subencargados y certificaciones de seguridad (ISO 27001, SOC 2).
  5. Funciones que almacenan datos: subida de archivos, estado de la conversación, caché, trabajos por lotes; cada una puede tener su propia retención.

Cuando los datos no pueden salir en absoluto de tu infraestructura, los modelos self-hosted eliminan las transferencias a terceros, aunque todas las demás obligaciones se mantienen.

Base jurídica y transparencia

Las bases jurídicas habituales para funcionalidades de IA son la ejecución de un contrato (el usuario pidió ayuda al asistente con su pedido) y el interés legítimo (herramientas internas de productividad); este último requiere una ponderación. El Dictamen 28/2024 del CEPD trata específicamente los modelos de IA, incluido cuándo un modelo entrenado con datos personales puede considerarse anónimo y cómo se aplica el interés legítimo al desarrollo y al despliegue.

Se aplican obligaciones de transparencia: actualiza tu aviso de privacidad para describir el tratamiento con IA, los proveedores y las finalidades. Según la Ley de IA de la UE, además hay que informar a los usuarios cuando interactúan con un sistema de IA; consulta la guía de la Ley de IA de la UE. Si un sistema de IA toma decisiones con efectos jurídicos o igualmente significativos sobre las personas —crédito, contratación, seguros—, se aplica el artículo 22 del RGPD sobre decisiones automatizadas y hace falta una revisión humana significativa.

Anonimización y seudonimización de PII

Eliminar los identificadores antes de enviar los datos al modelo es una medida de minimización sólida cuando la tarea no los necesita:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()      # add custom recognizers for local formats
anonymizer = AnonymizerEngine()

def redact(text: str) -> str:
    results = analyzer.analyze(text=text, language="en",
                               entities=["PHONE_NUMBER", "EMAIL_ADDRESS", "IBAN_CODE", "PERSON"])
    return anonymizer.anonymize(text=text, analyzer_results=results).text

Microsoft Presidio y herramientas similares detectan los identificadores habituales. Para datos españoles, añade reconocedores propios: DNI y NIE (8 dígitos más letra, o letra, 7 dígitos y letra), NIF/CIF de empresas, teléfonos españoles (+34…), IBAN (ES + 22 dígitos). Si trabajas con varios países, añade sus formatos (RFC, CURP, CUIT…). La detección de nombres propios en español es más difícil que en inglés; prueba el recall con muestras reales.

La seudonimización suele ser mejor que el borrado: sustituye los identificadores por marcadores (<CUSTOMER_1>), guarda la correspondencia en el servidor y vuelve a insertar los valores reales en la respuesta del modelo antes de mostrársela al usuario autorizado. El modelo puede razonar sobre "el pedido del cliente 1" sin ver el nombre.

Sé realista: la anonimización nunca es perfecta, y algunas tareas necesitan los datos (un asistente que redacta una respuesta a un cliente con nombre). Combínala con controles contractuales y técnicos en lugar de confiar solo en ella.

RAG y agentes: el control de acceso es control de la privacidad

El incidente de privacidad más común en funcionalidades de IA no es una filtración del proveedor; es que un usuario vea los datos de otro porque la recuperación o las herramientas ignoraron los permisos:

  • Filtra la recuperación por los permisos del usuario en la propia consulta, con metadatos guardados en cada fragmento; consulta bases de datos vectoriales.
  • Ejecuta las herramientas con la identidad del usuario final, tomada de la sesión y nunca de los argumentos del modelo; consulta diseño de herramientas.
  • No indexes datos que los usuarios del asistente nunca deberían ver.
  • Recuerda que los embeddings derivados de datos personales también son datos personales; el derecho de supresión debe llegar al índice vectorial.

Logs, trazas y memoria

Las herramientas de observabilidad son un almacén de datos que a menudo se olvida. Aplica las mismas reglas que a las bases de datos de producción:

  • Separa el contenido de los metadatos; conserva el contenido durante una ventana corta (por ejemplo, 14–30 días).
  • Anonimiza antes de exportar cuando sea viable.
  • Restringe el acceso a quien lo necesite.
  • Incluye las herramientas de LLM (SaaS de trazas, conjuntos de evaluación) en tu registro de actividades y en la evaluación de proveedores.

La parte de herramientas se trata en observabilidad de LLM. Para la memoria del asistente, deja que los usuarios vean y borren lo que se guarda, y haz caducar los recuerdos que no se usan.

Fine-tuning y memorización

Entrenar con datos personales crea problemas más difíciles. Los modelos de lenguaje pueden memorizar y reproducir partes de sus datos de entrenamiento, incluida información personal (Carlini et al., 2021). Hoy no es práctico borrar los datos de una persona de un modelo ya entrenado; reentrenar es la única opción fiable. Por tanto:

  • Prefiere RAG para todo lo que implique datos personales: borrar significa eliminar un documento; consulta fine-tuning vs RAG.
  • Si tienes que hacer fine-tuning con conversaciones, seudonimiza a fondo, documenta la base jurídica y mantén los conjuntos de entrenamiento al mínimo.

Derechos de los interesados

Planifica cómo gestionarás las solicitudes:

  • Acceso: ¿puedes exportar las conversaciones, los recuerdos guardados y los datos derivados de una persona?
  • Supresión: ¿puedes borrarlos de la base de datos, el índice vectorial, los logs, las cachés y las copias de seguridad (dentro de su rotación)?
  • Oposición y limitación: ¿puede un usuario excluirse del tratamiento con IA y seguir usando el servicio?

Construye estas capacidades al diseñar el almacenamiento, no cuando llegue la primera solicitud.

España y América Latina: qué se aplica

En España, el RGPD se complementa con la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD), y la autoridad de control es la Agencia Española de Protección de Datos (AEPD). En América Latina, muchos países tienen leyes propias —por ejemplo, la Ley 25.326 en Argentina o la Ley 1581 de 2012 en Colombia— con principios similares de finalidad, consentimiento o base legal, seguridad y derechos de los titulares. Las empresas latinoamericanas que tratan datos de residentes en la UE quedan además sujetas al RGPD a través de sus servicios o de los contratos con sus clientes. En la práctica, diseñar con los estándares del RGPD cubre a la vez la mayoría de los requisitos locales y las expectativas de los clientes.

Lista de comprobación de privacidad para funcionalidades de IA

  • Flujos de datos mapeados: entradas, recuperación, herramientas, salidas, logs, memoria
  • Proveedor en un nivel business/API con DPA, sin entrenamiento con tus datos y con retención conocida
  • Mecanismo de transferencia documentado; tratamiento regional donde haga falta
  • Solo se envían al modelo los datos necesarios; anonimización o seudonimización donde sea viable
  • La recuperación y las herramientas imponen los permisos del usuario final
  • Retención fijada para conversaciones, logs, trazas, embeddings y memoria
  • Aviso de privacidad actualizado; los usuarios saben que hablan con una IA
  • Los procesos de acceso, supresión y exclusión cubren todos los almacenes de datos de IA
  • Evaluación de impacto hecha para los tratamientos de alto riesgo (gran escala, datos sensibles, decisiones significativas)

Preguntas frecuentes

¿Podemos enviar datos de clientes a una API de LLM bajo el RGPD? Sí, con una base jurídica, un contrato de encargo con el proveedor, garantías adecuadas para las transferencias, minimización y transparencia. La pregunta es cómo, no si se puede.

¿Un modelo self-hosted cumple automáticamente? No. Evita las transferencias a terceros, pero la limitación de la finalidad, la retención, la seguridad y los derechos de los interesados siguen aplicándose.

¿Los embeddings son anónimos? No. Los embeddings derivados de datos personales a menudo pueden vincularse al texto de origen y deben tratarse como datos personales.

¿Necesitamos una evaluación de impacto para un chatbot? A menudo no para un bot sencillo de preguntas frecuentes; a menudo sí cuando se tratan datos sensibles, se monitoriza a empleados, se opera a gran escala o se apoyan decisiones significativas. Pregunta a tu DPD.

Fuentes

  1. Reglamento (UE) 2016/679 (RGPD).
  2. CEPD (2024). Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models.
  3. BOE. Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales.
  4. Carlini et al. (2021). Extracting Training Data from Large Language Models.
  5. Microsoft. Presidio.
  6. OWASP. Top 10 for LLM Applications 2025: Sensitive Information Disclosure.