La API de Gemini guarda las solicitudes por defecto: cómo usar store=false por solicitud y por proyecto

Contexto: qué cambió en los proyectos de pago nuevos de Gemini

Desde el 26 de octubre de 2026, los proyectos de pago nuevos de la API de Gemini almacenan por defecto los prompts y las respuestas de Generate Content. Los proyectos creados antes de esa fecha mantienen el almacenamiento desactivado. Dos proyectos de la misma organización, con el mismo código, pueden comportarse de forma distinta solo por la fecha en que se crearon.

Nada en tu código ni en tus registros de errores indica que el registro esté activado, y por eso pasa desapercibido. Si esos prompts contienen datos de clientes, tu responsable de protección de datos querrá saberlo, idealmente por ti, junto con una explicación honesta de lo que todavía se desconoce. La nota de la versión no explica por qué Google cambió el valor por defecto, no define el corte exacto para los proyectos nuevos y no indica si el cambio se extenderá más adelante a los proyectos existentes. Planifica en función de la división actual y asume que podría cambiar.

Aquí nadie ha filtrado nada; simplemente cambió un valor por defecto. El registro es una función documentada con usos reales para depuración y evaluación, así que el trabajo consiste en saber qué proyectos lo tienen activado y por qué.

Qué guarda Google y durante cuánto tiempo

El periodo de retención por defecto de los registros es de 55 días, tras los cuales caducan y se marcan para su eliminación. Los propietarios del proyecto pueden acortar ese plazo a 7, 14 o 28 días.

Los conjuntos de datos (datasets) requieren atención aparte, porque siguen reglas distintas. Los registros guardados en un dataset no tienen periodo de retención y permanecen hasta que alguien los elimina. Los datasets se pueden exportar como CSV, JSONL o a Google Sheets, lo que los hace útiles para tareas de evaluación. Esas exportaciones implican que pueden acabar existiendo copias fuera del proyecto si nadie les hace seguimiento.

Por defecto, los prompts y las respuestas de los registros de proyectos con facturación habilitada no se usan para mejorar ni desarrollar los productos de Google. El Contributor Tier, que se trata en las advertencias más abajo, es la excepción a vigilar.

Algunos modelos y entradas no admiten registro en absoluto. El resumen de BaristaLabs sobre la guía de Google enumera los modelos Imagen y Veo, los modelos de embeddings de Gemini, el modelo Gemini Robotics, las entradas que contienen vídeos, GIF o PDF, y los agentes en vista previa pública.

La fundamentación (grounding) sigue una vía de retención completamente distinta. Los datos de la fundamentación con la Búsqueda de Google y con Google Maps se conservan durante 30 días, y esa retención no se puede desactivar.

Fase 1 (Audit): inventariar proyectos, SDK y responsables de datos

Empieza con una lista de todos los proyectos de pago de la API de Gemini que tiene tu organización, con su fecha de creación. Trata cualquier proyecto creado a partir del 26 de octubre de 2026 como si almacenara solicitudes hasta que confirmes lo contrario.

Para cada servicio de esa lista, anota el lenguaje del SDK y la versión instalada en el entorno en ejecución, ya que un README o un archivo de requisitos antiguo puede ir por detrás de lo que realmente está desplegado. Solo puedes fijar store en una solicitud si el SDK lo admite, y las versiones mínimas varían según el lenguaje.

Los servicios que también llaman a Vertex AI merecen una línea aparte en el inventario. Tanto las notas de versión de Python como las de JavaScript etiquetan la opción store como "Gemini Developer API only". Si algunos servicios llaman a Vertex AI mediante el mismo SDK, no des por hecho que esta guía los cubre. Revisa la documentación de gobernanza de datos de Vertex AI de Google Cloud para esos servicios y registra esa decisión junto a tus proyectos de la Gemini Developer API.

Una vez que sepas qué proyectos y SDK están en uso, la pregunta de auditoría que queda es de política: ¿qué cargas de trabajo pueden seguir registrando? Resuélvela con tu responsable de datos y deja la respuesta por escrito, proyecto por proyecto. La depuración interna y el trabajo de evaluación son candidatos razonables. Las solicitudes que contienen datos personales de clientes, por lo general, no lo son. A modo de ejemplo, imagina un equipo con dos proyectos de Gemini: un asistente de soporte que resume tickets con nombres de clientes y datos de cuenta, y un script interno de evaluación que reproduce prompts sintéticos para comparar versiones del modelo. El proyecto de soporte tiene el registro del proyecto desactivado y store=false en el código. El proyecto de evaluación puede mantener el registro con un plazo de retención corto, porque allí las solicitudes almacenadas ayudan al equipo a depurar regresiones y crear datasets, y ninguno de esos contenidos plantearía un problema de privacidad.

Fase 2 (Upgrade): pasar cada servicio a un SDK que admita store

El parámetro store por solicitud requiere, como mínimo, las siguientes versiones del SDK:

La versión 2.33.0 de Python y la versión 2.31.0 de JavaScript se publicaron el 22 de octubre de 2026, y ambas añaden store a GenerateContentConfig. Para Java y Go, los mínimos indicados son google-genai 1.79.0 y google.golang.org/genai 1.76.0.

Actualiza cada servicio y fija la versión en tu lockfile. Si la versión no está fijada, una reversión o un entorno nuevo podría perder sin avisar la compatibilidad con el campo.

Fase 3 (Configure): configurar primero el registro a nivel de proyecto en AI Studio

La configuración del proyecto atrapa las solicitudes que alguien olvida marcar, así que fíjala antes de tocar el código.

En los proyectos que nunca deban almacenar solicitudes, desactiva el registro a nivel de proyecto en AI Studio siguiendo los pasos de la documentación de registros y datasets. Donde el registro siga activado para depuración o evaluaciones, acorta la retención de los 55 días por defecto a 7, 14 o 28 días, según lo que encaje con tu política de datos. Los datasets existentes necesitan su propia revisión, porque cambiar la retención de los registros no los limpia: elimina los que nadie necesita y registra cualquier exportación a CSV, JSONL o Google Sheets para que quede sujeta a tu gestión de datos habitual.

¿Qué configuración prevalece cuando la solicitud y el proyecto no coinciden? Te sugerimos confirmar la regla de precedencia en la documentación actual de registros antes de confiar en una sola de las dos configuraciones. Configurar ambas le quita casi toda la urgencia a la pregunta. Si el proyecto lo tiene desactivado y la solicitud indica store=false, un cambio futuro del valor por defecto o una configuración olvidada no volverán a activar el almacenamiento sin que nadie lo note.

Fase 3, continuación: excluir cada solicitud con store=false

Paso 1: fijar store en false en GenerateContentConfig

La configuración es un campo llamado store en GenerateContentConfig. Los fragmentos de Python y JavaScript siguen la forma descrita en las notas de versión. Considera los fragmentos de Java y Go como no verificados: no hemos confirmado el método del builder de Java ni su tipo de parámetro, ni si el campo Store de Go es un bool o un *bool, en las versiones v1.79.0 y v1.76.0. Revisa las notas de versión y la documentación del paquete de Go antes de desplegarlos.

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)

Paso 2: centralizar la configuración en un único wrapper de cliente

Las exclusiones suelen fallar en esa única llamada que nadie pasó por el wrapper. Haz que todas las llamadas a Gemini pasen por un único helper interno que aplique store=false por defecto y que solo permita el registro cuando quien llama lo pida explícitamente y la política del proyecto lo autorice. Así la política vive en un único archivo revisado en lugar de en decenas. Si ya centralizas las llamadas a proveedores detrás de un gateway, esa capa de enrutamiento es un lugar sensato para la regla. Solo confirma que el indicador de cada proveedor se transmite realmente.

Paso 3: hacerlo cumplir con una prueba o una regla de lint

Una prueba unitaria sobre la configuración que genera tu wrapper, o una regla de lint que señale las llamadas directas de generación sin un valor explícito de store, detecta el endpoint que alguien añade el próximo trimestre y olvida enrutar correctamente.

Streaming, procesamiento por lotes y otros proveedores

El nuevo valor por defecto se describe para las solicitudes de Generate Content. Antes de suponer que las rutas de streaming o de procesamiento por lotes se comportan igual, consulta la documentación de registros y datasets de Google y las notas de versión de la API de Gemini.

Los equipos que usan más de un proveedor pueden compartir una única política. La Responses API de OpenAI también conserva el estado de la aplicación durante 30 días por defecto y acepta store: false.

Fase 4 (Verify): demostrar la exclusión con una prueba de marcador

El código muestra lo que solicitaste. El panel de registros muestra lo que realmente se almacenó. Comprobar lo segundo lleva unos minutos.

1. Genera una cadena de marcador única, por ejemplo un ID aleatorio más la fecha de hoy.
2. Desde el proyecto que estás probando, envía una solicitud que contenga el marcador con store=false.
3. Desde el mismo proyecto, envía una solicitud de control con otro marcador y el registro permitido, si tu política permite almacenar un prompt de prueba inofensivo.
4. En el panel de registros de AI Studio de ese proyecto, filtra o recorre los registros recientes por marca de tiempo y busca ambos marcadores.
5. Correcto: solo aparece la solicitud de control. Fallo: aparece la solicitud con store=false, así que vuelve a revisar la versión del SDK, el wrapper o la configuración del proyecto.
6. Elimina la entrada de registro de control si tu política lo exige.

Si el registro a nivel de proyecto ya está desactivado

En ese caso tampoco aparecerá la solicitud de control, y no ver ninguno de los dos marcadores es el resultado esperado. Eso demuestra que nada llegó a los registros. No demuestra que store=false funcione por sí solo, porque la configuración del proyecto suprime la solicitud en cualquier caso. Para aislar el indicador, repite la prueba desde un proyecto de pruebas dedicado con el registro activado, usando la misma versión del SDK y el mismo wrapper, y solo prompts inofensivos.

Repite la prueba después de actualizar el SDK, de cambiar el wrapper y con cada proyecto nuevo. Guarda un registro fechado: proyecto, versión del SDK, configuración de registro del proyecto, configuración de la solicitud y resultado. Cuando una revisión de cumplimiento pregunte qué se probó y cuándo, ese registro es tu respuesta. Ten en cuenta que la prueba solo cubre la función de registro; la supervisión de abusos y la retención de la fundamentación quedan fuera de ella.

Errores comunes al desactivar el almacenamiento de solicitudes de Gemini

Suponer que un SDK antiguo respetará store. Por debajo de los mínimos de la Fase 2, el campo no está disponible en GenerateContentConfig.

Corregir un proyecto y olvidar el siguiente. Los proyectos de pago nuevos empiezan con el registro activado, así que incluye la configuración del proyecto en tu lista de comprobación de creación de proyectos.

Tratar la exclusión como retención cero. Según un artículo de DEV Community, la supervisión de abusos de Google, que es independiente, sigue conservando prompts y resultados durante 55 días, usados solo para hacer cumplir las políticas. Desactivar el registro no cambia eso, y la retención de la fundamentación también queda fuera de estas configuraciones.

Dejar datasets antiguos en su sitio. Los datasets no caducan, y acortar la retención de los registros no les afecta.

Suponer que el indicador cubre Vertex AI. Las notas de versión del SDK limitan store a la Gemini Developer API. Aplica el paso de Vertex AI de la Fase 1.

Lista de comprobación para tu revisión de almacenamiento AUCV

• [ ] Audit: inventariar los proyectos de pago de la API de Gemini y marcar los creados a partir del 26 de octubre de 2026
• [ ] Audit: registrar el lenguaje del SDK y la versión instalada por servicio, e identificar las llamadas a Vertex AI
• [ ] Audit: acordar con el responsable de datos qué cargas de trabajo pueden registrar
• [ ] Upgrade: pasar a Python 2.33.0, JavaScript 2.31.0, Java 1.79.0 o Go 1.76.0 o posteriores, y fijar las versiones
• [ ] Configure: desactivar el registro a nivel de proyecto donde no se permita el almacenamiento, o acortar la retención a 7, 14 o 28 días
• [ ] Configure: revisar los datasets obsoletos, registrar sus exportaciones y eliminarlos
• [ ] Configure: fijar store=false en un wrapper central, reforzado con una prueba o una regla de lint
• [ ] Configure: comprobar la cobertura de streaming y procesamiento por lotes en la documentación de Google
• [ ] Verify: ejecutar la prueba de marcador y guardar un registro fechado
• [ ] Verify: documentar la retención de la fundamentación y de la supervisión de abusos en los avisos de privacidad

Advertencias y preguntas abiertas

Google no ha dicho si los proyectos existentes pasarán al nuevo valor por defecto. Eso por sí solo ya es motivo para fijar store=false en el código también en los proyectos antiguos. La cobertura de endpoints y las reglas de precedencia están en las páginas de registros y del changelog de Google, que pueden cambiar sin previo aviso, así que vuelve a revisarlas cada vez que actualices los SDK.

La cifra de 55 días de supervisión de abusos procede de una publicación de la comunidad y no de la documentación de Google, así que confírmala con las condiciones de uso de datos de Google antes de incluirla en un documento de política.

Los precios con descuento pueden empujar en la dirección contraria. Google describe un Contributor Tier solo por invitación, en vista previa privada, en el que los desarrolladores que cumplen los requisitos reciben hasta un 50% de descuento en el coste de los tokens en determinados modelos a cambio de permitir que los datos de esos modelos se usen según las condiciones de los Unpaid Services. Eso anula la protección por defecto de los registros de los proyectos de pago, así que implica al responsable de privacidad antes de apuntarte.

Nada de esto convierte el registro en una mala opción. Las solicitudes almacenadas ayudan a depurar incidencias en producción y a crear datasets de evaluación. Con el registro del proveedor desactivado, tus propias trazas se convierten en el registro de depuración. Nuestra guía de trazabilidad GenAI con OpenTelemetry cubre esa configuración, y la misma decisión del responsable de datos debería regir cualquier contenido de prompts que captures allí. El objetivo es una decisión clara por proyecto, ya que una exclusión general puede dejar a los ingenieros sin los datos que necesitan.

Si te resulta útil una revisión externa, Optijara puede llevar a cabo esta revisión de almacenamiento con tu equipo en Gemini y en los demás proveedores de IA que utilices.