La ampliación de ZDR para clientes API elegibles muestra que retención, seguridad y observabilidad deben diseñarse como capas separadas.
OpenAI anunció en agosto que determinados clientes de API podían utilizar modelos frontier con Zero Data Retention: los prompts y las respuestas no se conservan después del procesamiento, el contenido no queda disponible para revisión por personal de OpenAI salvo las excepciones indicadas, y los datos empresariales no se usan para entrenar modelos a menos que el cliente lo autorice.
La compañía presentó además Private Safety Processing, concebido para detectar patrones entre interacciones relacionadas manteniendo compatibilidad con ZDR y con almacenamiento o claves controlados por el cliente.
La cuestión de arquitectura supera a un proveedor. Las empresas necesitan separar inferencia, retención, procesamiento de seguridad y registro de negocio.
“Sin retención” no significa “sin datos”
Una petición sigue procesando información. La aplicación puede recuperar documentos, crear archivos temporales, invocar herramientas, escribir trazas o guardar el resultado en un sistema corporativo. El compromiso ZDR de la capa de modelo solo cubre una parte.
El mapa completo debe incluir:
- entrada del usuario antes del modelo;
- contexto recuperado y cachés;
- prompts construidos por la orquestación;
- respuestas;
- argumentos y resultados de herramientas;
- trazas y observabilidad;
- colas de revisión humana;
- registros finales en CRM, ERP o sistema de casos;
- backups y artefactos de incidentes.
La mejor condición contractual del proveedor no compensa una aplicación que guarda todos los prompts en texto plano.
Separar cuatro finalidades
1. Inferencia
Datos necesarios de forma momentánea para producir el resultado. Deben minimizarse, acotarse y procesarse en una región aprobada.
2. Registro empresarial
Evidencia que la organización sí debe conservar: una decisión aprobada, referencias, identificador de transacción o comunicación al cliente.
3. Telemetría operativa
Información para operar el servicio: latencia, versión, estado de herramientas, coste y códigos de error. A menudo es útil sin guardar contenido bruto.
4. Seguridad e investigación
Señales para detectar abuso, incidentes o patrones dañinos. Esta capa genera tensión con la retención mínima y necesita diseño explícito.
Separar finalidades permite políticas precisas. También excluye contenido sensible de logs generales conservando evidencia suficiente.
ZDR cambia el diseño de observabilidad
Guardar prompts completos es la forma más fácil de depurar y, con frecuencia, la menos compatible con privacidad.
Alternativas:
- trazas estructuradas que registren tipo de evento y no contenido completo;
- redacción antes de enviar telemetría;
- hashes o referencias a registros en sistemas del cliente;
- captura cifrada y de corta duración activada para un incidente;
- almacenamiento y claves controlados por el cliente;
- casos sintéticos para evaluación rutinaria;
- retención por campo.
Los equipos deben decidir antes cómo investigarán un fallo sin depender de copias permanentes.
La seguridad no debe convertirse en una puerta trasera
Private Safety Processing representa un enfoque para analizar patrones limitando el acceso del personal. Con cualquier proveedor, conviene preguntar:
- ¿Se almacena contenido y dónde?
- ¿Quién controla las claves?
- ¿Qué sistemas automatizados pueden inspeccionarlo?
- ¿Cuánto tiempo se conservan señales derivadas?
- ¿Qué excepciones legales o de seguridad existen?
- ¿Puede el cliente auditar o configurar el proceso?
- ¿Activar una función cambia el compromiso de retención?
“Compatible con ZDR” debe traducirse a un diagrama real de datos y a condiciones contractuales.
No todos los procesos necesitan retención cero
Algunas decisiones reguladas o relevantes necesitan registros. Un proceso de crédito, empleo o reclamación puede exigir evidencia de datos usados, versión de política y revisión humana.
El objetivo no es borrar la rendición de cuentas. Es conservar la evidencia mínima útil en el sistema autorizado, evitando copias sin control en proveedores y logs.
Un buen flujo de trabajo puede no guardar la conversación y sí conservar un registro estructurado de decisión.
La visión de Lexdatum
Zero Data Retention no es un interruptor al final de compras. Es una propiedad de la arquitectura completa.
El compromiso del proveedor es una capa. La aplicación también debe controlar retrieval, estado temporal, herramientas, trazas, registros y acceso por incidentes.
Privacidad y observabilidad no son opuestas. Se vuelven compatibles cuando dejamos de tratar el contenido bruto como única forma de evidencia.
Fuentes
Nota de investigación: este análisis se basa en información pública disponible a 31 de agosto de 2026. Las capacidades, los precios y las interpretaciones regulatorias pueden cambiar. Las métricas comunicadas por proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad o inversión.