A OpenAI apresentou em 19 de agosto de 2026 uma prévia do Private Safety Processing, abordagem criada para identificar padrões de risco ao longo de várias interações sem dar a funcionários da empresa acesso ao conteúdo subjacente de prompts e respostas. A proposta tenta conciliar duas necessidades que costumam entrar em tensão em projetos corporativos de IA: manter dados sensíveis sob controle do cliente e detectar abusos que só aparecem quando diferentes ações são analisadas em conjunto.
O anúncio não transforma o recurso em uma proteção disponível para qualquer conta. O teste está sendo conduzido com clientes iniciais, enquanto o próprio Zero Data Retention, ou ZDR, permanece sujeito a elegibilidade, aprovação prévia e requisitos adicionais. A OpenAI informou que pretende iniciar a disponibilização do novo processamento e publicar um documento técnico em setembro.
O que foi anunciado
Hoje, os sistemas compatíveis com ZDR avaliam cada interação individualmente. Isso pode ser suficiente para bloquear um pedido explicitamente perigoso, mas tem dificuldade para reconhecer uma sequência em que cada etapa parece comum quando vista isoladamente.
Segundo a publicação oficial da OpenAI, o Private Safety Processing foi desenhado para ampliar essa análise a interações relacionadas. Sistemas automatizados poderiam reconhecer padrões de sondagem repetida de salvaguardas, coordenação entre contas ou ações de um agente que se afastam da intenção declarada pelo usuário.
Quando um risco é identificado, a OpenAI afirma que recebe um sinal limitado sobre o tipo de atividade. O conteúdo que originou o alerta não seria entregue aos funcionários da empresa. Se um cliente precisar contestar uma decisão ou colaborar em uma investigação, poderá escolher quais informações compartilhar.
Como a arquitetura descrita pretende funcionar
A prévia apresenta dois caminhos para o conteúdo usado nessa análise. Em uma implantação ZDR, ele permanece na infraestrutura controlada pelo cliente. Em uma opção ainda em desenvolvimento, o conteúdo poderá ficar em infraestrutura da OpenAI, criptografado com chaves controladas pelo cliente.
Nesse segundo desenho, a OpenAI diz que seus funcionários não terão uma cópia das chaves. Sistemas automatizados processariam o material protegido e retornariam somente sinais de segurança definidos, sem expor prompts e respostas às equipes humanas do fornecedor.
Essa descrição é uma arquitetura anunciada, não uma auditoria independente nem uma garantia de que qualquer integração já cumpre requisitos regulatórios específicos. O documento técnico prometido para setembro será importante para avaliar detalhes como modelo de ameaça, isolamento, gestão de chaves, metadados, registros operacionais, resposta a incidentes e verificações externas.
O que Zero Data Retention significa na API
Na documentação da plataforma, a OpenAI explica que os dados enviados à API não são usados para treinar modelos por padrão, salvo quando o cliente escolhe compartilhá-los. Isso é diferente de retenção operacional. No modo padrão, registros de monitoramento de abuso podem conter conteúdo do cliente e ser mantidos por até 30 dias, salvo exigência legal de prazo maior.
Clientes aprovados para ZDR podem excluir conteúdo de prompts e respostas desses registros. Nos endpoints compatíveis, o parâmetro store das APIs Responses e Chat Completions é tratado como falso, mesmo se a solicitação tentar ativá-lo. A documentação oficial de controles de dados também diferencia registros de abuso de estado persistido pela aplicação.
Essa distinção é essencial. Dizer que uma organização tem ZDR não significa que toda função da plataforma deixa de armazenar qualquer estado em qualquer situação. A compatibilidade depende do endpoint, da ferramenta e do modo de execução escolhido.
Quatro controles que não devem ser confundidos
Não usar dados para treinamento
A política padrão da API informa que o conteúdo do cliente não é usado para treinar ou melhorar os modelos, a menos que a organização escolha participar. Essa regra responde a uma pergunta sobre finalidade de uso. Ela não informa, sozinha, se dados ficam temporariamente em registros de abuso ou se uma ferramenta persiste estado para executar a tarefa.
Zero Data Retention
ZDR trata da exclusão do conteúdo do cliente em registros de monitoramento de abuso e altera o comportamento de endpoints compatíveis. É um controle aprovado para clientes elegíveis, não uma configuração universal disponível automaticamente. A tabela da plataforma precisa ser consultada antes de incluir cada recurso no projeto.
Residência de dados
Residência define em qual região determinadas operações de armazenamento e, em alguns casos, processamento ocorrem. Ela não é sinônimo de ausência de retenção. A própria documentação separa dados do cliente de dados de sistema, como informações de conta, metadados de uso e estatísticas operacionais. Uma equipe pode precisar avaliar ZDR e residência ao mesmo tempo, mas por motivos diferentes.
Chaves controladas pelo cliente
O anúncio descreve uma futura opção de armazenamento na infraestrutura da OpenAI com criptografia baseada em chaves controladas pelo cliente. Isso ajuda a limitar acesso, porém não deve ser apresentado como criptografia de ponta a ponta sem uma especificação técnica que demonstre onde o conteúdo é descriptografado, quais componentes podem processá-lo e quais metadados permanecem visíveis.
Separar esses quatro conceitos evita duas conclusões erradas: acreditar que “não usado para treinamento” significa “nunca armazenado” ou que ZDR cobre automaticamente qualquer ferramenta conectada.
Limitações que precisam entrar no desenho
A documentação atual lista recursos que não são elegíveis para ZDR ou que exigem comportamento diferente. Objetos de conversas, arquivos, assistentes, threads e armazenamentos vetoriais podem manter estado da aplicação. O modo de processamento em segundo plano da Responses API também precisa guardar dados temporariamente para permitir consulta posterior e não é compatível com ZDR.
Há outras fronteiras práticas. O Code Interpreter não pode ser usado quando ZDR está habilitado. Servidores MCP remotos são serviços de terceiros, portanto os dados enviados a eles seguem as políticas de retenção desses provedores. Entradas de imagem e arquivo passam por verificações específicas de segurança, com uma exceção de retenção para possível revisão quando o classificador detecta conteúdo relacionado a abuso sexual infantil.
Por isso, a pergunta correta não é apenas “a conta tem ZDR?”. Uma análise responsável precisa mapear cada endpoint, ferramenta, conector, armazenamento, região, log e sistema de destino usado pelo fluxo completo.
Fatos do anúncio e análise editorial
O que está confirmado pela OpenAI
- O Private Safety Processing está em teste com clientes iniciais.
- A proposta é analisar padrões entre interações relacionadas sem fornecer o conteúdo subjacente a funcionários da OpenAI.
- Implantações ZDR mantêm o conteúdo em infraestrutura controlada pelo cliente.
- Uma opção com armazenamento na infraestrutura da OpenAI e chaves controladas pelo cliente ainda está em desenvolvimento.
- A empresa planeja iniciar a disponibilização e publicar um documento técnico em setembro de 2026.
O que ainda precisa ser demonstrado
- Os detalhes técnicos suficientes para avaliar isolamento, metadados e resistência a falhas.
- O alcance real dos sinais enviados ao fornecedor e como falsos positivos serão tratados.
- Quais clientes, modelos, regiões, endpoints e configurações participarão de cada fase.
- Resultados de avaliações independentes ou evidências públicas de eficácia.
- Compatibilidade com obrigações regulatórias de cada organização e setor.
Por que isso importa para equipes brasileiras
Empresas que trabalham com prontuários, documentos jurídicos, registros financeiros, propriedade intelectual ou dados de clientes precisam limitar acesso, retenção e circulação de informação. Ao mesmo tempo, agentes com acesso a ferramentas podem executar sequências longas, e o risco nem sempre aparece em uma única mensagem.
A prévia aponta para um modelo em que a detecção de padrões não exige que uma equipe do fornecedor leia o material sensível. Se a implementação cumprir o desenho anunciado, isso pode reduzir uma barreira importante para usos controlados de modelos avançados. Mas a promessa não substitui avaliação jurídica, arquitetura de segurança nem contratos adequados.
A Lei Geral de Proteção de Dados exige que cada organização defina finalidade, necessidade, base legal, controles e responsabilidades conforme seu caso. Um recurso técnico do provedor pode apoiar esse trabalho, mas não decide sozinho se um tratamento é legítimo ou seguro.
Perguntas para uma avaliação técnica ou contratação
- Quais endpoints, ferramentas, modelos e regiões do projeto são realmente elegíveis para ZDR?
- Que tipo de sinal de segurança sai do ambiente controlado pelo cliente e por quanto tempo esse sinal é mantido?
- Como contas e interações são relacionadas sem expor conteúdo ou criar identificadores excessivos?
- Quem controla as chaves, como ocorre a rotação e o que acontece após revogação ou perda?
- Como falsos positivos podem ser investigados sem obrigar o cliente a revelar dados desnecessários?
- Quais registros ficam na aplicação, nos conectores, nas ferramentas de observabilidade e nos provedores terceiros?
- Há relatório técnico, auditoria externa, teste de isolamento ou procedimento documentado de resposta a incidentes?
- O contrato descreve responsabilidades, suboperadores, regiões, exclusão, notificações e apoio ao exercício de direitos?
Essas perguntas não presumem que o recurso seja inadequado. Elas transformam uma promessa de arquitetura em requisitos que segurança, privacidade, jurídico e engenharia conseguem verificar em conjunto.
Checklist antes de considerar ZDR em um projeto
- Liste os dados usados. Separe dados pessoais, segredos comerciais, credenciais, documentos regulados e conteúdo público.
- Desenhe o fluxo completo. Inclua aplicação, API, ferramentas, conectores, MCPs, filas, observabilidade, backups e sistemas de destino.
- Confirme a elegibilidade. Verifique se a organização e o projeto foram aprovados para ZDR e quais requisitos adicionais foram aceitos.
- Cheque endpoint por endpoint. Não estenda a compatibilidade de uma API para recursos que persistem estado.
- Controle as chaves. Defina rotação, revogação, segregação de funções e resposta a comprometimento.
- Registre decisões sem registrar conteúdo sensível. Metadados mínimos podem ajudar auditoria, mas também precisam de governança.
- Teste interrupção e abuso. Simule tentativas repetidas, ferramentas fora de escopo e um agente que continua após receber ordem para parar.
- Planeje contestação. Determine quem investiga alertas e quais evidências podem ser compartilhadas com o fornecedor.
Também vale revisar permissões antes de conectar qualquer agente a contas e arquivos. O guia do Bastidores da IA sobre permissões para agentes de IA ajuda a transformar esse cuidado em uma lista operacional. Para projetos com vários clientes, o passo anterior é separar arquivos e contextos antes do primeiro envio.
O ponto central
A OpenAI está propondo uma forma de observar sinais de risco em sequências mais longas sem abrir o conteúdo para revisão humana do fornecedor. É uma direção relevante para ambientes sensíveis, mas ainda está em prévia e depende de controles que não se aplicam automaticamente a toda a plataforma.
Até que o documento técnico e o escopo de disponibilização sejam publicados, a decisão prudente é tratar o Private Safety Processing como arquitetura em avaliação. ZDR continua sendo um controle específico, sujeito a aprovação e compatibilidade por recurso, não um selo geral de privacidade.
Fontes consultadas em 21 de agosto de 2026: anúncio do Private Safety Processing e documentação de controles de dados da API da OpenAI.