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

OpenAI promete no guardar datos, incluso cuando busque abusos entre sesiones

|Autor: Equipo editorial de QUASA|5 lectura mínima| 10
OpenAI promete no guardar datos, incluso cuando busque abusos entre sesiones

OpenAI presentó el 19 de agosto de 2026 Private Safety Processing, un sistema aún en pruebas que busca detectar patrones de abuso entre interacciones sin conservar las solicitudes y respuestas de los clientes elegibles. La información publicada por Axios confirma que el piloto se dirige a clientes empresariales y de API elegibles, no a usuarios de los planes de consumo de ChatGPT.

La propuesta intenta resolver una tensión concreta: reconocer riesgos que solo aparecen al relacionar varias interacciones sin convertir a OpenAI en custodio de las conversaciones. Los sistemas automatizados procesarían el contenido, pero la empresa recibiría únicamente una señal limitada sobre la actividad detectada; su personal no tendría acceso a las solicitudes ni a las respuestas subyacentes.

La retención cero tiene un alcance preciso

Zero Data Retention (ZDR) significa que OpenAI no conserva las solicitudes ni las respuestas del modelo después de procesar una petición de un cliente de API elegible. El contenido tampoco queda disponible para que el personal de OpenAI lo revise, y los datos empresariales no se utilizan para entrenar modelos salvo autorización expresa del cliente.

La promesa no cubre automáticamente cualquier cuenta, función o categoría de datos. Se aplica a clientes y cargas de trabajo elegibles; los ajustes de Free, Plus, Go y Pro no cambian con este anuncio. Tampoco impide que la organización usuaria guarde sus propios registros, algo necesario si después debe investigar una alerta o impugnar una medida.

Existe además una excepción explícita: las imágenes marcadas como posible material de abuso sexual infantil seguirán reteniéndose para revisión manual y denuncia, incluso en implementaciones ZDR. Por eso, “retención cero” describe el tratamiento ordinario del contenido elegible, no una prohibición absoluta de cualquier conservación bajo cualquier circunstancia.

Los dos recorridos separan contenido, claves y señales

Dos recorridos de Private Safety Processing mantienen el contenido bajo control del cliente y limitan el acceso de OpenAI a una señal de seguridad.

Private Safety Processing contempla dos arquitecturas. En las implementaciones ZDR, el contenido permanece en infraestructura controlada por el cliente. La segunda opción, todavía en desarrollo, permitiría almacenarlo en infraestructura de OpenAI, pero cifrado con claves controladas por el cliente y de las que el personal de la empresa no tendría copia.

  • Contenido: queda en sistemas controlados por el cliente en el recorrido ZDR; en la opción alojada permanece cifrado en infraestructura de OpenAI.
  • Claves: siguen bajo control del cliente en la modalidad alojada en desarrollo.
  • Procesamiento: sistemas automatizados examinan interacciones relacionadas para buscar patrones potencialmente peligrosos.
  • Señal: OpenAI recibe una indicación limitada sobre el tipo de actividad, no los mensajes originales.
  • Acceso humano: el personal de OpenAI no puede consultar el contenido subyacente, salvo la excepción legal indicada para posibles imágenes de abuso sexual infantil.

La descripción oficial de las dos arquitecturas presenta ambas como formas de detectar posibles abusos sin exponer las solicitudes y respuestas al personal de OpenAI. Solo el primer recorrido se identifica expresamente como una implementación ZDR; la modalidad alojada no debe confundirse con una disponibilidad ya general.

Una alerta no sustituye el expediente del cliente

El cliente investiga una alerta con sus propios registros mientras OpenAI recibe solo una categoría limitada de riesgo.

Las protecciones actuales compatibles con ZDR evalúan cada interacción por separado. Private Safety Processing pretende ampliar ese análisis a interacciones relacionadas para reconocer conductas que pueden pasar inadvertidas en una sola solicitud, como intentos repetidos de sortear salvaguardas, coordinación entre cuentas o una tarea autónoma que continúa después de recibir la orden de detenerse.

Si el sistema detecta riesgo, OpenAI recibiría una categoría estrechamente definida que podría servir para decidir si corresponde aplicar medidas. La alerta no incluiría las solicitudes ni las respuestas originales, incluso cuando la actividad haya sido marcada.

La investigación detallada recaería principalmente en la organización usuaria. El cliente podría revisar la información disponible en sus sistemas y compartir voluntariamente datos pertinentes con OpenAI para apelar, aclarar una actividad legítima o colaborar en la investigación de un abuso verificado. La arquitectura reduce el contenido visible para el proveedor, pero no elimina la necesidad de conservar evidencia donde las obligaciones internas o legales la exijan.

El contraste con Anthropic está en la custodia de la evidencia

El anuncio expone dos respuestas distintas al mismo problema. Anthropic exige 30 días de retención para determinados modelos empresariales porque considera necesario conservar datos al buscar ataques sofisticados que abarcan varias solicitudes. OpenAI propone que el proveedor conserve la alarma mientras el cliente mantiene el material necesario para investigarla.

Eso no demuestra todavía que una arquitectura sea más segura que la otra. El análisis de Computerworld considera viable la detección mediante indicadores derivados, pero identifica la verificación como la dificultad central y señala que la carga forense se desplaza hacia la empresa usuaria.

La diferencia puede ser relevante para organizaciones que manejan información financiera, sanitaria o empresarial confidencial: limitar la retención del proveedor reduce una vía de exposición, pero no garantiza por sí solo el cumplimiento de una norma. El resultado dependerá de la implementación, de los registros que conserve el cliente y de los controles disponibles para revisar alertas y falsos positivos.

La promesa aún precede a la documentación técnica

El piloto de Private Safety Processing sigue pendiente de documentación sobre auditoría, precisión y gestión de falsos positivos.

Private Safety Processing continúa en pruebas con clientes iniciales y no es una función de acceso general. OpenAI prevé comenzar su despliegue y publicar un documento técnico en septiembre de 2026, pero aún no ha divulgado detalles como la duración del contexto analizado, la precisión de las señales, los mecanismos de auditoría o el procedimiento completo ante falsos positivos.

Por ahora, lo confirmado es más limitado que el alcance potencial del sistema: OpenAI mantiene su promesa de no retener solicitudes y respuestas elegibles y ha descrito una arquitectura para detectar riesgos entre interacciones sin entregar ese contenido a su personal. La evaluación dependerá del documento técnico, de la ampliación del piloto y de datos que permitan comprobar si las señales ofrecen protección útil sin reconstruir las conversaciones que ZDR pretende mantener fuera del alcance del proveedor.

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