Zero Data Retention (ZDR) se debe demostrar para la ruta concreta que transporta la solicitud, no para el logotipo del proveedor. Que una API no use prompts y respuestas para entrenar modelos no significa que no los conserve: el contenido puede aparecer en logs de abuso, historial de conversaciones, archivos, cachés, herramientas, un gateway o tu propia plataforma de observabilidad.
Antes de aprobar datos sensibles:
- dibuja el flujo completo desde la aplicación hasta el modelo y de vuelta;
- revisa seis planos de retención independientes;
- conserva evidencia de la organización o proyecto, endpoint, modelo, región, funciones y configuración real.
Si un plano no se puede probar, la ruta queda condicionada o bloqueada. Esta guía convierte términos de proveedor en controles técnicos; no certifica cumplimiento ni sustituye la revisión jurídica, de privacidad o de seguridad de tu organización.
No entrenar, retención limitada y ZDR no son sinónimos
Las tres promesas responden a preguntas distintas.
| Promesa | Qué permite afirmar | Qué no demuestra |
|---|---|---|
| No se usa para entrenamiento | El servicio descrito no utiliza tu contenido para mejorar el foundation model | Que el contenido nunca se escriba en un sistema |
| Retención limitada | El contenido o metadata se elimina tras un plazo definido | Que el plazo sea cero o igual para todas las funciones |
| Zero Data Retention | Bajo un acuerdo y una ruta elegible, el contenido no queda almacenado después del procesamiento definido | Que archivos, búsqueda, agentes, batch, gateways y logs propios estén cubiertos |
Este matiz cambia una decisión de producción. Un servicio de pago puede excluir el entrenamiento y conservar temporalmente contenido para prevención de abuso. Un parámetro store=false puede desactivar el estado de una API concreta, pero no concede por sí solo ZDR a la organización ni controla herramientas posteriores.
Los seis planos que debes revisar
Tratar “retención” como un único interruptor oculta excepciones. Separa al menos estos seis planos, cada uno con dueño, plazo y evidencia.
1. Uso para entrenamiento
Lee los términos del producto API, plan y mercado exactos. No transfieras las condiciones de un chatbot de consumo a la API empresarial. Este control es necesario, pero solo explica si el contenido mejora modelos.
2. Logs de abuso y seguridad
El proveedor puede conservar customer content para detectar o investigar abuso. OpenAI documenta hasta 30 días por defecto y ofrece Modified Abuse Monitoring o ZDR a organizaciones elegibles después de aprobación. También existen excepciones jurídicas y de safety que impiden prometer borrado absoluto.
3. Estado de aplicación del proveedor
Responses almacenadas, conversations, threads o session resumption son estado de producto, no necesariamente logs de abuso. Pueden tener otro control y otro ciclo de vida. Desactivar content logging no prueba que se haya desactivado una conversación persistente.
4. Almacenamiento de funciones
Files, vector stores, caches, batch jobs, fine-tuning, code execution y agent workspaces necesitan guardar estado. La tabla actual de OpenAI marca varias superficies como no elegibles para ZDR. Anthropic excluye Managed Agents, Files, batch, code execution y MCP connector.
5. Subencargados, herramientas y gateways
La solicitud puede atravesar un proxy, observability vendor, MCP server, web search o segundo proveedor. La política del modelo principal no cubre automáticamente esos nodos. Para una revisión de protección de datos, el mapa técnico también debe coincidir con la cadena contractual de encargados y subencargados.
6. Logs y bases controlados por el cliente
Un upstream con ZDR no borra payloads de API gateway logs, APM traces, error reports, SIEM, historial de prompts, tickets de soporte o copias de seguridad. Aquí suele quedar la copia más completa. Aplica redaction antes de escribir, allowlists de campos, plazos de borrado y pruebas de restauración.
Matriz actual: compara rutas y funciones, no empresas
Los hechos siguientes se verificaron el 27 de julio de 2026. Son una base para tu comprobación actual, no una garantía permanente.
| Ruta | Control oficial confirmado | Límite que cambia la decisión | Evidencia mínima |
|---|---|---|---|
| OpenAI API | Organizaciones elegibles pueden solicitar MAM/ZDR; con ZDR, /v1/responses y /v1/chat/completions tratan store como false | Conversations, ChatKit Threads, Assistants/Threads, files, vector stores, batches y otras superficies con estado pueden no ser elegibles | Aprobación, organization/project ID, endpoint, features y fila vigente de retención |
| Anthropic API | ZDR se habilita por organización; Messages y Token Counting elegibles no guardan prompts/responses at rest tras la respuesta | Managed Agents, Files, batch, code execution y MCP connector quedan fuera; algunos modelos actuales exigen 30 días | Organización, modelo exacto, endpoint y feature inventory |
| Gemini Developer API | Paid Services no usa prompts/responses para mejorar productos; el ZDR de un proyecto aprobado limpia contenido e identificadores antes del abuse log | Search/Maps grounding conserva 30 días. En Logs and datasets, Interactions usa store=true por defecto y Generate Content store=false, pero el logging puede activarse por request/proyecto; logs: 55 días por defecto, configurables a 7/14/28/55; datasets sin caducidad automática | Project ID, aprobación, store efectivo, project logging, datasets/export/share, plazo y borrado |
| Azure OpenAI / Azure Direct Models | Microsoft no entrena foundation models con prompts/outputs sin permiso; el estado de funciones queda en el recurso Azure del cliente | Microsoft habla de modified abuse monitoring, no de un ZDR genérico para cada deployment; previews pueden diferir | Resource, región, aprobación, ContentLogging=false y recursos asociados |
| Amazon Bedrock | AWS indica que los model providers no acceden a cuentas, logs, prompts o completions del deployment Bedrock | Invocation logging, CloudTrail, agents, knowledge bases y sessions siguen siendo planos de almacenamiento del cliente | Cuenta/región, inventario de servicios, logging, IAM/KMS y política de borrado |
| Gateway o agregador | Algunos permiten restringir routing a endpoints clasificados como ZDR | La etiqueta del gateway no certifica al upstream; sus logs y herramientas forman parte de la ruta | Política propia, upstream exacto, provider route, logs, subencargados y contrato |
OpenRouter, por ejemplo, diferencia no-training de no-retention y permite limitar routing a endpoints que clasifica como ZDR. Es un control útil, pero su clasificación no reemplaza la revisión del endpoint upstream, provider logging y sistemas del cliente.
En este análisis no se pudieron verificar términos públicos de ZDR para laozhang.ai. Por eso no debe elegirse para una carga que exige ZDR hasta demostrar su propia retención, el upstream exacto, subencargados, defaults de logging y contrato. Si tu tarea previa es decidir entre API directa y gateway por coste u operación, consulta la comparación de proveedores API LLM, pero vuelve a evaluar la ruta de datos por separado.
La ficha de evidencia que convierte una promesa en control
Una captura de una landing page no basta. Crea una ficha por cada ruta de producción:
textClasificación de datos: Aplicación y entorno: Organización / proyecto / workspace: Región: Gateway y upstream: Endpoint y modelo: Funciones, tools y grounding: Uso para entrenamiento: Abuse/safety retention: Application state: Files/cache/batch retention: Project logging y `store` efectivo: Datasets, exportación, compartición y borrado: Logs/traces/backups propios: Documento oficial y fecha: Export de configuración o evidencia admin: Excepciones y stop rule: Responsable: Próxima revisión:
La ficha debe permitir que otra persona reproduzca la conclusión. “Lo desactivamos en la consola” no es reproducible. Conserva el identificador del recurso, export de configuración o comprobación administrativa, evitando secretos, datos personales y customer content en el artefacto.
Para privacidad y compras, añade por separado base jurídica, finalidad, DPA, transferencias y cadena de subencargados. Esos elementos no se pueden deducir de un switch técnico de ZDR.
Prueba técnica sin usar datos reales
Una llamada no demuestra por sí sola la política contractual, pero sí revela configuraciones y copias no previstas.
- Crea un marcador sintético único. No uses un secreto ni un dato personal.
- Registra la ruta efectiva. Host, gateway, provider, endpoint, model ID, región y feature flags.
- Busca el marcador en tus sistemas. API gateway, application logs, traces, error monitoring, SIEM y data warehouse.
- Comprueba superficies con estado. Verifica que no se hayan creado conversation, file, cache, batch, agent session o search artifact.
- Ejecuta el borrado exigido. Si la función crea recursos, prueba delete, plazo y tratamiento de backups.
- Compara con contrato y documentación. Un
200 OKsolo prueba que el endpoint respondió; no prueba retención cero.
No introduzcas información real “para ver si se filtra”. Un marcador sintético ofrece trazabilidad sin crear un incidente nuevo.
Regla fail-closed para release y control de cambios
Convierte la ficha en un release gate. Obliga a repetir la revisión cuando cambie:
- model ID, proveedor o API version;
- endpoint, región, organización o proyecto;
- gateway, fallback o provider route;
- web search, grounding, MCP, code execution, Files, cache, batch o agents;
- project logging,
store, ventana 7/14/28/55 días, creación, exportación o compartición de datasets; - observability vendor, log level o backup retention;
- contrato, DPA, subencargados, eligibility o tabla oficial.
Si el nuevo camino no tiene ficha completa, no debe recibir campos sensibles. El producto puede enmascarar el payload, usar una ruta local aprobada o fallar con un mensaje claro. Nunca envíes silenciosamente la solicitud a un fallback cuya política no se ha revisado.
Para workloads que no pueden salir del perímetro controlado, incluso un ZDR externo puede ser insuficiente según el threat model. La alternativa puede ser self-hosting o una nube bajo controles propios, pero entonces debes auditar igualmente logs, snapshots, operadores y backups. ZDR reduce una clase de retención; no elimina la responsabilidad de arquitectura.
Decisión final
La pregunta útil no es “¿este proveedor ofrece ZDR?”, sino:
“¿Qué organización o proyecto, endpoint, modelo, región y conjunto de funciones no conserva el contenido, qué excepciones quedan y qué evidencia lo demuestra?
Aprueba únicamente la ruta que coincide con la documentación vigente, la configuración observada, la cadena completa de terceros y tus controles de borrado. Ante cualquier plano desconocido, detén el tráfico sensible. Una promesa de marca no sustituye una prueba por ruta.
