OpenAI testa segurança entre interações sem reter dados dos clientes

A OpenAI está a testar uma nova arquitetura de segurança destinada a detetar utilização indevida ao longo de várias interações relacionadas com IA sem exigir que a empresa retenha os prompts dos clientes ou as respostas dos modelos. O sistema, denominado Private Safety Processing, foi apresentado a 19 de agosto para clientes elegíveis da API que utilizam Zero Data Retention, ou ZDR. A OpenAI afirma que a abordagem pretende preservar um compromisso de privacidade importante para organizações reguladas e ambientes sensíveis do ponto de vista de segurança, dando ao mesmo tempo aos sistemas de proteção mais contexto do que uma única interação consegue fornecer.

O momento é relevante porque os modelos frontier estão a ser usados cada vez mais em trabalho prolongado, multi-etapa e agentic. A OpenAI diz que os mecanismos compatíveis com ZDR avaliam atualmente cada interação de forma isolada, o que pode falhar na deteção de padrões prejudiciais que só se tornam visíveis ao longo de uma sequência de ações. No seu anúncio, a empresa aponta como exemplos a tentativa repetida de contornar salvaguardas, atividade coordenada entre contas, ameaças disfarçadas de investigação normal e agentes que continuam a agir depois de receberem instruções para parar.

Com ZDR, os clientes elegíveis da API recebem a garantia de que a OpenAI não retém prompts ou respostas do modelo depois de o pedido ser processado e de que o conteúdo do cliente não fica disponível para revisão por funcionários da empresa. Este modelo é atrativo para organizações que tratam registos financeiros, dados de saúde, investigação proprietária ou outras informações sensíveis, mas cria um compromisso difícil em matéria de segurança. Um fornecedor que não guarda o conteúdo tem menos material disponível para investigações posteriores ou para identificar um padrão distribuído por vários pedidos.

O Private Safety Processing é a tentativa da OpenAI de separar o sinal necessário para enforcement de segurança do conteúdo subjacente do cliente. Nos deployments ZDR, a OpenAI afirma que o conteúdo permanece em infraestrutura controlada pelo cliente. A empresa está também a desenvolver uma segunda opção em que o conteúdo é armazenado na infraestrutura da OpenAI, mas cifrado com chaves controladas pelo cliente. Em ambos os casos, sistemas automatizados deverão identificar possível utilização indevida e devolver à OpenAI um sinal de segurança estritamente definido sem dar aos seus funcionários acesso aos prompts ou respostas.

A OpenAI afirma que estes sinais podem indicar o tipo de atividade envolvida e ser usados para decidir se é necessária alguma medida de enforcement. Se um cliente tiver de investigar um alerta, pode recorrer à informação disponível nos seus próprios sistemas. O cliente também pode escolher partilhar dados relevantes com a OpenAI para contestar uma decisão, explicar uma atividade legítima ou apoiar uma investigação sobre abuso confirmado. Parte da responsabilidade pela prova passa assim para o cliente, o que pode ser uma vantagem para organizações focadas em privacidade, mas cria também uma necessidade operacional de manter registos internos úteis.

A cobertura independente tem-se concentrado nesse compromisso. A Bloomberg noticiou que a OpenAI está a reforçar os processos de segurança para utilizadores pagos dos seus sistemas mais capazes, preservando os compromissos de zero retention para clientes elegíveis. A Computerworld descreveu a arquitetura como uma forma de correlacionar risco ao longo de várias interações preservando a privacidade, mas chamou a atenção para um problema fundamental de verificação: detetar comportamento ao longo do tempo continua a exigir alguma forma de representação persistente, mesmo que seja um sinal derivado em vez de conteúdo legível.

Esta distinção é importante para arquitetos empresariais. O Private Safety Processing não elimina state. Altera o tipo de state que é mantido, onde fica e quem o pode ler. Uma organização que avalie esta arquitetura deve perguntar que sinais são gerados, durante quanto tempo persistem, que eventos podem desencadear enforcement, como esses sinais são relacionados com evidência do lado do cliente e que audit trail fica disponível quando uma decisão é contestada. Sem estes detalhes, seria prematuro tratar o preview como resposta completa à tensão entre privacidade, segurança e accountability.

A arquitetura também pode alterar a forma como incident response deve funcionar. Se os funcionários da OpenAI não conseguem consultar o conteúdo sinalizado, o cliente pode tornar-se o principal detentor do registo forense. As organizações que usam ZDR precisam, por isso, de decidir se os seus application logs, telemetry de segurança e agent traces são suficientes para reconstruir um incidente sem comprometer a razão pela qual escolheram ZDR. A resposta será diferente consoante o setor. Um deployment em saúde, por exemplo, pode precisar de regras de retenção e controlo de acesso diferentes das de um agente de desenvolvimento que trabalha com código proprietário.

Para equipas de governance, a principal lição é que os controlos de privacidade e segurança devem ser desenhados em conjunto, em vez de tratados como duas caixas independentes num processo de procurement. Uma garantia ZDR pode reduzir a exposição de dados sensíveis no lado do fornecedor, mas não elimina a necessidade de controlos do lado do cliente sobre autorização, retenção, investigação e recurso. Da mesma forma, um detector entre interações pode melhorar a capacidade do fornecedor para identificar abuso sem necessariamente dar ao cliente transparência suficiente para explicar um alerta ou demonstrar que um workflow legítimo foi classificado incorretamente.

Existe também uma implicação mais ampla para segurança de agentes. Controlos baseados num único prompt estão cada vez menos alinhados com sistemas que planeiam e executam ações ao longo de muitas etapas. Agentes de longa duração podem acumular autoridade, interagir com ferramentas externas e afastar-se da intenção original do utilizador. A OpenAI cita explicitamente o caso de um agente continuar a atuar depois de lhe ser dito para parar como uma classe de risco que o novo sistema pretende detetar. Isto reforça uma mudança mais ampla da moderação ao nível do prompt para monitoring ao nível da sessão e da ação.

O anúncio deve, ainda assim, ser tratado como um preview e não como um controlo maduro com garantias verificadas de forma independente. A OpenAI afirma que o Private Safety Processing está atualmente a ser testado com clientes iniciais e que pretende começar o rollout em setembro, juntamente com um white paper técnico. A empresa ainda não publicou detalhe suficiente para que terceiros verifiquem como funciona a correlação entre interações, quais são as taxas de falsos positivos, como é implementada a gestão de chaves controladas pelo cliente ou de que forma os sinais de enforcement podem ser auditados de maneira independente.

A OpenAI também assinala uma limitação importante da promessa ZDR. Conteúdo que possa constituir material de abuso sexual de crianças continua sujeito a obrigações legais de reporte, e imagens sinalizadas como potencial CSAM podem ser retidas para revisão manual e comunicação às autoridades mesmo em deployments ZDR. Para compradores empresariais, esta exceção recorda que zero retention é um compromisso de produto e jurídico com limites definidos, e não uma afirmação universal de que nenhuma informação pode ser conservada em circunstância alguma.

A importância prática não é, portanto, que a OpenAI tenha resolvido a monitorização confidencial de segurança. A mudança material é que um fornecedor de modelos frontier está a avançar para uma arquitetura em que a deteção de risco ao longo de várias interações é separada do acesso direto do fornecedor ao conteúdo do cliente. Se o documento técnico de setembro sustentar as afirmações e o controlo tiver comportamento previsível em produção, o Private Safety Processing poderá tornar-se um padrão de arquitetura relevante para deployments de IA regulados. Até lá, arquitetos e equipas de governance devem tratá-lo como um mecanismo promissor de segurança com preservação de privacidade cuja auditabilidade, modos de falha e responsabilidades operacionais ainda precisam de ser testados.