OpenAI acaba de poner nombre a uno de los problemas que más frenan a una pyme cuando quiere usar agentes de IA. ¿Cómo monitorizar abusos sin conservar los documentos, correos o facturas que el agente necesita leer?
Su respuesta se llama Private Safety Processing y, por ahora, es una vista previa.
La compañía asegura que los clientes elegibles de su API pueden usar Zero Data Retention (ZDR). Los prompts y las respuestas no se conservan después de procesar la petición, y el contenido del cliente no queda disponible para que lo revise personal de OpenAI.
La novedad es que OpenAI quiere detectar patrones de riesgo entre varias interacciones sin recuperar ese contenido para una revisión humana. Fuente oficial de OpenAI
La parte importante para una empresa pequeña está en el matiz de la retención cero de OpenAI. Esto no es un interruptor que convierta ChatGPT, cualquier endpoint —la ruta técnica que recibe una petición— o cualquier herramienta conectada en un sistema privado.
Es un control técnico y contractual para recorridos concretos de la API, sujeto a aprobación y con excepciones documentadas.
Qué ha anunciado OpenAI
El anuncio del 19 de agosto presenta Private Safety Processing como una tecnología en vista previa. OpenAI planea empezar a desplegarla y publicar un documento técnico en septiembre; todavía no existe una especificación pública completa que permita auditar su implementación. Anuncio de OpenAI
La motivación es razonable. Una petición aislada puede parecer normal, pero una secuencia de peticiones puede revelar un intento de saltarse las salvaguardas de un modelo. OpenAI dice que sus sistemas compatibles con ZDR ya evalúan cada interacción por separado. Private Safety Processing intentaría detectar esos patrones entre interacciones relacionadas sin exponer los prompts y respuestas subyacentes a su personal.
La compañía describe dos diseños para los despliegues ZDR. Uno mantiene el contenido en infraestructura controlada por el cliente.
El otro lo almacena en infraestructura de OpenAI, cifrado con claves controladas por el cliente.
En ambos casos, los sistemas automatizados devolverían señales limitadas de seguridad sin entregar el contenido a una persona de OpenAI. El segundo diseño aparece como una opción en desarrollo, no como una disponibilidad general.
Retención cero, no invisibilidad total
La documentación de la API separa dos cosas que suelen mezclarse: los registros de monitorización de abuso y el estado de aplicación. Por defecto, los primeros pueden incluir prompts, respuestas y metadatos derivados, y conservarse hasta 30 días. Los clientes aprobados para ZDR pueden excluir el contenido de esos registros, pero las funciones que necesitan guardar estado pueden seguir haciéndolo. Documentación de controles de datos
Algunos límites son especialmente relevantes si se diseña un agente:
- En
/v1/responsesy/v1/chat/completions, OpenAI tratastorecomofalsecuando ZDR está activo. - El modo en segundo plano de Responses conserva datos durante aproximadamente diez minutos para poder consultar el resultado; no es compatible con ZDR.
- Los servidores MCP remotos —MCP es un protocolo para conectar herramientas externas— son servicios de terceros y aplican sus propias políticas de retención.
- Code Interpreter no se puede usar con ZDR.
- Archivos e imágenes tienen reglas específicas. Una imagen marcada por posible material de abuso sexual infantil puede conservarse para revisión manual y notificación incluso en un despliegue ZDR.
La conclusión no es que ZDR sea inútil. Es que hay que comprobar el recorrido completo: modelo, endpoint, herramienta, archivo, log, proveedor intermedio y copia de seguridad.
Un agente que no guarda el prompt en OpenAI puede enviarlo después a un servidor MCP que sí lo almacena.
No entrenar tampoco significa procesar en local
OpenAI afirma que los datos de clientes empresariales y de la API no se utilizan para entrenar sus modelos por defecto. La organización debe optar expresamente por compartirlos para cambiar esa regla. Privacidad empresarial de OpenAI
Es una garantía distinta de la retención cero. «No entrenar» responde a una pregunta de uso posterior: qué hace el proveedor con esos datos para mejorar sus modelos.
«No retener» responde a cuánto tiempo conserva el contenido para operar, monitorizar o investigar el servicio. Y «procesar en local» responde a una pregunta anterior: si el contenido tuvo que salir del dispositivo.
| Control | Qué limita | Qué no garantiza |
|---|---|---|
| No entrenar por defecto | El uso de los datos empresariales para mejorar modelos | Que no existan logs o estado técnico |
| Zero Data Retention | El contenido en los registros de abuso de recorridos elegibles | Que todas las funciones y terceros sean ZDR |
| DPA (acuerdo de tratamiento) y contrato | Roles, instrucciones, transferencias y obligaciones entre empresa y proveedor | Que el diseño técnico sea correcto por sí solo |
| Procesamiento local | El envío del contenido a un proveedor externo | Que la aplicación no tenga otras conexiones o extensiones |
| Permisos mínimos y revisión humana | Las acciones que puede ejecutar el agente | Que el modelo siempre interprete bien los datos |
El Comité Europeo de Protección de Datos (EDPB) recomienda aplicar la protección de datos desde el diseño y por defecto.
También recomienda tratar solo la información necesaria y mantener un registro de las operaciones.
ZDR puede ser una pieza de esa arquitectura; no sustituye el análisis de riesgos, el contrato con el encargado ni las obligaciones de la empresa. Guía del EDPB para pequeñas empresas
El contraste con Anthropic explica el debate
OpenAI y Anthropic han escogido respuestas diferentes ante el mismo problema. Anthropic exige una retención mínima de 30 días para todo el tráfico de Fable 5 y Mythos 5.
Anthropic explica que necesita ese periodo para investigar ataques complejos y jailbreaks que operan entre varias peticiones.
También afirma que esos datos no se usan para entrenar nuevos modelos. Política de Anthropic
No es una comparación simple entre una empresa «privada» y otra «insegura». Anthropic prioriza disponer del contenido para investigar; OpenAI intenta que esa investigación funcione con señales automatizadas y sin mostrar el contenido al personal. Mientras Private Safety Processing no tenga su documento técnico, no podemos evaluar qué garantías criptográficas hay detrás de esa promesa.
Qué significa para una pyme que quiere un agente
Imaginemos un agente que clasifica facturas, propone respuestas de correo y prepara documentos para aprobación.
La pregunta no es «¿puedo usar OpenAI?», sino qué parte del flujo necesita realmente enviar datos y durante cuánto tiempo.
En un diseño razonable, el agente debería extraer localmente lo que no necesita un modelo remoto y eliminar campos innecesarios.
Después puede enviar solo el contexto mínimo, usar un endpoint elegible y bloquear cualquier acción irreversible detrás de una aprobación humana. Si además se conecta a un CRM, un gestor documental o un servidor MCP, cada integración necesita su propia revisión.
La supervisión tampoco es un gesto de desconfianza hacia la IA. Es una propiedad del sistema. Los agentes pueden leer, escribir y llamar a herramientas, pero el permiso para ejecutar una acción debe estar separado de la capacidad de proponerla. Nuestra guía sobre qué pueden hacer de verdad los agentes de código parte de esa misma distinción entre autonomía, permisos y revisión.
Cinco comprobaciones antes de conectar un agente
Antes de subir una primera factura o abrir el buzón de la empresa, una pyme debería pedir respuestas concretas.
Estas son las cinco preguntas que no pueden faltar:
- ¿Qué recorrido exacto usa el dato? Modelo, endpoint, región, herramienta y proveedor intermedio. «Usa la API» no es suficiente.
- ¿Está aprobado ZDR para esta organización y este proyecto? OpenAI indica que los controles requieren aprobación previa y requisitos adicionales. Hay que conservar esa confirmación por escrito.
- ¿Qué funciones guardan estado? Modo en segundo plano, archivos, bases vectoriales, cachés, servidores MCP y registros propios pueden crear retenciones fuera del control principal.
- ¿Qué datos son imprescindibles? El agente no necesita el DNI completo de un cliente para clasificar el tipo de factura. La minimización reduce exposición y coste.
- ¿Qué puede hacer sin pedir permiso? Leer y proponer no es lo mismo que enviar, borrar, pagar o cambiar un registro. Las acciones de alto impacto deben requerir aprobación y dejar un registro (log) auditable.
En los productos móviles de Kroniq aplicamos esta misma regla desde el otro lado: Textium procesa el reconocimiento óptico de caracteres (OCR) en el dispositivo, RollBind genera el PDF localmente y MaternityCounter mantiene los datos de salud en el teléfono.
No todo puede ejecutarse en local, pero cada dato que no necesita viajar es un dato que no hay que proteger después en un proveedor externo. Nuestra guía para probar modelos locales con seguridad explica los límites de ese enfoque.
OpenAI está intentando resolver una tensión real. Los modelos más capaces necesitan controles de seguridad más sofisticados, pero las empresas no quieren entregar sus documentos como precio de entrada.
Private Safety Processing es una señal interesante, todavía no una prueba definitiva.
Para una pyme, la decisión prudente sigue siendo la misma: minimizar primero, exigir retención y permisos explícitos, y probar el agente con datos de bajo riesgo antes de darle acceso al negocio real.