O Zero Data Retention deixou a OpenAI cega para abusos em várias etapas

A OpenAI criou o Zero Data Retention para que os clientes elegíveis da API pudessem impedir a empresa de guardar os seus prompts ou respostas do modelo depois de um pedido ser processado, e essa promessa mantém-se hoje: sem revisão por parte do pessoal da OpenAI e sem utilização para treino sem consentimento explícito. O custo dessa promessa aparece do lado da segurança. No anúncio de 19 de agosto de 2026, a OpenAI reconhece abertamente que, à medida que os modelos assumem tarefas agênticas mais longas e complexas, os comportamentos mais perigosos - um agente malicioso que testa as proteções, se coordena entre várias contas, disfarça um ataque como investigação legítima, ou um agente que continua a agir depois de lhe ser dito para parar - só se tornam visíveis ao observar várias interações em conjunto, nunca dentro de uma única.

As verificações de segurança compatíveis com ZDR existentes avaliavam cada interação isoladamente, pelo que não conseguiam captar esse padrão por conceção. A OpenAI vai mais longe, referindo que "algumas implementações recentes de modelos de fronteira exigiram que os clientes permitissem ao seu fornecedor de IA guardar conteúdo sensível para monitorização de segurança" - uma farpa direta, ainda que sem nomear, a concorrentes que resolveram isto guardando mais dados, não menos. Para um banco, um grupo hospitalar ou uma sociedade de advogados sujeitos a obrigações rigorosas de tratamento de dados, essa cedência nunca foi aceitável, e é exatamente essa lacuna que o Private Safety Processing diz querer fechar.

A solução move as verificações de segurança para trás das chaves do cliente

O Private Safety Processing, ainda em pré-visualização a 19 de agosto de 2026, alarga as verificações de segurança de interação única da OpenAI para detetar padrões em interações relacionadas, sem dar ao pessoal da OpenAI acesso ao conteúdo subjacente do cliente. O mecanismo funciona de duas formas, consoante onde o conteúdo reside. Se estiver na infraestrutura do próprio cliente, num verdadeiro modelo ZDR, a OpenAI nunca lhe toca. Se estiver em armazenamento fornecido pela OpenAI, o conteúdo é encriptado com chaves que o cliente controla, e o pessoal da OpenAI simplesmente não possui essas chaves.

Quando o sistema deteta um risco, a OpenAI não recebe o prompt sinalizado, a resposta nem o raciocínio por trás do alerta. A empresa recebe apenas, nas suas próprias palavras, "um sinal estritamente definido que indica o tipo de atividade envolvida" - suficiente para decidir se é necessária uma ação, mas não suficiente para ler o que realmente aconteceu. Os clientes podem investigar qualquer alerta ou ação com os seus próprios sistemas, e podem optar por partilhar voluntariamente mais informação com a OpenAI apenas se quiserem recorrer de uma decisão ou apoiar uma investigação - a divulgação mantém-se voluntária do lado do cliente, nunca automática por parte da OpenAI.

Glean, Databricks, Abridge e Microsoft já testam o sistema

Quatro organizações identificadas já testam o Private Safety Processing antes de um lançamento mais alargado: Glean, Databricks, Abridge e Microsoft. Sunil Agrawal, Chief Information Security Officer da Glean, deu a OpenAI o apoio público mais firme até agora: "Enterprise AI adoption depends solely on customer control of data, with no direct or derivative use beyond the chosen service. OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI. As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust." Trata-se de um cliente empresarial a defender publicamente um sistema que ainda não foi lançado.

Uma exceção mantém-se em qualquer versão deste modelo: a OpenAI é legalmente obrigada a denunciar material presumivelmente de abuso sexual infantil, pelo que as imagens sinalizadas por possível CSAM continuam a ser guardadas para revisão manual e denúncia mesmo em implementações ZDR, exatamente como acontece hoje. O Private Safety Processing não toca nessa exceção. A OpenAI diz que o lançamento geral, juntamente com um white paper técnico que explica o mecanismo com mais profundidade, está previsto para setembro de 2026 - o que sair para o mercado no próximo mês, ainda moldado entretanto pelo feedback dos clientes, pode diferir do que está a ser testado agora.

O white paper de setembro é o verdadeiro teste, não este anúncio

Ninguém fora da OpenAI verificou de forma independente as alegações sobre encriptação e controlo de chaves por trás do Private Safety Processing, e essa é exatamente a lacuna que uma equipa de compliance no Reino Unido ou na UE deve manter em aberto até setembro. O "sinal estritamente definido" que a OpenAI descreve é, por conceção, opaco para o cliente que o recebe - útil para decidir se deve agir sobre um alerta, mas não suficientemente detalhado para satisfazer uma revisão ao abrigo do artigo 28 do RGPD ou um auditor que pergunte exatamente o que foi inferido do conteúdo encriptado e como. Até chegar o prometido white paper técnico, a resposta honesta a "conseguimos verificar isto" continua a ser não, ainda não.

O anúncio surge três dias depois de a diretora financeira da OpenAI ter falado numa possível oferta pública inicial em 2027, e poucos dias depois de o ChatGPT Ads se ter expandido para a Europa; em conjunto, o padrão mostra uma OpenAI a cortejar visivelmente a confiança de setores regulados antes de um crescimento comercial em maior escala. Isso não transforma o Private Safety Processing num mero exercício de marketing - a lista de clientes e o mecanismo são reais -, mas significa que o ónus da prova recai sobre o white paper técnico, não sobre este anúncio. Qualquer alegação de "zero data retention" de um fornecedor deve agora ser lida com uma pergunta adicional: como, exatamente, gere a monitorização de segurança entre sessões.

Leia a seguir: A receita empresarial da OpenAI já ultrapassa a de consumo  |  IBM aposta a sua consultoria num só fornecedor de IA