What decides whether your Gemini API data trains Google's models, and the one exception on the paid tier

The day I moved a small classification pipeline from the free quota to paid, the switch itself took ten minutes. What took the rest of the hour was reading the terms from the top, because I wanted to be able to say plainly that nothing I send from now on feeds model training.

By the end I had learned that this belief was only half right. The tier does change how your data is handled. But the paid side also ships an action that puts your data back under the free-tier terms — and I was about to take it without knowing, by turning on logging.

What follows is the note I wrote for myself that day, checked line by line against the official wording. Three things turned out to matter.

1. The definition of "paid" is different for AI Studio and for the Gemini API. With the same Google account, your browser sessions can count as paid while your API calls do not.
2. Even on the paid tier, any logs you turn into a dataset and share with Google are processed under the free-tier terms. Sharing is opt-in, so it never happens by itself.
3. Where you are, and where your users are, changes the premises of the first two.

One caveat before we start: this is a reading of the terms, not legal advice. When a contractual decision is on the line, go to the original text and to someone qualified to interpret it.

Where "paid" actually begins

This was the first place I got it wrong. The Gemini API Additional Terms define a paid service separately for AI Studio and for the API.

Read side by side, the AI Studio condition is the looser one. Access to a billing-enabled project is enough, so your free experimentation in that window is still handled as a paid service.

The API side is decided by the key you called with. In solo projects it is easy to spin up a throwaway project for experiments and then forget it exists. I had exactly one such key sitting around.

That difference carries straight through to how your content is treated.

The line about human reviewers is the easy one to skim past. Google does say it disconnects the data from your Google Account, API key, and Cloud project before reviewers see it — but what gets disconnected is the linkage, not the text itself. If unreleased App Store or Google Play copy, real in-app data, or support messages are flowing through free quota, this is a good moment to stop and check.

The logs only paid projects can keep

Projects with billing enabled can retain their own logs covering the full path from request to response. This is not on by default; a project owner opts in.

The default retention is up to 55 days, after which logs are automatically marked for deletion. In AI Studio you can change the window to 7, 14, 28, or 55 days.

So far this is all contained inside your own project. Those logs are private to you, and they are separate from the logs Google holds purely for abuse monitoring.

It is worth choosing the retention window on purpose rather than leaving the default. Fifty-five days is generous if you are debugging a slow-moving quality problem and want to look back across several releases. It is longer than you need if the logs carry customer text and you only ever review the last week. The setting costs nothing to change, and shortening it is the cheapest reduction in exposure available on this surface. If you want to see how these settings interact with each other, the note on what else stops when you turn AI Studio logging off covers an adjacent surprise.

Sharing a dataset reverses the protection

Here is the part I nearly missed.

When you pick logs you care about and turn them into a dataset, that dataset has no retention period. It steps outside the 55-day clock. On its own that is reasonable — the point of a dataset is to keep evaluation material around.

The consequence comes next. If you share that dataset with Google, the requests and responses inside it are processed under the terms for unpaid services. That means they may be used to develop and improve Google products, services, and machine learning technologies, including improving and training models, and they may be read by human reviewers.

In other words, the "not used for product improvement" state you bought by moving to paid is reversed for exactly the data you shared. The documentation says it directly, in bold: do not contribute logs containing sensitive, confidential, or proprietary information obtained through the paid service.

What matters is that this is opt-in. Nothing happens unless you choose it. But if your understanding stops at "we're on paid now, so we're fine," nothing stops your hand from clicking share either. That was precisely where I stood.

Your region changes the premises

One more layer sits on top.

If you are in the European Economic Area, Switzerland, or the United Kingdom, the paid-service data terms apply to all services, including AI Studio and unpaid quota in the Gemini API. Free usage lands on the protected side.

On top of that, the terms state that you may use only paid services when making your application available to users in those regions. Even a solo project is affected the moment the app is published worldwide.

This one caught my attention because store distribution defaults to broad availability, and most of us shipping as an indie developer never narrow it. Unless you have deliberately restricted the country list, your app is offered in the UK and across the EEA, which means the free quota is not a valid backend for it. If you built a prototype on an unpaid key and shipped it without revisiting that decision, the region rule applies even though nothing in the API responses ever complained.

Separately, if you use grounding with Google Search or Google Maps, prompts, any context you supply, and output are stored for thirty days and used for debugging and testing the systems behind grounding. That storage happens on the paid tier as well. For the cost side of these choices, the walkthrough of how Gemini API pricing and free quota fit together goes deeper than I will here.

Decide it in your own code, before you send

The awkward part is that nothing in the response tells you which tier you are on. You get token counts and a model name. You do not get the handling category.

Asking code to guess something it cannot see produces bugs. So I stopped guessing and made the caller declare it.

from dataclasses import dataclass
 
SENSITIVITY_ORDER = {"public": 0, "internal": 1, "confidential": 2}
 
 
class SendBlocked(Exception):
    pass
 
 
@dataclass(frozen=True)
class CallPolicy:
    tier: str             # "unpaid" / "paid" — declared by the caller, never inferred
    share_datasets: bool  # is dataset sharing turned on for this project?
 
    def max_allowed(self) -> str:
        if self.tier == "unpaid":
            return "public"
        if self.share_datasets:
            return "public"
        return "confidential"
 
 
def guard(text: str, sensitivity: str, policy: CallPolicy) -> str:
    if sensitivity not in SENSITIVITY_ORDER:
        raise ValueError(f"unknown sensitivity: {sensitivity}")
    limit = policy.max_allowed()
    if SENSITIVITY_ORDER[sensitivity] > SENSITIVITY_ORDER[limit]:
        raise SendBlocked(
            f"tier={policy.tier} share_datasets={policy.share_datasets} "
            f"cannot carry {sensitivity} (limit {limit})"
        )
    return text

Folding share_datasets into the decision is the whole point of this article expressed as code. Paid tier or not, if sharing is on, your ceiling drops back to where the free tier sits.

Running four combinations gives this:

BLOCKED confidential tier=unpaid share=False -> cannot carry confidential (limit public)
OK      confidential tier=paid   share=False
BLOCKED confidential tier=paid   share=True  -> cannot carry confidential (limit public)
OK      public       tier=unpaid share=False

The gap between lines two and three is one settings toggle. It looks small in the console; it moves the boundary of what you are allowed to send.

When sharing does come up, counting at the folder level first makes the decision faster.

import json
import pathlib
from collections import Counter
 
RECORDS = pathlib.Path("records")
 
 
def tally(directory: pathlib.Path) -> Counter:
    counts = Counter()
    for path in sorted(directory.glob("*.json")):
        record = json.loads(path.read_text())
        counts[record.get("sensitivity", "unlabeled")] += 1
    return counts
 
 
counts = tally(RECORDS)
total = sum(counts.values())
for key in ("public", "internal", "confidential", "unlabeled"):
    if counts[key]:
        print(f"{key:<13} {counts[key]:>3} / {total}")
blocking = counts["internal"] + counts["confidential"] + counts["unlabeled"]
print("verdict:", "safe to share as-is" if blocking == 0 else f"{blocking} records need sorting first")

Against twenty local records:

public         12 / 20
internal        5 / 20
confidential    3 / 20
---
verdict: 8 records need sorting first

Counting unlabeled on the blocking side is deliberate. An unlabeled record is not safe; it is undecided.

To be honest about the limits: all this guarantees is that your declaration and your intent agree. If a key marked tier="paid" actually belongs to a different project, the code has no way to notice. Only a person checking the key-to-project mapping can catch that.

If you do one thing today

Check which Cloud project your current API key belongs to. Whether billing is attached to that project is what decides everything above. When I checked mine, that was the moment I found the experiment key still sitting on free quota.

Reading terms carefully is tedious work. If any of this saves you from spending the same hour, I am glad. Thank you for reading.