La documentación oficial revisada no establece un plazo máximo general para conservar los prompts, las respuestas y todos los registros de la API directa de DeepSeek. Sí describe reglas específicas para la caché de contexto y los archivos subidos. Esas reglas tienen alcances distintos y no permiten asignar una misma fecha de eliminación a todos los datos.
Para evaluar la retención de datos en DeepSeek API, necesitas separar tres preguntas: qué información se almacena, si puede utilizarse para mejorar modelos y cómo se elimina. También importa quién recibe la solicitud: la API oficial, un intermediario o un proveedor que ejecuta el modelo en su propia infraestructura.
¿Cuánto tiempo conserva DeepSeek API tus datos?
Esta guía toma como referencia la API directa disponible en api.deepseek.com. La revisión de sus términos de Open Platform y de la documentación técnica ofrece el siguiente panorama. Es una lectura de fuentes públicas, no una auditoría del almacenamiento interno del proveedor.
| Categoría | Qué está documentado | Cómo interpretar el alcance |
|---|---|---|
| Prompts y respuestas de inferencia | No se identificó un plazo máximo general en las fuentes revisadas. | No asumir una eliminación inmediata ni una ventana estándar de 30 días. |
| Caché de contexto | Se limpia normalmente entre unas horas y unos días después de dejar de usarse. | Describe la caché; no todos los registros de la solicitud. |
| Archivos subidos mediante Files API | Admiten vencimiento configurable; sin configurarlo, la documentación describe almacenamiento permanente. | La regla corresponde al recurso del archivo. |
| Estado de Responses API | La respuesta incluye siempre store: false. | No constituye por sí solo una garantía de retención cero. |
| Logs operativos y copias de respaldo | No se identificó una duración pública única para todas estas categorías. | Solicitar detalles si tu integración exige una fecha límite verificable. |
La política de privacidad vincula la retención de datos personales a las finalidades, obligaciones y reclamaciones aplicables. Incluye un ejemplo de conservación mientras exista la cuenta; no ofrece un calendario específico para todas las solicitudes API.
Los términos de Open Platform son específicos para desarrolladores e incorporan los términos generales. Su sección 5.5 remite a la política de privacidad para la información personal del desarrollador y distingue las reglas de tratamiento que este debe comunicar a los usuarios de su aplicación. Esa distinción no demuestra que los datos enviados desde una aplicación queden fuera de todo procesamiento del proveedor.
Si necesitas una respuesta como «este contenido se elimina como máximo en determinado plazo», la documentación pública revisada no basta para establecerla para todo el flujo. Define las categorías que necesitas cubrir y pide confirmación para el servicio y la cuenta que utilizarás.
Prompts, caché y archivos: los plazos no son intercambiables
Un mismo flujo puede producir varias copias: el texto que envía tu aplicación, un recurso subido, información usada durante la inferencia y registros generados por tus propias herramientas. Eliminar una de ellas no demuestra que las demás hayan desaparecido.
Una API sin estado y store: false no equivalen a ZDR
Una API sin estado conversacional no mantiene una conversación reutilizable de la misma manera que una aplicación de chat. Esto describe cómo continúa el diálogo; no responde por sí solo qué conserva la infraestructura para otras finalidades.
En la guía oficial de Responses API, DeepSeek indica que previous_response_id y conversation no están soportados. Tampoco admite configurar store: el objeto devuelto lleva siempre store: false. Por tanto, ese valor no es un control que puedas activar para obtener una política especial de privacidad.
Para hablar de zero data retention o ZDR, necesitas conocer qué contenido abarca el compromiso, cuándo deja de conservarse y qué excepciones existen. La ausencia de un historial consultable desde un endpoint no demuestra ausencia de logs, archivos o caché. En las fuentes revisadas no se identificó una garantía pública general de ZDR para toda la API directa.
Cuánto dura la caché de contexto
DeepSeek documenta una caché de contexto en disco habilitada de forma predeterminada. Puede reutilizar partes iniciales coincidentes de solicitudes para evitar procesarlas de nuevo. Cuando la caché deja de utilizarse, normalmente se limpia en un intervalo de unas horas a unos días.
El punto de referencia es el momento en que deja de usarse, no necesariamente la hora de la primera solicitud. Además, la descripción es aproximada: no equivale a un plazo contractual máximo de borrado de todos los datos.
La compatibilidad de Responses también señala que prompt_cache_retention no está soportado y que la caché se gestiona automáticamente. No bases tu política de eliminación en enviar ese parámetro ni en comprobar que una solicitud dejó de obtener un acierto de caché.
Cómo establecer la caducidad de los archivos
La Files API permite subir imágenes y reutilizarlas por su file_id. Su ciclo de vida merece atención propia: omitir la caducidad deja el recurso sin un vencimiento automático configurado, comportamiento que la documentación denomina almacenamiento permanente. Eso no significa que sea imposible eliminarlo.
El endpoint de carga de archivos admite dos campos que deben enviarse juntos:
expires_after[anchor]: su valor debe sercreated_at.expires_after[seconds]: acepta entre3600y2592000segundos, equivalentes a una hora y 30 días.
Por ejemplo, estos campos del formulario de carga solicitan que el archivo venza una hora después de su creación:
expires_after[anchor]=created_at
expires_after[seconds]=3600La respuesta de carga incluye expires_at cuando configuraste la expiración. Guarda ese dato junto con el identificador del recurso para poder revisar su ciclo de vida.
La duración del archivo no establece cuánto se conservan los mensajes que lo referencian ni los posibles registros asociados. En tu aplicación, trata el vencimiento del recurso y la eliminación de otros datos como operaciones con alcances diferentes.
¿DeepSeek usa los datos de la API para entrenar modelos?
La respuesta exige distinguir una autorización de uso en los documentos de una prueba sobre el destino de cada solicitud. La sección 4.3 de los términos generales contempla un uso limitado de entradas y salidas para operar y mejorar los servicios y sus tecnologías, bajo las medidas de cifrado y desidentificación descritas. Esos términos incluyen las APIs en su definición de servicios.
Además, la explicación oficial de los métodos de entrenamiento señala que una pequeña parte de los pares de preguntas y respuestas utilizados durante la fase de optimización podría basarse en entradas de usuarios. Describe medidas de protección y una posibilidad de exclusión.
Estos textos no permiten prometer que todos los datos de la API están excluidos del entrenamiento, ni demuestran que cada solicitud se utilice para entrenar. Tampoco basta con observar que los términos específicos de la plataforma no repiten una cláusula que aparece en los documentos generales incorporados.
Qué debes confirmar sobre el opt-out
Los términos generales mencionan el control Improve the model for everyone. Sin embargo, en las fuentes revisadas no se verificó que modificar un ajuste de la interfaz de chat otorgue automáticamente una exclusión para todas las solicitudes de una cuenta API.
Si necesitas excluir tus datos del entrenamiento, pide que la confirmación identifique la cuenta u organización, los productos incluidos, la fecha desde la que aplica y el tratamiento de datos enviados anteriormente. Conserva la respuesta junto con la configuración de tu integración.
El opt-out y el borrado resuelven cuestiones distintas: dejar de autorizar una finalidad de uso no demuestra que se hayan eliminado las copias existentes. Del mismo modo, una promesa de no entrenar no define por sí sola cuánto tiempo se guardan registros.
¿Dónde se almacenan los datos y qué cambia según el proveedor?
La política de privacidad de DeepSeek declara que los datos personales que cubre se recopilan, procesan y almacenan directamente en la República Popular China. Esa declaración no debe trasladarse automáticamente a una empresa distinta que aloje un modelo DeepSeek.
Para identificar la política aplicable, revisa el dominio al que se conecta tu aplicación, la entidad que te factura y quién ejecuta la inferencia. El nombre del modelo no identifica por sí solo toda la ruta de los datos.
| Forma de uso | Qué debes revisar |
|---|---|
| API directa de DeepSeek | Los términos de DeepSeek, la documentación del endpoint y cualquier acuerdo específico aplicable. |
| Intermediario que reenvía solicitudes | La política del intermediario y la del proveedor final; también los cambios de ruta y los proveedores de respaldo. |
| Proveedor que aloja el modelo | Las condiciones de ese servicio y del despliegue contratado. Comprueba si ejecuta el modelo o reenvía la solicitud. |
| Despliegue bajo tu control | El servidor de inferencia, el alojamiento, los logs, las copias de respaldo y las integraciones externas. |
Dos ejemplos muestran por qué conviene comprobar la configuración concreta. Together AI documenta que ZDR no está activado por defecto y que su activación afecta a las solicitudes posteriores, sin borrar automáticamente lo almacenado antes. También separa esa opción del consentimiento para entrenamiento.
Por su parte, OpenRouter distingue ZDR de Safety Retention, que permite conservar contenido con fines de prevención de abuso. Su opción zdr: true sigue la elección de la cuenta y las reglas de control sobre si se permiten esos endpoints. Revisa también las excepciones publicadas y las políticas de herramientas adicionales.
Estos ejemplos explican cómo varían los controles entre servicios; no prueban las condiciones de la API directa de DeepSeek. Si ejecutas el modelo íntegramente en tu infraestructura y no envías contenido a servicios externos, el análisis se concentra en los sistemas que tú y tus proveedores administran. Aun así, el despliegue propio no elimina automáticamente logs ni respaldos.
Cómo eliminar archivos y solicitar el borrado de otros datos
Qué puedes borrar desde tu integración
Para un archivo subido, DeepSeek documenta DELETE /files/{file_id}. El identificador debe corresponder al recurso que deseas eliminar. Revisa el resultado de la operación y actualiza las referencias que guarda tu aplicación para evitar que vuelva a intentar utilizarlo.
Ese endpoint permite eliminar el recurso del archivo. Su respuesta no constituye una certificación de borrado de todos los registros o copias relacionadas con solicitudes que lo utilizaron.
También puedes borrar los datos que controla tu aplicación: conversaciones de su base de datos, archivos temporales y registros de depuración. Hazlo según una política que contemple las copias de respaldo; retirar un elemento de la interfaz no demuestra que haya desaparecido de todos esos sistemas.
No uses la revocación de una API key como comprobante de eliminación: cambia el acceso mediante esa credencial, mientras que el borrado necesita su propio procedimiento. Tampoco interpretes la eliminación de una conversación en una interfaz de chat como una orden de borrado de todas las solicitudes API.
Cómo presentar una solicitud a DeepSeek
La política de privacidad ofrece el correo [email protected] para ejercer derechos sobre datos personales, sujetos a la legislación y las excepciones aplicables. Puede requerirse verificación de identidad. Para cuestiones del servicio API, los términos de la plataforma indican [email protected].
Una solicitud útil delimita qué necesitas confirmar o eliminar:
- Servicio y cuenta: especifica que utilizaste la API directa o identifica al intermediario correspondiente.
- Periodo y referencias: aporta el intervalo de uso y los identificadores necesarios para localizar las solicitudes o archivos.
- Categorías: distingue entradas, respuestas, recursos subidos, registros operativos y copias de respaldo.
- Resultado esperado: pide confirmación de lo eliminado, de lo que deba conservarse y de los motivos y plazos aplicables.
No incluyas claves API ni vuelvas a enviar contenido confidencial para demostrar que existe. Solicita un canal adecuado si necesitan información adicional para identificar los datos.
Modelo de solicitud de información y eliminación
Solicito información sobre los plazos de conservación aplicables a mi uso de la API de DeepSeek y la eliminación de los datos que corresponda suprimir. Agradeceré que distingan entradas, respuestas, archivos subidos, registros operativos y copias de respaldo.
Indiquen qué información necesitan para identificar mi cuenta y las solicitudes afectadas mediante un canal adecuado. Confirmen el alcance del borrado, los datos que deban conservarse, su finalidad y el plazo aplicable. También solicito aclarar si mis entradas o respuestas se usan para entrenamiento o mejora de modelos y cómo excluirlas cuando corresponda.
Guarda la solicitud y la respuesta. Si se informa una excepción, registra qué categoría afecta y cuándo debe revisarse. Los términos generales contemplan conservación exigida legalmente después de eliminar una cuenta; por ello, no prometas a tus usuarios un borrado total e inmediato basándote únicamente en cerrar el acceso.
Cómo reducir los datos que envías y conservas
La parte que puedes controlar empieza antes de llamar a la API. Define qué información necesita cada tarea y evita añadir datos por comodidad. Estas medidas reducen lo expuesto y las copias bajo tu administración; no cambian por sí solas la política del proveedor.
- Reduce el contexto. Envía el fragmento necesario para resolver la tarea, en lugar de historiales completos o documentos que contienen información ajena a la consulta.
- Separa identidad y contenido. Sustituye identificadores directos por referencias internas cuando sea posible. Mantén la correspondencia fuera del prompt; no presupongas que un texto queda anónimo solo por quitar un nombre.
- Revisa los logs de toda la ruta. Comprueba el backend, los proxies, las herramientas de monitoreo, el rastreo de errores y cualquier registro de prompts. Usa métricas operativas sin copiar cuerpos completos cuando no sean necesarios.
- Define vencimientos y responsables. Asigna una finalidad y una regla de eliminación a conversaciones, archivos temporales, registros y respaldos. Evita que cada componente conserve información sin una decisión explícita.
- Controla reintentos y rutas alternativas. Verifica si un error puede reenviar la misma entrada o activar otro proveedor con condiciones diferentes.
- Comprueba tu propio borrado. Usa datos sintéticos para revisar que la eliminación prevista alcance bases de datos, archivos y registros controlados por tu equipo.
Ejemplo: un asistente de soporte al cliente
Supongamos que una aplicación utiliza DeepSeek para clasificar un ticket. Si la tarea solo requiere identificar el motivo de contacto, puede enviar una descripción depurada y una referencia interna, sin adjuntar toda la conversación, el correo del cliente y sus documentos.
Al cerrar el ticket, la aplicación puede eliminar su copia temporal y conservar únicamente la clasificación que necesita. Si hubo un archivo subido, debe gestionar también su vencimiento o borrado. Cada paso se registra por separado: el cierre del ticket no debe presentarse como prueba de que el proveedor eliminó todos los datos relacionados.
Este diseño facilita responder una solicitud de eliminación: sabes qué enviabas, dónde había copias y qué acciones corresponden a tu equipo. Las preguntas pendientes sobre almacenamiento del proveedor siguen requiriendo su respuesta.
Qué confirmar antes de usar datos confidenciales
Además, la política de privacidad señala que sus servicios no están diseñados para procesar datos personales sensibles y pide no proporcionarlos. Distingue esa categoría de la información comercial confidencial: acordar un plazo de retención no resuelve, por sí solo, qué datos admite el servicio.
Convierte los requisitos de tu proyecto en preguntas concretas. Una respuesta comercial general sobre privacidad resulta poco útil si no identifica categorías, excepciones y servicio contratado.
| Pregunta para el proveedor | Qué debería aclarar la respuesta |
|---|---|
| ¿Qué contenido de mis solicitudes se conserva? | Si incluye prompts, respuestas, archivos o contenido dentro de logs. |
| ¿Cuál es el plazo máximo por categoría? | Desde qué evento se cuenta y cómo se tratan las copias de respaldo. |
| ¿Para qué se utiliza y cómo se excluye del entrenamiento? | El alcance de la exclusión y su fecha de aplicación. |
| ¿Qué cubre una eventual opción de ZDR? | Qué permanece, qué excepciones existen y qué endpoints o herramientas quedan fuera. |
| ¿Quién procesa los datos y en qué ubicaciones? | Las entidades, regiones y rutas aplicables a tu despliegue. |
| ¿Cómo se solicita y confirma la eliminación? | El procedimiento, sus límites y la evidencia que recibirás. |
Si tu proyecto exige un plazo máximo demostrable, exclusión de entrenamiento o una región específica, trata esos puntos como condiciones que deben quedar documentadas para tu servicio. Mientras no estén resueltos, puedes evaluar la integración con datos sintéticos y mantener fuera de ese flujo la información que requiere esas garantías.
La decisión sobre DeepSeek API debe basarse en la combinación de documentos aplicables, configuración y ruta real de los datos. Un ajuste de la interfaz, el nombre del modelo o una respuesta store: false no sustituyen esa comprobación.
Última verificación de las fuentes: 10 de noviembre de 2026.