Retención de datos y ZDR en LLM: quién puede leer tus prompts

Tu prompt no va simplemente a “la empresa de IA”. En un stack de agentes, atraviesa una cadena de partes que lo procesan en texto claro. Cuáles intervienen depende del stack: la telemetría del framework de agentes, una plataforma de tracing, un almacén de memoria, una herramienta de analítica, un gateway de IA y uno de tres tipos de proveedores de inferencia. Cada uno aplica su propia política de retención, región de almacenamiento y cláusula de entrenamiento. Quien más tiempo conserva tus prompts suele estar de tu lado de la API: los proveedores de modelos eliminan los logs estándar en unos 30 días, mientras que los servicios de tracing y memoria suelen conservarlos hasta que tú los borras. La retención cero de datos (ZDR) es un acuerdo real y útil, pero solo fija una de esas partes y uno de tres ejes. Este artículo recorre toda la cadena: quién retiene qué, durante cuánto tiempo y qué cubre realmente ZDR.

TL;DR

• Cada salto que recibe texto claro puede recopilarlo. El tracing y los almacenes de memoria del agente conservan los prompts mucho más tiempo que cualquier proveedor de modelos.
• La retención se define por funcionalidad: en la API de Claude, el caching admite ZDR, los jobs batch duran 29 días y Fable 5 exige 30 días.
• La ubicación depende del servidor: la API oficial de DeepSeek almacena los datos en la República Popular China, sin otra opción.
• Los endpoints gratuitos presentan el mayor riesgo: los derechos de entrenamiento suelen ser el precio de la capacidad gratuita.
• ZDR resistió ante los tribunales: la orden de conservación del NYT solo eximió a los clientes de API con retención cero.

¿Quién puede leer tu prompt en un stack de agentes?

Todos los que están en la ruta, y la ruta es más larga de lo que suele aparecer en los diagramas de los equipos:

Recorrámosla de izquierda a derecha. La capa del agente es tuya, pero rara vez solo tuya: los frameworks incluyen telemetría; las plataformas de tracing y observabilidad existen precisamente para almacenar prompts y respuestas completos; las funciones de memoria escriben conversaciones en almacenes vectoriales que no caducan por sí solos; y un script de analítica con session replay en la interfaz web captura el prompt mientras el usuario lo escribe, antes incluso de que llegue al backend. El gateway representa una parte si lo operas tú y dos si es SaaS. Los gateways SaaS se dividen en dos tipos. El primero es el agregador multiproveedor: una API que distribuye cada solicitud entre los proveedores conectados. Su tratamiento de los datos siempre combina dos políticas, la suya y la del host que haya procesado esa solicitud concreta. El segundo procede de proveedores de seguridad: gateways de prevención de pérdida de datos (DLP) y guardrails cuyo producto consiste en inspeccionar payloads, redactarlos y aplicar políticas. Leer cada prompt es parte de su función, y los prompts marcados suelen conservarse intencionadamente como eventos de seguridad.

Tras el gateway hay tres tipos de proveedores de inferencia: la API del propio proveedor del modelo, un proveedor cloud que aloja el modelo dentro de tu tenancy y hosts de GPU que sirven pesos abiertos bajo sus propias políticas de logging. La rama alternativa, inferencia self-hosted en un tenant dedicado o en tus propias GPU, es la única ruta donde ningún tercero procesa texto claro, aunque tiene una contrapartida que veremos más adelante.

La regla que ordena todo lo demás es simple: ver y conservar son cuestiones distintas. Cada componente puede recopilar datos técnicamente. Que lo haga o no depende de sus valores predeterminados, su configuración y sus contratos, que varían enormemente a lo largo de la cadena.

¿Quién conserva realmente tus prompts?

Normalmente, tus propias herramientas, y durante más tiempo que nadie. Las ventanas de retención de los proveedores que dominan los cuestionarios de seguridad se miden en días. Los almacenes del agente que nadie incluye en esos cuestionarios conservan los datos para siempre.

La capa del agente retiene datos por diseño. El producto de una plataforma de tracing es una base de datos con tus prompts y outputs. Su retención es una configuración del proyecto, no un efecto accidental de la política. Los valores predeterminados varían según la herramienta y conviene conocerlos: la integración de OpenTelemetry de GitHub Copilot exporta la estructura de los spans, los tiempos y el número de tokens, pero no el contenido de los prompts, salvo que actives expresamente su captura. Es un patrón conservador en materia de privacidad que más herramientas para agentes deberían copiar. El modo de privacidad de Cursor existe porque el modo predeterminado comparte datos del código. Aunque el proveedor del modelo borre la información después de 30 días, tu almacén de trazas seguirá teniéndola el día 300.

El gateway conserva lo que decide conservar. Un gateway no puede prescindir de los registros de uso: para facturar necesita conocer el número de tokens, los modelos y la marca de tiempo de cada solicitud. Sí puede evitar por completo el almacenamiento de payloads: los cuerpos de prompts y respuestas pueden pasar por memoria sin escribirse nunca en almacenamiento persistente. Sin embargo, dos funciones habituales de los gateways cruzan esa línea sin llamar mucho la atención. Una consola de inspección de solicitudes u observabilidad almacena payloads por definición, igual que una plataforma SaaS de tracing situada un salto antes. El caching en el gateway también almacena el contenido del prompt en ese salto: una caché semántica conserva un embedding del prompt y la respuesta completa, mientras que una caché de respuestas conserva ambos lados literalmente en el disco donde se ejecuta el gateway. Al evaluar un gateway, SaaS o self-hosted, hay que separar tres preguntas: qué incluye el registro de la solicitud, qué persiste la vista de observabilidad y qué escribe la caché.

Los proveedores definen la retención por funcionalidad, no por empresa. El modelo mental más útil aparece directamente en la documentación de retención de la API de Anthropic, que detalla la compatibilidad función por función: prompt caching admite ZDR porque el estado de la caché solo se mantiene en memoria; el procesamiento batch almacena los jobs durante 29 días porque los procesos asíncronos necesitan almacenamiento; los contenedores de ejecución de código persisten hasta 30 días; y los archivos subidos permanecen hasta que los eliminas. La frase más clara de esa página merece citarse: usar una función con estado “es decidir que esos datos concretos queden fuera de tu acuerdo ZDR”. Por parte de OpenAI, la documentación sobre controles de datos enumera los endpoints compatibles con ZDR, mantiene por defecto los logs de supervisión de abusos hasta 30 días y explica que los prompts almacenados en caché permanecen como tensores clave-valor cifrados en almacenamiento local de la GPU, con un TTL limitado. En la API de Claude, el plazo comercial estándar de eliminación es de hasta 30 días.

¿Dónde residen físicamente los datos?

Donde se encuentre la infraestructura que atiende la solicitud. Cada tipo de proveedor ofrece una respuesta distinta. Un modelo alojado en cloud es el caso más sólido: en Amazon Bedrock, el proveedor cloud actúa como encargado del tratamiento y la inferencia permanece en la región elegida. Por eso los compradores sujetos a regulación suelen optar primero por esta vía. La API propia de un proveedor de modelos se ejecuta donde ese proveedor tenga su infraestructura: OpenAI ofrece procesamiento regional en Estados Unidos y la UE para la mayoría de los endpoints; los proveedores más pequeños suelen no publicar información. El caso extremo y sin ambigüedades es DeepSeek. Su política de privacidad establece que los datos personales se recopilan, procesan y almacenan en la República Popular China, sin alternativa en Estados Unidos o la UE para la API oficial. Esos mismos pesos abiertos, servidos por un host de GPU estadounidense, no comparten esa ubicación. Este caso muestra con claridad que el destino de los datos de un modelo depende de quién lo sirve, no del modelo.

Hay dos extensiones más allá de la copia principal. Las cachés y los archivos batch permanecen en la región de servicio durante sus respectivos periodos, al margen del log de solicitudes. Además, todos los proveedores dependen de subencargados, es decir, sus propios proveedores, y de copias de seguridad. Los compromisos de eliminación suelen referirse al borrado de los sistemas activos, seguido de periodos de propagación en backups. Si tu diagrama de flujo de datos termina en el logotipo del proveedor de la API, le faltan al menos esas dos cajas.

¿Quién exige retención y quién entrena con tus prompts?

Tres fuerzas distintas mantienen los datos más allá de los plazos predeterminados, y solo una aparece en el marketing del proveedor.

Requisitos de las políticas. Algunos modelos imponen retención como condición de seguridad. Claude Fable 5 y Mythos 5 exigen 30 días de retención incluso para clientes con ZDR. El sistema falla de forma explícita: si la configuración de retención de una organización no cumple el requisito, la solicitud se rechaza con un 400 en lugar de aceptarse silenciosamente. El escalado por abuso añade otra retención: el contenido marcado por infringir las políticas de uso sigue un plazo completamente distinto. La política de consumo de Anthropic documenta hasta 2 años para inputs y outputs marcados, y hasta 7 años para las puntuaciones de los clasificadores.

Órdenes de conservación judicial. El litigio NYT contra OpenAI produjo el experimento real más claro sobre las promesas de retención. Una orden de conservación de mayo de 2025 obligó a OpenAI a preservar logs de outputs que, de otro modo, habría eliminado, incluidos chats borrados por usuarios de los planes de consumo. La orden se acotó en septiembre, y más tarde un tribunal ordenó entregar 20 millones de logs de chats durante la fase de discovery. Para los compradores de API, el detalle clave es que los clientes enterprise y con retención cero quedaron excluidos, porque no había datos almacenados que conservar. Una orden judicial puede suspender una política de eliminación. No puede afectar a datos que la arquitectura nunca almacenó.

Intermediarios que recopilan datos. Los intermediarios de la cadena sí han sido descubiertos monetizando texto claro, y el mayor caso documentado estaba en el punto más cercano al usuario. En diciembre de 2025, investigadores de seguridad documentaron que una extensión de navegador de una VPN “de privacidad”, con millones de instalaciones, inyectaba scripts en páginas de chat con IA. Interceptaba todos los prompts y respuestas de ChatGPT, Claude, Gemini y otros cinco asistentes, y enviaba las conversaciones a una empresa afiliada dedicada a la intermediación de datos. La recopilación se producía tanto si la VPN estaba activada como si no y afectó a unos 8 millones de usuarios de la familia de extensiones del proveedor. El incidente implicó un interceptor en el cliente, no un gateway de API, pero la lección se aplica a cada caja del diagrama: cualquier intermediario que procese texto claro puede recopilarlo, su incentivo puede ser monetizarlo y la interceptación resulta invisible desde ambos extremos. Confiar en un intermediario depende de su modelo de negocio, no de su lista de funciones.

Cláusulas de entrenamiento. Las API empresariales de los principales proveedores no entrenan con tus datos por defecto. Los productos de consumo lo hacen cada vez más, salvo que desactives esa opción. Es otra razón para enviar el tráfico de los agentes mediante API keys y no desde cuentas de consumo. Además, cada vez más productos delegan el entrenamiento en una opción que debes encontrar por tu cuenta: planes de consumo con entrenamiento activado por defecto y un opt-out escondido en la configuración; herramientas de desarrollo cuya opción de telemetría o de compartir código también sirve como consentimiento para entrenar; programas de proveedores que ofrecen descuentos o cuota gratuita a cambio de compartir datos; y paneles de agregadores con opciones de entrenamiento separadas para planes de pago y gratuitos. Cada opción se aplica por cuenta, a veces por workspace, y su valor predeterminado puede cambiar al actualizarse las condiciones. Revisarlo una vez no basta. Auditar estas opciones debe formar parte de la misma lista periódica que la rotación de claves.

Modelos gratuitos, tratados aparte de forma intencionada. Todas las advertencias anteriores se concentran en un punto: el nivel gratuito. El lanzamiento de un modelo gratuito suele estar subvencionado por quien se beneficia del tráfico, normalmente el propio proveedor del modelo. Los prompts enviados a la variante gratuita llegan a esa parte bajo su política, que suele incluir derechos de entrenamiento, y se procesan donde opere. Para los proveedores chinos, eso significa China. Los gateways agregadores publican políticas de datos por endpoint y ofrecen una opción para excluir a los proveedores que entrenan precisamente porque estas cláusulas aparecen en las rutas gratuitas. La regla práctica es directa: trata un endpoint gratuito como un envío de datos, no como una llamada de API. Alguien paga la inferencia gratuita, y la moneda suelen ser tus prompts.

¿Qué significa realmente ZDR?

ZDR fija uno de tres ejes, para una parte concreta de la cadena y solo en las funciones compatibles. No es una crítica, sino la definición. Conocer sus límites permite utilizarlo correctamente.

• Los tres ejes. El uso para entrenamiento, la duración de la retención y el acceso humano son independientes. Las API empresariales ya excluyen tus datos del entrenamiento. ZDR reduce a cero la retención de payloads. El acceso humano se rige por separado mediante procesos de control de abusos. Confundirlos lleva a exagerar lo que ofrece ZDR.
• Qué permanece con ZDR. Los metadatos de uso y los registros de facturación, los outputs de los clasificadores de seguridad y el estado de cualquier función con estado que actives. Los dos grandes proveedores ya diseñan sus sistemas para evitar la excepción del control de abusos: uno conserva señales de seguridad sin payloads y el otro solo los resultados de los clasificadores.
• Qué queda fuera de ZDR. Todo lo situado antes del proveedor: tu almacén de tracing, los logs del gateway y la memoria vectorial. La configuración más habitual, y la menos coherente, es tener un acuerdo ZDR con un proveedor de modelos mientras un SaaS de tracing conserva cada prompt indefinidamente.
• La salvedad del self-hosting. Ejecutar pesos abiertos en tus propias GPU elimina a todos los terceros, pero traslada el problema a tu infraestructura: logging de solicitudes del servidor de inferencia, access logs y archivos de trazas. El self-hosting reubica la superficie de retención. Solo una gestión deliberada de los logs la reduce.

Cómo lo gestiona Synthorai

El salto del gateway es nuestro, así que los compromisos son concretos. En el modo de retención cero, los cuerpos de las solicitudes y respuestas pasan por memoria y no se escriben en almacenamiento persistente. Solo se conserva el registro de uso necesario para facturar: marcas de tiempo, modelo, número de tokens y un hash del contenido que permite identificar una solicitud durante una disputa sin guardar lo que se dijo. Antes de enrutar, filtramos la lista de proveedores: Synthorai solo incorpora proveedores que se comprometen a aplicar retención cero a nuestro tráfico, con una excepción documentada, Claude Fable 5. Su retención de 30 días viene impuesta por el proveedor del modelo y no puede eliminarse mediante contrato. Elegir proveedor implica elegir retención. La función del gateway es mostrar esa propiedad de forma explícita para cada ruta, no esconderla en el PDF de una política: una ruta de Fable 5 incluye su requisito de retención como metadato documentado, no como sorpresa.

Preguntas frecuentes

¿Los proveedores de LLM entrenan por defecto con los datos de la API?

No. Las API empresariales de los principales proveedores no entrenan por defecto con los datos de sus clientes. Ese compromiso figura en la documentación sobre controles de datos de cada proveedor. Las excepciones se concentran en los actores menos consolidados: productos de consumo que requieren opt-out en lugar de opt-in, algunos hosts de GPU que sirven pesos abiertos y endpoints gratuitos donde los derechos de entrenamiento forman parte del precio.

¿ZDR significa que el proveedor no almacena absolutamente nada?

No. ZDR significa que los payloads de prompts y respuestas no se conservan para las funciones compatibles. Los metadatos de uso, los registros de facturación y los outputs de los clasificadores de seguridad permanecen. Las funciones con estado, como los jobs batch o la carga de archivos, almacenan datos por su propia naturaleza y quedan fuera de ZDR. Lee la tabla de compatibilidad por función, no el titular.

¿Es seguro enviar datos de producción a modelos gratuitos?

Trata un endpoint gratuito como un envío de datos, no como una llamada de API. La capacidad gratuita está subvencionada por quien se beneficia del tráfico, los derechos de entrenamiento suelen formar parte del acuerdo y los datos se procesan donde opere esa parte. Para experimentos desechables puede ser un intercambio razonable. Para cualquier contenido con datos de clientes, código o credenciales, rara vez lo es.

¿El self-hosting es automáticamente la opción más privada?

Elimina a todos los terceros de la ruta de texto claro, y eso es una ventaja real. No elimina la retención: los servidores de inferencia, reverse proxies y sistemas de tracing generan logs por defecto. Un stack self-hosted con la configuración predeterminada puede conservar más datos de prompts que una API con ZDR. La privacidad depende de cómo configures el logging, no del modelo de hosting.

Fuentes verificadas el 2026-08-29: cada afirmación sobre proveedores enlaza con la documentación del propio proveedor o con expedientes judiciales originales. Las políticas de este ámbito cambiaron dos veces durante el mes anterior a la publicación, así que considera los enlaces como la fuente de referencia actualizada. Este es un análisis técnico, no asesoramiento jurídico.

Relacionado: el requisito de retención de 30 días de Fable 5, cómo funciona prompt caching, comparativa de cachés de proveedores.

← Volver al blog