EU data residency no GPT-6 Sol só com Standard processing: o que isso limita no seu projeto?

diagrama mostrando GPT-6 Sol EU data residency restrita ao Standard processing na API Platform
Resposta rápida

A documentação da OpenAI é direta: nos modelos GPT-6 (Astra, Sol e Luna), a residência de dados na UE está disponível apenas com Standard processing. Na prática, quem precisa de EU data residency no GPT-6 Sol perde Batch e Flex (que custam metade da tarifa) e também o Fast mode, e ainda soma o acréscimo de 10% dos endpoints de processamento regional para modelos lançados a partir de 05/03/2026. A configuração sai de um Project novo no dashboard da API Platform com a região escolhida, com tráfego por eu.api.openai.com, e exige aprovação em abuse monitoring mais o aditivo de Modified Retention

Fala aí, beleza? A OpenAI colocou uma frase curtinha na doc do GPT-6 Sol que muda arquitetura inteira: EU data residency available only with Standard processing

Ou seja: se o seu requisito é processar na Europa, você não escolhe modo de processamento, você fica com o Standard e pronto

Isso não é detalhe de rodapé pra quem atende cliente europeu ou tem cláusula contratual de residência de dados assinada. É decisão de custo, de pipeline e de prazo, e precisa ser tomada ANTES de subir o modelo em produção, não depois que o time de compliance do cliente pedir o desenho da arquitetura 🙂

O que é o GPT-6 Sol e onde a restrição aparece

O GPT-6 Sol foi lançado em 16 de setembro de 2026, com o id de API gpt-6-sol, e também chegou ao ChatGPT Work e ao Codex

As specs que estão na página do modelo já dão o tom de pra que ele foi feito:

  • janela de contexto de 1.050.000 tokens
  • máximo de 128.000 tokens de saída
  • knowledge cutoff em 30 de abril de 2026

Contexto de mais de 1 milhão de tokens é exatamente o tipo de coisa que gente usa pra jogar base de conhecimento inteira dentro do prompt, e aí a pergunta "onde esses dados são processados?" deixa de ser teórica

E é aí que entra o aviso. A mesma restrição aparece em dois lugares: na documentação do modelo e na página viva de preços da API, na linha do gpt-6-sol

O texto é o mesmo nos dois: para GPT-6 Astra, Sol e Luna, a residência de dados na UE está disponível apenas com Standard processing

Quando a mesma frase aparece na doc do modelo E na tabela de preços, ela não é ressalva esquecida, é regra de produto

Formação Claude Code
Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

  • 120 aulas
  • 4 projetos
  • 9h 45min

O que muda no seu projeto: os modos de processamento que você perde

Aqui mora o impacto real. A OpenAI tem modos de processamento com preço diferente, e a relação entre eles é simples:

  • Batch e Flex: 50% da tarifa Standard
  • Fast mode (que era o antigo Priority processing, renomeado em 30/07/2026): 2x as tarifas aplicáveis
  • Standard: a tarifa de referência

Se o requisito é residência na UE nesses modelos, sobra só o Standard

Traduzindo pro seu backlog: aquele pipeline noturno de classificação em massa que você ia rodar em Batch pela metade do preço? Não é uma opção nessa configuração

E não é só perder o desconto. Você perde também o MODELO MENTAL do processamento assíncrono barato, que é o jeito clássico de fazer volume grande caber no orçamento. Reprocessar histórico, enriquecer base, gerar embeddings de arquivo antigo, tudo isso costuma ser desenhado em cima de Batch

Do outro lado, também não dá pra comprar latência: Fast mode está fora da mesa do mesmo jeito

E tem o acréscimo. Endpoints de processamento regional têm uplift de 10% sobre a tarifa para modelos lançados em ou após 5 de março de 2026 que sejam elegíveis a residência de dados. O Sol saiu em setembro de 2026, então cai direto nessa regra

Resumo grosso: você perde a via barata e ainda paga a mais pela via que sobrou

Quanto custa rodar o GPT-6 Sol com residência na UE

As tarifas padrão do gpt-6-sol na API, em contexto curto e Standard processing, são estas:

Item Tarifa Standard (por 1M de tokens)
Entrada US$ 2,00
Entrada cacheada US$ 0,20
Saída US$ 10,00

Em cima disso entra o uplift de 10% do endpoint regional

Um aviso honesto antes de você levar número pra reunião: a OpenAI publica a regra do acréscimo, não uma tabela pronta com o preço europeu já calculado. Então trate o resultado como estimativa aritmética e confira na fatura real, beleza?

Aplicando a regra na mão é aquilo mesmo: pega a tarifa Standard da linha e soma 10% em cima. Nada exótico, mas em projeto de volume 10% é a diferença entre caber e não caber

E tem os multiplicadores que continuam valendo por cima de tudo isso:

  • Prompt acima de 272 mil tokens de entrada: a requisição INTEIRA passa a ser cobrada com 2x nas tarifas de entrada e de cache e 1,5x na saída
  • Cache read: 10% da tarifa de entrada não cacheada
  • Cache write: 1,25x da tarifa de entrada não cacheada

Olha o detalhe sacana do primeiro item: é a requisição inteira, não só o excedente. Você tem 1.050.000 tokens de janela disponíveis, mas passar de 272K muda a conta do request todo

Quem tem tendência a "joga tudo no contexto que a IA resolve" vai sentir isso na fatura…

Esse tipo de raciocínio de orçamento, aliás, é o mesmo que vale pra comparar modelos dentro da própria família: dá pra ler sobre custo por tarefa resolvida no GPT-6 Astra pra entender por que preço por token isolado engana

Como a residência de dados é configurada na API da OpenAI

A parte operacional é curta, mas tem uma pegadinha que derruba gente no primeiro dia. Vamos por partes

  1. Confirme a elegibilidade antes de escrever qualquer linha de código. Para usar residência de dados em qualquer região fora dos Estados Unidos é preciso ser aprovado nos controles de abuse monitoring e assinar um aditivo de Modified Retention, e a elegibilidade é verificada com o time de vendas. Erro comum deste passo: tratar isso como detalhe jurídico pra resolver depois. É pré-requisito técnico, sem ele a rota europeia não existe pra você
  1. Se o caminho for projeto regional, crie um NOVO Project no dashboard da API Platform e selecione a região. É assim que a região fica amarrada ao projeto, segundo o artigo de ajuda da OpenAI sobre data residency. Erro comum deste passo: achar que o projeto que você já usa vai herdar a região depois de mexer numa configuração. A definição não é retroativa a projetos existentes, então o projeto que já roda hoje não vira europeu por ajuste de flag (e se você não quer criar projeto regional, olha o passo 4)
  1. Aponte o tráfego europeu para o endpoint certo. O tráfego de API com residência na Europa usa eu.api.openai.com. Se o seu client continua batendo no host global, não adianta o projeto estar marcado como europeu no painel
  1. Ou use o processamento regional por requisição. Existe a alternativa de selecionar processamento regional por request usando o domínio prefixado, com uma chave de API de um projeto de geografia Global. Serve bem pra quem tem um sistema só atendendo clientes de geografias diferentes e não quer duplicar toda a infra de credenciais
  1. Fixe o modo Standard e o id do modelo. É gpt-6-sol em Standard, sem Batch, sem Flex, sem Fast. Erro comum deste passo: deixar um fallback no código que, sob pressão de fila, chaveia pro modo assíncrono barato. Nessa configuração isso não é degradação elegante, é sair do requisito contratual
  1. Cheque a lista de endpoints e snapshots suportados. A cobertura regional vale para os endpoints, modelos e snapshots listados na documentação. Confira os seus contra essa lista antes de prometer qualquer coisa

O que a residência de dados cobre (e o que ela não cobre)

Essa seção é a que você vai copiar pra responder auditoria, então vou ser bem literal com o que está documentado no guia de dados da OpenAI

O que está dentro do escopo:

  • Requisições feitas por projetos com residência de dados configurada são tratadas em região com zero data retention, ou seja, requisições e respostas do modelo não ficam armazenadas em repouso nos servidores da OpenAI
  • Para requisições enviadas a us.api.openai.com ou eu.api.openai.com, a OpenAI usa Cloudflare Regional Services para que a terminação TLS e a descriptografia HTTPS aconteçam dentro da região escolhida
  • O conteúdo do cliente fica armazenado em repouso na região escolhida na medida em que o endpoint exija persistência pra funcionar (o caso de /v1/batches)

Esse ponto do TLS é mais importante do que parece. Não é só "onde o modelo roda", é onde o pacote é DESCRIPTOGRAFADO. Auditor gosta dessa distinção

O que está fora do escopo:

  • System data: a residência de dados não se aplica a ele, e esse dado pode ser processado e armazenado fora da região selecionada
  • Agents API: suporta residência de dados apenas nos Estados Unidos e não suporta Zero Data Retention
  • Cobertura por lista: a regionalização vale para os endpoints, modelos e snapshots listados na documentação, e não como uma promessa geral "toda a API roda na Europa"

O item da Agents API merece um destaque em CAIXA ALTA no seu documento interno. Se a sua aplicação é um agente e o requisito é UE, essa rota específica não te atende, e descobrir isso depois do contrato assinado é ruim demais

Decisões de arquitetura antes de subir em produção

Agora a parte que vira tarefa no board. A restrição de Standard processing não é um flag que você liga no deploy, ela empurra escolhas lá no começo

Separe projetos por geografia desde o dia zero. Como a configuração de região não é retroativa, o custo de "depois a gente separa" é migrar credencial, reconfigurar client e revalidar tudo. Nasce separado ou nasce com dívida

Decida entre projeto regional e domínio prefixado por requisição. Projeto regional é mais simples de auditar porque a geografia é do projeto. O domínio prefixado, com API key de projeto Global, dá flexibilidade por request pra quem serve clientes de várias geografias com a mesma aplicação. Os dois estão documentados, a escolha é sua e é arquitetural

Não desenhe pipeline assíncrono em cima de Batch ou Flex se o requisito é UE. Vale repetir porque é o tropeço mais caro: você pode montar uma arquitetura linda de fila e processamento em lote e descobrir tarde que ela não é compatível com a exigência de residência

Confira endpoints e snapshots contra a lista suportada. Vector store, arquivos, conversas, o que a sua app usa precisa estar coberto, não basta o modelo estar

E tem duas decisões de API que mexem direto no custo e no comportamento:

  • A OpenAI recomenda a Responses API para ferramentas nativas e function calling no GPT-6 Sol. Em Chat Completions, o function calling só funciona com reasoning_effort definido como none
  • O parâmetro reasoning.effort aceita none, low, medium (que é o padrão), high, xhigh e max

Por que isso entra numa conversa de residência de dados? Porque esforço de raciocínio mexe no volume de saída, e saída é o token caro (US$ 10,00 por 1M na tarifa Standard, mais o uplift regional)

Se você já está pagando 10% a mais e sem acesso ao modo barato, calibrar o effort deixa de ser ajuste fino e vira controle de orçamento

E se o seu plano B era "deixo o agente rodando em max e revejo depois", se liga: revise antes 😛

OpenAI API x Microsoft Foundry: onde o GPT-6 Sol atende a UE

Existe uma segunda rota pra quem precisa de processamento na Europa: o GPT-6 Sol também está disponível no Microsoft Foundry

Aspecto API da OpenAI Microsoft Foundry
Como a Europa é atendida Projeto com região selecionada, tráfego por eu.api.openai.com Deployment Standard em Data Zone da UE
Modo de processamento com UE Somente Standard processing (GPT-6 Astra, Sol e Luna) Standard em Global e nas Data Zones dos EUA e da UE
Capacidade dedicada Não documentada nos fatos desta página Provisioned Throughput em Global e nas Data Zones dos EUA e da UE
Modo prioritário Fast mode não disponível com residência na UE Priority Processing apenas em Global e US Data Zone
Onde o conteúdo é processado Região selecionada, com TLS terminado na região via Cloudflare Regional Services Em Data Zone, prompts e respostas processados dentro da zona especificada (conteúdo da UE dentro de um país membro)
Retenção Zero data retention nas requisições de projetos com residência configurada Não coberto pelos dados desta página
Pré-requisitos Aprovação em abuse monitoring, aditivo de Modified Retention e verificação com vendas Não coberto pelos dados desta página

O padrão se repete nas duas rotas: o modo prioritário some quando você pede Europa

Na API é o Fast mode que não entra na configuração com residência na UE. No Foundry, o Priority Processing existe em Global e US Data Zone, mas não aparece na EU Data Zone pro Sol

E tem o contraste mais importante do Foundry pra quem lê contrato: em deployment do tipo Data Zone, armazenamento e processamento ficam na geografia selecionada, enquanto o Global Standard pode rotear fora da região. Escolher o tipo de deployment errado no portal é o equivalente, do lado Azure, a esquecer de trocar o host pro eu.api.openai.com

Detalhe: o preço no Foundry e quais regiões Azure exatamente formam a EU Data Zone pro Sol não estão nos dados que usei aqui, então não vou chutar

Vídeo: GPT-5.6 Sol frente a Kimi K3 e Fable 5

Pra quem está chegando agora na família Sol e quer contexto antes de mergulhar na parte de residência de dados, o canal tem um comparativo de modelos direto ao ponto

É o "Kimi K3 x GPT-5.6 Sol x Fable 5: o teste que decide quem é o melhor (IMPRESSIONANTE)", com os modelos colocados lado a lado

Conclusão

O recado da documentação é curto e tem consequência longa: com residência de dados na UE, o GPT-6 Sol roda só em Standard processing

Sem Batch, sem Flex, sem Fast mode nessa configuração, e com o acréscimo de 10% do endpoint de processamento regional por cima das tarifas (US$ 2,00 por 1M de entrada, US$ 0,20 por 1M de entrada cacheada e US$ 10,00 por 1M de saída), ainda sujeito aos multiplicadores de contexto grande e de cache

O próximo passo prático é bem objetivo: mapeie os endpoints e snapshots que a sua aplicação usa contra a lista suportada na documentação, confirme se a Agents API está no caminho (porque residência ali só existe nos EUA e sem ZDR), e abra a conversa de elegibilidade (abuse monitoring e aditivo de Modified Retention) com antecedência

Fazer isso ANTES de prometer prazo ao cliente europeu é a diferença entre entregar e remontar a arquitetura no meio do projeto

até o próximo post! =)

Perguntas frequentes

Dá pra usar Batch processing com residência de dados na UE no GPT-6 Sol?

Não. A documentação da OpenAI afirma que, para GPT-6 Astra, Sol e Luna, a residência de dados na UE está disponível apenas com Standard processing. Isso deixa Batch, Flex e Fast mode fora da mesa quando o requisito é processar na Europa.

O acréscimo de 10% nos endpoints regionais vale pra qualquer modelo da OpenAI?

Não, ele se aplica a modelos lançados em ou após 5 de março de 2026 que sejam elegíveis a residência de dados. O GPT-6 Sol, lançado em 16 de setembro de 2026, entra direto nessa regra.

A Agents API suporta residência de dados na Europa?

Não. A Agents API suporta residência de dados apenas nos Estados Unidos e não suporta Zero Data Retention. Quem precisa de residência europeia com ZDR tem que ficar nos endpoints de API tradicionais elegíveis pra isso.

O que acontece se um prompt no GPT-6 Sol passar de 272 mil tokens de entrada?

A requisição inteira passa a ser cobrada com multiplicador: 2x nas tarifas de entrada e de cache, e 1,5x na tarifa de saída. Não é só o excedente que sobe de preço, é o request todo, mesmo com a janela de 1.050.000 tokens disponível.

O system data também fica retido dentro da região europeia escolhida?

Não. A residência de dados não se aplica a system data, que pode ser processado e armazenado fora da região selecionada. O escopo da residência cobre requisições e respostas do modelo, não todo tipo de dado do sistema.

Preciso migrar meu projeto atual pra ativar EU data residency no GPT-6 Sol?

Se o caminho escolhido for um projeto com região configurada, sim: é preciso criar um novo Project no dashboard da API Platform e selecionar a região, porque a configuração não é retroativa a projetos existentes. Mas existe a alternativa documentada de selecionar processamento regional por requisição, usando o domínio prefixado com uma chave de API de um projeto de geografia Global.




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min

Blog | Mais populares