Activar el modo de retención cero para el contenido de IA

Para habilitar el modo de retención cero para el contenido de IA de forma responsable, empiece por definir qué abarca realmente la «retención cero». OpenAI describe la Retención Cero de Datos (ZDR) como el compromiso de que las solicitudes y respuestas del modelo de los clientes de API elegibles no se conservan una vez procesada una solicitud. También afirma que el contenido de los clientes sujeto a ZDR no está disponible para que el personal de OpenAI lo revise, mientras que los datos de clientes empresariales no se utilizan para entrenar modelos, salvo que el cliente acepte expresamente participar.

Esta definición es importante, pero habilitar ZDR no constituye una estrategia de privacidad basada en un único interruptor. La elegibilidad, la configuración de la organización y los proyectos, la compatibilidad de los endpoints, el comportamiento del estado de la aplicación, la observabilidad, los registros internos y las pruebas de cumplimiento afectan al resultado. Por tanto, una implementación fiable combina los controles documentados de OpenAI con una arquitectura de aplicaciones rigurosa, la minimización de datos, las pruebas y una gobernanza continua.

Comprenda qué significa y qué no significa la Retención Cero de Datos

La política estándar de retención de la API de OpenAI y la Retención Cero de Datos son políticas diferentes. Según la política predeterminada de la API descrita por OpenAI, las entradas y salidas de la API se eliminan después de 30 días, salvo que la empresa esté legalmente obligada a conservarlas. ZDR es una opción adicional disponible para clientes elegibles y endpoints compatibles; no es simplemente otro nombre para la política predeterminada de 30 días.

En los casos de uso aprobados, ZDR cambia la forma en que se gestiona el contenido del cliente después del procesamiento. OpenAI afirma que las solicitudes y las respuestas del modelo no se conservan una vez completada una solicitud, y que el contenido no está disponible para que su personal lo revise. Esto puede reducir de manera sustancial la cantidad de contenido del cliente que conserva el proveedor del modelo.

Regla operativa: Considere ZDR como un control de retención del lado del proveedor con un alcance estrictamente definido, no como una prueba de que todo el flujo de trabajo de IA no conserva datos en ninguna parte.

Su aplicación aún puede crear copias antes o después de una solicitud a la API. Los servidores web, las puertas de enlace de API, los sistemas de seguimiento, el almacenamiento del navegador, los sistemas de gestión de contenidos, las plataformas de análisis, las herramientas de asistencia, los sistemas de seguimiento de errores, las copias de seguridad y los dispositivos de los empleados pueden conservar contenido de IA independientemente del proveedor del modelo.

Por ejemplo, una aplicación editorial podría enviar un borrador confidencial a un endpoint compatible con ZDR y, al mismo tiempo, escribir la solicitud completa en un registro interno de depuración. La solicitud del lado del proveedor podría cumplir con ZDR mientras que el sistema en su conjunto seguiría conservando el borrador. Eso supondría un fallo de arquitectura y gobernanza, aunque la configuración de la API fuera correcta.

Separe cuatro conceptos que suelen confundirse

• Procesamiento de solicitudes: El modelo debe procesar la solicitud y generar una respuesta. Retención cero no significa procesamiento cero.
• Retención por parte del proveedor: ZDR aborda si OpenAI conserva las solicitudes y respuestas después del procesamiento en configuraciones elegibles y con funciones compatibles.
• Entrenamiento de modelos: OpenAI afirma que los datos de clientes empresariales no se utilizan para entrenar modelos, salvo que el cliente acepte expresamente participar. Esto está relacionado con la privacidad, pero es distinto del periodo de retención de las solicitudes.
• Retención por parte de la aplicación: Sus propios sistemas y proveedores pueden almacenar documentos de origen, solicitudes, respuestas, metadatos o contenido derivado conforme a políticas independientes.

Esta distinción permite ofrecer una respuesta más precisa cuando los equipos jurídicos, de seguridad o de compras preguntan si se conserva el contenido de IA. En lugar de afirmar que «no se almacena nada», documente qué parte procesa cada categoría de datos, dónde pueden crearse copias, qué regla de retención se aplica y qué control técnico la hace cumplir.

Confirme que la organización y el caso de uso sean elegibles

OpenAI no presenta ZDR como una opción universal para todas las cuentas. Su información sobre privacidad empresarial indica que las organizaciones que cumplan los requisitos pueden configurar políticas de retención, incluida una política de retención cero de datos, a través de la plataforma API. La disponibilidad está limitada a clientes de API elegibles y casos de uso que cumplan los requisitos.

Por tanto, la primera tarea de implementación es revisar la elegibilidad, no modificar la configuración de producción. Póngase en contacto con el canal adecuado de cuenta o asistencia de OpenAI y describa con precisión el flujo de trabajo previsto. Evite describir únicamente el ejemplo de menor riesgo si el tráfico de producción incluirá material más sensible o utilizará capacidades adicionales.

Prepare una descripción clara del caso de uso

Un paquete de revisión útil debe explicar el servicio sin enviar contenido innecesario de los clientes. Puede incluir:

• La finalidad de la función de IA y los usuarios previstos.
• Las categorías de contenido que pueden aparecer en las solicitudes, los archivos adjuntos y las respuestas.
• Si se incluyen datos regulados, confidenciales, personales, sanitarios o de propiedad exclusiva.
• Los modelos, endpoints de API, herramientas y modos de respuesta que la aplicación prevé utilizar.
• Si el flujo de trabajo es síncrono, de varios turnos, basado en agentes o dependiente del procesamiento en segundo plano.
• Los proyectos, entornos y unidades organizativas que requieren ZDR.
• Las reglas internas de retención y eliminación que se aplican fuera de OpenAI.

El Anexo para el Sector Sanitario de OpenAI ofrece una definición especialmente explícita de una «API de Retención Cero»: el contenido del cliente se procesa sin guardarse, conservarse ni registrarse para su revisión humana. Esta formulación puede ayudar a una organización sanitaria a comprender el comportamiento previsto del proveedor, pero no debe generalizarse para afirmar que todos los endpoints, cuentas o flujos de trabajo sanitarios están cubiertos automáticamente. Las condiciones contractuales, el estado de aprobación y la documentación vigente de los endpoints siguen siendo determinantes.

No dé por sentado que la aprobación de la cuenta hace que todas las funciones sean compatibles

OpenAI advierte que no todos los endpoints o capacidades son compatibles con ZDR. Algunas funciones pueden almacenar el estado de la aplicación incluso cuando una organización ha habilitado una política de retención cero. El modo en segundo plano es un ejemplo documentado: es incompatible con ZDR porque los datos de respuesta se almacenan brevemente para que la aplicación pueda consultar el resultado.

Esto significa que la elegibilidad debe evaluarse en más de un nivel. Una organización puede estar aprobada para ZDR y, aun así, un flujo de trabajo concreto puede no ser adecuado porque utiliza un endpoint incompatible o una capacidad con estado. El enfoque más seguro consiste en mantener una lista explícita de modelos, endpoints, modos y herramientas aprobados, en lugar de suponer que la configuración de la organización abarca todas las operaciones de la API.

Configure ZDR en los niveles de organización y proyecto

La documentación de la plataforma de OpenAI indica que las organizaciones aprobadas pueden elegir entre la Retención Cero de Datos o la Supervisión Modificada de Abusos en el nivel de la organización y, posteriormente, configurar el comportamiento por proyecto. Esta jerarquía es importante porque las aplicaciones de producción suelen estar repartidas entre proyectos, entornos, unidades de negocio o clasificaciones de datos.

Las etiquetas exactas de la interfaz y las opciones disponibles pueden cambiar a medida que evoluciona la plataforma, por lo que la documentación vigente de la plataforma OpenAI debe ser la fuente de referencia durante la implementación. El siguiente proceso se centra en objetivos de control duraderos, en lugar de presuponer una disposición concreta de la interfaz.

1. Obtenga y registre la aprobación. Confirme que la organización de API correcta es elegible para ZDR y que el caso de uso previsto está dentro del alcance. Guarde la aprobación o las pruebas contractuales en el repositorio de cumplimiento de la organización.
2. Haga un inventario de las organizaciones y proyectos. Identifique todas las organizaciones y proyectos de OpenAI utilizados por los equipos de desarrollo, pruebas, preproducción, producción, ciencia de datos y asistencia. No debe suponerse que una configuración aplicada a un proyecto abarca otro.
3. Elija la política en el nivel de la organización. En una organización aprobada, seleccione la política documentada de Retención Cero de Datos cuando resulte apropiado. Comprenda la diferencia entre ZDR y la Supervisión Modificada de Abusos antes de elegir.
4. Revise cada proyecto. Establezca o verifique el comportamiento de cada proyecto según los datos que gestione. Las cargas de trabajo muy sensibles no deben compartir un proyecto configurado de forma ambigua con experimentos que tengan requisitos de retención diferentes.
5. Documente todas las operaciones de la API. Enumere el endpoint, el modelo, las herramientas, los modos, la gestión de archivos, el comportamiento del estado y cualquier función basada en agentes utilizada por cada ruta de la aplicación. Compruebe cada elemento con la documentación vigente sobre compatibilidad con ZDR.
6. Elimine los comportamientos incompatibles. Rediseñe las llamadas que dependan de funciones con estado no compatibles. En particular, no utilice el modo en segundo plano en un flujo de trabajo presentado como compatible con ZDR mientras la documentación identifique dicho modo como incompatible.
7. Restrinja las credenciales y el acceso. Conceda a los servicios acceso únicamente a los proyectos y capacidades que necesiten. Esto reduce la posibilidad de que una carga de trabajo ZDR se redirija silenciosamente a través de un proyecto no aprobado.
8. Pruebe la configuración en un entorno controlado. Verifique los identificadores de proyecto, las rutas de las solicitudes, la gestión de errores, los reintentos y las alternativas sin incluir contenido sensible de producción en los registros de prueba.
9. Apruebe el lanzamiento en producción. Exija que los responsables de privacidad, seguridad, ingeniería y datos pertinentes confirmen que la configuración documentada coincide con la arquitectura desplegada.
10. Supervise las desviaciones. Vuelva a comprobar la política cuando añada un modelo, endpoint, herramienta, proyecto, integración o una nueva clase de contenido.

El diseño en el nivel de proyecto resulta especialmente útil para imponer límites. Una empresa podría aislar un servicio sensible de procesamiento de documentos en un proyecto aprobado y mantener los prototipos de bajo riesgo en otro. La separación facilita la revisión de accesos, la atribución de costes, el control de despliegues y las pruebas de cumplimiento, aunque no sustituye las comprobaciones de compatibilidad en el nivel de endpoint.

Defina una política segura ante fallos

Los errores de configuración deben producir un cierre seguro cuando el contenido requiera ZDR. Si el proyecto aprobado no está disponible, la aplicación no debe redirigir automáticamente las solicitudes sensibles a un proyecto con retención estándar únicamente para mantener la disponibilidad. Cualquier alternativa que modifique la política de retención debe tratarse como un cambio sustancial y aprobarse expresamente.

El mismo principio se aplica a las funciones alternativas. Si falla una solicitud síncrona, cambiar silenciosamente al modo en segundo plano entraría en conflicto con un requisito ZDR, ya que OpenAI identifica dicho modo como incompatible. Los objetivos de disponibilidad deben equilibrarse con el compromiso de privacidad declarado, en lugar de anularlo de forma invisible.

Diseñe toda la ruta del contenido de IA para minimizar la retención

La configuración del proveedor es solo una capa de una arquitectura de retención cero. Para habilitar el modo de retención cero para el contenido de IA de manera significativa, siga el recorrido del contenido desde su recopilación hasta su preprocesamiento, transmisión, gestión de respuestas, visualización y eliminación. Cada componente de esa ruta debe tener una finalidad y una regla de retención definidas.

Minimice el contenido antes de llamar a la API

Envíe únicamente la información necesaria para realizar la tarea. Si un modelo necesita clasificar un párrafo, quizá no necesite el nombre del autor, el historial completo del documento, el número de cuenta ni archivos adjuntos no relacionados. Eliminar campos innecesarios reduce la exposición independientemente de la configuración de retención del proveedor.

Cuando proceda, las aplicaciones pueden sustituir los identificadores directos por referencias internas antes de la transmisión. La correspondencia debe permanecer en un sistema independiente y controlado, y no debe incluirse en la solicitud. La anonimización debe probarse con el formato real del contenido, ya que los datos sensibles pueden aparecer en texto libre, nombres de archivo, encabezados, imágenes, metadatos o historiales de conversación citados.

Controle los registros y seguimientos

Muchos marcos de IA capturan solicitudes y respuestas para ayudar a los desarrolladores a solucionar problemas de calidad. Este comportamiento resulta útil en un entorno de laboratorio, pero puede menoscabar un objetivo de retención cero en producción. Revise los registros HTTP, el seguimiento distribuido, la supervisión del rendimiento de las aplicaciones, los informes de errores, los análisis y los procesos de evaluación para detectar la captura completa de solicitudes o respuestas.

• Registre identificadores de solicitudes, tiempos, nombres de modelos, códigos de estado y metadatos operativos relacionados con tokens solo cuando sea necesario.
• Deshabilite la captura de contenido en rutas sensibles.
• Depure los mensajes de excepción y los campos de contexto de las pilas de errores.
• Evite incluir fragmentos de solicitudes en los títulos de alertas o en herramientas de colaboración.
• Aplique controles de acceso y reglas de eliminación a los metadatos que se conserven.
• Compruebe si las llamadas fallidas, los reintentos y los tiempos de espera agotados generan registros más detallados que las llamadas correctas.

No afirme que desaparecen todos los registros. OpenAI indica que pueden existir registros de seguridad y cumplimiento al margen de la retención del contenido del cliente. Sus API de cumplimiento conservan los registros durante 30 días, y las solicitudes de eliminación se conservan internamente durante un máximo de 30 días con fines de auditoría y seguridad. Estos hechos refuerzan la necesidad de definir con precisión si una declaración se refiere a las solicitudes y respuestas del cliente, los metadatos operativos, los registros de cumplimiento o los registros de auditoría de eliminaciones.

Gestione deliberadamente el contenido generado

ZDR no impide que su aplicación guarde la respuesta del modelo. Una plataforma de gestión de contenidos puede almacenar intencionadamente un borrador generado, mientras que una herramienta de resumen transitoria puede mostrar un resultado y descartarlo. Ambos diseños pueden utilizar ZDR en el proveedor, pero presentan resultados distintos en cuanto a la retención en la aplicación.

Documente si el contenido generado es temporal, está controlado por el usuario o constituye un registro empresarial formal. Si se guarda, defina su ubicación de almacenamiento, propietario, política de acceso, periodo de retención, proceso de eliminación y tratamiento en las copias de seguridad. Calificar una aplicación como de «retención cero» sería engañoso si almacena intencionadamente todas las respuestas de forma indefinida.

Tenga en cuenta el estado de los endpoints y los flujos de trabajo basados en agentes

Las aplicaciones modernas de IA pueden implicar más que una sola solicitud seguida de una única respuesta. Las interacciones de varios turnos, las llamadas a herramientas, la continuidad del razonamiento y los procesos basados en agentes pueden depender de un estado. Dicho estado debe evaluarse por separado, en lugar de suponer que queda incluido en una interpretación sencilla de solicitud y respuesta.

OpenAI ha continuado trabajando en productos relacionados con ZDR en 2026. Una publicación reciente de OpenAI sobre modelos de vanguardia afirma que ZDR puede admitir nuevos flujos de trabajo basados en agentes, incluidas respuestas que mantienen elementos de razonamiento entre turnos mediante un estado cifrado. El anuncio de OpenAI del 19 de agosto de 2026 también presenta los nuevos sistemas de seguridad como «procesamiento privado de seguridad» y afirma que se están ofreciendo en versión preliminar sin dejar de ser compatibles con ZDR.

Estos avances demuestran que los flujos de trabajo sofisticados y ZDR no son necesariamente incompatibles. Sin embargo, no establecen una compatibilidad universal para todos los agentes, endpoints, herramientas o mecanismos de estado. Los equipos deben verificar la combinación concreta que pretendan desplegar comparándola con la documentación vigente y con la configuración aprobada de su cuenta.

Formule preguntas específicas sobre el estado

• ¿Qué estado se crea durante el flujo de trabajo?
• ¿Lo conserva el proveedor, la aplicación del cliente u otro proveedor?
• ¿El estado es contenido del cliente, un estado cifrado del flujo de trabajo, metadatos operativos o un registro de la aplicación?
• ¿Durante cuánto tiempo necesita cada componente conservar el estado?
• ¿El endpoint y el modo están documentados expresamente como compatibles con ZDR?
• ¿La consulta periódica requiere almacenar temporalmente los datos de respuesta?
• ¿Puede continuar el flujo de trabajo sin almacenar las solicitudes y respuestas completas en registros controlados por el cliente?

El modo en segundo plano merece un control independiente porque su diseño de consulta periódica almacena brevemente los datos de respuesta y, por tanto, no es compatible con ZDR según OpenAI. Una revisión del código debe buscar tanto configuraciones explícitas del modo en segundo plano como envoltorios o kits de desarrollo de software que puedan habilitar indirectamente dicho comportamiento.

En los flujos de trabajo basados en agentes que utilicen un estado cifrado, mantenga un alcance limitado de la afirmación: el trabajo de producto citado de OpenAI afirma que este mecanismo puede mantener elementos de razonamiento entre turnos cuando se desarrolla con ZDR. Esto no justifica describir todos los agentes con estado como de retención cero. Registre el modelo compatible, el endpoint, el mecanismo de estado, la política del proyecto y la versión de la documentación revisada para el lanzamiento.

Gestione las compensaciones entre gobernanza e intercambio de datos

El Centro de ayuda de OpenAI indica que las organizaciones con la Retención Cero de Datos habilitada no pueden aceptar participar en el intercambio de datos. No pueden participar en programas de intercambio de datos para comentarios, evaluación o ajuste fino mientras ZDR esté habilitado. Esta es una consecuencia importante para la gobernanza, no una preferencia menor de la cuenta.

Los equipos acostumbrados a enviar ejemplos de producción a un proveedor para su evaluación o mejora necesitan un proceso de calidad diferente. Pueden seguir evaluando su propia aplicación, pero el conjunto de datos, las herramientas, los permisos y las reglas de retención deben gestionarse dentro de su entorno autorizado y cumplir los contratos y políticas aplicables.

Cree un proceso de evaluación que tenga en cuenta la privacidad

Un proceso interno práctico puede utilizar casos de prueba aprobados que sean sintéticos, estén desidentificados o cuenten con una autorización específica. Los revisores humanos solo deben ver el contenido necesario para su función, y los resultados de las evaluaciones deben tener un periodo de retención documentado. Si se necesitan ejemplos reales de clientes, obtenga la base jurídica apropiada y la aprobación interna, en lugar de tratar ZDR como una autorización general.

La imposibilidad de participar en los programas de OpenAI de intercambio de datos para comentarios, evaluaciones o ajuste fino debe reflejarse en los planes técnicos y de producto. Un equipo no debe habilitar ZDR y diseñar simultáneamente una exportación automatizada de solicitudes a un canal de intercambio de datos del proveedor. Eso entraría en conflicto con la restricción documentada de la cuenta y con el objetivo de privacidad de la configuración.

Principio de gobernanza: La mejora de la calidad del modelo no debe cambiar silenciosamente el destino, la finalidad o la retención aprobados del contenido sensible.

Asigne responsables para gestionar esta compensación. El equipo de ingeniería puede operar la configuración de la API, pero el equipo de privacidad debe definir los usos aceptables de los datos, el equipo de seguridad debe revisar los controles, el departamento jurídico o de cumplimiento debe interpretar las obligaciones y los responsables de producto deben decidir si la función puede cumplir los requisitos de calidad sin compartir datos con el proveedor.

Utilice un lenguaje preciso de cara a los usuarios

Los avisos de privacidad, documentos comerciales o mensajes de la interfaz deben evitar afirmaciones absolutas como «sus datos nunca se almacenan en ninguna parte». Una descripción más defendible identifica el límite: las solicitudes elegibles se procesan mediante una configuración de la API de OpenAI según la cual OpenAI no conserva las solicitudes ni las respuestas del modelo después de su procesamiento, mientras que las prácticas de almacenamiento propias de la aplicación se describen por separado.

Toda afirmación pública debe coincidir con la ruta de producción real. Si algunos proyectos utilizan la retención estándar de la API, determinados endpoints son incompatibles o los borradores generados se guardan en la cuenta del cliente, explique estas diferencias. La confianza procede de establecer límites precisos, no de comprimir varias políticas en una promesa comercial general.

Valide el despliegue y conserve pruebas

Los controles de privacidad requieren pruebas. Una captura de pantalla de la configuración no basta, porque no demuestra que el tráfico de producción utilice la organización, el proyecto y el endpoint compatible previstos. Del mismo modo, las pruebas de la aplicación por sí solas no demuestran que el proveedor haya aprobado y configurado la cuenta para ZDR.

Cree un conjunto de pruebas que combine registros administrativos, arquitectónicos y operativos. Evite incluir contenido innecesario de las solicitudes.

1. Pruebas de aprobación: Conserve la confirmación correspondiente de OpenAI, la documentación de la cuenta, el material contractual u otro registro autorizado que demuestre la elegibilidad para ZDR.
2. Pruebas de configuración: Registre la política de la organización y el comportamiento pertinente de cada proyecto. Incluya la fecha de revisión y el responsable.
3. Pruebas de compatibilidad: Identifique la documentación utilizada para confirmar que cada modelo, endpoint, modo y capacidad admite ZDR.
4. Pruebas de arquitectura: Mantenga un diagrama del flujo de datos que abarque la entrada del usuario, el preprocesamiento, la transmisión a la API, la gestión de respuestas, el almacenamiento interno, la observabilidad y la eliminación.
5. Pruebas de código: Revise cómo elige la aplicación las credenciales de los proyectos, los endpoints, los modos de solicitud, las herramientas, los reintentos y las alternativas.
6. Pruebas de registro: Demuestre que los cuerpos sensibles de las solicitudes y respuestas no se copian en registros, seguimientos, alertas o sistemas de evaluación no aprobados.
7. Pruebas funcionales: Utilice marcadores no sensibles para comprobar las ubicaciones de almacenamiento controladas por la aplicación y verificar el enrutamiento previsto, sin afirmar que tiene acceso a sistemas del proveedor que no puede inspeccionar.
8. Pruebas de lanzamiento: Registre la aprobación de los responsables designados de ingeniería, seguridad, privacidad y datos.

Pruebe las rutas negativas, no solo las solicitudes correctas

Los fallos de privacidad suelen aparecer durante las excepciones. Simule fallos de autorización, límites de frecuencia, errores de endpoints, tiempos de espera agotados en la red, fallos de análisis y dependencias no disponibles con entradas no sensibles. Compruebe si el software intermedio de depuración captura los cuerpos o si el sistema redirige las solicitudes a una alternativa sin ZDR.

Pruebe también la separación de proyectos. Un servicio destinado a un proyecto ZDR debe rechazar las credenciales o configuraciones pertenecientes a un entorno no aprobado. Las plantillas de despliegue pueden validar los identificadores de los proyectos, mientras que los controles de gestión de cambios pueden exigir una revisión cuando dichos identificadores se modifiquen.

Sea honesto acerca de lo que puede verificarse

Por lo general, los clientes no pueden inspeccionar directamente el almacenamiento interno de un proveedor. Por tanto, las garantías dependen de los compromisos documentados del proveedor, los acuerdos aplicables, la configuración de la cuenta, la documentación de compatibilidad y los controles técnicos del propio cliente. No presente una prueba del lado del cliente como demostración de todos los procesos internos del proveedor.

OpenAI vincula ZDR con controles empresariales más amplios de privacidad y cumplimiento, incluidos el cifrado, los controles de retención y las opciones de residencia de datos para organizaciones que cumplan los requisitos. Estos controles pueden contribuir a un programa de cumplimiento, pero ninguno debe considerarse una certificación automática de que una aplicación concreta cumple todos los requisitos legales.

Integre ZDR en el cumplimiento y las operaciones continuas

ZDR puede reducir la retención de contenido por parte del proveedor y respaldar los objetivos de minimización de datos. No obstante, el cumplimiento sigue dependiendo del contexto: el tipo de datos, la legislación aplicable, los compromisos contractuales, las expectativas de los usuarios, el papel de la organización, la ubicación, las medidas de seguridad y el comportamiento de cada encargado o subencargado del tratamiento del flujo de trabajo.

Una declaración de controles defendible debe ser específica. Podría indicar que una organización aprobada para utilizar la API de OpenAI emplea ZDR en determinados proyectos y endpoints compatibles, mientras que el almacenamiento interno de contenidos sigue un calendario independiente. También debe revelar las exclusiones pertinentes, como el modo en segundo plano, los registros de la aplicación o la información operativa de auditoría.

Mantenga un registro de controles actualizado

• Identifique a los responsables empresariales y técnicos.
• Enumere las organizaciones, proyectos, modelos, endpoints y capacidades aprobados.
• Registre los modos prohibidos, incluido el modo en segundo plano cuando sea necesario aplicar ZDR.
• Describa las reglas internas de registro y almacenamiento de respuestas.
• Documente la restricción relativa al intercambio de datos con OpenAI para comentarios, evaluaciones y ajuste fino.
• Incluya referencias a la documentación y los acuerdos del proveedor revisados.
• Establezca factores desencadenantes de revisión para los cambios de producto, no solo una revisión periódica.

Entre los factores útiles para iniciar una revisión se incluyen la adopción de un nuevo modelo de vanguardia, la incorporación de herramientas, la habilitación del estado entre varios turnos, el cambio de un SDK, la creación de un proyecto, la modificación de la observabilidad, la introducción de una alternativa o la ampliación a una nueva categoría de datos. El trabajo de OpenAI de 2026 sobre el estado cifrado y el procesamiento privado de seguridad ilustra por qué los controles deben evolucionar a medida que cambian los flujos de trabajo compatibles.

La respuesta ante incidentes también debe distinguir entre la retención por parte del proveedor y las filtraciones del lado del cliente. Si las solicitudes aparecen en un seguimiento interno, deshabilitarlo y eliminar las copias no autorizadas puede ser la prioridad inmediata, aunque ZDR siga estando correctamente configurado en OpenAI. Si el tráfico se ha dirigido a través de un modo incompatible o un proyecto incorrecto, detenga la ruta afectada, conserve pruebas que no incluyan contenido siempre que sea posible, evalúe el alcance y siga los procedimientos de gestión y notificación de incidentes de la organización.

Utilice un lenguaje preciso en las auditorías

Los auditores y clientes pueden preguntar si existen «registros». Las declaraciones de OpenAI requieren una respuesta matizada: ZDR se refiere a las solicitudes y respuestas del modelo después del procesamiento y a su disponibilidad para la revisión humana, mientras que determinados registros de seguridad, cumplimiento, eliminación o auditoría pueden recibir un tratamiento diferente. OpenAI afirma que los registros de su API de cumplimiento se conservan durante 30 días y que las solicitudes de eliminación se mantienen internamente durante un máximo de 30 días con fines de seguridad y auditoría.

La precisión refuerza, en lugar de debilitar, la descripción de los controles. Demuestra que la organización ha examinado distintas categorías de datos, en lugar de basarse en una promesa indefinida. Debe aplicarse el mismo rigor al cifrado y la residencia de datos: describa los controles realmente habilitados, su alcance y cualquier limitación de elegibilidad o del producto.

Cree una lista de comprobación práctica para producción

Antes de lanzar un flujo de trabajo de contenido de IA bajo una afirmación de retención cero, realice una revisión final que vincule la política con el comportamiento desplegado. La lista de comprobación debe tener un responsable, ser repetible y estar vinculada a la gestión de lanzamientos.

• OpenAI ha confirmado que la organización y el caso de uso son elegibles para ZDR.
• La política de retención correcta está configurada en el nivel de la organización.
• Cada proyecto de producción se ha revisado de forma independiente.
• Cada modelo, endpoint, herramienta, modo y mecanismo de estado está documentado como compatible.
• El modo en segundo plano no se utiliza cuando se requiere ZDR.
• Las credenciales no pueden redirigir silenciosamente el tráfico a un proyecto con retención estándar.
• Las alternativas producen un cierre seguro en lugar de debilitar la política de retención.
• Las solicitudes y respuestas se excluyen de los registros y seguimientos innecesarios de la aplicación.
• El contenido generado que almacena la aplicación tiene una finalidad empresarial y una regla de retención explícitas.
• Las opciones de OpenAI para compartir datos destinados a comentarios, evaluaciones y ajuste fino no se consideran disponibles para la organización ZDR.
• El lenguaje dirigido a los usuarios y el utilizado en los contratos describe con precisión los límites del proveedor y de la aplicación.
• Las pruebas se conservan sin almacenar contenido sensible únicamente para demostrar que se ha minimizado la retención.
• Los cambios en los modelos, endpoints, comportamiento de los SDK, herramientas, proyectos o estado del flujo de trabajo desencadenan una nueva revisión.

Ninguna lista de comprobación puede sustituir la documentación vigente. Las capacidades de la plataforma evolucionan, como demuestra el trabajo de OpenAI de 2026 compatible con ZDR sobre flujos de trabajo basados en agentes, estados cifrados y procesamiento privado de seguridad. Vuelva a validar la compatibilidad antes de adoptar una función nueva, en lugar de suponer que hereda el comportamiento de la política de un endpoint anterior.

Es igualmente importante no exagerar lo que ofrece la lista de comprobación. Puede respaldar las garantías de implementación e identificar deficiencias habituales, pero el cumplimiento legal y la idoneidad contractual requieren la revisión de profesionales cualificados que comprendan los datos, la jurisdicción, el sector y las obligaciones de la organización.

Para habilitar correctamente el modo de retención cero para el contenido de IA, combine la aprobación de OpenAI, la configuración de la organización y los proyectos, las comprobaciones de compatibilidad de los endpoints, la recopilación mínima de datos, el control de los registros, las alternativas seguras y una verificación documentada. ZDR puede proporcionar un sólido control de privacidad del lado del proveedor para los clientes de API elegibles, pero su alcance debe quedar claro: aborda la retención de solicitudes y respuestas del modelo en condiciones compatibles, no todas las copias creadas en el ecosistema de una aplicación.

La implementación más fiable es aquella que puede explicar sus límites sin recurrir a afirmaciones absolutas. Consulte la documentación vigente de OpenAI, aísle las cargas de trabajo aprobadas, evite funciones incompatibles como el modo en segundo plano, tenga en cuenta los registros independientes de seguridad y cumplimiento, y reevalúe el diseño cada vez que cambie el flujo de trabajo. Este enfoque convierte una configuración de retención en una práctica de privacidad auditable, en lugar de una simple etiqueta comercial.