Controles de dados na plataforma da OpenAI

Entenda como a OpenAI usa seus dados e como você pode controlar esse uso.

Seus dados pertencem a você. Desde 1º de março de 2023, os dados enviados à API da OpenAI não são usados para treinar ou aprimorar os modelos da OpenAI (a menos que você opte explicitamente por compartilhar dados conosco).

Tipos de dados armazenados ao usar a API da OpenAI

Ao usar a API da OpenAI, os dados podem ser armazenados como:

• Logs de monitoramento de abuso: Logs gerados a partir do seu uso da plataforma, necessários para que a OpenAI faça cumprir suas Políticas de Uso e contratos e reduza os usos prejudiciais da IA.
• Estado da aplicação: Dados persistidos por alguns recursos da API para executar a tarefa ou atender à solicitação.

Controles de retenção de dados para monitoramento de abuso

Os logs de monitoramento de abuso podem conter determinados conteúdos do cliente, como prompts e respostas, além de metadados derivados desses conteúdos, como saídas de classificadores. Por padrão, os logs de monitoramento de abuso são gerados para todo uso dos recursos da API e retidos por até 30 dias, a menos que uma retenção mais longa seja exigida por lei ou seja razoavelmente necessária para proteger nossos serviços ou terceiros contra danos.

Clientes elegíveis podem ter seu conteúdo excluído desses logs de monitoramento de abuso, respeitadas as limitações abaixo, mediante aprovação para os controles de Zero retenção de dados ou Monitoramento de abuso modificado. Atualmente, esses controles estão sujeitos à aprovação prévia da OpenAI e à aceitação de requisitos adicionais. Clientes aprovados podem escolher entre Monitoramento de abuso modificado e Zero retenção de dados para sua organização ou projeto da API.

Os clientes que ativam o Monitoramento de abuso modificado ou a Zero retenção de dados são responsáveis por garantir que seus usuários sigam as políticas da OpenAI para o uso seguro e responsável da IA e por cumprir quaisquer requisitos de moderação e comunicação previstos na legislação aplicável.

Entre em contato com nossa equipe de vendas para saber mais sobre essas opções e consultar os critérios de elegibilidade.

Monitoramento de abuso modificado

O Monitoramento de abuso modificado exclui o conteúdo do cliente dos logs de monitoramento de abuso em todos os endpoints da API (com exceção de imagens e arquivos de entrada em casos raros, conforme descrito abaixo), sem impedir que o cliente aproveite todas as capacidades da plataforma da OpenAI.

Zero retenção de dados

A Zero retenção de dados exclui o conteúdo do cliente dos logs de monitoramento de abuso da mesma forma que o Monitoramento de abuso modificado.

Além disso, a Zero retenção de dados altera alguns comportamentos dos endpoints: o parâmetro store de /v1/responses e v1/chat/completions sempre será tratado como false, mesmo que a solicitação tente definir o valor como true.

Além dessas alterações específicas de comportamento, os endpoints e as capacidades indicados como Não na coluna Elegível para Zero retenção de dados da tabela abaixo ainda podem armazenar o estado da aplicação, mesmo que a Zero retenção de dados esteja ativada.

Sem revisão humana

Para clientes aprovados para Zero retenção de dados ou Monitoramento de abuso modificado, reservamo-nos o direito de tornar modelos inelegíveis para Zero retenção de dados ou Monitoramento de abuso modificado para clientes específicos, mediante aviso prévio por escrito aos clientes afetados. Nesse caso, o conteúdo do cliente será retido nos logs de monitoramento de abuso, mas não será submetido à revisão humana, a menos que isso seja exigido pela legislação aplicável. Para clientes que tenham firmado o Adendo de Associado Comercial e de Saúde da OpenAI, assim que a opção Sem revisão humana for provisionada para o ID da organização, os endpoints elegíveis para BAA poderão ser usados para processar PHI, mesmo que os dados sejam retidos.

Retenção para segurança

Para clientes aprovados para Zero retenção de dados ou Monitoramento de abuso modificado, reservamo-nos o direito de tornar modelos inelegíveis para Zero retenção de dados ou Monitoramento de abuso modificado para clientes específicos, se isso for razoavelmente necessário para investigar ou prevenir atividades de risco grave, mediante aviso prévio por escrito aos clientes afetados. Nesse caso, poderemos reter e submeter à revisão humana o conteúdo do cliente usado com esses modelos quando nossos classificadores identificarem nesse conteúdo uma possível violação das nossas Políticas de Uso ou do seu contrato. Nos demais casos, a retenção não será afetada. Para clientes que tenham firmado o Adendo de Associado Comercial e de Saúde da OpenAI, assim que a opção Retenção para segurança for provisionada para o ID da organização, os endpoints elegíveis para BAA poderão ser usados para processar PHI, mesmo que os dados sejam retidos.

Configuração dos controles de retenção de dados

Depois que sua organização for aprovada para os controles de retenção de dados, você verá a aba Retenção de dados em Configurações → Organização → Controles de dados. Nessa aba, você pode configurar os controles de retenção de dados tanto no nível da organização quanto no nível do projeto.

• Controles no nível da organização: Escolha entre Zero retenção de dados e Monitoramento de abuso modificado para toda a organização.
• Controles no nível do projeto: Para cada projeto, selecione default para herdar a configuração da organização, escolha explicitamente Zero retenção de dados ou Monitoramento de abuso modificado, ou selecione Nenhum para desativar esses controles no projeto.

Requisitos de armazenamento e controles de retenção por endpoint

A tabela abaixo indica quando o estado da aplicação é armazenado em cada endpoint. Os endpoints elegíveis para Zero retenção de dados não retêm nenhum conteúdo do cliente como estado da aplicação, respeitadas as limitações abaixo. Endpoints ou capacidades inelegíveis para Zero retenção de dados podem reter o estado da aplicação quando usados, mesmo que você tenha ativado a Zero retenção de dados.

/v1/chat/completions

• O estado da aplicação referente às saídas de áudio é armazenado por 1 hora para permitir conversas com múltiplas interações.
• Quando a opção Zero retenção de dados está habilitada para uma organização, o parâmetro store sempre é tratado como false, mesmo que a requisição tente definir o valor como true.
• Consulte imagens e arquivos de entrada.
• O cache de prompts pode armazenar tensores de chave/valor criptografados no armazenamento local das máquinas com GPU como estado da aplicação. Esses dados são armazenados localmente nessas máquinas e não são retidos após o prazo de expiração de 24 horas. Para gpt-5.5 e gpt-5.5-pro, definir prompt_cache_retention como in_memory retorna um erro. Para os modelos GPT-5.6 e famílias de modelos posteriores, prompt_cache_options.ttl controla o tempo mínimo de permanência no cache, não esse período máximo de retenção do estado da aplicação. Para saber mais, consulte o guia de cache de prompts.

/v1/responses

• Exceto nos casos indicados abaixo, a API Responses tem um período de retenção do estado da aplicação de 30 dias por padrão ou quando o parâmetro store é definido como true. Nesses casos, os dados da resposta são armazenados por pelo menos 30 dias.
• Quando a opção Zero retenção de dados está habilitada para uma organização, o parâmetro store sempre é tratado como false, mesmo que a requisição tente definir o valor como true.
• O modo em segundo plano armazena os dados da resposta em disco por cerca de 10 minutos para permitir consultas periódicas. Para projetos que usam o Monitoramento de abuso modificado, incluindo o Monitoramento de abuso modificado aprimorado, as requisições em primeiro plano seguem a retenção padrão quando store é omitido ou definido como true. As respostas em segundo plano seguem o período de retenção padrão somente quando a requisição define explicitamente store=true. Se store for omitido ou definido como false em uma requisição em segundo plano, a resposta será excluída após o período temporário de consultas periódicas.
• O estado da aplicação referente às saídas de áudio é armazenado por 1 hora para permitir conversas com múltiplas interações.
• Consulte imagens e arquivos de entrada.
• Servidores MCP (usados com a ferramenta de servidor MCP remoto) são serviços de terceiros, e os dados enviados a um servidor MCP estão sujeitos às políticas de retenção de dados desse serviço.
• Os contêineres hospedados usados pelo Shell hospedado e pelo Code Interpreter podem gravar estado temporário da aplicação no sistema de arquivos do contêiner (baseado em armazenamento de blocos efêmero) enquanto ele estiver ativo. Os dados do contêiner são excluídos quando ele expira ou é explicitamente excluído.
• O cache de prompts pode armazenar tensores de chave/valor criptografados no armazenamento local das máquinas com GPU como estado da aplicação. Esses dados são armazenados localmente nessas máquinas e não são retidos após o prazo de expiração de 24 horas. Para gpt-5.5 e gpt-5.5-pro, definir prompt_cache_retention como in_memory retorna um erro. Para os modelos GPT-5.6 e famílias de modelos posteriores, prompt_cache_options.ttl controla o tempo mínimo de permanência no cache, não esse período máximo de retenção do estado da aplicação. Para saber mais, consulte o guia de cache de prompts.
• Quando a opção Zero retenção de dados não está habilitada para uma organização, todas as consultas usam o cache estendido de prompts em todos os modelos compatíveis.
• Na compactação do lado do servidor, nenhum dado é retido quando store="false".
• Oferecemos suporte a Habilidades em duas modalidades: execução local e execução em contêineres hospedados. As habilidades hospedadas seguem o mesmo ciclo de vida de contêiner do shell hospedado: as habilidades montadas e os arquivos do contêiner permanecem disponíveis enquanto ele está ativo e são descartados quando ele expira ou é excluído.
• Os dados transmitidos a serviços de terceiros por conexões de rede estão sujeitos às políticas de retenção de dados desses serviços.

/v1/assistants, /v1/threads e /v1/vector_stores

• Os objetos relacionados à API Assistants são excluídos dos nossos servidores 30 dias após você excluí-los pela API ou pelo painel. Os objetos que não forem excluídos pela API ou pelo painel serão retidos por tempo indeterminado.

/v1/images

• A geração de imagens é compatível com a opção Zero retenção de dados ao usar gpt-image-2.5-sunburst, gpt-image-2.5-sunburst-2026-09-08, gpt-image-2.5-flare, gpt-image-2.5-flare-2026-09-08, gpt-image-2, gpt-image-1.5, gpt-image-1 e gpt-image-1-mini.

/v1/files

• Os arquivos podem ser excluídos manualmente pela API ou pelo painel, ou automaticamente ao definir o parâmetro expires_after. Consulte aqui para obter mais informações.

/v1/videos

• A API v1/videos inclui um fluxo de trabalho que salva os dados em disco durante o processamento e os retém por 48 horas para permitir que quem fez a chamada baixe o vídeo produzido e, depois, por 30 dias para monitoramento de abuso. Atualmente, v1/videos está bloqueado para requisições com MAM ou ZDR. Se sua organização tiver controles de retenção de dados habilitados, configure um projeto com a opção de retenção definida como Nenhuma , conforme descrito em Configuração dos controles de retenção de dados, para usar /v1/videos com esse projeto.

Imagens e arquivos de entrada

Imagens e arquivos podem ser enviados como entradas para /v1/responses (inclusive ao usar a ferramenta Uso do computador), /v1/chat/completions e /v1/images. As imagens e os arquivos de entrada são verificados quanto à presença de conteúdo CSAM no momento do envio. Se o classificador detectar possível conteúdo CSAM, a imagem será retida para revisão manual, mesmo que a opção Zero retenção de dados, Monitoramento de abuso modificado ou Eyes Off esteja habilitada.

Pesquisa na Web

A Pesquisa na Web com acesso à internet em tempo real não é elegível para HIPAA e não é coberta por um BAA. A Pesquisa na Web no modo offline/somente cache (external_web_access: false) é elegível para cobertura por um BAA quando usada com uma chave de API de um projeto com ZDR habilitado em uma organização com ZDR. Esta orientação sobre HIPAA/BAA se aplica somente à ferramenta web_search da API Responses. Observação: as variantes de prévia (web_search_preview) ignoram esse parâmetro e se comportam como se external_web_access fosse true. Recomendamos usar web_search.

Controles de residência de dados

Os controles de residência de dados são uma opção de configuração do projeto que permite definir a localização da infraestrutura usada pela OpenAI para fornecer serviços.

Entre em contato com nossa equipe de vendas para verificar se você pode usar os controles de residência de dados. Os endpoints de residência de dados têm um acréscimo de 10% para modelos lançados a partir de 5 de março de 2026 que sejam elegíveis para residência de dados.

Como funciona a residência de dados?

Quando a residência de dados está habilitada na sua conta, você pode escolher uma das regiões disponíveis listadas abaixo para os novos projetos que criar na conta. Se você usar os endpoints, modelos e snapshots compatíveis listados abaixo, seu conteúdo do cliente (conforme definido no contrato de serviços) desse projeto será armazenado em repouso na região selecionada, na medida em que o endpoint exigir persistência de dados para funcionar (como /v1/batches).

Se você selecionar uma região que ofereça suporte ao processamento regional, conforme indicado especificamente abaixo, os serviços também realizarão a inferência do seu Conteúdo do Cliente na região selecionada.

A residência de dados não se aplica aos dados do sistema, que podem ser processados e armazenados fora da região selecionada. Dados do sistema são dados da conta, metadados e dados de uso que não contêm Conteúdo do Cliente e que são coletados pelos serviços e usados para gerenciá-los e operá-los. Entre eles estão informações da conta ou perfis de usuários finais que acessam os serviços diretamente (por exemplo, seus funcionários), análises, estatísticas de uso, informações de cobrança, solicitações de suporte e esquemas de saída estruturada.

Suboperadores e processamento regional de solicitações

A OpenAI usa suboperadores para fornecer seus serviços. Para solicitações enviadas a us.api.openai.com ou eu.api.openai.com, a OpenAI usa o Cloudflare Regional Services para que a terminação TLS e a descriptografia HTTPS ocorram na região de processamento selecionada.

Limitações

A residência de dados não se aplica a: (1) qualquer transmissão ou armazenamento de Conteúdo do Cliente fora da região selecionada causado pela localização de um Usuário Final ou da infraestrutura do Cliente ao acessar os serviços; (2) produtos, serviços ou conteúdo oferecidos por terceiros que não sejam a OpenAI por meio dos Serviços; ou (3) quaisquer dados que não sejam Conteúdo do Cliente, como dados do sistema.

Se a Região selecionada não oferecer suporte ao processamento regional, conforme indicado abaixo, a OpenAI também poderá processar e armazenar temporariamente o Conteúdo do Cliente fora da Região para fornecer os serviços.

Requisitos adicionais para regiões fora dos EUA

Para usar a residência de dados em qualquer região que não seja os Estados Unidos, você precisa ter aprovação para os controles de monitoramento de abuso e assinar um aditivo de Retenção Modificada.

A seleção da região dos Emirados Árabes Unidos exige aprovação adicional. Entre em contato com a equipe de vendas para obter ajuda.

Como usar a residência de dados

A residência de dados é configurada por projeto na sua Organização da API.

Para configurar a residência de dados para armazenamento regional, selecione a região apropriada no menu suspenso ao criar um novo projeto.

Para solicitações a projetos com residência de dados configurada, adicione a cada solicitação o prefixo de domínio definido na tabela abaixo.

Selecione uma região de processamento por solicitação

Como alternativa à criação de um projeto específico para uma região, você pode selecionar o processamento regional para uma solicitação individual usando o domínio com prefixo e uma chave de API de um projeto cuja localização geográfica esteja definida como Global.

Os requisitos existentes de elegibilidade e de controle de retenção de dados continuam válidos. O endpoint e o modelo selecionados também precisam oferecer suporte ao processamento regional, conforme indicado na tabela abaixo.

O exemplo a seguir reutiliza um único cliente e uma chave de API de um projeto Global para solicitações globais, dos EUA e da UE:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28from openai import OpenAI

client = OpenAI()

# No processing constraint.
response = client.responses.create(
    model="gpt-5.6-terra",
    input="Reply with OK.",
)
print(response.output_text)

# US processing and storage.
response = client.with_options(
    base_url="https://us.api.openai.com/v1",
).responses.create(
    model="gpt-5.6-terra",
    input="Reply with OK.",
)
print(response.output_text)

# EU processing and storage.
response = client.with_options(
    base_url="https://eu.api.openai.com/v1",
).responses.create(
    model="gpt-5.6-terra",
    input="Reply with OK.",
)
print(response.output_text)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21require "openai"

client = OpenAI::Client.new

response = client.responses.create(
  model: "gpt-5.6-terra",
  input: "Reply with OK."
)
puts(response.output_text)

response = client.with_options(data_residency: :us).responses.create(
  model: "gpt-5.6-terra",
  input: "Reply with OK."
)
puts(response.output_text)

response = client.with_options(data_residency: :eu).responses.create(
  model: "gpt-5.6-terra",
  input: "Reply with OK."
)
puts(response.output_text)

Quais modelos e recursos são elegíveis para residência de dados?

Os modelos e serviços de API a seguir são atualmente elegíveis para residência de dados nas regiões especificadas abaixo.

Use Suporte por região para comparar as capacidades regionais e expandir a lista de serviços disponíveis em cada região. Use Suporte a endpoints da API, ferramentas e modelos para consultar listas completas de modelos e uma visão detalhada dos serviços. O suporte ao armazenamento regional não implica suporte ao processamento regional.

Limitações dos endpoints

/v1/chat/completions

• Não é possível definir store=true em regiões fora dos EUA.
• O cache estendido de prompts em regiões sem suporte ao processamento regional pode exigir que a OpenAI processe e armazene temporariamente o Conteúdo do Cliente fora da Região para fornecer os serviços.

/v1/responses

• Não é possível definir background=True na região da UE.
• O cache estendido de prompts em regiões sem suporte ao processamento regional pode exigir que a OpenAI processe e armazene temporariamente o Conteúdo do Cliente fora da Região para fornecer os serviços.

/v1/live/sessions

As sessões do GPT-Live são elegíveis para zero retenção de dados. Com a zero retenção de dados habilitada, store é tratado como false, mesmo que uma solicitação o defina como true.

O armazenamento de sessões fica desabilitado por padrão. Em projetos com armazenamento de sessões habilitado, store: true mantém a gravação da sessão concluída por 30 dias para que ela possa ser baixada ou usada para iniciar uma sessão derivada de um fork. As sessões armazenadas e seu índice expiram após 30 dias. O download de gravações e a criação de forks exigem uma política de dados que permita a persistência e não estão disponíveis com zero retenção de dados.

Definir store: false em um fork impede o armazenamento da nova sessão; isso não exclui a gravação de origem nem elimina a autorização necessária para lê-la. A API não oferece um endpoint público para excluir sessões armazenadas.

O GPT-Live oferece suporte à residência de dados nos Estados Unidos e na Europa. Os modelos e as ferramentas de backend acionados por delegação têm seus próprios controles de dados; consulte as entradas dos endpoints e recursos aplicáveis nesta página.

/v1/realtime

Atualmente, o rastreamento em /v1/realtime não atende aos requisitos de residência de dados da UE.

Gerenciamento de chaves empresariais (EKM)

O gerenciamento de chaves empresariais (EKM) permite criptografar seu conteúdo de cliente na OpenAI usando chaves gerenciadas pelo seu próprio sistema externo de gerenciamento de chaves (KMS).

Após a configuração, o EKM se aplica a qualquer estado da aplicação criado durante o uso da plataforma. Consulte o artigo sobre EKM na Central de Ajuda para saber mais sobre como o EKM funciona e como integrá-lo ao seu provedor de KMS.

Limitações do EKM

A OpenAI oferece suporte à criptografia com sua própria chave (BYOK) usando contas externas no AWS KMS, no Google Cloud (GCP) e no Azure Key Vault. Se sua organização usa outro serviço de gerenciamento de chaves, essas chaves precisam ser sincronizadas com um dos provedores de KMS na nuvem compatíveis para uso com a OpenAI.

O EKM não oferece suporte aos produtos a seguir. Uma tentativa de usar estes endpoints em um projeto com EKM ativado retornará um erro.

• Assistants (/v1/assistants)
• Ajuste fino de visão