Zero Data Retention dejó a OpenAI ciego ante el abuso en varios pasos
OpenAI creó Zero Data Retention para que los clientes elegibles de su API pudieran impedir que la empresa conservará sus prompts o respuestas del modelo una vez procesada una solicitud, y esa promesa sigue vigente: sin revisión por parte del personal de OpenAI y sin uso para entrenamiento salvo consentimiento explícito. El coste de esa promesa aparece en el lado de la seguridad. En su anuncio del 19 de agosto de 2026, OpenAI reconoce que, a medida que los modelos asumen tareas agenticas más largas y complejas, los comportamientos más peligrosos - un actor malicioso que prueba las salvaguardas, se coordina entre varias cuentas, disfraza un ataque de investigación legítima, o un agente que sigue actuando tras recibir la orden de detenerse - solo se hacen visibles al observar varias interacciones juntas, no dentro de una sola.
Los controles de seguridad compatibles con ZDR existentes evaluaban cada interacción de forma aislada, así que no podían detectar ese patrón por diseño. OpenAI va más alla y afirma que "algunos despliegues recientes de modelos de frontera han exigido a los clientes permitir que su proveedor de IA conserve contenido sensible para la supervisión de seguridad" - una crítica directa, aunque sin nombrar a nadie, a rivales que resolvieron esto guardando más datos, no menos. Para un banco, un grupo hospitalario o un despacho de abogados sujeto a obligaciones estrictas de tratamiento de datos, esa concesión nunca fue aceptable, y esa es exactamente la brecha que Private Safety Processing dice querer cerrar.
La solución traslada la seguridad detrás de las claves del cliente
Private Safety Processing, todavía en fase de vista previa el 19 de agosto de 2026, amplia los controles de seguridad de interacción individual de OpenAI para detectar patrones a través de interacciones relacionadas, sin dar al personal de OpenAI acceso al contenido subyacente del cliente. El mecanismo funciona de dos formas según donde resida el contenido. Si vive en la infraestructura propia del cliente bajo un despliegue ZDR real, OpenAI nunca llega a tocarlo. Si reside en almacenamiento proporcionado por OpenAI, el contenido se cifra con claves que controla el cliente, y el personal de OpenAI simplemente no posee esas claves.
Cuando el sistema detecta un riesgo, OpenAI no recibe el prompt marcado, la respuesta ni el razonamiento detrás de la alerta. Recibe únicamente, en sus propias palabras, "una señal estrictamente definida que indica el tipo de actividad implicada" - suficiente para decidir si hace falta actuar, pero no suficiente para leer lo que realmente ocurrió. Los clientes pueden investigar cualquier alerta o medida con sus propios sistemas, y pueden compartir voluntariamente más información con OpenAI solo si quieren apelar una decisión o respaldar una investigación - la divulgación sigue siendo voluntaria por parte del cliente, no automática por parte de OpenAI.
Glean, Databricks, Abridge y Microsoft ya prueban el sistema
Cuatro organizaciones identificadas ya prueban Private Safety Processing antes de un lanzamiento más amplio: Glean, Databricks, Abridge y Microsoft. Sunil Agrawal, director de seguridad de la información en Glean, ofrecio a OpenAI el respaldo público más contundente hasta ahora: "Enterprise AI adoption depends solely on customer control of data, with no direct or derivative use beyond the chosen service. OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI. As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust." Se trata de un cliente empresarial defendiendo públicamente un sistema que todavía no se ha lanzado.
Una excepción sobrevive en cualquier versión de este diseño: OpenAI esta legalmente obligada a denunciar material de presunto abuso sexual infantil, así que las imágenes marcadas por posible CSAM siguen conservándose para revisión manual y denuncia incluso en despliegues ZDR, exactamente igual que hoy. Private Safety Processing no toca esa excepción. OpenAI dice que el despliegue general, junto con un informe técnico que explique el mecanismo con más detalle, está previsto para septiembre de 2026 - lo que finalmente se lance el mes que viene, moldeado entretanto por comentarios de clientes, podría diferir de lo que se prueba ahora.
El informe técnico de septiembre es la prueba real, no este anuncio
Nadie fuera de OpenAI ha verificado de forma independiente las afirmaciones de cifrado y control de claves detrás de Private Safety Processing, y esa es la brecha que un equipo de cumplimiento en España o cualquier otro país de la UE debería mantener abierta hasta septiembre. La "señal estrictamente definida" que describe OpenAI es, por diseño, opaca para el cliente que la recibe - útil para decidir si actuar ante una alerta, pero no lo bastante detallada para satisfacer una revisión del artículo 28 del RGPD o a un auditor que pregunte exactamente que se infirió del contenido cifrado y como. Hasta que llegue el prometido informe técnico, la respuesta honesta a "podemos verificarlo" es no, todavía no.
El anuncio llega tres días después de que el director financiero de OpenAI hablara de una posible salida a bolsa en 2027 y pocos días después de que ChatGPT Ads se expandiera a Europa, y en conjunto el patrón muestra a una OpenAI cortejando visiblemente la confianza de sectores regulados antes de un crecimiento comercial a mayor escala. Eso no convierte a Private Safety Processing en un simple ejercicio de marketing - la lista de clientes y el mecanismo son reales -, pero si significa que la carga de la prueba recae en el informe técnico, no en este anuncio. Cualquier afirmación de "retención cero de datos" de un proveedor debería leerse ahora con una pregunta de seguimiento: como, exactamente, gestiona la supervisión de seguridad entre sesiones.
Leer a continuación: Los ingresos empresariales de OpenAI ya superan al consumo | IBM apuesta su consultoria a un solo proveedor de IA
