APIs de IA y RGPD: guía práctica para desarrolladores

Puntos clave

Tener un DPA firmado con tu proveedor de IA es necesario, pero no suficiente para cumplir el RGPD
Necesitas base jurídica explícita (Art. 6), minimización de datos (Art. 5), y una transferencia internacional válida si el proveedor está fuera de la UE (Art. 44-46)
El patrón más sólido técnicamente: seudonimizar los datos antes de la llamada API — el modelo nunca recibe datos identificables
El derecho de supresión (Art. 17) se vuelve trivial si el proveedor nunca ha procesado datos reales de tus usuarios

La mayoría de los desarrolladores que integran APIs de IA en sus aplicaciones no son abogados. Tampoco necesitan serlo. Pero hay cuatro preguntas del RGPD que tienes que poder responder antes de poner tu aplicación en producción — o antes de que lo haga tu responsable de protección de datos.

Esta guía está escrita desde la perspectiva técnica: qué obligaciones tiene tu código, no solo tu empresa.

El error más común: confundir DPA con cumplimiento

Cuando un equipo de desarrollo necesita integrar OpenAI, la respuesta estándar es: “tenemos el DPA firmado”. El Data Processing Agreement (Acuerdo de Tratamiento de Datos) con tu proveedor de IA es el Art. 28 del RGPD — el contrato que regula cómo el proveedor trata los datos en tu nombre. Es necesario. No es suficiente.

El DPA regula la relación entre tu empresa y el proveedor. No regula qué datos envías, ni si tenías derecho a enviarlos, ni si la transferencia al servidor del proveedor es legal en primer lugar.

El cumplimiento completo requiere cuatro capas que el DPA solo cubre parcialmente:

Base jurídica para el tratamiento (Art. 6) — responsabilidad tuya, no del proveedor
Minimización de los datos que envías (Art. 5(1)(c)) — responsabilidad técnica tuya
Transferencia internacional válida si el proveedor está en EEUU (Art. 44-46) — el DPA incluye SCCs pero hay matices
Registro de actividades (Art. 30) — tienes que documentar qué haces, no solo que firmaste algo

Base jurídica: de qué depende cuál usar

El Art. 6 exige que toda operación de tratamiento tenga una base jurídica. Para la mayoría de las aplicaciones de IA que procesan datos de usuarios, las candidatas son:

Interés legítimo (Art. 6(1)(f)): La más usada en B2B y en aplicaciones donde el tratamiento está implícito en el servicio. Requiere un test de ponderación de tres pasos: (1) identificar el interés legítimo concreto, (2) demostrar que el tratamiento es necesario para ese interés, (3) equilibrarlo contra los derechos e intereses del interesado.

Si tu aplicación usa IA para analizar documentos que el usuario ha subido explícitamente para ese fin, el interés legítimo probablemente aguanta. Si tu aplicación envía conversaciones de usuarios a una API de IA sin que el usuario lo sepa ni lo espere, el test falla.

Consentimiento (Art. 6(1)(a)): Solo es válido si es libre, específico, informado e inequívoco. Para muchas integraciones de IA, el consentimiento es difícil de conseguir bien: la granularidad que exige el RGPD hace que los banners de consentimiento rara vez sean suficientes. Nunca uses consentimiento si el usuario no puede rechazarlo sin perder funcionalidad principal.

Ejecución de contrato (Art. 6(1)(b)): Válido cuando el tratamiento es estrictamente necesario para el servicio que el usuario ha contratado. Si el usuario contrató un servicio de revisión automática de contratos, procesar esos contratos con una API de IA puede encajar aquí.

Para datos sensibles (Art. 9) — datos de salud, biométricos, religiosos, políticos, entre otros — necesitas una base jurídica adicional del Art. 9(2). Ninguna API de IA estándar te la proporciona: tienes que gestionarla tú.

El DPA con tu proveedor de IA: qué exige el Art. 28

Si usas una API de IA para procesar datos de tus usuarios, el proveedor es un encargado del tratamiento. El Art. 28 te exige un contrato escrito que incluya:

Las finalidades y duración del tratamiento
La naturaleza y tipo de datos personales
Los derechos y obligaciones del responsable (tú)
Que el encargado solo trate los datos según tus instrucciones
La lista de subencargados y cómo se gestionan los cambios
Las medidas técnicas y organizativas de seguridad
La devolución o destrucción de datos al finalizar el contrato

OpenAI, Anthropic y los principales proveedores tienen DPAs que cubren estos puntos. El proceso para firmarlo es habitualmente automático (aceptas unas condiciones adicionales en el panel de control o por email). Lo que debes verificar:

Retención: ¿cuánto tiempo guarda el proveedor tus prompts y respuestas? OpenAI retiene 30 días por defecto — esto tiene implicaciones directas para las solicitudes de supresión del Art. 17.
Subencargados: ¿qué empresas procesan tus datos en nombre del proveedor? Un DPA que no liste subencargados no cumple el Art. 28(2).
Monitorización de abusos: la mayoría de los proveedores se reservan el derecho a revisar una parte del tráfico para detección de abusos. Es una excepción real al principio de finalidad limitada.

Transferencias internacionales: SCCs vs región UE

Si el proveedor está en EEUU y tus datos contienen información de usuarios de la UE, estás ante una transferencia internacional de datos regulada por el Capítulo V del RGPD (Art. 44-50).

El mecanismo más habitual es las Cláusulas Contractuales Tipo (CCT/SCCs) — un contrato estandarizado aprobado por la Comisión Europea que obliga al proveedor a proteger los datos según estándares europeos. Los grandes proveedores las incluyen en sus DPAs.

Pero las SCCs tienen un límite que la sentencia Schrems II (TJUE, C-311/18, 2020) puso encima de la mesa: si la ley del país de destino (EEUU) puede obligar al proveedor a entregar datos a autoridades sin una salvaguarda equivalente al RGPD, las SCCs por sí solas pueden no ser suficientes. El Art. 46(1) exige “garantías adecuadas” — si el contexto concreto las anula, tienes que documentarlo y añadir medidas suplementarias.

La alternativa más limpia técnicamente es desplegar con región UE. Azure OpenAI permite elegir región europea (West Europe, France Central, Sweden Central). En ese caso el tratamiento ocurre en infraestructura de la UE y el Art. 44 no se activa para los datos en tránsito. Las SCCs siguen siendo necesarias para los datos que viajan fuera de la región (logs, soporte, facturación).

La opción más sólida desde el RGPD es no enviar datos personales identificables: si el proveedor nunca recibe datos reales, las restricciones de transferencia se aplican sobre datos seudonimizados — categoría con requisitos más livianos.

Minimización de datos: el principio que más se ignora en IA

El Art. 5(1)(c) establece el principio de minimización: los datos deben ser “adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados”.

En la práctica de desarrollo de aplicaciones de IA, este principio casi nunca se implementa bien. El antipatrón habitual:

# Antipatrón: enviar el perfil completo del usuario
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{
        "role": "user",
        "content": f"Analiza este caso: {user.full_profile_json}"
    }]
)

El perfil completo contiene nombre, email, historial, dirección, preferencias. El modelo solo necesita el historial clínico o la descripción del problema. Enviar el perfil completo viola Art. 5(1)(c) tanto como lo haría guardarlo innecesariamente.

La minimización se implementa en el código, no en el DPA.

El patrón técnico: interceptar, seudonimizar, llamar, rehidratar

El patrón que satisface minimización, transferencia y supresión a la vez:

Tu aplicación → [capa de seudonimización] → API de IA → [capa de rehidratación] → Tu aplicación

En código:

# 1. Detectar e interceptar datos personales
tokens, mapping = pseudonymize(prompt)
# prompt:  "El paciente María López, DNI 12345678A..."
# tokens:  "El paciente [PERSON_1], DNI [ID_1]..."
# mapping: {"PERSON_1": "María López", "ID_1": "12345678A"}

# 2. Llamar a la API con datos seudonimizados
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": tokens}]
)

# 3. Rehidratar la respuesta para el usuario
result = rehydrate(response.choices[0].message.content, mapping)

El modelo de IA solo ve [PERSON_1] y [ID_1]. El mapeo de seudonimización permanece en tu infraestructura y nunca sale. Desde la perspectiva del proveedor, no ha procesado ningún dato personal: ha procesado tokens anónimos.

Registro de actividades: qué debes documentar

El Art. 30 obliga a los responsables a mantener un registro de actividades de tratamiento. Para cada actividad que involucre una API de IA, el registro debe incluir:

Finalidades del tratamiento
Categorías de interesados y de datos personales
Destinatarios (incluido el proveedor de IA y sus subencargados)
Plazos de supresión
Descripción de las medidas de seguridad del Art. 32

Lo que no tienes que registrar es el contenido de los prompts. El registro es a nivel de actividad, no de transacción. No guardes los prompts en tus propios logs si no tienes base para ello — eso crearía un tratamiento adicional que también necesita base jurídica.

Si usas el patrón de seudonimización, tus logs pueden registrar metadatos (timestamp, categorías de datos detectados, modelo utilizado, latencia) sin almacenar contenido personal. Esto es un registro de actividad útil para auditorías que no genera riesgo RGPD adicional.

Derecho de supresión: por qué la arquitectura simplifica la respuesta

El Art. 17 obliga a suprimir los datos de un interesado cuando lo solicite (con las excepciones habituales). Para aplicaciones de IA, esto plantea una cadena de supresión compleja: tus propias bases de datos, los logs de la API, la retención del proveedor, los backups.

Si has implementado seudonimización antes de la llamada API:

El proveedor nunca ha almacenado datos reales del interesado — no hay nada que suprimir en su sistema
El mapeo de seudonimización está en tu infraestructura — borrarlo rompe el vínculo entre el token y la identidad real
Tus propios registros solo contienen metadatos anónimos — no hay contenido personal que borrar

La supresión se reduce a eliminar el mapeo de seudonimización en tu sistema. El resto de la cadena se resuelve solo.

La implementación de este patrón de seudonimización en producción requiere detección de entidades robusta y gestión segura del mapeo. Privedge proporciona esta capa como un proxy transparente: un cambio de endpoint en tu SDK y todos tus prompts pasan por el proceso de seudonimización antes de llegar al proveedor.

La guía de cumplimiento RGPD cubre la arquitectura técnica completa y los patrones de despliegue.