Private Intelligence: la IA que no se queda nada

Dos piezas de privacidad bajo una sola etiqueta

El anuncio llegó en la parte del DevDay dedicada a los desarrolladores, después de las novedades de Codex y de la Agents API. OpenAI lo presentó como una vista previa de un paquete con nombre propio, OpenAI Private Intelligence, pensado para «dar controles más fuertes sobre tus datos mientras usas las capacidades más avanzadas de nuestros modelos».

Dentro hay dos cosas que no están en el mismo punto. La primera, ZDR con Private Safety Processing, entrega la revisión de seguridad del modelo «sin guardar tu contenido en nuestros servidores en absoluto», y tiene desde ya una guía de configuración publicada, con capturas de la consola y comandos. La segunda, Private Inference, se describió en una sola frase: con ella, dijo la compañía, «podemos incluso dar privacidad en el momento de la inferencia».

OpenAI añadió que ha trabajado «estrechamente con algunos de nuestros clientes más grandes» para diseñar sistemas de privacidad y seguridad a la altura de sus estándares más altos. La cadena de televisión económica estadounidense CNBC, en su cobertura en directo del acto, recoge que Altman nombró a tres: Cisco, que fabrica equipos de red, y las plataformas de datos en la nube Databricks y Snowflake. Ni ahí ni en la presentación se precisa qué parte del diseño aportó cada una.

La política se activa por proyecto y se lo come entero

El interruptor no es de cuenta, es de proyecto. Una vez activado, la política se aplica a todo el tráfico de API de ese proyecto, incluidas las peticiones a modelos que de otro modo no exigirían Private Safety Processing. Quien quiera retención cero sin este mecanismo para los modelos que lo permiten tiene que mandar esas peticiones por un proyecto aparte, configurado de otra manera.

El trámite lo hace un administrador de la organización, no de proyecto, y para la vía de la Management API hace falta una clave de administrador: una clave de inferencia del proyecto no sirve. La región del almacén tiene que casar con la residencia de datos del proyecto, y los puntos de entrada son distintos para los proyectos globales, los de Estados Unidos y los europeos.

Hay un detalle que conviene leer dos veces: registrar el almacenamiento no cambia por sí solo la política de retención. Es la validación la que la activa, y la consola solo entonces muestra la política de retención cero de datos con Private Safety Processing en modo de solo lectura.

El almacén lo pone el cliente, y con las reglas que marca OpenAI

La parte que cuesta dinero y trabajo recae en el cliente: contratar y configurar el almacén donde van a parar esos registros. OpenAI admite tres nubes y detalla la configuración de cada una hasta el nivel de la política de permisos en formato JSON.

El plazo es el mismo en las tres: los objetos caducan a los 30 días. La guía avisa de que esa caducidad del almacenamiento es independiente de la caducidad de la clave de descifrado que gestiona OpenAI, y de que conviene comprobar que ninguna otra regla borre los registros antes de tiempo. En los proyectos globales con Google Cloud, además, la configuración hay que repetirla por cada región que se piense usar.

En ninguno de los tres casos se comparten claves: en Azure, OpenAI gestiona las credenciales de su propia aplicación y la guía pide expresamente no crear ni compartir una clave de la cuenta de almacenamiento, un token SAS o un secreto de cliente.

«Validado» no quiere decir vigilado

La validación comprueba la configuración y el acceso, y activa la retención gestionada por el cliente para ese proyecto. Por la Management API, la respuesta correcta devuelve el estado validado; por la consola, aparece el rótulo correspondiente y la política pasa a ser de solo lectura. Si falla, se corrige lo que se indique y se reintenta.

La propia guía pone el límite de lo que eso significa, y es un límite grande: validado registra una comprobación correcta, no la salud continua del almacenamiento. Y el botón de refrescar no vuelve a validar. La vigilancia del día a día queda del lado del cliente, con las páginas de operación y resolución de problemas como única referencia.

Es decir: quien activa esto se queda con la factura del almacén, la obligación de mantenerlo sano y la responsabilidad de que la regla de caducidad siga en pie. A cambio, OpenAI deja de guardar el contenido.

Private Inference llega en otoño y se pide por formulario

De la segunda pieza sí hay plazo y hay descripción, aunque cortos. OpenAI dice que su vista previa de Private Inference «llega este otoño» y que «combina computación confidencial con controles estrictos y verificables». Computación confidencial es la técnica que mantiene los datos cifrados también mientras se procesan, y no solo cuando viajan o cuando están guardados, de forma que ni quien opera la máquina llegue a leerlos.

Lo que falta es lo operativo. No hay página de producto, ni guía de configuración como la que acompaña a Private Safety Processing, ni lista de modelos compatibles, ni fecha concreta dentro del otoño. Y no se activa: quien la quiera la pide por el formulario de interés en Private Intelligence.

El coste tampoco está. OpenAI no ha publicado tarifa para Private Intelligence, ni para la pieza que ya funciona ni para la que llegará, y su guía de configuración no menciona ningún recargo por usar retención cero de datos con Private Safety Processing. Lo que sí está contabilizado, aunque no lo facture OpenAI, es el almacenamiento: el bucket o el contenedor los paga el cliente a su proveedor de nube, con sus propias tarifas.

Queda un requisito previo que puede valer más que el precio: hay que estar aprobado para retención cero de datos. Las organizaciones que ya lo están pueden configurar esto directamente en la consola; las demás pasan antes por los requisitos de acceso y aprobación que OpenAI publica en su guía de datos.