Quasa
Utilice la aplicación QUASA
¡Únase hoy al pionero del trabajo autónomo criptográfico Web3!
Abierto
Tecnología

OpenAI o Anthropic con ZDR: «cero datos» no cubre todos los productos

|Autor: Equipo editorial de QUASA|6 lectura mínima| 4
OpenAI o Anthropic con ZDR: «cero datos» no cubre todos los productos

Ni OpenAI ni Anthropic convierten Zero Data Retention (ZDR) en una garantía para todo su catálogo. En ambos casos, la cobertura depende de la organización habilitada y del servicio utilizado; archivos, procesos asíncronos, herramientas alojadas o sesiones con estado pueden conservar datos aunque la llamada principal sea elegible.

La diferencia relevante no es quién promete “cero datos”, sino qué combinación de organización, proyecto o workspace, endpoint, modelo y función queda dentro del acuerdo. Tampoco deben confundirse ZDR, la exclusión del entrenamiento y la residencia regional: son controles distintos y pueden coexistir con metadatos operativos, señales de seguridad o retenciones legales.

La cobertura empieza en la organización, no en la cuenta completa

OpenAI concede ZDR y Modified Abuse Monitoring a clientes aprobados. Después de la aprobación, el control puede configurarse para la organización y por proyecto: un proyecto puede heredar la política general, elegir otro control autorizado o quedar sin esos controles.

Anthropic aplica una frontera semejante, pero exige habilitar cada organización por separado. La explicación contractual de Anthropic limita ZDR a API elegibles, productos que usen la clave de una organización Commercial y Claude Code en planes Enterprise habilitados; los productos de consumo no quedan incluidos.

Por tanto, una negociación comercial no basta para clasificar todo el despliegue. Una filial con otra organización, una clave vinculada al entorno equivocado o un proyecto que no hereda la configuración pueden quedar sujetos a una política diferente, aunque pertenezcan al mismo cliente empresarial.

OpenAI: store=false no elimina todos los estados

Validación de OpenAI que separa Responses con almacenamiento desactivado de archivos, conversaciones y recursos persistentes fuera de ZDR.

En OpenAI, ZDR excluye el contenido del cliente de los registros ordinarios de supervisión de abuso y obliga a tratar store como false en Responses y Chat Completions, incluso si la solicitud intenta activarlo. Sin embargo, la matriz de controles de OpenAI clasifica como no elegibles recursos persistentes como Conversations, ChatKit Threads, Assistants, Threads, Vector Stores, Files, fine-tuning, evals y batches.

Esto separa dos clases de almacenamiento. El prompt y la respuesta de una inferencia elegible pueden quedar fuera de la retención, mientras un archivo, un hilo o un almacén vectorial creado por la aplicación permanece hasta que se elimina. Moderations, embeddings, Realtime y varios endpoints de audio figuran como elegibles; Videos, en cambio, está bloqueado para solicitudes de proyectos con ZDR o Modified Abuse Monitoring.

Incluso los endpoints elegibles tienen límites funcionales. Las salidas de audio de Responses y Chat Completions mantienen estado durante una hora para permitir conversaciones de varios turnos. Los contenedores alojados pueden escribir estado temporal mientras están activos, y la información enviada a servidores MCP u otros servicios externos queda sometida a las políticas de esos terceros.

Anthropic: Messages puede ser elegible y su herramienta no

Flujo de Claude API donde Messages es compatible con ZDR, pero ejecución de código, archivos y batches conservan estado propio.

Anthropic define ZDR como la ausencia de almacenamiento en reposo de prompts y respuestas después de devolver la respuesta de la API. Su tabla de retención de Claude Platform incluye Messages y Token Counting, pero advierte que una capacidad invocada mediante Messages no hereda automáticamente esa elegibilidad.

Code execution queda fuera porque los datos del contenedor pueden conservarse hasta 30 días. Batch processing necesita almacenamiento asíncrono y tiene una retención declarada de 29 días; Files conserva los objetos hasta su eliminación explícita. Claude Managed Agents también queda fuera porque sus sesiones son recursos con estado y las transcripciones persisten hasta que el cliente las elimina.

Bajo ZDR, Anthropic no bloquea necesariamente las funciones clasificadas como no elegibles: utilizarlas significa salir del acuerdo para esos datos concretos y aceptar la política de la función. En cambio, computer use y memory pueden ser elegibles cuando se ejecutan o almacenan en el entorno controlado por el cliente. Cache diagnostics ocupa una categoría intermedia: no guarda prompts ni respuestas, pero conserva brevemente una huella con hashes criptográficos y estimaciones de tokens.

La matriz útil separa contenido, archivos y cumplimiento

Una evaluación empresarial necesita más detalle que una columna con “sí” o “no”. Para cada flujo conviene distinguir estas capas:

  • Contenido de inferencia: prompts, respuestas, imágenes y documentos enviados directamente al endpoint.
  • Estado de aplicación: conversaciones, hilos, agentes, trabajos asíncronos y almacenes vectoriales necesarios para mantener continuidad.
  • Archivos: objetos subidos mediante una API específica, con reglas independientes de eliminación o caducidad.
  • Funciones auxiliares: ejecución de código, búsqueda, MCP, caché, contenedores y herramientas de terceros.
  • Datos operativos: cuenta, facturación, métricas de uso, actividad administrativa y resultados de clasificadores de seguridad.
  • Sesiones: transcripciones locales o remotas cuyo responsable de almacenamiento depende del producto y del lugar de ejecución.

La matriz debe añadir cuatro columnas de control: política predeterminada, acuerdo negociado, configuración observada y excepción aplicable. Así se evita presentar como equivalente una llamada sin retención, un archivo que espera eliminación y una señal de seguridad que no contiene el prompt original.

Las excepciones alcanzan modelos, seguridad y obligaciones legales

Comparación de workspaces de Anthropic con ZDR general y una excepción de retención de 30 días para modelos específicos.

Anthropic documenta modelos cubiertos que requieren 30 días de retención y, por ello, no están disponibles bajo ZDR. Una organización con retención cero puede habilitar esa retención en un workspace específico sin cambiar los demás, de modo que el modelo y el workspace también deben formar parte del inventario.

OpenAI contempla Safety Retention para modelos y clientes concretos cuando considere necesario investigar o prevenir actividades de riesgo grave, con aviso previo por escrito. Además, las imágenes detectadas como posible material de abuso sexual infantil pueden conservarse para revisión manual y cumplimiento legal incluso en despliegues ZDR.

El anuncio de Private Safety Processing, publicado el 19 de agosto de 2026, presenta un sistema diseñado para detectar patrones entre interacciones sin dar al personal de OpenAI acceso al contenido subyacente. En despliegues ZDR, el contenido permanece en infraestructura controlada por el cliente y solo se devuelven señales de seguridad limitadas; todavía es una prueba con clientes iniciales, no una capacidad general disponible para todos.

La elección depende de la arquitectura concreta

No hay un ganador universal. OpenAI fuerza store=false en sus rutas principales bajo ZDR, pero deja fuera numerosos recursos con estado. Anthropic cubre Messages y varias herramientas sin persistencia, aunque excluye archivos, batches, ejecución alojada, agentes y determinados modelos.

La afirmación “tenemos retención cero” solo resulta precisa para un flujo identificado. Debe indicar la organización, el proyecto o workspace, el modelo, el endpoint, las funciones activadas, los terceros conectados y quién controla la eliminación del estado. El contrato fija el marco; la configuración y la arquitectura determinan qué datos quedan realmente dentro.

Lee también:

Compartir:

Suscríbete a nuestro boletín

Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.

0