A OpenAI passou a oferecer Zero Data Retention, ou ZDR, para clientes elegíveis da API que usam seus modelos de fronteira. A modalidade estabelece que prompts e respostas não sejam retidos pela empresa depois do processamento e que o conteúdo do cliente não fique disponível para revisão por funcionários.1
A mudança atende organizações que não podiam colocar dados sensíveis em fluxos de IA por causa de requisitos de retenção. Ela também exige uma leitura técnica cuidadosa. ZDR não significa que nenhuma informação seja processada, não cobre automaticamente todos os recursos de uma plataforma e não apaga os registros mantidos pela própria aplicação.
Retenção zero precisa ser verificada por endpoint
Na configuração padrão da API, logs de monitoramento de abuso podem conter conteúdo do cliente e permanecer por até 30 dias. Clientes aprovados podem excluir esse conteúdo por meio de ZDR ou de Modified Abuse Monitoring, sujeitos a requisitos adicionais.2
O comportamento varia entre endpoints. Em /v1/responses e /v1/chat/completions, ZDR força store para false. Já conversas persistentes, threads, vector stores e outros recursos podem guardar estado até que o objeto seja excluído e não aparecem como elegíveis na tabela de retenção zero. A decisão arquitetural precisa olhar a capacidade usada, não apenas o modelo selecionado.
Ferramentas conectadas também mudam o limite. Dados enviados a um servidor MCP remoto ou a outro serviço seguem a política de retenção desse terceiro. Um contrato ZDR com o provedor do modelo não controla automaticamente o destino de uma busca, um CRM, uma ferramenta de suporte ou um banco vetorial externo.
O mapa de dados começa antes do modelo
Uma requisição de IA normalmente atravessa mais componentes do que a chamada ao provedor. O navegador pode registrar erros; o backend pode gravar payloads; uma fila pode manter a tarefa; ferramentas de observabilidade podem capturar atributos; e o histórico pode ser salvo para reconstruir a conversa.
Por isso, a análise deve acompanhar o dado desde a origem. Quais campos entram no prompt? Onde são montados? Existe cache? O conteúdo aparece em logs, traces ou mensagens de erro? Quais ferramentas recebem uma cópia? Por quanto tempo cada sistema conserva a informação? Quem consegue acessá-la?
Sem esse inventário, ZDR pode proteger apenas um trecho de uma cadeia que continua armazenando o mesmo conteúdo em vários lugares. O controle real combina minimização, classificação, prazo de descarte e acesso restrito em toda a aplicação.
Não usar para treinamento é uma garantia diferente
A OpenAI declara que dados empresariais não são usados para treinar seus modelos por padrão. Essa política responde a uma pergunta: se o conteúdo será incorporado ao treinamento. Retenção responde a outra: se ele permanece armazenado para estado da aplicação, segurança, suporte ou obrigação legal.3
As duas garantias são relevantes, mas não intercambiáveis. Uma empresa pode aceitar processamento sem treinamento e ainda não aceitar armazenamento por 30 dias. Outra pode precisar preservar um histórico auditável no próprio ambiente, mesmo quando o provedor não mantém uma cópia.
O requisito deve ser escrito de forma verificável. Em vez de pedir apenas que o fornecedor não use os dados, o contrato e a arquitetura precisam definir finalidade, localização, duração, acesso humano, subprocessadores, exceções e evidências de exclusão.
Privacidade e segurança precisam operar juntas
Sistemas de segurança costumam analisar sequências de interações para reconhecer abuso que não aparece em uma mensagem isolada. A OpenAI apresentou o Private Safety Processing como uma forma de detectar padrões entre interações sem entregar o conteúdo subjacente para revisão humana. A prévia prevê processamento em infraestrutura controlada pelo cliente ou armazenamento criptografado com chaves sob controle do cliente.1
Esse desenho mostra que privacidade não elimina a necessidade de monitoramento. O desafio é produzir sinais suficientes para detectar risco sem criar uma cópia ampla e indefinida do conteúdo. Para a aplicação contratante, a mesma lógica vale: registrar categoria do evento, resultado, identidade técnica e decisão pode ser mais adequado do que colocar o prompt completo em todos os logs.
Exceções também precisam entrar na avaliação. A documentação prevê limitações por capacidade e retenções exigidas em situações específicas. Uma promessa comercial resumida nunca deve substituir a matriz de recursos e as condições vigentes para a organização.
A aplicação continua responsável pelo próprio histórico
Ao desativar armazenamento no provedor, o produto pode perder facilidades de continuidade de conversa e depuração. Se esse estado é necessário, a empresa precisa mantê-lo em ambiente próprio com criptografia, controle de acesso, prazo de expiração e exclusão por usuário ou contrato.
Esse histórico não deve nascer como um espelho irrestrito. É melhor separar mensagem original, resumo operacional, artefatos gerados e metadados de auditoria. Cada categoria recebe um prazo e uma permissão compatíveis com sua finalidade.
Testes precisam confirmar o comportamento. A equipe deve inspecionar configurações por projeto, exercitar endpoints e ferramentas, verificar observabilidade e simular exclusão. Mudanças de modelo, modo de processamento ou integração devem disparar nova revisão, porque podem alterar a elegibilidade de retenção.
ZDR vira requisito de arquitetura, não selo de compra
Zero Data Retention reduz uma barreira importante para IA em finanças, saúde, jurídico, pesquisa e operações confidenciais. O benefício aparece quando a organização traduz a oferta em controles concretos: classifica dados, escolhe endpoints compatíveis, evita ferramentas que ampliam retenção, limita logs e mantém o estado necessário sob sua governança.
A pergunta correta não é apenas se o provedor oferece ZDR. É quais dados ainda existem depois que a tarefa termina, em qual sistema, por qual motivo e sob o controle de quem. Essa resposta completa é o que transforma uma cláusula de privacidade em arquitetura operacional.
- OpenAI, "Offering Zero Data Retention for frontier models", 19 ago. 2026. ↩
- OpenAI, "Data controls in the OpenAI platform", acesso em 19 ago. 2026. ↩
- OpenAI, "Enterprise privacy at OpenAI", acesso em 19 ago. 2026. ↩