"Zero Data Retention" es la frase que te pone en el portal de cualquier proveedor de IA serio. Suena a garantía absoluta: cero datos retenidos, nada que preocupar. La realidad es más granular, tiene letra pequeña y depende de qué endpoint uses, qué plan tengas y a qué hayas dicho que sí.
Este artículo explica qué significa ZDR realmente en 2026, cómo funciona en OpenAI y Anthropic, qué limitaciones tiene y qué deberías exigir por escrito antes de firmar con un proveedor.
La definición corta
Zero Data Retention significa que, cuando tu aplicación manda un prompt al proveedor, la infraestructura:
Procesa la petición.
Devuelve la respuesta.
Elimina los datos inmediatamente.
Sin logs persistentes, sin almacenamiento para safety review, sin retención para entrenamiento futuro, sin acceso humano a revisores internos.
Lo que NO significa:
No significa que el dato nunca pase por la infraestructura del proveedor (sí pasa, solo se borra después).
No significa que no haya latencia de red hacia EEUU si el proveedor es americano.
No significa compliance RGPD automático (ZDR es condición necesaria, no suficiente).
Cómo funciona ZDR en OpenAI
OpenAI tiene dos regímenes de retención para la API:
Régimen estándar (sin ZDR)
Por defecto, la API de OpenAI retiene peticiones y respuestas 30 días para propósitos de monitoreo de abuso y seguridad. Después, se borran. Esta retención aplica a:
chat/completionsyresponsesendpoints.embeddings,moderations,audio,images.Fine-tuning APIs.
Durante esos 30 días, revisores humanos de OpenAI pueden acceder a los datos si el sistema de abuso marca algo sospechoso.
Régimen ZDR
Disponible solo para clientes aprobados (no es automático). Requiere:
Solicitar explícitamente a sales.
Firmar términos adicionales.
Cumplir criterios de caso de uso y volumen.
Con ZDR activado:
No hay retención de 30 días.
Datos no se usan para entrenamiento.
Datos no pasan por abuse monitoring humano.
El output se entrega y el input se borra.
Pero dos excepciones importantes:
Detección de CSAM: si el clasificador automático detecta contenido de abuso infantil, la imagen se retiene para revisión manual incluso con ZDR. Esto es obligación legal, no política.
Tú sigues siendo responsable del uso: ZDR te transfiere parte del marco de safety. Si tus usuarios usan tu app para algo prohibido, OpenAI se reserva el derecho.
Qué endpoints soportan ZDR
A abril de 2026, ZDR está disponible para los endpoints principales (chat/completions, responses, embeddings, audio). No está disponible para fine-tuning (necesariamente retiene datos para entrenar).
Si usas Azure OpenAI Service, ZDR se solicita a través de Microsoft con formulario distinto y tiene criterios propios. Es un proceso separado.
Cómo funciona ZDR en Anthropic
Anthropic tiene una postura más clara pública:
API por defecto: datos no se usan para entrenar.
Claude Pro, Team: datos no se usan para entrenar.
Claude Enterprise: retención configurable, ZDR disponible.
La diferencia clave: Anthropic declara públicamente "no entrenamos con chats de usuarios de producto" para todos los planes. OpenAI lo hace para Team y Enterprise, con matices para Plus.
En Enterprise, Anthropic ofrece:
Retención mínima configurable (puede llegar a 0).
Compliance API con audit logs.
HIPAA-ready con BAA disponible.
El modelo de retención en API está documentado en sus términos de servicio. Para proyectos con datos sensibles, lo normal es pedir un DPA específico que confirme ZDR y SCCs para transferencia UE-EEUU.
ZDR ≠ RGPD compliance
Aquí es donde muchos proveedores (y muchos compradores) confunden. ZDR resuelve una pieza del puzle RGPD:
✅ Principio de minimización (Art. 5.1.c): no retienes más de lo necesario.
✅ Limitación de plazo (Art. 5.1.e): el plazo es cero.
Pero NO resuelve:
❌ Base legal (Art. 6): sigues necesitando consentimiento o interés legítimo para procesar.
❌ Transferencia internacional (Art. 44-49): si el proveedor es americano, Schrems II sigue siendo tema.
❌ Derechos del interesado (Art. 15-22): si no retienes, bien, pero igual necesitas procedimiento para responder solicitudes.
❌ Sub-procesadores (Art. 28): ZDR no cubre qué hace el proveedor con otros terceros.
Para ser compliant RGPD en IA, ZDR es condición necesaria pero no suficiente. Necesitas todo el stack: DPA firmado, SCC, TIA documentado, base legal, y lo que la guía completa de IA y RGPD detalla.
Cómo verificar ZDR en un proveedor antes de firmar
Tres capas de verificación:
1. El papel: qué dice el DPA
Pedir la versión del DPA (Data Processing Agreement) del proveedor. Buscar cláusulas específicas:
Retention period: ¿dice "zero", "immediately deleted" o da un plazo? Un plazo ≠ ZDR.
Access logs: ¿el proveedor registra qué pasó aunque no retenga el contenido? Eso puede ser problemático.
Sub-processors: ¿se declaran? ¿Puedes auditar la lista? ¿Se actualiza con notificación?
Exceptions: ¿hay casos donde sí retienen (CSAM, requerimientos legales, auditoría de seguridad)?
Geographic scope: ¿ZDR aplica igual en región EEUU y EU? ¿O solo en una?
2. La técnica: qué se observa en transit
¿Te dan IP ranges de entrada para whitelist?
¿TLS 1.3 obligatorio y confirmado?
¿Usas residencia de datos configurable por región?
¿Hay headers de respuesta que indiquen cero retention (algunos proveedores los incluyen)?
3. La operación: qué pasa en incidente real
Pregunta al proveedor:
¿Cómo respondes a un data subject request cuando dices que no retienes datos?
¿Cómo auditas tú mismo que estás cumpliendo ZDR?
¿Tenéis informe SOC 2 Type 2 con test de controles de retention?
Si hay una brecha, ¿qué notificáis si no había nada que brechar?
Las respuestas a estas preguntas separan proveedores serios de los que solo escriben "Zero Data Retention" en marketing.
El caso empresa europea
Para una empresa española o europea evaluando proveedores de IA en 2026, la lógica de decisión típica:
ZDR disponible: mínimo no negociable.
Infraestructura UE: segundo filtro. Si hay opción UE + ZDR, preferir UE (menos complejidad Schrems).
DPA específico RGPD: no un template americano con disclaimer de ley aplicable California.
Sub-procesadores europeos: preferible pero no bloqueante.
SOC 2 + ISO 27001 + ENS (si aplica por ser administración pública): obligatorio.
Proveedores que cumplen los 5 puntos a 2026:
Mistral (Francia): EU-native, GDPR compliance, Paris hosting.
Aleph Alpha (Alemania): mismo perfil en centro-Europa.
Levante Platform (España): wrapper multi-proveedor con enrutado UE por defecto, ZDR estándar.
Proveedores con ZDR pero en EEUU:
OpenAI (con Enterprise + ZDR + TIA).
Anthropic (con Enterprise + DPA específico).
Azure OpenAI (con EU Data Boundary + ZDR).
Ningún plan funciona para todos los casos. Para datos del Art. 9 (salud, biometría, origen racial, etc.), la tendencia es a exigir UE-hosting adicionalmente a ZDR.
El caso desarrollador/startup
Si no estás en una empresa regulada y solo quieres protección razonable:
Claude Pro o ChatGPT Plus: datos no se usan para entrenar, retention 30 días. Sirve para trabajo normal.
APIs con retention estándar: 30 días es aceptable para la mayoría de casos.
ZDR opcional: solo lo necesitas si tus clientes (los tuyos) te lo exigen o si procesas datos sensibles.
No sobre-ingenieriza. ZDR cuesta esfuerzo operativo (procedimientos, contratos, auditoría) y no siempre compensa.
FAQ
¿ZDR aplica a GPT-4/5 usado desde ChatGPT o solo desde la API?
ZDR como feature contractual está disponible solo vía API con aprobación. ChatGPT Team/Enterprise tienen políticas de no-entrenamiento pero no ZDR estricto al 100% — siguen reteniendo para safety review 30 días.
¿Claude tiene ZDR por defecto?
En API: retention mínima está declarada y los datos no se usan para entrenar en Pro/Team/Enterprise. ZDR estricto contractual suele pedirse en Enterprise con DPA firmado.
¿ZDR se puede auditar técnicamente?
Parcialmente. Puedes verificar con SOC 2 reports que hay controles implementados, pero no puedes observar directamente "el dato no está almacenado". Te basas en el reporte de auditoría externa y en el contrato.
¿Gemini / Azure OpenAI / Bedrock tienen ZDR?
Google Gemini: Enterprise tiene políticas similares a OpenAI Enterprise. Azure OpenAI: ZDR disponible con proceso aparte vía Microsoft. Amazon Bedrock: retention configurable con políticas de AWS.
¿Qué pasa con logs de infraestructura?
Aunque el contenido no se retenga, la infraestructura suele registrar metadata (request ID, timestamp, tamaño, etc.). Esto normalmente no es dato personal identificable por sí solo, pero revisa en el DPA cómo se describe.
¿ZDR impide detectar abuso?
Sí y no. Con ZDR, el proveedor no puede hacer abuse monitoring humano de tus prompts. La responsabilidad de prevenir abuso se traslada a ti como cliente. Por eso ZDR requiere criterios de elegibilidad.
¿Qué pasa con el context window / conversation history?
La history de conversación que mandes como parte del prompt se trata igual que el prompt: se procesa y se borra. Si tu aplicación almacena la history en tu DB, eso es tuyo y tu responsabilidad.
Recapitulando
ZDR es una garantía real y significativa, pero no mágica. No elimina la complejidad del compliance RGPD — solo uno de sus ejes. Si lo exiges a tu proveedor, verifica el DPA con cuidado, entiende las excepciones (CSAM, requerimientos legales) y no asumas que ZDR solo ya te protege frente a Schrems II o sanciones AEPD.
Para el marco completo de cómo usar IA en empresa de forma compliant, el punto de partida es IA y RGPD en 2026: guía para empresas. Para una plataforma europea que integra ZDR por defecto + infraestructura UE + DPA específico español, Levante Platform.
Datos verificados: OpenAI Data controls documentation (abril 2026), Claude pricing (abril 2026).
