OpenAI presentó el 19 de agosto de 2026 su oferta Zero Data Retention para los despliegues de modelos avanzados con clientes API elegibles, así como un dispositivo en versión preliminar llamado Private Safety Processing. Estos conceptos son importantes para los proyectos sensibles, pero no deben reducirse a la fórmula «los datos no se almacenan».
1. ¿Qué es la Retención Cero de Datos?
En el marco anunciado, los clientes de API elegibles pueden usar ciertos modelos con solicitudes y respuestas que no se conservan después del procesamiento. OpenAI también indica que estos contenidos no son accesibles para su personal y recuerda que los datos de las empresas no se utilizan para entrenar los modelos sin la elección explícita del cliente.
Esta opción responde a una restricción frecuente: evitar que un contenido empresarial, un documento confidencial o un dato personal permanezca en los registros del proveedor más allá del tiempo necesario para la llamada.
El término « elegible » es esencial. Hay que verificar el modelo, el endpoint, el contrato, la región, las funciones utilizadas y las posibles excepciones. La documentación oficial muestra que la compatibilidad depende de cada endpoint y de su configuración: conversaciones, asistentes, archivos, almacenes vectoriales, procesos por lotes, vídeo y algunos modos asincrónicos requieren especialmente una verificación separada. Una política declarada a nivel de cuenta no se aplica necesariamente a cada herramienta, archivo, caché o servicio auxiliar.
Al 2 de septiembre de 2026, la documentación oficial también distingue los regímenes « Eyes Off » y « Safety Retention ». OpenAI indica poder hacer que ciertos modelos no sean elegibles para la Retención Cero de Datos para un cliente dado, con notificación por escrito. Según el régimen aplicado, los contenidos pueden entonces ser conservados y, para Safety Retention, examinados para investigar una actividad que presente un riesgo severo. Esta reserva debe aparecer en el análisis contractual.
La misma documentación precisa que el modo background de la API Responses puede escribir temporalmente datos para permitir la consulta del resultado, que la caché de prompts puede conservar tensores cifrados en la GPU durante un tiempo limitado y que los servicios de terceros, incluyendo los servidores MCP remotos, aplican su propia política de conservación.
2. Lo que esto no significa
Cero retención no significa cero tratamiento. Los datos deben ser transmitidos y cargados en la memoria para producir una respuesta. La seguridad del transporte, el aislamiento de la infraestructura, los accesos técnicos y la gestión de incidentes siguen siendo determinantes.
Esto tampoco significa que la aplicación cliente no conserve nada. Los prompts pueden aparecer en los registros de la aplicación, en las trazas APM, en las colas de mensajes, en las copias de seguridad, en el navegador o en una herramienta de observabilidad. El eslabón más parlante se encuentra a menudo del lado del integrador.
Finalmente, la no utilización para el entrenamiento, la duración de conservación y la localización son tres temas distintos. Deben documentarse por separado en el análisis de riesgos y en el registro de tratamientos.
3. El papel de Private Safety Processing
OpenAI presenta Private Safety Processing como un medio para detectar patrones de riesgo que aparecen a través de varias interacciones sin dar al personal acceso a los contenidos subyacentes. Según la arquitectura anunciada, el contenido puede permanecer bajo control del cliente. OpenAI también está desarrollando una opción de procesamiento en una infraestructura cifrada con claves controladas por el cliente; no debe considerarse como generalmente disponible en este momento.
El proveedor recibiría entonces una señal de riesgo estrechamente definida, y no el detalle de las conversaciones. El mecanismo busca conciliar la confidencialidad y la detección de abusos coordinados, especialmente cuando el análisis de una llamada aislada sería insuficiente.
Se trata aún de una preversión probada con los primeros clientes. OpenAI anunciaba un inicio de despliegue y un libro blanco técnico en septiembre. Al 2 de septiembre de 2026, no se había encontrado ningún anuncio distinto de disponibilidad general: los detalles de implementación, las garantías verificables y las condiciones de acceso deben ser examinados caso por caso.
4. Una arquitectura con varios niveles de control
Un proyecto robusto debe distinguir al menos cinco capas. La primera es la minimización: nunca enviar al modelo un dato innecesario. La segunda es la seudonimización o el enmascaramiento antes de la llamada. La tercera cubre el transporte y el procesamiento en el proveedor. La cuarta concierne a la conservación. La quinta trata sobre los registros y controles de la aplicación cliente.
Private Safety Processing añade una sexta capa: la eventual producción de una señal de riesgo distinta del contenido. Esta capa debe ser documentada como un flujo completo, con su finalidad, sus destinatarios, su duración y sus posibles consecuencias.
El cifrado con clave controlada por el cliente puede reforzar el control, pero no es suficiente por sí solo. Es necesario saber en qué momento se descifra el dato, qué componente puede utilizarlo, cómo se renuevan las claves y qué sucede en caso de revocación.
5. Las preguntas que hacer antes de contratar
Comience por establecer una matriz de las funciones utilizadas: texto, archivos, imágenes, herramientas, búsqueda, caché y procesos asíncronos. Para cada una, pregunte la duración de conservación, las excepciones, la región, los subcontratistas y el método de eliminación.
Luego verifique las condiciones de elegibilidad para la Retención Cero de Datos, la prueba disponible, el tratamiento de incidentes y los mecanismos de auditoría. Pregunte cómo se gestionan los abus, las obligaciones legales y las categorías particulares de contenidos. El anuncio menciona en particular una excepción relacionada con imágenes de abuso sexual infantil; los equipos deben conocer con precisión las reglas aplicables a su servicio.
Para Private Safety Processing, solicite la definición exacta de la señal, su persistencia, las decisiones que puede desencadenar y los medios de impugnación o investigación disponibles.
6. Los controles a mantener del lado del cliente
Una opción de privacidad del proveedor no reemplaza el control de acceso. Cada llamada debe estar vinculada a un usuario, un caso de uso y una política de datos. Los documentos recuperados deben respetar los derechos de la persona que consulta el sistema.
Implemente un filtro de datos sensibles antes del envío, un esquema de salida estricto, plazos, cuotas y una capacidad para desconectar rápidamente al proveedor. Los registros deben privilegiar identificadores, hashes y métricas en lugar de los contenidos completos.
Las pruebas de seguridad deben incluir las inyecciones de prompt, la exfiltración indirecta, las herramientas mal configuradas y los errores de compartimentación. Estos temas se desarrollan en nuestra guía sobre la gobernanza operativa de la IA.
7. Los casos de uso adaptados
La retención cero de datos es particularmente relevante para el resumen de documentos confidenciales, la asistencia interna, el análisis de contratos, el soporte técnico o la extracción de datos cuando el proveedor cumple con los demás requisitos del proyecto.
No hace automáticamente aceptable el envío de datos médicos, financieros o judiciales. Para estas categorías, sigue siendo necesario un análisis profundo, una base legal, medidas reforzadas y, a veces, una infraestructura dedicada.
Los casos de uso con alta autonomía también requieren más que la confidencialidad. Un agente que pueda escribir en el SI debe tener permisos mínimos, validaciones y una trazabilidad de cada acción.
8. Cómo conducir un piloto
Seleccione un corpus de prueba representativo pero desensibilizado. Mapee todos los flujos, incluidos los registros, copias de seguridad y herramientas de soporte. Active la opción contractual adecuada y luego verifique el comportamiento real de cada endpoint.
Simule los errores, las interrupciones y la revocación de la clave. Mida los datos visibles en la observabilidad y controle que nadie pueda recuperar el contenido a partir de un identificador o de una traza.
Finalmente, haga validar la documentación por seguridad, el DPO y el negocio. El piloto es exitoso cuando la organización puede explicar por dónde pasa cada dato, quién puede acceder a él y cómo detener el servicio.
El anuncio del 19 de agosto constituye un avance interesante para las empresas exigentes. Su valor dependerá de la documentación técnica anunciada, de las condiciones contractuales y de la capacidad de los integradores para aplicar la misma disciplina en su propia arquitectura.
Partitech acompaña el diseño de servicios de IA seguros: mapeo de flujos, elección de arquitectura, minimización de datos, control de acceso, observabilidad y documentación de conformidad.