Private Intelligence: la IA que no es queda res

Dues peces de privacitat sota una sola etiqueta

L'anunci va arribar a la part del DevDay dedicada als desenvolupadors, després de les novetats de Codex i de l'Agents API. OpenAI el va presentar com una vista prèvia d'un paquet amb nom propi, OpenAI Private Intelligence, pensat per «donar controls més forts sobre les teves dades mentre uses les capacitats més avançades dels nostres models».

A dins hi ha dues coses que no estan al mateix punt. La primera, ZDR amb Private Safety Processing, entrega la revisió de seguretat del model «sense desar el teu contingut als nostres servidors en absolut», i té des d'ara una guia de configuració publicada, amb captures de la consola i ordres. La segona, Private Inference, es va descriure en una sola frase: amb ella, va dir la companyia, «podem fins i tot donar privacitat en el moment de la inferència».

OpenAI va afegir que ha treballat «estretament amb alguns dels nostres clients més grans» per dissenyar sistemes de privacitat i seguretat a l'altura dels seus estàndards més alts. La cadena de televisió econòmica nord-americana CNBC, en la seva cobertura en directe de l'acte, recull que Altman en va nomenar tres: Cisco, que fabrica equips de xarxa, i les plataformes de dades al núvol Databricks i Snowflake. Ni allà ni a la presentació es precisa quina part del disseny va aportar cada una.

La política s'activa per projecte i se'l menja sencer

L'interruptor no és de compte, és de projecte. Un cop activada, la política s'aplica a tot el trànsit d'API d'aquest projecte, incloses les peticions a models que altrament no exigirien Private Safety Processing. Qui vulgui retenció zero sense aquest mecanisme per als models que ho permeten ha d'enviar aquestes peticions per un projecte a part, configurat d'una altra manera.

El tràmit el fa un administrador de l'organització, no de projecte, i per a la via de la Management API cal una clau d'administrador: una clau d'inferència del projecte no serveix. La regió del magatzem ha de casar amb la residència de dades del projecte, i els punts d'entrada són diferents per als projectes globals, els dels Estats Units i els europeus.

Hi ha un detall que convé llegir dues vegades: registrar l'emmagatzematge no canvia per si sol la política de retenció. És la validació la que l'activa, i la consola només aleshores mostra la política de retenció zero de dades amb Private Safety Processing en mode de només lectura.

El magatzem el posa el client, i amb les regles que marca OpenAI

La part que costa diners i feina recau en el client: contractar i configurar el magatzem on van a parar aquests registres. OpenAI admet tres núvols i detalla la configuració de cada un fins al nivell de la política de permisos en format JSON.

El termini és el mateix en els tres: els objectes caduquen als 30 dies. La guia avisa que aquesta caducitat de l'emmagatzematge és independent de la caducitat de la clau de desxifratge que gestiona OpenAI, i que convé comprovar que cap altra regla no esborri els registres abans d'hora. En els projectes globals amb Google Cloud, a més, la configuració s'ha de repetir per cada regió que es pensi fer servir.

En cap dels tres casos no es comparteixen claus: a Azure, OpenAI gestiona les credencials de la seva pròpia aplicació i la guia demana expressament no crear ni compartir una clau del compte d'emmagatzematge, un token SAS ni un secret de client.

«Validat» no vol dir vigilat

La validació comprova la configuració i l'accés, i activa la retenció gestionada pel client per a aquest projecte. Per la Management API, la resposta correcta retorna l'estat validat; per la consola, apareix el rètol corresponent i la política passa a ser de només lectura. Si falla, es corregeix el que s'indiqui i es reintenta.

La guia mateixa posa el límit del que això significa, i és un límit gran: validat registra una comprovació correcta, no la salut contínua de l'emmagatzematge. I el botó de refrescar no torna a validar. La vigilància del dia a dia queda del costat del client, amb les pàgines d'operació i resolució de problemes com a única referència.

És a dir: qui activa això es queda amb la factura del magatzem, l'obligació de mantenir-lo sa i la responsabilitat que la regla de caducitat continuï en peu. En canvi, OpenAI deixa de desar el contingut.

Private Inference arriba a la tardor i es demana per formulari

De la segona peça sí que hi ha termini i hi ha descripció, tot i que curts. OpenAI diu que la seva vista prèvia de Private Inference «arriba aquesta tardor» i que «combina computació confidencial amb controls estrictes i verificables». Computació confidencial és la tècnica que manté les dades xifrades també mentre es processen, i no només quan viatgen o quan estan desades, de manera que ni qui opera la màquina arribi a llegir-les.

El que falta és l'operatiu. No hi ha pàgina de producte, ni guia de configuració com la que acompanya Private Safety Processing, ni llista de models compatibles, ni data concreta dins de la tardor. I no s'activa: qui la vulgui la demana pel formulari d'interès en Private Intelligence.

El cost tampoc no hi és. OpenAI no ha publicat tarifa per a Private Intelligence, ni per a la peça que ja funciona ni per a la que arribarà, i la seva guia de configuració no menciona cap recàrrec per usar retenció zero de dades amb Private Safety Processing. El que sí que està comptabilitzat, tot i que no el facturi OpenAI, és l'emmagatzematge: el bucket o el contenidor els paga el client al seu proveïdor de núvol, amb les seves pròpies tarifes.

Queda un requisit previ que pot valer més que el preu: cal estar aprovat per a retenció zero de dades. Les organitzacions que ja ho estan poden configurar això directament a la consola; les altres passen abans pels requisits d'accés i aprovació que OpenAI publica a la seva guia de dades.