Qué datos guarda OpenAI cuando usas su API: lo que dice la documentación oficial y lo que no te cuenta

Puntos clave

Por defecto, OpenAI retiene los inputs y outputs de la API para monitorización de abuso. La ventana actual debe verificarse directamente en tu acuerdo
Zero Data Retention (ZDR) elimina esa retención para endpoints elegibles, pero los metadatos se siguen almacenando
Un BAA cambia las obligaciones contractuales pero no habilita ZDR por sí mismo
Tus propios logs, proxies y bases de datos suelen ser un riesgo mayor que la retención de OpenAI

Si construyes con la API de OpenAI y tu aplicación toca datos personales (historias clínicas, datos financieros, documentos legales, comunicaciones de usuarios), necesitas saber exactamente qué retiene OpenAI. No lo que la página de marketing sugiere. Lo que la política de privacidad, los acuerdos enterprise y la documentación de la API dicen realmente.

Esta guía recorre cada categoría de retención, enlazando a la documentación del proveedor donde el detalle importa. Estas políticas cambian: trata cada cifra concreta como un punto de partida a verificar, no como un hecho asentado. Donde hay ambigüedad, lo decimos.

Aviso: este artículo explica el marco general del RGPD y HIPAA aplicado a las prácticas de tratamiento de datos de un proveedor concreto. No es asesoramiento jurídico. Las políticas descritas pueden cambiar. Verifica las condiciones vigentes directamente con el proveedor y confirma las decisiones de compliance con tu asesoría legal.

Retención por defecto de datos de la API

Según la documentación de OpenAI, cuando haces una llamada a la API, tu input (el prompt) y el output (la respuesta) se almacenan por defecto para monitorización de abuso y seguridad, no para entrenamiento. La ventana de retención actual y su alcance exacto deben verificarse en tu acuerdo, no asumirse de una cifra citada aquí.

Lo que la política documentada establece sobre esta ventana:

Si envías {"role": "user", "content": "Resume esta nota clínica: María López, fecha nacimiento 15/04/1962, NHC 48291..."}, esa cadena se almacena en la infraestructura de OpenAI durante el período de retención por defecto
Empleados de OpenAI con acceso legítimo pueden revisar inputs y outputs almacenados para fines de seguridad e investigación de abuso
Tras el período de retención, estos datos se eliminan, salvo que tengas un acuerdo contractual que especifique lo contrario

La ventana de 30 días importa para datos regulados. Bajo HIPAA, cualquier sistema que almacena PHI requiere sus propias salvaguardas. Bajo el RGPD, el almacenamiento de datos personales exige una base legal y un plazo de conservación definido.

Zero Data Retention (ZDR): qué cubre y qué no

Zero Data Retention es una configuración opcional disponible para clientes API elegibles (típicamente cuentas enterprise). Con ZDR activado:

OpenAI no almacena tus prompts ni respuestas después de devolver la respuesta
No hay ventana de retención para el contenido de las peticiones

Lo que ZDR no elimina:

Retención de metadatos: timestamps, nombre del modelo, conteo de tokens, IDs de petición y códigos de error se retienen para facturación, rate limiting y fines operativos, incluso con ZDR
Procesamiento en tránsito: tus datos siguen pasando por la infraestructura de inferencia de OpenAI mientras se procesa la petición. ZDR afecta a la persistencia, no al procesamiento
Detección de abuso: los sistemas de detección de abuso en tiempo real de OpenAI siguen procesando las peticiones; ZDR afecta a la retención de logs, no a las comprobaciones de seguridad
Tus propios logs: todo lo que tu aplicación registre antes o después de la llamada a la API está fuera del control de OpenAI

La elegibilidad para ZDR no es automática. Requiere un acuerdo enterprise y puede no estar disponible para todos los endpoints de modelos. Verifica tu acuerdo actual o contacta con ventas de OpenAI.

Característica	Por defecto	Con BAA	Con ZDR
Retención de input/output	Según condiciones vigentes del proveedor	Regido por los términos del BAA	Sin retención de contenido
Retención de metadatos	Sí	Sí	Sí
Entrenamiento con tus datos	No (según política declarada)	No	No
Acceso de empleados	Para revisión de seguridad/abuso	Para revisión de seguridad/abuso	Reducido (sin contenido almacenado)
Transferencia RGPD	Limitada	Parcialmente cubierta	Requiere CCT adicionales
Idoneidad HIPAA	Requiere BAA	Requiere BAA + salvaguardas técnicas	Postura más sólida

Estas filas reflejan la política documentada de OpenAI en el momento de escribir. Las ventanas de retención, la elegibilidad ZDR y los términos BAA cambian. Verifica las cifras actuales directamente con el proveedor antes de diseñar controles de compliance basados en ellas.

Entrenamiento con tus datos: la política declarada

Según la documentación publicada de OpenAI, los datos de la API no se usan para entrenar los modelos de OpenAI por defecto. Esto aplica a inputs y outputs de la API de Chat Completions, Assistants, Embeddings y otros endpoints estándar. Verifícalo directamente en tu acuerdo actual. Las políticas declaradas de uso de datos pueden cambiar sin aviso, y el detalle que importa es lo que dice tu acuerdo, no lo que decía una versión anterior de la documentación.

La excepción clave: los datos de fine-tuning. Cuando envías un trabajo de fine-tuning, subes datos de entrenamiento a OpenAI. Esos datos:

Se usan para entrenar tu variante de modelo fine-tuned
Se almacenan durante la duración del trabajo y la existencia de tu modelo
No se usan para entrenar los modelos fundacionales de OpenAI (según la política actual)

Si estás haciendo fine-tuning con datos que contienen PHI o información personal, los datos de entrenamiento viajan a OpenAI y persisten allí. Un BAA que cubra datos de fine-tuning debe especificar qué puede y no puede hacer OpenAI con ellos tras la finalización del trabajo. La mayoría de BAAs estándar no abordan esto con suficiente especificidad.

La API de Embeddings: a menudo ignorada

La API de Embeddings convierte texto en vectores numéricos para búsqueda semántica y sistemas RAG.

Cuando llamas a la API de Embeddings:

El texto de entrada se envía a OpenAI para su procesamiento
Aplica la misma retención por defecto
El embedding devuelto (un vector de floats) es opaco, pero la llamada API que lo generó contenía tu texto original

Los equipos que construyen sistemas RAG sobre documentos sanitarios o legales a menudo se centran en la seguridad del vector store sin considerar que cada documento troceado y embebido pasó por la infraestructura de OpenAI como texto plano. Si esos documentos contienen PHI o datos personales, las llamadas a la API de embeddings están sujetas a los mismos requisitos HIPAA y RGPD que cualquier otra llamada.

El principio de mínimo necesario aplica también aquí: no siempre necesitas embeber documentos completos. Embeber solo las partes clínicamente o legalmente relevantes reduce tanto tu superficie de compliance como tus costes de embeddings.

Tus propios logs: la exposición más común

Un hallazgo contraintuitivo al auditar sistemas de IA: tu propia infraestructura es a menudo un riesgo de datos mayor que tu proveedor de IA.

Fuentes comunes de retención no intencionada de datos personales en aplicaciones de IA:

Logs de aplicación: la mayoría de frameworks web registran los cuerpos de las peticiones en nivel DEBUG
Logs de API gateway: si tu gateway o balanceador registra cuerpos de petición (algunos lo hacen por defecto), los datos personales en prompts quedan capturados
Logs de proxy y middleware: herramientas de observabilidad LLM (LangSmith, Helicone, Portkey) que se sitúan entre tu aplicación y OpenAI registran prompts y respuestas por diseño
Logs de cliente (navegador/móvil): si la construcción del prompt ocurre en el cliente y este envía logs a un servicio de crash reporting, los datos pueden acabar en Sentry, Datadog o herramientas similares sin controles
Logs de consultas a base de datos: si tu sistema RAG registra qué documentos se recuperaron y esos documentos contienen datos personales, tu log de consultas es un almacén de datos personales

Auditar tu propio pipeline de logging es frecuentemente más productivo que negociar ZDR con OpenAI.

Conclusión práctica

El tratamiento de datos de OpenAI para clientes API es más consciente de la privacidad de lo que la mayoría asume: sin entrenamiento con tus datos por defecto, ventana de retención limitada, ZDR disponible. Los riesgos son reales pero gestionables, y a menudo se gestionan mejor controlando qué llega a OpenAI que optimizando los términos contractuales de lo que OpenAI hace con lo que recibe.

Si tu aplicación envía datos personales a OpenAI, la ventana de retención, el acceso de empleados para revisión de seguridad y el procesamiento en Estados Unidos son preocupaciones legítimas. La solución para todas ellas es la misma: interceptar los datos personales antes de la llamada a la API, seudonimizarlos y enviar tokens en lugar de identificadores.

Privedge ejecuta esta interceptación en el edge de Cloudflare, antes de la llamada a OpenAI, en infraestructura que tú controlas. Nombres, fechas e identificadores de pacientes se convierten en tokens. OpenAI recibe y retiene contenido anonimizado. Tu BAA, tu configuración ZDR y tu ventana de retención pasan a ser consideraciones secundarias en lugar de riesgos primarios.

Si quieres entender mejor la diferencia entre anonimización, tokenización y cifrado antes de implementar, aquí tienes la guía: Anonimización vs tokenización vs cifrado en IA. Y si lo que necesitas es una checklist de cumplimiento para tu DPO: Cumplimiento normativo IA: checklist para DPOs.