API Gemini armazena requisições por padrão: como definir store=false por requisição e por projeto

Contexto: o que mudou para novos projetos pagos do Gemini

Desde 26 de outubro de 2026, novos projetos pagos da API Gemini armazenam por padrão os prompts e as respostas do Generate Content. Projetos criados antes dessa data mantêm o armazenamento desativado. Dois projetos na mesma organização, executando código idêntico, podem se comportar de forma diferente apenas por causa da data em que foram criados.

Nada no seu código ou nos seus logs de erro indica que o registro está ativado, e é por isso que isso passa despercebido. Se esses prompts carregam dados de clientes, o responsável pela proteção de dados vai querer saber, de preferência por você, junto com um relato honesto do que ainda não se sabe. A nota de lançamento não explica por que o Google mudou o padrão, não define o corte exato para novos projetos e não diz se a mudança será estendida depois aos projetos existentes. Planeje para a divisão atual e presuma que ela pode mudar.

Ninguém vazou nada aqui; um padrão mudou. O registro de logs é um recurso documentado, com usos reais para depuração e avaliação, então o trabalho consiste em saber quais projetos o têm ativado e por quê.

O que o Google guarda e por quanto tempo

O período de retenção padrão dos logs é de 55 dias; depois disso, os logs expiram e são marcados para exclusão. Os proprietários do projeto podem reduzir essa janela para 7, 14 ou 28 dias.

Os datasets precisam de atenção separada, porque seguem regras diferentes. Logs salvos em um dataset não têm período de retenção e permanecem até que alguém os exclua. Os datasets podem ser exportados como CSV, JSONL ou para o Google Sheets, o que os torna úteis para trabalhos de avaliação. Essas exportações significam que cópias podem acabar fora do projeto se ninguém as acompanhar.

Por padrão, prompts e respostas nos logs de projetos com faturamento ativado não são usados para melhorar ou desenvolver os produtos do Google. O Contributor Tier, abordado nas ressalvas abaixo, é a exceção que merece atenção.

Alguns modelos e entradas não têm suporte a registro de logs. O resumo da BaristaLabs sobre o guia do Google lista os modelos Imagen e Veo, os modelos de embedding do Gemini, o modelo Gemini Robotics, entradas que contêm vídeos, GIFs ou PDFs e agentes em prévia pública.

O grounding é um caminho de retenção totalmente separado. Os dados de grounding com a Pesquisa Google e de grounding com o Google Maps são retidos por 30 dias, e essa retenção não pode ser desativada.

Fase 1 (Audit): inventário de projetos, SDKs e responsáveis pelos dados

Comece com uma lista de todos os projetos pagos da API Gemini que sua organização possui, com a data de criação de cada um. Trate qualquer projeto criado a partir de 26 de outubro de 2026 como se estivesse armazenando requisições até confirmar o contrário.

Para cada serviço dessa lista, registre a linguagem do SDK e a versão instalada no ambiente em execução, já que um README ou um arquivo de requirements antigo pode estar desatualizado em relação ao que está de fato implantado. Você só consegue definir store em uma requisição se o SDK oferecer suporte, e as versões mínimas variam por linguagem.

Serviços que também acessam o Vertex AI merecem uma linha separada no inventário. As notas de lançamento de Python e de JavaScript identificam a opção store como "somente Gemini Developer API". Se alguns serviços chamam o Vertex AI pelo mesmo SDK, não presuma que este guia os cobre. Revise a documentação de governança de dados do Vertex AI no Google Cloud para esses serviços e registre essa decisão ao lado dos seus projetos da Gemini Developer API.

Depois de saber quais projetos e SDKs estão em uso, a pergunta restante da auditoria é de política: quais cargas de trabalho podem manter o registro de logs? Resolva isso com o responsável pelos dados e anote a resposta projeto por projeto. Depuração interna e trabalhos de avaliação são candidatos razoáveis. Requisições com dados pessoais de clientes geralmente não são. Como ilustração, imagine uma equipe com dois projetos Gemini: um assistente de suporte que resume tickets com nomes de clientes e dados de conta, e um script interno de avaliação que reexecuta prompts sintéticos para comparar versões de modelos. O projeto de suporte fica com o registro do projeto desativado e store=false no código. O projeto de avaliação pode manter o registro com uma janela de retenção curta, porque as requisições armazenadas ali ajudam a equipe a depurar regressões e montar datasets, e nenhum conteúdo levantaria questões de privacidade.

Fase 2 (Upgrade): migre todos os serviços para um SDK com suporte a store

O store por requisição exige pelo menos as seguintes versões de SDK:

O lançamento 2.33.0 do Python e o lançamento 2.31.0 do JavaScript saíram em 22 de outubro de 2026, e ambos adicionam store ao GenerateContentConfig. Para Java e Go, as versões mínimas listadas são google-genai 1.79.0 e google.golang.org/genai 1.76.0.

Atualize cada serviço e fixe a versão no seu lockfile. Se a versão ficar solta, um rollback ou um ambiente novo pode silenciosamente perder o suporte ao campo.

Fase 3 (Configure): defina primeiro o registro de logs no nível do projeto no AI Studio

A configuração do projeto captura as requisições que alguém esquece de marcar, então defina-a antes de mexer no código.

Para projetos que nunca devem armazenar requisições, desative o registro no nível do projeto no AI Studio, seguindo os passos da documentação de Logs e datasets. Onde o registro continuar ativo para depuração ou avaliações, reduza a retenção do padrão de 55 dias para 7, 14 ou 28 dias, conforme sua política de dados. Os datasets existentes precisam de uma revisão própria, porque alterar a retenção dos logs não os remove: exclua os que ninguém usa e registre todas as exportações em CSV, JSONL ou Google Sheets para que fiquem sob o seu tratamento de dados habitual.

Qual configuração prevalece quando a requisição e o projeto divergem? Sugerimos confirmar a regra de precedência na documentação atual de logs antes de confiar em apenas uma das configurações. Definir as duas tira a maior parte da urgência da pergunta. Se o projeto está desativado e a requisição diz store=false, uma futura mudança de padrão ou uma configuração esquecida não vai reativar o armazenamento silenciosamente.

Fase 3, continuação: opt-out por requisição com store=false

Passo 1: defina store como false no GenerateContentConfig

A configuração é um campo chamado store no GenerateContentConfig. Os trechos em Python e JavaScript seguem o formato descrito nas notas de lançamento. Considere os trechos em Java e Go como não verificados: não confirmamos o método do builder em Java nem o tipo do parâmetro, nem se o campo Store em Go é bool ou *bool, nas versões v1.79.0 e v1.76.0. Consulte as notas de lançamento e a documentação do pacote Go antes de colocá-los em produção.

Python:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="YOUR_MODEL_ID",
    contents="Summarize this support ticket...",
    config=types.GenerateContentConfig(store=False),
)

JavaScript:

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "YOUR_MODEL_ID",
  contents: "Summarize this support ticket...",
  config: { store: false },
});

Java:

// Unverified shape: confirm the builder method and parameter type in 1.79.0.
GenerateContentConfig config = GenerateContentConfig.builder()
    .store(false)
    .build();

GenerateContentResponse response = client.models.generateContent(
    "YOUR_MODEL_ID", "Summarize this support ticket...", config);

Go:

// Unverified shape: confirm whether Store is bool or *bool in v1.76.0.
config := &genai.GenerateContentConfig{
    Store: genai.Ptr(false),
}

resp, err := client.Models.GenerateContent(ctx, "YOUR_MODEL_ID",
    genai.Text("Summarize this support ticket..."), config)

Passo 2: centralize a configuração em um único wrapper de cliente

Os opt-outs costumam falhar justamente no ponto de chamada que ninguém passou pelo wrapper. Encaminhe todas as chamadas ao Gemini por um único helper interno que aplique store=false por padrão e só permita o registro quando quem chama pedir explicitamente e a política do projeto permitir. Assim, a política fica em um único arquivo revisado, e não espalhada por dezenas. Se você já centraliza as chamadas aos provedores atrás de um gateway, essa camada de roteamento é um lugar sensato para a regra. Só confirme que a flag de cada provedor é de fato repassada.

Passo 3: garanta a regra com um teste ou uma regra de lint

Um teste unitário sobre a configuração que seu wrapper gera, ou uma regra de lint que sinalize chamadas diretas de geração sem um valor explícito de store, pega o endpoint que alguém adicionar no próximo trimestre e esquecer de rotear corretamente.

Streaming, batch e outros provedores

O novo padrão é descrito para requisições Generate Content. Antes de presumir que os caminhos de streaming ou batch se comportam da mesma forma, consulte a documentação de Logs e datasets do Google e as notas de lançamento da API Gemini.

Equipes que usam mais de um provedor podem compartilhar uma única política. A Responses API da OpenAI também guarda o estado da aplicação por 30 dias por padrão e aceita store: false.

Fase 4 (Verify): comprove o opt-out com um teste de marcador

O código mostra o que você solicitou. O painel de logs mostra o que foi de fato armazenado. Verificar o segundo leva poucos minutos.

1. Gere uma string de marcador única, como um ID aleatório mais a data de hoje.
2. A partir do projeto em teste, envie uma requisição contendo o marcador com store=false.
3. A partir do mesmo projeto, envie uma requisição de controle com outro marcador e o registro permitido, se sua política permitir armazenar um prompt de teste inofensivo.
4. No painel de logs do AI Studio desse projeto, filtre ou navegue pelos logs recentes por timestamp e procure os dois marcadores.
5. Aprovado: só a requisição de controle aparece. Reprovado: a requisição com store=false aparece; nesse caso, verifique de novo a versão do SDK, o wrapper ou a configuração do projeto.
6. Exclua a entrada de log de controle se sua política exigir.

Se o registro no nível do projeto já estiver desativado

Nesse caso, o controle também não vai aparecer, e não ver nenhum dos marcadores é o resultado esperado. Isso mostra que nada chegou aos logs. Não prova que store=false funciona sozinho, porque a configuração do projeto suprime a requisição de qualquer forma. Para isolar a flag, repita o teste em um projeto de teste dedicado com o registro ativado, usando a mesma versão de SDK e o mesmo wrapper, e apenas prompts inofensivos.

Execute o teste novamente após atualizações de SDK, mudanças no wrapper e a cada novo projeto. Mantenha um registro datado: projeto, versão do SDK, configuração de log do projeto, configuração da requisição e resultado. Quando uma revisão de compliance perguntar o que foi testado e quando, esse registro é a sua resposta. Lembre-se de que o teste cobre apenas o recurso de registro de logs; o monitoramento de abuso e a retenção de grounding ficam fora dele.

Erros comuns ao desativar o armazenamento de requisições do Gemini

Presumir que um SDK mais antigo vai respeitar o store. Abaixo das versões mínimas da Fase 2, o campo não existe no GenerateContentConfig.

Corrigir um projeto e esquecer o próximo. Novos projetos pagos começam com o registro ativado, então inclua a configuração do projeto no seu checklist de criação de projetos.

Tratar o opt-out como retenção zero. Segundo um artigo da DEV Community, o monitoramento de abuso separado do Google ainda guarda prompts e saídas por 55 dias, usados apenas para aplicação de políticas. Desativar o registro não muda isso, e a retenção de grounding também fica fora dessas configurações.

Deixar datasets antigos no lugar. Datasets não expiram, e reduzir a retenção dos logs não os afeta.

Presumir que a flag cobre o Vertex AI. As notas de lançamento do SDK restringem o store à Gemini Developer API. Use o passo sobre o Vertex AI da Fase 1.

Checklist para a sua revisão de armazenamento AUCV

• [ ] Audit: faça o inventário dos projetos pagos da API Gemini e sinalize os criados a partir de 26 de outubro de 2026
• [ ] Audit: registre a linguagem do SDK e a versão instalada por serviço, e identifique as chamadas ao Vertex AI
• [ ] Audit: combine com o responsável pelos dados quais cargas de trabalho podem registrar logs
• [ ] Upgrade: migre para Python 2.33.0, JavaScript 2.31.0, Java 1.79.0 ou Go 1.76.0 ou posteriores, e fixe as versões
• [ ] Configure: desative o registro no nível do projeto onde o armazenamento não é permitido, ou reduza a retenção para 7, 14 ou 28 dias
• [ ] Configure: revise datasets obsoletos, registre suas exportações e exclua-os
• [ ] Configure: defina store=false em um wrapper central, garantido por um teste ou regra de lint
• [ ] Configure: verifique a cobertura de streaming e batch na documentação do Google
• [ ] Verify: execute o teste de marcador e salve um registro datado
• [ ] Verify: documente a retenção de grounding e de monitoramento de abuso nos avisos de privacidade

Ressalvas e questões em aberto

O Google não disse se os projetos existentes passarão ao novo padrão. Só isso já é motivo para definir store=false no código também nos projetos mais antigos. A cobertura de endpoints e as regras de precedência estão nas páginas de logs e de changelog do Google, que podem mudar sem aviso, então confira-as de novo sempre que atualizar os SDKs.

O número de 55 dias do monitoramento de abuso vem de uma publicação da comunidade, e não da documentação do próprio Google, então confirme-o nos termos de uso de dados do Google antes de incluí-lo em um documento de política.

Preços com desconto podem puxar na direção oposta. O Google descreve um Contributor Tier somente por convite, em prévia privada, no qual desenvolvedores elegíveis recebem até 50% de desconto nos custos de tokens em modelos selecionados em troca de permitir que os dados desses modelos sejam usados sob os termos dos Unpaid Services. Isso inverte a proteção padrão para os logs de projetos pagos, então envolva o responsável pela privacidade antes de aderir.

Nada disso torna o registro de logs uma má escolha. Requisições armazenadas ajudam a depurar problemas em produção e a montar datasets de avaliação. Com o registro do provedor desativado, seus próprios traces passam a ser o registro de depuração. Nosso playbook de tracing de GenAI com OpenTelemetry cobre essa configuração, e a mesma decisão do responsável pelos dados deve reger qualquer conteúdo de prompt que você capture ali. O objetivo é uma decisão clara por projeto, já que um opt-out generalizado pode deixar os engenheiros sem os dados de que precisam.

Se um revisor externo ajudar, a Optijara pode conduzir essa revisão de armazenamento com a sua equipe no Gemini e nos outros provedores de IA que você usa.