Privedge
RGPD OpenAI privacidad API

Cómo Usar la API de OpenAI sin Violar el RGPD: Guía Técnica para Desarrolladores

El RGPD exige garantías adecuadas para transferir datos personales fuera de la UE. Esta guía técnica explica cómo construir apps con OpenAI que sean conformes por arquitectura.

P
Privedge Team
· 8 min de lectura
Puntos clave
  • Enviar datos personales a OpenAI = transferencia internacional bajo RGPD Cap. V — las CCT son cobertura legal, no técnica
  • Tras Schrems II, los reguladores exigen medidas técnicas suplementarias: seudonimización antes de la transferencia
  • Los datos seudonimizados no son “datos personales” bajo Art. 4(1) RGPD — la restricción de transferencia deja de aplicar
  • El cambio es una línea de código: apuntar tu cliente de OpenAI a un proxy que anonimiza antes de enviar

Cada desarrollador que construye funcionalidades de IA para usuarios europeos enfrenta la misma pregunta incómoda: cuando mi aplicación envía un prompt con datos personales a OpenAI, ¿constituye eso una transferencia internacional de datos bajo el RGPD? La respuesta es sí — y las implicaciones son más graves de lo que la mayoría de los equipos de ingeniería reconocen.

El Problema: Datos Personales en Prompts = Transferencia Internacional

El Capítulo V del RGPD regula las transferencias de datos personales a terceros países. El artículo 44 establece el principio general: cualquier transferencia de datos personales a un tercer país (fuera de la UE/EEE) solo puede realizarse si se cumplen las condiciones del Capítulo V.

Estados Unidos, donde OpenAI procesa los datos, no es un país con “nivel de adecuación” según el artículo 45. Esto significa que cada llamada a la API que contiene datos personales y cruza el Atlántico requiere garantías adecuadas bajo el artículo 46.

¿Qué son datos personales en el contexto de los prompts? Cualquier información que identifique o pueda identificar a una persona natural: nombres, direcciones de correo electrónico, números de teléfono, números de DNI/NIE, direcciones postales, datos de salud, números de cuenta, IPs, e incluso combinaciones de datos que, aunque aparentemente neutros, permitan identificar a una persona.

Si tu aplicación de atención al cliente recibe un ticket que dice “Hola, soy María García, y mi pedido #ES-4521 no ha llegado”, ese texto contiene datos personales. Cuando tu backend lo envía a OpenAI para generar una respuesta, estás realizando una transferencia internacional de datos personales sin que la AEPD haya parpadea todavía. Pero está mirando.

RGPD Art. 44-46: Por Qué las CCT No Son Suficientes para Datos Sensibles

La respuesta de OpenAI a los requisitos del Capítulo V es las Cláusulas Contractuales Tipo (CCT) — un conjunto de obligaciones contractuales aprobadas por la Comisión Europea que vinculan legalmente a los procesadores a proteger los datos personales de la UE.

Las CCT son un mecanismo reconocido bajo el artículo 46(2)(c). El problema: las CCT son un mecanismo legal, no técnico.

Las CCT obligan a OpenAI contractualmente a respetar ciertas protecciones. No impiden que los datos abandonen la UE. No impiden que OpenAI acceda a los nombres, direcciones de correo electrónico, información de salud o datos financieros de tus usuarios durante la inferencia.

La sentencia Schrems II (C-311/18, julio de 2020) estableció que las CCT solo pueden utilizarse si el nivel de protección que ofrecen es “esencialmente equivalente” al garantizado dentro de la UE. Para los procesadores con sede en EE.UU., esto es estructuralmente difícil de lograr porque las leyes de vigilancia de EE.UU. (particularmente la Sección 702 de FISA) permiten el acceso del gobierno estadounidense a datos en manos de empresas estadounidenses.

La orientación del Comité Europeo de Protección de Datos (CEPD) posterior a Schrems II fue clara: se requieren medidas técnicas suplementarias cuando las CCT por sí solas no pueden garantizar la equivalencia. La medida recomendada: cifrado o seudonimización de modo que el importador de datos no pueda acceder a los datos en claro.

Qué Ocurre Técnicamente Cuando Envías un Prompt a OpenAI

Para entender el riesgo, hay que entender el flujo técnico:

  1. Tu aplicación construye un prompt que puede incluir datos de usuario, contexto de sesión, historial de conversación, o datos recuperados de tu base de datos
  2. Tu backend realiza una llamada HTTPS a api.openai.com con ese prompt en el cuerpo de la petición
  3. El prompt llega a servidores de OpenAI en EE.UU. (principalmente Azure en distintas regiones)
  4. OpenAI ejecuta la inferencia, generando una respuesta
  5. La respuesta se devuelve a tu aplicación

En el paso 2, los datos personales han abandonado la UE. No hay forma de deshacer esto. Si el prompt contenía el nombre de tu usuario, su dirección o sus datos de salud, esa información ya está en manos de un procesador estadounidense, regido por la ley estadounidense.

La única forma de evitar esto técnicamente es eliminar los datos personales antes del paso 2.


Privedge fue diseñado específicamente para resolver este problema. Se despliega en tu infraestructura europea (Cloudflare Workers en nodos edge europeos) e intercepta cada prompt antes de que salga. Los nombres se convierten en [PERSONA_1], las direcciones de correo en [EMAIL_1], los números de teléfono en [TEL_1]. La tabla de correspondencia nunca abandona tu red. Lo que recibe OpenAI ya está seudonimizado.

El cambio en tu código es de una sola línea:

// Antes — datos personales cruzan el Atlántico
const client = new OpenAI({ baseURL: 'https://api.openai.com/v1' })

// Después — solo tokens seudonimizados llegan a OpenAI
const client = new OpenAI({ baseURL: 'https://api.privedge.io/v1' })

La respuesta vuelve con los tokens intactos, Privedge sustituye los originales, y tu aplicación recibe la respuesta completa. OpenAI procesó un documento sobre [PERSONA_1] — nunca vio a la persona.


La Solución: Interceptar Antes de Enviar

La seudonimización antes de la transferencia es la solución técnica que reconoce la RGPD explícitamente. El artículo 4(5) define la seudonimización como el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado específico sin utilizar información adicional, siempre que dicha información adicional figure por separado.

Si tu aplicación envía [PERSONA_1] a OpenAI, y la tabla que relaciona [PERSONA_1] con “María García” permanece en tu servidor europeo, los datos transferidos a OpenAI no son datos personales bajo el artículo 4(1) del RGPD: no se pueden atribuir a una persona natural sin la información adicional que está separada.

Esto no elimina la necesidad de CCT — el principio de limitación de finalidad del artículo 5(1)(b) sigue aplicando a cómo OpenAI usa los tokens. Pero resuelve el problema de fondo: los datos personales nunca se transfieren.

Minimización de Datos: Solo Tokens Anonimizados Salen de la UE

El principio de minimización de datos del artículo 5(1)(c) exige que los datos personales sean “adecuados, pertinentes y limitados a lo necesario” para los fines del tratamiento.

En la práctica, esto significa preguntarte: ¿necesita OpenAI saber el nombre real del usuario para generar esta respuesta? En la mayoría de los casos, no. El modelo puede razonar perfectamente sobre “el cliente [PERSONA_1] tiene el pedido [ID_1]” sin conocer el nombre real.

La minimización técnica — no solo la legal — es lo que satisface tanto la letra como el espíritu del RGPD.

AEPD y el Futuro de las Sanciones por IA

La Agencia Española de Protección de Datos (AEPD) ha incrementado notablemente su actividad investigadora en materia de IA. En 2025-2026, las investigaciones relacionadas con IA se multiplicaron respecto al año anterior. La AEPD publicó en 2024 una guía sobre el uso de IA en tratamientos de datos que establece claramente la necesidad de garantías técnicas, no solo contractuales.

El Garante italiano (la DPA de Italia) ya ha bloqueado servicios de IA que operaban sin garantías adecuadas. La CNIL francesa emitió orientaciones en 2026 aclarando que las CCT solas, sin medidas técnicas, son insuficientes para servicios de IA que procesan datos sensibles a escala.

La tendencia es inequívoca: los reguladores europeos están pasando de “necesitas una CCT” a “necesitas una CCT Y seudonimización técnica”. Construir la capa técnica ahora — antes de que la aplicación normativa alcance a tu producto — es la única estrategia que escala.

Conclusión

Usar la API de OpenAI de forma conforme con el RGPD no requiere cambiar de proveedor, construir un modelo propio, o almacenarlo todo on-premises. Requiere resolver el problema de la transferencia por arquitectura: interceptar los datos personales antes de que salgan de la UE, reemplazarlos con seudónimos reversibles, y asegurarse de que la clave nunca cruza la frontera.

Eso es exactamente lo que hace Privedge — una línea de código, sin refactoring, y una base técnica que satisface tanto la letra como el espíritu del Capítulo V del RGPD. Empieza con el nivel gratuito en privedge.io.

Protege los prompts de tu IA con Privedge

Intercepta datos personales antes de que lleguen a OpenAI u otros proveedores. Un cambio de una línea. Sin refactoring.

Empieza gratis

Lectura relacionada

Cómo usar la API de OpenAI sin violar el RGPD ¿Es ChatGPT legal en tu empresa? Lo que dice la AEPD Proxy de IA con privacidad: qué es y por qué lo necesitan las empresas europeas