Cómo usar la API de OpenAI sin violar el RGPD: guía técnica para desarrolladores

Aviso: este artículo explica el marco general del RGPD aplicado a las transferencias internacionales de datos en aplicaciones de IA. No es asesoramiento jurídico ni una calificación de tu caso. Cualquier decisión sobre licitud de un tratamiento concreto corresponde al responsable del tratamiento con su asesoría legal.

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, en la gran mayoría de configuraciones donde el proveedor procesa fuera del EEE, es que sí — pero la calificación exacta depende de la configuración concreta y debe confirmarse con asesoría legal.

El Problema: Datos Personales en Prompts = Transferencia Internacional

Las reglas de transferencia internacional del RGPD regulan las transferencias de datos personales a terceros países: cualquier transferencia de datos personales a un tercer país (fuera de la UE/EEE) solo puede realizarse si se cumplen determinadas condiciones.

Estados Unidos, donde OpenAI procesa los datos, no cuenta, en general, con una decisión de adecuación de la Comisión Europea. Esto significa que cada llamada a la API que contiene datos personales y cruza el Atlántico requiere garantías adecuadas bajo las reglas de transferencia internacional del RGPD.

¿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, ese envío encaja, en principio, en el supuesto de transferencia internacional que regula el RGPD — la calificación exacta de cada caso corresponde a tu asesoría legal.

Transferencias internacionales: Por Qué las CCT No Son Suficientes para Datos Sensibles

La respuesta de OpenAI a los requisitos de transferencia internacional 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 por el RGPD para las transferencias internacionales. 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. Tampoco garantizan por sí solas que el procesamiento durante la inferencia esté exento de acceso a nombres, direcciones de correo electrónico, información de salud o datos financieros de tus usuarios.

Una sentencia del Tribunal de Justicia de la UE estableció en el pasado que las CCT solo pueden utilizarse si el nivel de protección que ofrecen es “esencialmente equivalente” al garantizado dentro de la UE — un criterio que ilustra que este terreno cambia y que conviene verificar con asesoría legal en cada momento. Para los procesadores con sede en EE.UU., esto puede ser estructuralmente difícil de lograr, dado que la normativa de vigilancia estadounidense permite en determinados supuestos el acceso del gobierno a datos en manos de empresas estadounidenses.

Distintas autoridades y organismos europeos de protección de datos han señalado en diversas ocasiones, tras Schrems II, la necesidad de medidas técnicas suplementarias cuando las CCT por sí solas no pueden garantizar la equivalencia — conviene verificar la guía vigente en el momento. La medida recomendada habitualmente: 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 el RGPD explícitamente. El RGPD 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 identificables bajo el 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 la finalidad 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 RGPD 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.

El Futuro de la Aplicación Normativa en IA

Los reguladores europeos de protección de datos vienen mostrando, en general, mayor atención a la IA en los últimos años — conviene consultar la guía vigente de tu autoridad de control antes de diseñar la arquitectura de tu aplicación.

La tendencia general apunta hacia exigir no solo cobertura contractual (CCT) sino también medidas técnicas complementarias como la seudonimización. Construir la capa técnica con antelación, en lugar de esperar a que la aplicación normativa alcance a tu producto, es una estrategia prudente que escala mejor a largo plazo.

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.